Most migration stories that go wrong follow the same pattern. The new site goes live, the first week looks fine, and three weeks later organic traffic turns out to be down by thirty percent. Then the search begins — while the old site is already offline and nobody remembers exactly what was on it.
The cause almost never lies in the execution, but in the preparation. No complete list was made of what was there. Which meant nobody could check whether everything had come across.
1. Take inventory before you touch anything
Start with a complete list of every URL on the current site. Not the pages in the menu — every URL. Old campaign pages, archived news items, filter combinations, PDFs, language variants.
Combine at least three sources, because each one on its own misses something:
- A crawl of your site — finds everything linked internally
- Search Console — finds pages that get traffic but are linked nowhere
- Your server logs or analytics — finds what visitors actually request
The differences between those three lists are more interesting than the overlap. A page that pulls traffic but is linked nowhere is guaranteed to be missing from your new sitemap.
2. Work out what each URL is worth
Not every page deserves the same attention. Put three numbers next to each URL: organic traffic over the past twelve months, the number of referring domains, and the positions it holds.
What you almost always find: a small share of your pages accounts for the overwhelming majority of your value. That group gets individual attention. The rest you can handle in bulk.
—A page with no traffic but ten referring domains is worth more than a page with five hundred visitors and no links at all. Do not look at visitor counts alone.
3. Decide per URL, not per pattern
The temptation is to make rules: everything under /blog/ goes to /knowledge/, done. That works for most of it, but the exceptions are exactly what costs you positions.
There are four possible outcomes per URL:
- 1Keep — the page continues to exist, possibly at a new address
- 2Merge — the content is absorbed into another page, with a redirect
- 3Redirect — the page goes, but its value passes to the closest alternative
- 4Retire — the page goes with no replacement, deliberately
That last category is allowed to exist. An expired campaign page from 2019 does not need to go anywhere. But it has to be a decision, not an oversight.
4. Redirect once, not in chains
By the second or third migration, chains appear: A points to B, B to C, C to D. Every link costs speed, and search engines do not follow indefinitely.
Update your old redirects so they point straight to the endpoint. Tedious work, but it is the cheapest win in the whole project.
5. Measure beforehand, so you have something afterwards
Record how your site stood before you launch: positions on your key terms, organic traffic per section, number of indexed pages, load times.
Without that baseline you cannot establish afterwards whether a drop came from the migration or from something else. And you cannot demonstrate when you are back to where you were.
6. Look every day for the first few weeks
The first fourteen days after launch are decisive. Check daily for 404s in your logs, for redirects that do not fire, and for pages dropping out of the index.
A fault you find in week one takes an hour to fix. The same fault in week six has already cost weeks of traffic and is often harder to trace.
Where this falls apart
This checklist is not complicated. What makes it heavy is the scale: on a site with a thousand URLs, steps one to three quickly become a week of manual work in spreadsheets. Which is precisely why teams skip it, or do half of it.
That is why we built the Benchmark Agent and the Migration Agent: they take on the inventory and the valuation, so the time is left for the judgement — which page goes where, and why.