Redirect map: how to verify your redirects work after a migration
Most of the damage in a migration is not caused by a bad redirect strategy. It is caused by a good strategy that nobody verified after launch. The redirect map gets built, the site goes live, and the first real check only comes weeks later in the traffic review, when the drop is already visible in the numbers. The fix is a planned process of ongoing checks, not a better spreadsheet.
A redirect map is a dataset, not a document to hand over
A redirect map that gets built in a spreadsheet, handed to the developers and never opened again has only one purpose. When something fails, there is someone to point at. A redirect map that actually works is a fixed dataset with a clearly defined structure, because everything that follows, meaning implementation, testing and verifying the redirects after launch, runs against it automatically.
The minimum set of columns is old URL, new URL, intended status code, URL type (product, category, article, filter, media, other) and a source flag that says where the old URL came from. That last one matters more than it looks. The inventory of old URLs has to be built from every source that knows about your URLs, because each of them knows a different subset.
- A full crawl of the current site shows what is linked today.
- Search Console shows what has impressions, including URLs that are no longer linked internally.
- Analytics shows which pages people actually land on.
- The backlink profile shows where other sites point. These URLs carry value whether you still like them or not.
- Server logs show which URLs Googlebot still requests, including URLs that have been inactive for years.
Merge these five lists into one. Deduplicate it and normalize protocol, domain, trailing slashes and tracking parameters (UTM), so the same URL is not recorded three times in slightly different forms. Only this one list is the real scope of the migration. On most sites it is noticeably larger than the CMS export the project started with, and that difference is exactly the set of URLs that would quietly end up on a 404.
Deciding what each URL type deserves
Not every old URL deserves a 1:1 redirect, and pretending otherwise is how maps swell into unmaintainable lists. The decision for each type is simple.
| Old URL type | Decision | Why |
|---|---|---|
| Has traffic, links or impressions, and an equivalent exists | 301 to the matching page | Keeps both the value and the user’s intent |
| Has value but no direct equivalent | 301 to the closest parent page (category, hub page) | The closest related page is better than the homepage if it genuinely replaces the original content |
| No traffic, no links, no equivalent | 410 (or a clean 404) | A clear 404 or 410 is better than a redirect to nowhere |
| URLs with parameters and filters | Rewrite by rule, not row by row | One rule per pattern replaces thousands of rows |
Filtered URLs and URLs with parameters are the only type where the map should not decide on its own. The decision has to follow the indexation rules. I use the same framework for them as for faceted navigation.
Resist the temptation to redirect everything left over to the homepage. Google’s site move documentation is clear about this. Do not redirect many old URLs to one unrelated destination, such as the homepage of the new site, because it can confuse users and may be treated as a soft 404. Such a redirect may not pass on the signals you wanted to keep. A user who clicked an old product link lands on the homepage and wonders what happened. If no equivalent exists, return a 404 or 410 status code.
The 48-hour migration check workflow
Those 48 hours are my working standard, not a Google rule. Within 48 hours of launch, you can reliably verify whether every old URL behaves according to the map, because you run the check, not the search engine. The process I use on migration projects has five steps.
- Save the baseline before launch. A final crawl of the old site, a Search Console export and the finished map. Store them somewhere you can query them. Every post-launch question then gets answered against this trio.
- Test on staging before launch. Run the full list of old URLs on staging in your crawler’s list mode. For every row, record the final URL and the status code, and compare both with the map. Fix the discrepancies before they go public.
- On launch day, run the full list of old URLs on production. Not a sample. Use the full list. For every row, record the first status code, the final destination, the chain length, the destination’s status code and its indexability. It is one automated job, and it is the core of the whole process.
- During the first 48 hours, fix errors by priority. First 404s and 500s on URLs with traffic or links, then redirects pointing to noindexed destinations or to 404s, and finally chains of two or more steps. Then repeat the crawl until the result matches the map.
- On day two, submit the old sitemap alongside the new one. A sitemap full of redirected URLs looks like a mistake, but it is intentional. It gives Google the complete list of moves to process and gives you a view of coverage in Search Console while the old URLs drop out.
There is one detail about that old sitemap that the documentation does not cover. Google says that warnings on a sitemap with old URLs are normal. Google also recommends submitting both, so you can track the move. The documentation only says that you can remove it once you have submitted the new one. How long to keep it for tracking, it does not say.
The practical number comes from John Mueller, who wrote on Twitter in March 2022 about one to three months, lowering an earlier figure of six months. He also noted that the effect today is minimal. Treat it as a guide for monitoring, not as a tool that changes anything.
From my own practice. The launch-day crawl is scripted before migration week, not written during it. A migration launch never falls on a quiet day, and a check that needs an hour of manual setup is a check that gets skipped. The script takes the map as input and returns a list of differences. Anyone on the team can run it, and that is exactly the point.
How long to keep redirects
Google’s site move recommendation is to keep redirects for as long as possible, generally at least a year, and from the users’ point of view to consider keeping them permanently. In practice, I keep redirects for at least a year, and for URLs that external links still point to, usually permanently. Removing a redirect does not delete the old link on someone else’s site, it only decides that the click now ends on a 404.
What to avoid
- Do not build the map only from a CMS export. The trouble comes from exactly the URLs the CMS forgot, meaning old structures, campaign landing pages and URLs that exist only in backlinks and logs.
- Do not let slugs change after the map is approved. A last-minute slug “improvement” quietly invalidates rows, and nobody rechecks a map that was already approved.
- Do not deploy redirect chains. From the old URL to the new one in a single step. Googlebot can handle up to ten hops, but Google itself recommends pointing straight to the final destination and, if that is not possible, keeping the chain ideally to three hops and definitely under five. Long chains also slow users down, and some clients stop following them after a few hops. If the map creates A→B→C, flatten it to A→C before launch and adjust internal linking so the site itself links straight to the final URL.
- Do not judge the migration by rankings a week after launch. Rankings are the slowest signal you have. Status codes are immediate, while indexing status changes gradually over weeks. Watch those first.
- Do not combine a redesign, a platform change and a URL restructure into one launch if you can avoid it. When traffic drops, three simultaneous changes mean the cause cannot be attributed.
- Do not test only on staging. Staging often has a different .htaccess or a different CDN than production, and after launch half of the rules behave differently. The launch-day test belongs on production.
- Do not delete the old sitemap right after launch. “So it stops throwing errors” is a bad reason. Warnings on it are normal, and it is exactly where you see the old URLs disappearing from the index. Keep it for one to three months, then remove it.
- Do not forget entry points outside the CMS. Old campaign landing pages from PPC and email are not in the CMS export and end up on a 404 after launch. Landing pages from analytics and the logs belong in the inventory too.
What to measure after the site goes live?
- Match with the map. The share of old URLs that resolve correctly in a single step. Within the first 48 hours it should reach effectively 100%. Anything lower is unfinished work, not a rounding error.
- 404 requests to old URLs in the server logs. Check every such request as a URL the inventory may have missed. During the first month, feed them back into the map once a week.
- Indexing status of the new URLs in Search Console, against the saved baseline of how many old URLs were indexed. When the Search Console bulk export is running, the comparison is one BigQuery query, not manual work.
- Impressions by section, old versus new, on the same query sets. A section-level comparison reveals a localized problem while the site-wide chart still looks fine.
Whether a migration succeeds is not decided only by the quality of the map. It is decided in the first two days, while the fix is still cheap and nobody sees it in the traffic report.
Planning a migration and cannot afford to lose organic traffic?
I build the redirect map as a verifiable dataset and run the post-launch checks with your team. The first traffic report then brings no surprises.