Every agency has seen the same graph: a relaunch date, then organic traffic stepping down and staying down. The new site is usually better than the old one. That is not what caused the drop.
Migrations lose traffic for a small number of specific, preventable reasons, and all of them are decided before launch. This is the workstream we run on every migration, in order.
The four things that actually cause the drop
In our experience assessing sites after a bad relaunch, the cause is nearly always one or more of the following. None of them are exotic.
- An incomplete URL inventory. The redirect map was built from the CMS sitemap, so it covered the pages the CMS knew about – and missed the campaign landing pages, the old blog structure, the parameterised URLs and the pages that were manually created years ago. Those URLs held links and traffic.
- Redirects that lose their target. Redirects were implemented as chains, or pointed at the home page instead of the equivalent page. A redirect to the home page is treated as a soft 404 and passes nothing.
- Silent content loss. Content was migrated by hand and some of it did not arrive, or arrived without its metadata, headings, internal links or structured data. Nobody compared old and new systematically.
- Launching without a baseline. No pre-migration benchmark was recorded, so when traffic moved, nobody could tell a migration problem from a seasonal change – and by the time it was clear, the recoverable window had passed.
Step 1: Build a URL inventory from three sources, not one
This is the single highest-value step and the one most often shortcut. A CMS sitemap is not an inventory of your site; it is an inventory of what the CMS currently believes should be indexed. Those are different lists, and the difference is where the traffic loss lives.
Combine three sources and deduplicate:
- A full crawl of the live site, following internal links, including paginated and parameterised URLs. This finds what is reachable.
- Analytics landing page data, for at least the last twelve months. This finds what receives traffic, including pages nobody links to any more.
- Search Console performance and index coverage data, exported in full. This finds what search engines actually have, including URLs the crawl will not reach because nothing links to them.
Where backlink data is available, add it as a fourth source. A URL with external links is worth redirecting even if it has had no traffic for a year, because the links are the asset.
The combined list is routinely two to five times larger than the CMS sitemap. That gap is the difference between a migration that holds and one that does not.
Step 2: Benchmark before anything changes
Record the current state while you still have it. This takes a day and it is the difference between diagnosing a problem and arguing about whether there is one.
- Organic sessions and conversions by landing page, for twelve months.
- Ranking positions for the queries that matter commercially.
- Index coverage: how many URLs are indexed, and the reasons given for those that are not.
- Core Web Vitals by template, from field data.
- Conversion rate by device and by landing page template.
- A full crawl export: every URL with its title, description, headings, canonical, status code and structured data.
Step 3: Map every URL, one hop, with a decision for the exceptions
Take the combined inventory and map each URL to its destination on the new site. Three rules make this reliable.
One-to-one wherever an equivalent exists. The closest equivalent page, not a category page and never the home page. A redirect to an irrelevant destination is treated as a soft 404, which is functionally the same as deleting the page.
One hop, always. If the old site already contains redirects – and it will – resolve them so the final map points directly from the original URL to the final destination. Chains lose signal and add latency, and chains that cross a domain change frequently break entirely.
A written decision for every URL with no equivalent. Either redirect it to the nearest genuinely relevant page, or return a 410 deliberately. What you must not do is leave it to fall through to a 404 by accident, because then nobody knows whether it was a decision or an oversight.
Consolidation deserves particular care. If the migration merges twelve thin pages into one good one, that is usually correct – but each of the twelve needs to redirect to the survivor, and the survivor needs to actually cover what they covered.
Step 4: Check parity, do not assume it
Content migration tools and manual re-entry both lose things. The only reliable approach is to compare the new site against the benchmark crawl, field by field, before launch.
Crawl the staging environment and diff it against the pre-migration export for:
- Page presence: every URL that should exist, does.
- Titles and meta descriptions: present, unique, and intentionally changed where changed.
- Heading structure: one H1 per page, hierarchy intact.
- Body content: word count within a reasonable tolerance of the original, flagging anything that dropped sharply.
- Canonical tags: self-referencing and absolute, not pointing at staging.
- Structured data: same types, same required properties, still matching visible content.
- Internal links: navigation and in-content links resolving, not pointing at old URLs.
- Images: present, with alt text carried across.
Two staging mistakes are worth calling out because they are common and both are serious. First, staging must be blocked from indexing – by authentication, not by robots.txt alone, which does not prevent indexing of a URL that is linked externally. Second, and the inverse, the noindex and authentication must be removed on launch. A site launched with staging directives intact is a genuinely catastrophic and entirely routine mistake.
Step 5: Launch deliberately
The cutover itself should be dull. Everything that makes it dull happens beforehand.
- Reduce DNS TTL several days in advance, so a rollback propagates in minutes rather than hours.
- Choose a genuine low-traffic window for your audience, not for your team. Avoid Fridays; you want people available afterwards.
- Keep the previous environment running and reachable. Switching it off immediately removes your rollback option and your reference copy.
- Verify redirects against the full inventory as the first post-launch action, in bulk, not by spot-checking.
- Confirm analytics and conversion tracking are firing. Tracking that silently stopped is discovered weeks later, and the data is not recoverable.
- Submit the new sitemap in Search Console and request indexing for the most important templates.
Step 6: Monitor intensively for the first month
Most recoverable migration problems are only recoverable if found quickly. Assign a named person to check, daily for the first two weeks and then weekly:
- Crawl errors and 404s in Search Console, and in your server logs – the logs surface URLs Search Console has not got to yet.
- Index coverage: new URLs being indexed, old ones dropping out at a reasonable rate.
- Organic traffic by landing page, compared against the benchmark rather than against last week.
- Conversion rate by template, which catches broken forms that traffic figures hide.
- Core Web Vitals field data, which takes several weeks to stabilise on the new site.
Expect fluctuation. Search engines need to recrawl and reprocess a changed site, and a few weeks of movement is normal even on a well-run migration. What is not normal is a sustained step change in a specific template or section – that is a signal, and it is usually a redirect or a parity problem you can still fix.
What nobody can promise
No supplier can guarantee that rankings will be unchanged after a migration, and you should be wary of one who does. Search systems change, competitors move, and a redesign genuinely does change how a page is assessed.
What can be committed to is the work: a complete inventory, a recorded benchmark, a one-hop redirect map with a decision for every exception, verified content parity, a rehearsed launch, and monitoring that finds problems while they are still cheap. Migrations that do those six things do not usually lose traffic. Migrations that skip any of them usually do.