What’s the first thing that breaks rankings in a site migration?
- Published November 6, 2026
- Linked from 3 answers
- In a cluster of 7
The redirect map. When old URLs do not point, one by one, to their true new equivalents with a permanent redirect, the signals those URLs earned have nowhere to go, and searchers and Googlebot land on errors. Google’s guide to moving a site with URL changes puts the mapping of old URLs to new ones at the center of the move for that reason, and it is a step that can fail at scale before any subtler problem has a chance to show. It is not the only one: a staging noindex carried over, canonicals still pointing to old URLs, or a server that falls over on launch day can hurt as fast, so test those in the same cutover checks.
How the redirect map fails
| Failure | What it does |
|---|---|
| Old URLs left without a redirect | They return errors; their rankings and links are stranded |
| Whole sets of old URLs sent to the home page or one unrelated page | Google can treat these as soft 404s, so the redirect passes little |
| Redirects pointing to the wrong page | The new page does not match what the old one ranked for |
| Temporary redirects where permanent ones are needed | Google does not take a temporary redirect as a sign that the target should be canonical |
| Chains of several hops | Slower to process and more places for a step to break |
| Rules that miss parameters, trailing slashes or changed slugs | Gaps that only show up later as lost traffic on specific pages |
The second row is a shortcut that does real damage. Google’s guide warns against sending large numbers of old URLs to a single unrelated destination such as the home page: visitors are left confused, Google may handle the redirect as a soft 404, and the old page’s value does not arrive anywhere.
Close behind: settings that block the new site
The same guide’s checklist also covers three problems that can hold a move back even when redirects are right: a noindex or robots.txt block carried over from the staging site, canonical tags still pointing to the old URLs, and internal links that still lead to old addresses. Each is quick to check and quick to fix, and each can hold the new site back while the redirects do their job.
Check before and after launch
- Build a complete list of old URLs from your sitemap, server logs and analytics, and map each to its closest new equivalent.
- Test the map on staging, then crawl the old URLs again on launch day and confirm each returns one permanent redirect to the right page.
- Remove staging blocks, update canonical tags and internal links to the new URLs, and submit the new sitemap.
For how long a dip after a correct migration lasts, see how long to expect a traffic dip after a migration. For a large site, decide early whether to migrate everything at once or in phases. Get the map right first, because every other part of the move depends on it.
Add a comment