Common technical SEO issues in large migrations (and fixes)

Large site migrations fail in predictable ways. The same issues appear across CMS replatforms, domain consolidations, and URL restructures – not because they are difficult to fix, but because they are easy to miss in the complexity of a large deployment. This breakdown covers the eight most common causes of migration-related traffic loss, and what to do about each.

Key Takeaways

  • Incomplete redirect maps and canonicalisation errors account for the majority of post-migration traffic drops

  • Most of these issues are detectable in staging before go-live – the cost of finding them there is a fraction of the cost of remediating them in production

  • JavaScript rendering issues introduced during a platform migration often go undetected for weeks because they are invisible in browser testing

  • Each issue listed here has a specific, actionable fix – none require a rollback

Issue 1: Incomplete redirect map

Problem: URLs with organic traffic or backlink value are not included in the redirect map and return 404 after launch. This is the single most common cause of post-migration traffic loss.

Fix: Conduct a full pre-migration crawl and cross-reference every URL against Google Search Console traffic data and backlink data. Any URL with organic visits or inbound links in the past 12 months must have a 301 redirect. Use a spreadsheet to track every URL, its redirect destination, and its validation status before go-live.

The scale of this issue is often underestimated on large sites. A site with 500,000 pages may have 200,000 URLs with zero organic traffic that can be safely allowed to 404 – but identifying which 200,000 requires the data, not an assumption.

Issue 2: Redirect chains and loops

Problem: New redirects point to old URLs that themselves redirect, creating multi-hop chains. In the worst cases, loops form where URL A redirects to URL B, which redirects back to URL A. Both waste crawl budget and dilute link equity.

Fix: After implementing the redirect map, crawl the redirect inventory specifically to detect chains and loops. Consolidate all chains to single-hop 301s pointing directly to the final destination URL. Test the full redirect map in a staging environment before applying to production.

Issue 3: Canonicalisation errors on the new site

Problem: Canonical tags on the new site point to old URLs, to the wrong page type, or are missing entirely. This is particularly common when canonical logic is template-driven and the templates are not fully reviewed before launch.

Fix: Audit canonical tag implementation across all page types in staging. For each template, confirm that: (1) self-referencing canonicals point to the correct new URL, (2) canonicals do not reference old domain or URL patterns, and (3) paginated pages handle canonical logic consistently. Run a crawl in staging specifically to extract and validate canonical tags at scale.

Issue 4: Robots.txt blocking the new site

Problem: The most preventable migration issue. The staging environment’s robots.txt disallow-all configuration is either carried into production or the production robots.txt is incorrectly configured at launch, blocking Googlebot from crawling the new site entirely.

Fix: Make robots.txt configuration a specific launch checklist item owned by a named individual. Check it within the first 30 minutes of go-live. Set up a Search Console alert for coverage drops. If Googlebot is blocked post-launch, correct the robots.txt immediately and submit the sitemap to accelerate recrawl.

This issue has caused significant organic traffic loss for large sites that went undetected for days because browser testing shows the correct page regardless of robots.txt configuration.

Issue 5: JavaScript rendering regressions

Problem: A move to a JavaScript-heavy front end, or a change in how JavaScript is handled during a platform migration, introduces rendering gaps that are invisible in browser testing. Content, internal links, or structured data present in the browser are absent from the raw HTML served to Googlebot.

Fix: Conduct a dedicated rendering audit in staging: capture raw HTML and rendered DOM for representative URLs across each major page type and compare them systematically. Any content or links present only in the rendered version are at risk. Where possible, implement server-side rendering or pre-rendering for critical content rather than relying on client-side execution.

This is why a rendering audit is a distinct phase from a standard crawl. SUSO Digital captures raw HTML alongside rendered output across all major page templates as part of their migration audit scope – the gap between the two is where indexation issues hide on JavaScript-heavy sites.

Problem: After the migration, internal links within the new site still reference old URL patterns. This creates unnecessary redirect hops for crawlers following internal links and signals inconsistency in site architecture.

Fix: Run a full crawl of the new site after launch specifically looking for internal links that resolve through a redirect rather than pointing directly to the new URL. Update all internal links to reference new URLs directly. Pay particular attention to navigation elements, breadcrumbs, and any programmatically generated internal links driven by CMS templates.

Issue 7: Hreflang errors on international migrations

Problem: International migrations that change URL structure, subdomain configuration, or ccTLD setup frequently introduce hreflang errors. Missing return tags, incorrect language codes, and hreflang-canonical conflicts are all common – and all cause Google to discount the international targeting signals.

Fix: Validate the complete hreflang implementation in staging before launch. Confirm that every hreflang tag has a corresponding return tag in the referenced page. Check that hreflang language and region codes are correct for each market. Confirm that hreflang-referenced URLs match canonical URLs exactly, including trailing slashes and protocol.

Issue 8: XML sitemap not updated

Problem: The XML sitemap submitted to Search Console still references old URLs after the migration, either because it has not been regenerated or because the sitemap generation logic has not been updated to reflect new URL patterns.

Fix: Regenerate the XML sitemap from the new site after launch and confirm it contains only new URLs returning 200 status codes. Submit the updated sitemap to Search Console immediately after go-live and monitor the coverage report to confirm Google is processing it correctly. Remove any sitemaps referencing old URLs from Search Console.

Preventing issues versus remediating them

Every issue in this list is significantly easier to prevent than to remediate. Detection in staging takes hours; remediation in production – after Googlebot has cached errors, after rankings have shifted, after users have encountered broken experiences – can take weeks or months.

The common thread across all eight issues is preparation: a thorough pre-migration audit, a validated redirect map, and a structured staging review process. Migrations that invest properly in these three phases rarely encounter issues that require post-launch recovery. Migrations that compress or skip them almost always do.

Specialist agencies that focus on large-scale technical SEO, like SUSO Digital, build pre-migration audit and staging validation in as the primary deliverable, not a preliminary step. Their migration process covers all eight issues in this list as structured checklist phases before a single URL goes live. That front-loaded investment is what separates a clean migration from a months-long recovery.

FAQs

How quickly should I expect rankings to recover after fixing these issues?

Recovery timelines depend on how long the issue was present before being fixed and how frequently Googlebot crawls the affected pages. For high-crawl-frequency pages on large sites, corrections to redirects and canonicalisation can be processed within days. For lower-value pages, it may take two to four weeks. Full traffic recovery to pre-migration baseline typically takes four to twelve weeks after all issues are resolved.

Do I need a rollback plan?

Yes, but it should be a last resort. A rollback reverses the technical work of the migration but does not undo the SEO damage caused by a failed launch – crawl data, index changes, and ranking signals do not roll back cleanly. The better investment is prevention: a thorough staging review that means a rollback is never needed.

What’s the earliest sign that a migration has gone wrong?

An unexpected spike in 404 errors in Search Console within the first 24 hours is the earliest and most reliable signal. A sudden drop in crawl activity – visible in server logs – indicates a robots.txt or server configuration issue. Either signal warrants immediate investigation, not a wait-and-see approach.