What 20+ Site Migrations Taught Me About Technical SEO at Scale

Why Migrations Are the Highest-Stakes Work in SEO

When you tell leadership you need to migrate the website, you are asking them to trust you with the company's organic revenue. If you get it wrong, recovery can take months — or may never fully happen. That is not hyperbole. I have seen migrations erase years of organic equity overnight because the wrong assumptions were made about what could be skipped.

A bad migration is uniquely destructive because everything changes at once. URLs change. Templates change. Content structure changes. Internal links change. Schema markup changes. Server configuration changes. And search engines have to re-evaluate the entire site simultaneously rather than absorbing incremental updates over time. Google does not process a site migration the way it processes a single page update. It has to recrawl, reindex, and reassess the entire domain — and during that reprocessing window, your rankings are vulnerable.

Other SEO work is incremental. You optimize a title tag and watch one page's performance. You fix a crawl issue and see a handful of pages recover. Migration is the opposite. It is a binary event. You either preserved your organic equity through the transition or you did not. And you will not know which outcome you got for at least two to four weeks after launch.

The Pre-Migration Audit Nobody Wants to Do

The success or failure of a migration is determined before launch day. It is determined in the unglamorous, tedious audit phase that most teams want to rush through. Every migration failure I have been involved in — or cleaned up after — traces back to an incomplete pre-migration audit, not bad execution on launch day.

Crawl the existing site completely. Not just the pages in the sitemap. Every URL. Use Screaming Frog or Sitebulb to discover every HTML page, PDF, image, and resource the site serves. Sitemaps are aspirational; they show what you want indexed. A full crawl shows what actually exists. On more than one migration, I found hundreds of live URLs that were not in any sitemap but were receiving organic traffic.

Document every URL that receives organic traffic. Pull Google Search Console performance data for at least 16 months (to capture seasonal patterns) and map it to your full URL list. Do not just look at the top 50 pages. The long tail matters. I have seen migrations that preserved the top pages perfectly but broke hundreds of long-tail URLs that collectively drove 30% of organic traffic. Those losses are invisible until someone notices the aggregate numbers declining weeks later.

Map current rankings and keyword positions as your baseline. Before anything changes, document where you rank for your priority keywords. You need a comparison point for post-migration monitoring. Without this baseline, you cannot distinguish between a migration-related drop and a normal ranking fluctuation.

Catalog all existing schema markup and structured data. Crawl for every JSON-LD block, microdata element, and RDFa annotation on the site. Document which schema types are deployed, which pages they appear on, and what data they contain. Schema is one of the most commonly lost elements during a migration because it lives in the template layer, and new templates rarely replicate old schema perfectly.

Identify existing redirect chains. If the site has been through previous migrations or URL restructuring, there are likely redirect chains — URLs that redirect to URLs that redirect to other URLs. Map these chains completely. The migration is your opportunity to clean them up rather than add another hop to the chain.

Document external backlinks pointing to specific URLs. Export your backlink data from Ahrefs or SEMRush and map it to your URL inventory. Any URL with significant external backlinks absolutely cannot be broken during migration. These are the pages where a redirect failure directly costs you link equity that took years to accumulate.

Audit internal linking patterns. Understand how link equity flows through the current site architecture. Which pages are the most internally linked? Which hub pages distribute authority to deeper content? The new site structure needs to preserve these equity flows, not just the individual URLs.

Redirect Mapping Is Not a Spreadsheet Exercise

Redirect mapping is where most migrations go wrong. Not because teams forget to do it, but because they approach it the wrong way. A spreadsheet with 5,000 rows of one-to-one URL mappings is not a redirect strategy. It is a liability.

Common mistakes

Building one-to-one redirects manually in a spreadsheet without logic. This does not scale. For a multi-site migration with thousands of URLs, manual mapping introduces human error at every row. Typos, missed pages, and inconsistent logic compound into hundreds of broken redirects on launch day.

Redirecting everything to the homepage. This is the lazy approach that destroys topical relevance. When Google follows a redirect from a page about "AC repair in Phoenix" to your homepage, it does not transfer the topical relevance. That page's organic equity is effectively gone. Every URL should redirect to its closest equivalent on the new site.

Chaining redirects through multiple hops. Every hop in a redirect chain costs crawl budget and dilutes link equity. Google follows redirect chains, but with diminishing patience. After three or four hops, there is evidence that Google may stop following the chain entirely. A migration that adds a new redirect on top of existing chains compounds the problem.

Forgetting to redirect non-HTML assets. PDFs, images, and downloadable resources accumulate backlinks over the years. If your site has PDF guides or whitepapers that have been linked to by external sites, those URLs need redirects just like HTML pages. I have seen migrations lose significant link equity because nobody thought to map redirects for PDF files that had hundreds of backlinks.

Assuming the CMS will handle redirects automatically. No CMS handles redirects at migration scale without configuration. Relying on auto-generated redirects from a CMS plugin or module without testing is a recipe for mass 404 errors on launch day.

