Run a site migration without losing traffic

Charles Taylor's sequenced launch: clean the old site, map every URL, dark launch, switch canonicals, then 301, and keep redirects forever.

Use this when a site is moving to a new domain, CMS, or URL structure and you cannot afford to tank organic traffic. The default advice (stand up the new domain, submit sitemaps, fire 301s) is the trap: it lets Google treat both sites as live. This SOP forces Google to crawl the old URLs before it reaches the new ones. Set the client expectation up front: a well-run migration still drops roughly 10-25% for three to six months, then recovers. Do not migrate purely for SEO reasons.

Phase 1: Clean the legacy site first

Do this BEFORE anything else. Any crawl issue that exists now carries over to the new site and lengthens recovery.

1. Make HTML and XML sitemaps current.
2. Fix bad links. Broken pages (4xx) and existing redirects (3xx).
3. Fix soft 404s.
4. Fix bad canonicals.
5. Remove duplicate content.
6. Fix bad titles and meta descriptions.
7. Fix site structure. Resolve multiple or missing H1s, enforce headline hierarchy, use <p> tags instead of <span> tags.

Phase 2: Find every URL, then plan each one

Build one master list of every URL Google could know about, then assign each a fate.

8. Pull Search Console. Last 16 months of impressions, clicks, and landing pages.
9. Pull Google Analytics landing pages. Both organic-only and all traffic.
10. Pull URLs with external links / backlinks. These hold authority worth protecting.
11. Crawl the site and scrape the XML sitemap.
12. Combine all sources and de-dupe into one list.
13. Decide a fate for every URL: Keep, 301 Redirect, or Kill. Keep is best (no equity loss, already indexed). 301 if it must change. Kill/404 is acceptable but forfeits that page's authority.
14. Push the business to keep URLs unchanged wherever possible (for example, keep top-level category URLs even if product URLs change).

Phase 3: Build the new site to be better

The new site must be as good or better than the old one, technically and on-page. This is the recovery driver.

15. Clean taxonomy and architecture that is easy to use, navigate, and understand.
16. Make sure Googlebot can access, render, and index every page. Avoid JS / parallax / infinite-scroll that blocks crawling; watch page speed.
17. Follow URL best practices. Lowercase only (uppercase 301s to lowercase), no spaces or special characters, hyphens between words, one consistent trailing-slash and extension standard, HTTPS.
18. Keep internal linking and canonicals consistent. Use explicit <a href> links, not JS onclick, not relative paths.
19. Fill SEO tags on every page: Title, Meta description, Canonical, OG, Twitter, Meta robots.
20. Add custom 404 pages with a search box, links to key pages, on-brand.

Phase 4: The launch sequence (the "secret sauce")

This order forces Google to crawl the old URLs before reaching the new ones. Skip it and Google treats both sites as live.

21. Dark launch the new site.
22. Update the canonicals on the OLD site to point at the new-site URLs. Cover every page that is moving.
23. Wait about a week (roughly 7-10 days, depending on the site's authority).
24. Launch single-hop 301 redirects from old URLs to new URLs. Do not forget images and PDFs.
25. Launch the new XML sitemaps on the new site.
26. Wait about another week (roughly 7-10 days).
27. Update all internal links to point to the new URLs.
28. Update nav/site links and remove the legacy XML sitemaps (bonus step).
29. Update any external links you can influence.

Phase 5: After launch

30. Monitor constantly. This is how a bad redirect gets caught mid-migration. On a hiccup, do not panic; diagnose, then fix (for example, convert a many-to-one redirect back to one-to-one).
31. Keep the 301 redirects effectively forever. If humans or Google are still hitting an old URL, keep redirecting it. Only remove a redirect when no one hits it.
32. Keep the legacy domain in Search Console indefinitely.
33. Do NOT use the GSC Change of Address tool.
34. Do any further page culling only AFTER the migration. Removing thin pages is itself a mini-migration.

Pitfalls

• Following Google's stock advice verbatim. A study cited in the session found an average recovery of 523 days, with a large share of domains never recovering after 1,000 days (the deck's non-recovery figure and the spoken figure disagree; treat the exact percentage as unverified).
• Letting both sites stay live at once because the launch was not sequenced. Google is "just a dumb algorithm" and will index both.
• Redirect chains and broken redirects. Single-hop 301 only: A redirects to B, and B returns 200 and self-canonicalizes. No chains, no redirects to broken pages.
• Forgetting non-HTML assets. Images, PDFs, and legacy URLs need redirects too.
• Migrating for SEO reasons alone (for example, to shed toxic links). Fix the link profile instead; do not migrate.
• Culling thin pages during the migration. That is a second migration stacked on the first; do it after.
• Trusting the GSC Change of Address tool. No proven benefit, and it has historically blinded you to legacy-URL data.
• Self-inflicted breakage from devs. Most migration disasters come from internal changes (removing "www", swapping CMS and URL structure at once), not black-hat attacks.

Source

Charles Taylor (enterprise SEO background: LexisNexis, Verizon, Fox; SEO Fight Club), "Website Migrations With Zero Traffic Loss," Day 3 conference session. This page is conference-derived and reconstructed from the session notes; figures and examples are faithful to those notes only.

Connect it

• Technical SEO, On-Page & Migrations. The session-level strategy layer on crawlability and sequenced migrations.
• On-page discipline. The headings, canonicals, and internal-linking standards Phase 3 depends on.
• Advanced schema · Entities & machine IDs. Wiring the new site's structured data so the rebuild is genuinely better.
• SEO Neo: zero to hero. Rebuilding authority on the pages you keep or redirect.
• Tooling. Where Search Console, Analytics, and crawl/backlink data come from for the URL inventory in Phase 2.