Website migration SEO: what each move risks and when to hire

What each kind of move changes for Google

The risk a migration poses to organic search traffic depends on what the move changes for Google: the URLs, the page templates, the domain or the platform. A host move changes none of them, while a platform switch changes the platform and the templates, plus any URL whose pattern the new platform cannot reproduce.

Google’s documentation draws the same line. Its hosting guide covers infrastructure moves, where “A change in hosting infrastructure means switching hosting providers or moving to a content distribution network (CDN)”¹. Every move that changes a URL, from an HTTPS switch to a new domain, falls under its separate guide to site moves with URL changes².

Changes stacked into one launch add up. When a site move is combined with a redesign of the content and URL structure, Google’s Change of Address help says you “will probably see some traffic loss”, because Google may have to reassess each page³.

Every row except the host move needs a list of the URLs that matter, if only to check that each one reaches its new address after launch. Google notes that the simplest moves can be handled by one wildcard redirect, such as a domain change that keeps every path, while “In more complex site moves, you will need to generate a list of old URLs and map them to their new destinations”².

Who builds the new site does not change that work. When your developer or agency handles the build, you can still have the plan done for you and leave the build with them.

Where migrations lose search traffic

The losses a move can cause start at the old URLs. Googlebot crawls an old address and can find a 404, a redirect to an unrelated page, a page stripped of the content that ranked, or a crawl block carried over from staging. Redirects themselves are not the problem: Google’s site-move guide states that “301 and other permanent redirects don’t cause a loss in PageRank”².

Sending many old URLs to the home page is one of those failures: Google’s guide says it “can confuse users and might be treated as a soft 404 error”².

Public reports add a second view: which kind of move came before the drop. In 105 forum threads where someone reported a drop in Google traffic, rankings or indexing after changing the site, collected on 8 October 2026, a domain change came before the drop in 38, more than any other change, and platform switches came next, as the chart at the top shows.

The counts describe what people posted about, not how often each kind of move goes wrong; moves that went smoothly leave no thread to count.

The threads also show how a drop reads from the owner’s side. One site that moved to a new domain around mid-July 2026, with 301 redirects and a Change of Address in place, still reported almost three months later that “the new domain has not recovered the previous ranking”⁴. A shop that changed its domain and its platform in one launch wrote that “the site has lost nearly all organic visibility”⁵.

Changes that keep the domain show up too. After a WordPress redesign in which the person rebuilding the site “created new pages and deleted old ones”, the business found that its site “doesn’t appear anywhere in Google serps for a search on their own company name”⁶.

A host move that keeps every URL is the lowest-risk row in the table, but it still carries risk. One WordPress site that moved to a new server with the same domain, CMS and URL structure reported “0 pages in Google for 2+ months”⁷. Google’s hosting guide tells owners to check their firewall and denial-of-service settings and “Make sure it does not block Googlebot’s ability to reach the DNS or the hosting provider’s servers”¹.

The SEO work a migration needs, step by step

The SEO side of any migration that changes URLs comes down to six jobs, whoever does them. Every job except the mapping needs at least one of three things: Search Console data from before the change, a crawler, or access to the server.

1. List every URL that matters. Before the old site changes, collect each URL with Google Search Console clicks or impressions across the full date range Search Console keeps, backlinks, an index entry or a sitemap entry. Google’s guide says to “Start with your important URLs” and to include embedded files: “videos, images, JavaScript, and CSS files”². Needs: Search Console access, a backlink source and a crawler.
2. Map each URL to one page. Each URL keeps its path or gets one 301 redirect to its closest page on the new site, and repeating patterns become rules rather than rows. A page retired on purpose should “correctly return an HTTP 404 or 410 error response code on the new site”². Needs: the URL inventory, the new site’s URL plan and someone who signs off each mapping.
3. Compare each old page with its new version. A parity check sets the title, H1, body text, canonical tag, structured data and internal links of each important page against the same page on staging, while the templates can still change. Needs: access to the staging site and a crawler.
4. Check staging before launch. The staging site stays closed to search engines, and a staging crawl checks every row of the redirect map before launch day. Needs: a crawler that can reach the staging site.
5. Switch the redirects on at launch. Google recommends permanent server-side redirects, and its redirects guide notes that “Setting up server-side redirects requires access to the server configuration files (for example, the .htaccess file on Apache) or setting the redirect headers with server-side scripts (for example, PHP)”⁸. Launch QA then checks robots.txt, noindex rules, canonical tags and the new sitemap, plus the Change of Address on a domain change. Needs: server or hosting access, and the old and new sites verified in Search Console.
6. Crawl the old URLs after launch, and keep the redirects. Repeat crawls after launch check that every URL on the inventory still reaches its mapped page, and Google’s site-move guide advises keeping the redirects for at least a year². Needs: the crawler and the URL inventory from the first job.

Jobs 1, 3, 4 and 6 need a crawler, job 1 needs Search Console data from before the change, and job 5 needs access to the server. A team that has all three can run every job itself; a team missing one has found its hand-over point.

The site migration checklist breaks the six jobs into individual checks, including the steps that are specific to WordPress.

When to start the SEO planning

Start the SEO planning when the relaunch is agreed, before any design is approved. The inventory is taken from the live site, and every redirect the map adds is a path the new templates did not keep, so the earlier the map exists, the more old paths survive.

1. When the relaunch is agreed: decide which changes launch together. Google’s guide advises: “Plan your changes to your site one after the other, not everything at the same time”². In its example, a new domain, a new CMS and a new layout are done one at a time, starting with the domain.
2. Before the design is approved: build the URL inventory from the live site and its Search Console data.
3. Before the templates are built: sign off the redirect map, including any URL patterns that change, so the templates are built around the paths you keep.
4. On staging: run the parity check and the staging crawl while a fix is still a template change, not a repair after launch.
5. When you choose the launch window: Google’s guide says that “If your traffic is seasonal or dips on certain weekdays, it makes sense to move your site during the recurring traffic dips”².
6. After launch: keep the redirects, the crawls and, after a rebrand, the old domain. The extra steps on the old domain are set out in the domain-change plan.

Large sites can test the move first. Google suggests “initially moving just a piece of the site to test any effects on traffic and search indexing” when that is technically possible, while for small or medium sites it recommends moving all URLs at the same time².

What sets the size of the work, and Google’s own timeline

The cost of the SEO work follows the size of the URL inventory, the number of templates, the platforms involved and who builds the site. Market rates for each kind of provider are collected in published migration prices by provider type.

Google’s side runs on its own clock. Its site-move guide explains that “To consider a site move complete, Googlebot will have to visit every URL on your old and new site at least once”, and that “The move takes place on a per-URL basis”². By the same guide’s rule of thumb, larger sites take longer than small ones, even when the two launch on one date.

For domain changes, Search Engine Journal’s January 2025 study of 892 domain migrations, measured with third-party traffic estimates, found that on average it took 523 days for the new domain to show the same level of organic traffic as the old one, and not every domain in the sample caught up⁹. The study covers domain changes only, not redesigns or platform switches on the same domain.

Who should run the SEO work: you, your host, your developer or a specialist

Who should run the SEO side depends on two things: how much the move changes, and whether anyone on your side has Search Console data from before the change, a crawler and access to the server. Google’s own guide says that “Site migrations can be overwhelming and complicated, so there are lots of takes on how to proceed”².

If organic search brings in inquiries or sales, every URL on the inventory is a route to revenue, and a missing redirect closes that route on launch day. In that case, bring a specialist in as soon as the relaunch is agreed and before the templates are built, with the site URL, what is changing and the planned launch date.