Build the Redirect Map Before the Design Is Signed Off
Why the timing matters more than the spreadsheet
Everybody agrees a migration needs a redirect map, and almost everybody builds it after the new site is finished. At that point it is a reconciliation exercise: you discover which old pages have no equivalent, the structure is already agreed, and the only available answer is a redirect to something approximate.
Built before design sign-off, exactly the same spreadsheet is a requirement rather than a cleanup. ‘These forty addresses earn sixty per cent of our organic traffic and their content has to survive’ is a thing a wireframe can accommodate. The same sentence after launch is a complaint.
Most migration losses are preventable with one spreadsheet made early enough.
What gets lost
Traffic disappears when old URLs return errors, redirect in chains, or all land on the home page. Every one of those is a decision nobody made deliberately.
Rankings rarely come back by themselves because the signals were pointed at pages that no longer exist.
The inventory
Pull URLs from analytics, Search Console, the sitemap, a crawl and your backlink data. Deduplicate. That is the real list, and it is always longer than the CMS suggests.
Map each one to the closest equivalent on the new site. Where there is no equivalent, decide consciously between a redirect to a parent and a clean error.
Launch week
Test the map on staging. Monitor coverage, errors and rankings daily for a fortnight. Keep the old site accessible long enough to compare.
Why it belongs before the design sign-off
A redirect map built after the new site is finished is a reconciliation exercise: you discover which old pages have no new home, and by then the information architecture is agreed and the answer is a redirect to something approximate. Built before sign-off, the same exercise is a design input: it says there are two hundred pages earning traffic that your new structure has nowhere to put, which is a thing to fix in a wireframe rather than in a spreadsheet.
It also changes the conversation with whoever is building the site. ‘These forty addresses earn sixty per cent of our organic traffic and must survive with their content intact’ is a requirement. ‘Please redirect everything sensibly’ is a hope.
Building the map
- Export every indexable address with twelve months of clicks and impressions.
- Mark the primary query each address earns on, and the words on the page that answer it.
- Assign exactly one destination per address in the new structure.
- Flag every address with no genuine destination, and resolve each as build, merge or retire.
- Hand the flagged list to the design process while the structure can still change.
Chained and looping redirects
Migrations accumulate history, and a third replatform produces chains three or four hops long where each step was reasonable at the time. Chains lose value at every hop and occasionally close into loops that return nothing. Flatten every chain to a single hop as part of the map, not as a later clean-up that never gets scheduled.
Common questions
One-to-one or many-to-one?
One-to-one wherever a genuine equivalent exists. Many-to-one is a deliberate consolidation, which is fine when the merge makes sense and damaging when it is a shortcut.
301 or 302?
301 for anything permanent, which a migration is. A 302 tells a search engine to keep the old address, which is the opposite of what you want.
Do we need to redirect pages with no traffic?
If they have external links, yes. Traffic and links are different assets and only one of them shows in your analytics.
How do we test the map before launch?
Run it against the frozen inventory on staging and assert that every old address returns a single hop to a 200. It is a script, not a manual check.
