How do you plan redirects for a site migration?
Build the map before development finishes, sourced from a crawl, the sitemap, Search Console, analytics and server logs, then sort by traffic. Map your top pages by hand rather than by pattern — a 95%-correct rule is fine across a thousand low-traffic URLs and unacceptable across the twenty that pay for the business.
Build the map before you build the site
The map is a spreadsheet with one row per old URL and one column for its new destination. It should exist before development finishes, not after.
Source the old URLs from every angle, because no single source is complete:
- A full crawl of the current site
- The current XML sitemap
- Search Console performance data, exported
- Analytics landing pages over the last two years
- Server access logs
- The CMS list of all published content
Deduplicate, then add a traffic column from analytics and sort by it. That ordering is what tells you where accuracy matters.
Map by hand where it counts
Pattern rules are efficient and are the right tool for the long tail. For your top pages — the ones that actually generate enquiries — write the destination by hand and check it.
A pattern rule that is 95% correct is fine across a thousand low-traffic URLs and unacceptable across the twenty pages that pay for the business.
Decide the non-obvious cases in advance
Every migration has rows nobody wants to decide:
- Pages with no equivalent on the new site
- Content being deliberately retired
- Old blog posts, of which there are usually many
- Non-HTML files — PDFs, images linked externally
- Parameterised URLs from old campaigns
Decide each before launch. Anything with no sensible destination gets 410, not a redirect to the homepage.
Test on staging with the real map
Load the redirect rules into the staging environment and run the full old-URL list through them. Record the status, hop count and final destination for every row.
Fix everything that is not a single hop to a 200 before launch. This is dull and it is the entire point — a migration that has been tested this way rarely surprises anyone.
Launch-day sequence
- Redirect rules deployed with the site, not after
- Verify a sample immediately, before announcing anything
- Confirm robots.txt is not blocking the new site — a staging robots file going live is a classic and costly error
- Confirm noindex tags from staging are removed
- Submit the new sitemap in Search Console
- Keep the old sitemap submitted for a while so old URLs are recrawled and the redirects are discovered
Monitor for three months
Check weekly:
- 404 reporting for URLs nobody mapped
- Crawl statistics for anomalies
- Organic traffic against the same period last year, not last month
- Rankings for your commercially important terms
Some fluctuation in the first weeks is normal. A steady decline that does not stabilise is a mapping problem, and the earlier you find it the cheaper it is.
What this costs
Migration planning and execution is part of a rebuild under Growth Engine — $5,500 setup, $1,500 a month, or Authority Builder at $12,500 and $3,500 for larger sites with complex URL structures. It is not the place to save money — a bad migration costs more than the site did.
Frequently asked questions
When should the redirect map be built?
Before development finishes, not on launch night. It is a spreadsheet with one row per old URL, sourced from a crawl, the sitemap, Search Console, analytics, server logs and the CMS content list.
Should I use pattern rules or map by hand?
Both. Patterns are right for the long tail, but the pages that actually generate enquiries should be mapped by hand and checked. A 95%-correct pattern is fine across a thousand low-traffic URLs and unacceptable across your top twenty.
What about pages with no equivalent on the new site?
Decide before launch. Anything with no sensible destination should return 410 rather than being redirected to the homepage, which is treated as a soft 404 and confuses visitors.
What goes wrong most often on launch day?
A staging robots.txt or leftover noindex tags going live with the site. Both are quick to check and expensive to miss, so verify them before announcing anything.
How long should I monitor after a migration?
Three months, checking weekly: 404 reports, crawl statistics, organic traffic against the same period last year, and rankings for commercially important terms. Early fluctuation is normal; a steady decline is a mapping problem.