The SEO Migration Checklist: The Sequence That Stops a Replatform Losing Traffic

A meaningful share of the traffic collapses I am asked to diagnose are not penalties at all. They are migrations. Somebody replatformed, changed a URL structure, moved to a new domain or consolidated three sites into one, and the drop arrived a fortnight later looking exactly like an algorithmic demotion. By the time I see it, the team has usually spent a month auditing backlinks.

The good news is that migration damage is the most preventable and most reversible category of traffic loss, because the cause is mechanical and the evidence is still on the server. The bad news is that the window for a clean fix closes, and the single most common irreversible mistake is throwing away the old URL inventory.

Before anything: capture the current state

If you do nothing else on this page, do this, and do it before a single file moves. You cannot map URLs you no longer have a record of, and a decommissioned CMS takes its URL list with it.

1. Export every URL from your submitted sitemaps.
2. Export server logs and analytics for every URL with traffic, going back at least twelve months so seasonal pages are included.
3. Export the Links report from Search Console, so you know which URLs carry external authority.
4. Export the full URL list from the CMS, including embedded assets: images, video, CSS and JavaScript.
5. Crawl the live site and store the crawl. This is your only record of the old internal link graph.
6. Record current rankings and Search Console performance as a baseline. Without it you cannot prove recovery or quantify loss.

Google’s site move guidance names the same sources for compiling old URLs: sitemaps, server logs and analytics for high-traffic pages, the Links feature in Search Console, and the CMS. The reason to gather them in parallel rather than picking one is that each misses different pages, and the ones only server logs know about are frequently the ones with links.

Phase 1: prepare and test the new site

1. Build and populate the new site, including hosted images, video and downloads.
2. Obtain and configure TLS certificates if the scheme is changing.
3. Configure robots.txt for the new site, and check it is not the staging version.
4. Confirm deleted content returns 404 or 410 rather than a soft 404 or a redirect to the homepage.
5. Verify both the old and the new site in Search Console, including every variant: www and non-www, HTTP and HTTPS.
6. Re-upload any disavow file to the new property. Disavow files do not follow you, and this is forgotten almost every time.
7. If the new domain was bought rather than created, check it for existing manual actions and URL removals before you commit to it.

Items six and seven deserve emphasis because they are both invisible failures. A migration onto a domain with an inherited manual action imports a penalty you did not know you were buying, and no amount of redirect hygiene will save it.

Phase 2: build the URL map

One row per old URL, one destination each, no gaps. This document is the migration. Everything else is execution.

The homepage row is the expensive one. Google advises against redirecting multiple old URLs to one irrelevant destination, and a mass redirect to the homepage is exactly that. It tells Google the homepage is the best answer to several thousand different queries, which it is not, and the signals evaporate. Serve 410 for what is gone. A clean 410 loses one page. A lazy homepage redirect degrades the whole domain.

Phase 3: execute

1. Use permanent redirects, 301 or 308, wherever possible.
2. Keep chains short. Google supports up to ten hops but advises no more than three, and every hop is a request spent on nothing.
3. Update canonical annotations on the new site so they reference the new URLs, not the old ones.
4. Remove every noindex from the new site. A staging noindex surviving launch is the single fastest way to lose a site entirely.
5. Update internal links to point directly at final destinations rather than relying on the redirects.
6. Submit the new sitemap in Search Console and remove the old one once the new is accepted.
7. File a Change of Address in Search Console for a domain or subdomain move, for every verified variant.
8. Test with the URL Inspection tool and by crawling the old URL list. Every row of the map should resolve in one hop to a 200.

On timing: for small and medium sites Google recommends moving all URLs simultaneously rather than one section at a time. Phased migrations feel safer and are usually worse, because they double the period during which two versions of the site compete and they make attribution impossible when something goes wrong.

Phase 4: monitor, and do not panic

A temporary dip is normal. Google states that for medium-sized websites it can take a few weeks or more for it to gradually start showing the new URLs instead of the old ones, and longer for larger sites. Knowing that in advance is the difference between waiting and making things worse.

• Watch old sitemap indexed counts fall and new ones rise. Both moving together is the healthy signature.
• Watch the Page Indexing report for crawl errors and for new exclusion categories appearing.
• Watch server logs for 404s on old URLs, which are rows your map missed.
• Report impressions and average position alongside clicks, so a normal transfer is not misread as a collapse.

Keep the redirects. Google’s wording is to keep them for as long as possible, generally at least one year, so that it can transfer all signals to the new URLs including recrawling and reassigning links. Removing them at six months because the old server was costing money is a self-inflicted wound I have now seen more than once.

The seven things teams forget

If the migration has already gone wrong

Do not start rebuilding content. Crawl the old URL list first and count how many rows fail to resolve in one hop to a relevant 200. That number is your diagnosis, and it is usually large enough to explain the entire drop on its own. Fix the map, repoint the chains, restore the 410s that were turned into homepage redirects, and then wait, changing nothing else until the data settles.

Above all, establish that it is a migration problem before treating it as a penalty. A drop that begins on the day of a replatform and shows no alignment with any published update is a migration, and the manual actions report will be empty because nothing was violated. Separating those two cases is the whole point of manual action penalty or algorithmic demotion, and the wider diagnostic order is in my pillar on Google penalty recovery.

Two related pieces worth reading alongside this one. The indexability checks that catch a surviving staging noindex are Pass A of my SEO audit checklist, and if the new platform generates far more URLs than the old one did, which faceted ecommerce replatforms reliably do, the sizing arithmetic is in crawl budget.

Royking Niba is an SEO and GEO consultant specialising in penalty and spam-update recovery, with more than 8 million organic visits recovered for clients. Google’s site move requirements quoted here were checked against its published documentation on 22 September 2026.