Site migration redirect mapping — what to ship before relaunch

Quick frame: Site migrations kill organic traffic when URL mapping is incomplete or chains are sloppy. The fix is a comprehensive redirect map shipped to devs before relaunch, deployed as 301s, and verified post-launch with a crawler. Here's the checklist.

Before relaunch — preparation

1. Crawl the existing site (Screaming Frog or Sitebulb). Export the full URL list with status codes.
2. Filter to indexed URLs only — pages with status 200 and not noindexed.
3. Pull traffic data from Search Console for the last 6 months — sort URLs by clicks descending.
4. Pull backlink data from Ahrefs / Semrush — sort URLs by referring domains.
5. Prioritise the URL list by combined traffic + backlinks.

During mapping — the redirect table

6. For every indexed URL, identify the new URL on the relaunched site.
7. Group by pattern (e.g., entire /old-blog/* → /blog/*). Use regex where possible.
8. For URLs without an exact equivalent, redirect to the closest parent (category page, hub page) — not the homepage.
9. For deleted content, return 410 rather than 404 (signals permanent removal).
10. Document each mapping in a CSV: old URL, new URL, status code.

Use the redirect map generator to turn the CSV into a dev-ready PDF.

Before relaunch — testing

11. Test 20 random redirects on the staging environment. Confirm 301, not 302.
12. Test 20 high-priority redirects (top traffic, top backlinks). Manually verify each.
13. Test chain length with the redirect chain visualiser — every redirect should be single-hop.
14. Test edge cases: trailing slashes, query parameters, fragment identifiers, uppercase URLs.

At launch

15. Deploy redirects before DNS cutover, so they're in place when traffic shifts.
16. Submit new sitemap to Search Console immediately. Use the sitemap generator if needed.
17. Update internal links to point directly to new URLs (no via-redirect internal links).
18. Update canonical tags with the canonical generator to point to new URLs.

Post-launch — verification

19. Re-crawl the old URL list within 24 hours. Verify each returns 301 → new URL.
20. Re-crawl from inside the new site — confirm no broken internal links.
21. Search Console: monitor Coverage report for "Page with redirect" warnings.
22. Compare organic traffic week over week for 4 weeks. Expect 10–20% dip; recovery within 4–6 weeks.
23. For traffic still missing after 6 weeks, isolate the URLs and re-investigate.

Common migration killers

• Some redirects are 302 instead of 301 — link equity discounted.
• Chains accumulated: old → www → https → final = 4 hops.
• High-traffic URLs redirect to homepage — Google treats as soft 404.
• Sitemap still contains old URLs — Google crawls dead URLs.
• Internal links still point to old URLs — each becomes a chain hop.

The dev handover

Hand devs:

1. The CSV mapping (full URL list with status codes).
2. The generated PDF redirect map (free preview; ₹19 for clean version).
3. Apache or nginx rule blocks (use the .htaccess or nginx generators).
4. The deployment checklist (sections 14–17 above).

The 301 vs 302 vs 307 post covers status code selection. The chains piece covers flatness.

FAQ

Q. How long should I keep the redirects in place? A. At least 12 months. Some equity transfers within weeks; the tail extends for months. Keep until traffic is stable on the new URL.

Q. Can I 301 to a non-equivalent page? A. Yes, but Google may treat it as a soft 404 if the destination clearly isn't a fit. Better to 410 if no genuine replacement exists.

Q. What if I'm migrating to a new domain? A. Same process, plus add the new domain in Search Console, submit a Change of Address, and consider longer redirect retention (24 months+).