The single most important step is a complete URL map: every existing URL that has traffic, rankings or links, matched to its destination on the new site, with a 301 redirect in place before launch. Most migration losses trace back to URLs nobody inventoried, redirects pointing at the homepage instead of the equivalent page, or a staging robots.txt shipped to production. All three are preventable with a checklist.
Before anything else: the inventory
You cannot redirect what you have not listed. Pull URLs from every source, because no single source is complete.
- A full crawl of the current site, which finds what is linked.
- Search Console pages report, which finds what earns impressions, including pages nothing links to.
- Analytics landing pages over at least twelve months, to catch seasonal pages.
- Your XML sitemaps, current and any older ones still live.
- Server logs, which find URLs that are still being requested by anything at all.
- A backlink export, so you know which URLs other sites point at.
Merge those into one list and deduplicate. The result is usually far longer than anyone on the project expected, and the gap between the crawl and the backlink export is where the damage normally happens.
Mapping the redirects
| Equivalent page exists | 301 to it directly. One hop, no chain |
|---|---|
| Content merged into another page | 301 to the merged page |
| Content genuinely gone | 410, or 404. Do not redirect it to the homepage |
| URL unchanged | Leave it. Confirm it is genuinely identical, including trailing slashes and case |
Redirecting removed pages to the homepage is the most common shortcut and it is treated as a soft 404, so it passes nothing and hides the problem from your reporting.
The sequence
- Build and test the new site on a blocked staging environment. Password protection, not robots.txt alone.
- Load the redirect map and test every rule against staging before launch, not after.
- Check the robots.txt and meta robots tags that are about to go live. This is where a staging noindex escapes into production.
- Launch at a low-traffic time, with the people who can roll it back available.
- Immediately crawl the live site and check a sample of redirects by hand.
- Submit the new sitemap and keep the old one available for a while so the old URLs get recrawled and the redirects get seen.
- Watch indexation and impressions daily for a fortnight, then weekly for a quarter.
What goes wrong most often
- A staging robots.txt or noindex tag shipped to production
- Redirect chains of three or four hops, built by layering rules over time
- Internal links still pointing at old URLs, so every navigation click is a redirect
- Canonical tags left pointing at the staging domain
- Analytics and Search Console not reconfigured for the new property
- Changing the design, the URLs, the CMS and the content in one release, which makes any problem impossible to isolate
What to expect afterwards
Some fluctuation is normal for a few weeks while Google recrawls and reassesses. A drop that has not started recovering within a month is a problem rather than a settling period, and the redirect map is the first place to look.
Do not change URLs unless there is a real reason. A redesign that keeps its URLs carries a fraction of the risk, and "the new CMS does it differently" is not a good enough reason on its own.