The right approach

Build a redirect mapping system that works from URL pattern logic, not individual URLs. For a multi-site migration, you need rules-based redirect logic that can handle hundreds or thousands of URLs programmatically.

# Manual approach (does not scale):
/old-site/phoenix/ac-repair    ->  /phoenix-az/air-conditioning-repair
/old-site/phoenix/heating      ->  /phoenix-az/heating-repair
/old-site/phoenix/plumbing     ->  /phoenix-az/plumbing-services
/old-site/tucson/ac-repair     ->  /tucson-az/air-conditioning-repair
# ... repeated for every city and service. Thousands of lines.

# Pattern-based approach (scales):
/old-site/([a-z-]+)/ac-repair     ->  /$1-az/air-conditioning-repair
/old-site/([a-z-]+)/heating       ->  /$1-az/heating-repair
/old-site/([a-z-]+)/plumbing      ->  /$1-az/plumbing-services

# Catch-all for city landing pages:
/old-site/([a-z-]+)/?             ->  /$1-az/

# One rule covers dozens of cities instead of hundreds of lines.

Pattern-based rules reduce your redirect map from thousands of individual entries to dozens of logical rules. Each rule can be tested against a sample of URLs before deployment. And when a new city is added, the rules handle it automatically without manual updates.

Test redirects in staging before going live. Deploy your redirect rules to a staging environment and crawl every old URL against it. Verify that every redirect resolves to the correct destination with a single 301 hop. Any URL that returns a 404 or chains through multiple redirects needs to be fixed before launch.

Keep old redirects in place for at least 12 months after migration. Some guides suggest removing redirects after 90 days. Do not do this. Google can take months to fully process a migration, and external sites may continue linking to old URLs indefinitely. Twelve months is the minimum. For high-authority URLs with significant backlink profiles, consider keeping redirects permanently.

The Template Problem

New CMS templates are designed by developers who are thinking about visual design and content management workflows. They are not thinking about SEO requirements unless someone tells them exactly what those requirements are. This is the section that separates practitioners from theorists, because it requires having the conversation with your development team before they start building — not after the templates are already in QA.

Every page template needs proper heading hierarchy. One H1 per page. H2s for major sections. H3s for subsections. This sounds basic, but I have reviewed templates where the designer used H2 tags for visual styling in the sidebar, or where the CMS generated multiple H1 tags from different content fields. The heading hierarchy in the new template must be semantically correct, not just visually correct.

Title tags and meta descriptions must be editable per page. Templates that auto-generate title tags from a single CMS field ("Page Title | Brand Name") strip away years of carefully optimized title tags. Every page needs its own editable title tag and meta description field that migrated content can map into directly.

Canonical tags must be self-referencing by default and overridable when needed. The default behavior should be a self-referencing canonical on every page. But the CMS needs to support overriding the canonical for pages where you need to point it elsewhere — paginated content, filtered views, or intentionally duplicated pages.

Build schema markup into the template layer rather than adding it manually after launch. This is critical. If you wait until after migration to add schema, you lose structured data visibility during the reindexing window when you need it most. The new templates should generate the same schema types as the old site, populated by CMS fields. I covered this in depth in my piece on building a scalable schema markup architecture — the template system I describe there was originally designed during a migration, specifically to avoid losing schema coverage during the transition.

Verify that new templates generate clean, crawlable HTML. No critical content hidden behind JavaScript rendering that requires additional fetch cycles. No navigation or internal links loaded asynchronously in a way that search engines cannot discover on the initial crawl. Run the new templates through Google's URL Inspection tool and compare the rendered HTML against the raw HTML to identify any gaps.

Preserve internal links in navigation, footers, and sidebars. The template's global elements (header navigation, footer links, sidebar widgets) should maintain the same internal linking structure as the old site. If the old site's footer linked to all service category pages and the new template's footer links only to top-level pages, you have changed the internal link equity distribution — which changes how authority flows to deeper pages.

Content Freezes and the Timing Problem

Migrations do not happen in a vacuum. While you are migrating the site, the business keeps running. Content editors want to update pages. Marketing wants to launch new campaigns. Sales needs landing pages for an upcoming promotion. And the migration needs a stable target to migrate against. This operational challenge is often overlooked in migration planning and causes more real-world problems than any technical issue.

Implement a content freeze window and communicate it early. A content freeze means no new pages are published and no existing pages are modified on the old site during the migration window. This gives you a stable snapshot to migrate against. Communicate the freeze to every stakeholder who touches the website at least four weeks before it begins. Content editors, marketing teams, product managers — everyone needs to plan their publishing schedule around the freeze.

Have a process for tracking delta changes. Even with a freeze, there will be exceptions. Emergency content updates, legal compliance changes, and time-sensitive promotions may need to go live during the migration window. You need a formal process for tracking these changes so they can be replicated on the new site before launch. A shared document where stakeholders log any content changes made during the freeze period prevents updates from falling through the cracks.

