Migrations lose traffic for boring reasons: an incomplete URL inventory, redirect chains, a staging noindex left in production, or metadata that did not carry across. None of these are difficult to prevent — they just have to be done before launch, in a specific order.
Phase 1 — Baseline (2–4 weeks before launch)
You cannot prove a migration succeeded without a pre-migration record. Capture:
- Full crawl of the live site exported with URL, status code, title, meta description, canonical, H1, indexability and word count.
- Search Console export: top pages and queries by clicks and impressions, 16 months if available.
- Analytics export: landing-page traffic and conversions by month.
- Backlink export: which URLs hold external links.
- Index count from the Page indexing report per template.
- Core Web Vitals field data as the performance baseline.
Build the "protected URL" list. The intersection of pages with organic traffic, external links and conversions. These must have a working, single-hop redirect on day one — no exceptions.
Phase 2 — URL inventory from six sources
A crawl alone misses URLs that are no longer linked but still indexed and still receiving traffic. Combine:
- Site crawl (internal links).
- XML sitemaps, current and archived.
- Search Console Pages report — every URL Google knows.
- Analytics landing pages over 12–24 months.
- Server access logs, which reveal what bots and users still request.
- Backlink tools for externally linked URLs, including deleted pages.
Deduplicate into one master list, and include non-HTML assets: images, PDFs, feeds, and any downloads that earn links.
Phase 3 — Redirect mapping
| Old URL type | Destination rule |
|---|---|
| Page with a direct equivalent | 301 to the equivalent URL |
| Page merged into another | 301 to the merged page |
| Page removed, similar content exists | 301 to the closest topical match |
| Page removed permanently, no equivalent | 410 Gone |
| Paginated URLs | 301 to the equivalent page number, or to page 1 if pagination changes |
| Media and PDFs | 301 to the new asset path |
Rules for the map itself: single hop to the final destination, no loops, no redirects to noindexed pages, and protocol plus www handled in the same rule rather than as a second hop.
Do not bulk-redirect to the homepage. Google commonly treats mass homepage redirects as soft 404s, which discards the equity you were trying to preserve.
Phase 4 — Staging discipline
- Block staging with HTTP authentication, not just robots.txt. A disallowed staging site can still be indexed if it is linked.
- Keep a checklist item to remove the block at launch — and one to verify removal.
- Run the full crawl on staging and compare titles, descriptions, canonicals, H1s and structured data against the baseline export. Missing metadata is the second most common migration failure after missing redirects.
- Test the redirect map against staging with a bulk status checker before launch, not after.
Phase 5 — Launch day
- Confirm the site returns 200 and the correct HTML on the production domain.
- Remove staging authentication and any
noindex; check Settings → Reading and theX-Robots-Tagheader. - Verify robots.txt is the production version with the correct sitemap directive.
- Spot-check the protected URL list manually — every one should 301 in a single hop to a 200 page.
- Submit the new XML sitemap in Search Console; keep the old sitemap available temporarily so Google recrawls legacy URLs and discovers the redirects.
- Confirm analytics and tag manager fire on the new templates.
- Check SSL, including no mixed-content warnings after the asset paths changed.
- Run a fresh crawl of production and fix any internal links still pointing at old URLs.
Phase 6 — The first 30 days
- Days 1–3: daily crawl for 404s and redirect chains; watch server error rates and TTFB under real traffic.
- Week 1: monitor the Search Console Page indexing report for spikes in Not found, Redirect error or Excluded by noindex.
- Week 2: compare indexed URL counts per template against baseline; check Crawl stats for response-time regressions.
- Weeks 3–4: compare clicks and impressions against the same period pre-migration, segmented by template. A dip confined to one template points at a template-level problem, not a sitewide one.
Expect a dip. A short decline while Google reprocesses the site is normal. A decline that is still deepening after four weeks is a symptom — usually missing redirects, lost metadata, or content removed during the redesign.
What people forget
- Hreflang annotations pointing at old URLs.
- Structured data lost when templates were rebuilt.
- Image URLs changing, dropping image search traffic.
- Content trimmed "for the redesign" on pages that ranked because of that content.
- Internal search, filters and pagination generating a new crawlable URL pattern.
- Email and campaign links pointing to URLs not covered by the redirect map.
Keep the redirect map in version control and review it annually. Legacy rules that no longer receive requests can be retired, but only after the logs confirm it.