How to Handle Website Migrations Without Losing Rankings

Sites lose search traffic in a migration for reasons that are almost always known in advance: URLs that changed without a redirect, redirects that chain, a staging directive that shipped to production, or content that quietly got shorter. Everything else — a ranking wobble for two weeks, a dip in crawl rate — is normal and recovers.

“Migration” covers five different jobs, and the risk is not the same for each.

A single project often combines three of them. Where you can, separate them in time: move the platform first, keep the URLs; change the URLs a month later when the platform is stable. Debugging one variable is possible, debugging three at once is guesswork.

Inventory before anything else

You cannot preserve what you have not written down. Four exports, all taken in the same week:

A full crawl of the current site. Every URL with status code, title, meta description, canonical, word count and inbound internal link count. This becomes the “before” that every later check compares against.

Search Console performance, sixteen months, by page. The maximum retention window. Sort by clicks and by impressions separately — pages with impressions and no clicks still hold rankings you do not want to throw away.

Top landing pages from analytics, twelve months. Catches pages that earn traffic from sources other than search: newsletters, forums, a link in someone’s documentation.

Backlinks by target URL. Any tool you have. The list of URLs that other people link to is the list you must never break, even if the pages themselves are retired.

Merge the four into one sheet keyed by URL. That sheet is the migration; the rest is execution.

Building a redirect map that holds

Four rules cover almost every case.

One old URL, one new URL, one hop. A 301 to a 301 to a final page wastes crawl budget and loses signal at each hop. Rebuild chains as direct rules before launch, then verify by requesting every old URL and checking that the first response is the final destination.

Redirect to the closest equivalent, never to the homepage. Mass redirects to the root are treated as soft 404s. If a page has no successor, the honest answer is a 410, or a 404 with a useful page behind it.

Keep the pattern rules small and the exceptions explicit. A regex that covers 90% of a section is fine; the remaining 10% belong in a literal list. Clever single-rule solutions are where the two-hop chains come from.

Test the map against the inventory, not against a sample. Run every URL from the crawl and from the Search Console export through the staging rules. Anything that returns 404, 302 or a chain gets fixed before launch, not after.

Keep 301s in place for at least a year. Search engines stop needing them long before your visitors’ bookmarks do.

The things that ship by accident

Five directives cause most post-launch emergencies, and all five live on staging for good reasons:

• Disallow: / in robots.txt, copied to production with the rest of the config.
• noindex in a meta tag or an X-Robots-Tag header applied site-wide by the staging environment.
• Canonical tags pointing at the staging hostname, which survive a database migration because they are stored in content.
• Basic authentication left on a subdirectory, invisible to a logged-in browser session.
• Internal links, images and structured data still referencing the old host — the site works, and every one of those requests is a redirect.

A grep for the staging hostname across the database and template files takes two minutes and finds four of the five.

Launch sequence

An order that has survived a lot of moves:

Lower the DNS TTL to five minutes, at least a day ahead. This is what makes a rollback fast.

Deploy with redirects active but the site closed to crawling for as long as it takes to verify. Minutes, not hours.

Verify from outside your network: homepage, a template page of each type, the redirect map spot-check, robots.txt, the sitemap, and one URL from every top-twenty entry in the Search Console export.

Open crawling and submit the new sitemap. Keep a sitemap of the old URLs available for a few weeks as well — it accelerates discovery of the redirects.

For a domain move, use the change of address tool in Search Console. It requires both properties verified and the redirects already live.

Do not change content, titles or internal linking in the same week. If rankings move, you want one candidate explanation.

The six weeks after

Expect a dip. A structural move usually shows a fortnight of instability, and full recovery in four to eight weeks; a domain move can take longer. What matters is the shape, not the first three days.

Crawl stats. A rise in requests is healthy — that is discovery. A collapse means something is blocking access.

Index coverage. Watch “crawled, currently not indexed” and “discovered, currently not indexed” for the new URLs, and watch the old ones move to “page with redirect”. That transition is the migration completing.

404 log. Real 404s from real referrers, not from bots probing WordPress paths. Anything with an inbound link goes into the redirect map.

Rankings by cohort, not by average. Split the tracked set into pages whose URL changed and pages whose URL did not. If both cohorts moved, the cause is the design or the markup. If only the changed cohort moved, it is the redirects.

If clicks have not recovered after eight weeks, the problem is rarely the redirects — by then they have been processed. Look for content that got shorter, headings that turned into images, internal links that a new template dropped, or pages that were merged without their questions being answered.

The rollback question

Decide before launch what would make you revert, and keep the old environment alive and reachable for a month. “Traffic looks bad” is not a criterion; “the redirect map fails on more than 2% of top pages” or “server errors above baseline for an hour” are. With a five-minute TTL and a running old stack, reverting is a DNS change and a calm conversation instead of a bad night.