Coordinate launch timing with business priorities. Do not launch during your biggest sales month. Do not launch the week before a major marketing campaign. Do not launch during the holiday season. The two to four week post-migration monitoring period will consume significant team bandwidth, and if organic traffic dips temporarily (which is normal), you do not want that dip coinciding with the business's peak revenue period.

Have a rollback plan. If something goes catastrophically wrong on launch day — mass 404 errors, server failures, critical template bugs — you need the ability to revert to the old site within hours, not days. This means keeping the old site's infrastructure live (but not publicly accessible) for at least two weeks after launch. A rollback plan you have never tested is not a rollback plan. Test it in staging before migration day.

Launch Day Is Not the Finish Line

The migration launches. The redirects fire. The new site is live. This is not the end of the project. This is the beginning of the most critical monitoring phase in the entire process. Problems caught in the first 48 hours can be fixed before they cause lasting damage. Problems caught after two weeks may have already cost you rankings that take months to recover.

Monitor Google Search Console indexing reports hourly for the first 48 hours. Watch the Coverage report for spikes in errors, particularly 404s, soft 404s, and server errors. Watch the submitted vs indexed URL count. If the indexing rate drops sharply, Google is having trouble processing the migration and you need to investigate immediately.

Watch for crawl errors, soft 404s, and server errors in real time. Set up server log monitoring to track Googlebot's activity on the new site. You want to see Googlebot discovering new URLs and getting 200 responses. If you see Googlebot hitting old URLs and getting 404s instead of 301s, your redirects have gaps.

Track keyword positions daily for the first two weeks. Not weekly. Daily. Use your rank tracking tool to monitor your priority keyword set every day. Some fluctuation is normal during the reindexing period. A keyword dropping from position 3 to position 8 temporarily is expected. A keyword dropping from position 3 to position 40 is a problem that needs immediate investigation.

Verify that Google is discovering and indexing new URLs at an acceptable rate. Submit the new sitemap in Search Console and monitor the "Sitemap" report for processing status. If Google is not picking up new URLs after 48 hours, check for crawl blocks, robots.txt issues, or noindex tags that may have been accidentally deployed on the new templates.

Check that all redirects are resolving correctly in production. What worked in staging may not work in production due to CDN caching, server configuration differences, or load balancer behavior. Crawl a sample of old URLs against the production site and verify every redirect resolves to the correct destination with a single 301 hop.

Monitor organic traffic trends at the page level. Site-level traffic can mask individual page losses. If ten pages each lose 50% of their traffic but twenty other pages gain 10%, the site-level number might look flat. Page-level monitoring catches these hidden losses before they compound.

Set up alerts for significant traffic drops. Any page that drops more than 20% in organic traffic within the first 30 days post-migration should trigger an investigation. Automated alerting catches problems that manual spot-checks miss. Beyond organic traffic monitoring, consider tracking whether your pages continue to appear in AI answer engines post-migration — AI search visibility can shift after a URL change just like traditional rankings.

What I Got Wrong

Twenty-plus migrations have given me plenty of opportunities to make mistakes. Here are the ones that taught me the most.

Underestimating how long redirect chains from previous migrations had been compounding. On one migration, I discovered that some URLs were already three hops deep from a previous platform change years earlier. Adding our migration's redirect created a four-hop chain that Google stopped following entirely. Those pages disappeared from the index. Lesson: always audit the existing redirect landscape before adding new redirects.

Not documenting image and PDF URLs that had accumulated backlinks. I was thorough about mapping HTML page redirects but completely missed the fact that several PDF downloads and product images had been linked to by industry publications over the years. When the new CMS changed the media library URL structure, those assets returned 404s and the backlink equity evaporated. Lesson: your URL audit must include every resource type, not just pages.

Trusting CMS auto-generated meta descriptions instead of migrating the originals. The new CMS had a feature that auto-generated meta descriptions from the first 160 characters of page content. It seemed convenient. It was not. The auto-generated descriptions replaced years of carefully crafted, click-optimized meta descriptions with generic content excerpts. Click-through rates dropped measurably for pages where the original meta descriptions had been performing well. Lesson: always migrate existing meta data as discrete fields.

Launching on a Friday. Never launch on a Friday. If something breaks Friday evening, you have a skeleton crew available to fix it over the weekend while Googlebot crawls the broken site for 48 hours. Every migration should launch on a Tuesday or Wednesday morning, giving you the full work week to monitor and respond to issues. I learned this one the hard way.

Not building automated monitoring early enough. For my earlier migrations, post-launch monitoring was entirely manual. I checked Search Console, ran crawls, and reviewed rankings by hand. Problems were caught days later instead of hours later because I could not check everything at once. Now I set up automated alerts and monitoring dashboards before launch day, so the system catches issues faster than any human could. Lesson: invest in monitoring infrastructure before you need it, not after.

The Migration Checklist I Use Now

Distilled from every lesson above, this is the high-level checklist I follow for every migration. It is not a step-by-step tutorial — it is the critical checkpoints that I have learned cannot be skipped.