Site migrations—whether switching domains, platforms, or restructuring URLs—pose real risk to organic traffic if core technical steps are missed. This guide walks through the critical errors that cause ranking drops and how to prevent them through proper planning, redirect mapping, and post-launch monitoring.
The most preventable mistake is migrating without a complete inventory of URLs that currently receive traffic, backlinks, or rank for target queries. Teams often rely on CMS-generated sitemaps or surface-level crawls, missing dynamic parameter URLs, archived content, or subdirectory structures that still hold authority.
Before any migration, run a full crawl using Screaming Frog or Sitebulb with custom extraction rules to capture every accessible URL. Cross-reference this with Google Search Console performance data filtered by clicks over the trailing twelve months, and pull backlink profiles from Ahrefs or Majestic to identify pages with inbound equity even if traffic is low. Export Analytics landing page reports to catch entry points driven by paid or referral sources.
The output is a prioritised inventory: tier-one URLs that must redirect one-to-one, tier-two content that can consolidate to stronger equivalents, and tier-three pages to intentionally retire with 410 status codes. Without this map, redirect rules default to guesswork, and valuable pages disappear from the index without ceremony.
A redirect chain occurs when URL A redirects to URL B, which redirects to URL C. Each hop dilutes link equity and increases latency; Google may stop following after three or four hops, leaving the final destination unindexed. This happens when migrations layer on top of previous moves, or when both old-to-new and www-to-non-www rules fire sequentially.
Redirect loops—where URL A points to B, and B points back to A—block indexing entirely and waste crawl budget until resolved. These typically emerge from conflicting rules in .htaccess, server config, and CMS-level redirects firing simultaneously.
Validate every redirect at the server response level using cURL or the redirect path tool in Screaming Frog before launch. Each legacy URL should return a single 301 directly to its canonical replacement, with no intermediate stops. After deployment, retest a sample of high-value URLs to confirm the path is clean. If you discover chains post-launch, update the rules immediately rather than assuming Google will parse through them; every extra hop costs you crawl efficiency and ranking signal pass-through.
Migrations often coincide with rebrands, redesigns, or platform switches, tempting teams to bundle changes. Moving from example.ca to newbrand.ca while simultaneously restructuring all category URLs, rewriting title tags, switching from Apache to Nginx, and overhauling internal linking creates a diagnostic nightmare if traffic drops.
When rankings decline post-launch, isolating the cause becomes impossible. Was it the redirect logic, the new URL structure, the server response time spike, the diluted anchor text, or the altered content? Recovery slows because every hypothesis requires sequential testing.
Where feasible, stage changes: migrate the domain first with identical URL paths and content, confirm indexing and traffic stability over two weeks, then introduce structural changes. If the timeline forces bundling, at least preserve URL structure or content layer to maintain one constant. Canadian sites with /en/ and /fr/ subdirectories should keep that structure intact if switching domains, avoiding simultaneous language-path changes. Document every variable altered so post-launch analysis can weight likely causes when troubleshooting.
Staging environments typically use robots.txt disallow rules or meta noindex tags to prevent premature indexing. The catastrophic error is launching the production site without removing these blocks. Google continues to crawl but refuses to index pages, and rankings vanish while the technical team celebrates a smooth deploy.
This mistake appears obvious in hindsight but occurs with surprising frequency, especially when different teams manage DNS, server config, and CMS settings. A developer updates the robots.txt file on staging but forgets the production sync, or a page template carries a noindex tag that no one audits post-migration.
Before DNS cutover, audit the new site's robots.txt file, meta robots tags in page source, and X-Robots-Tag HTTP headers. Use Google Search Console's URL Inspection tool on a sample of new URLs to confirm 'Indexing allowed' status. After go-live, submit the new XML sitemap and request indexing for priority pages. Monitor Index Coverage reports daily for the first two weeks to catch any no-index or robots.txt blocks that propagate from cached config files or CDN rules.
Even when external redirects are perfect, internal site links often still point to old URLs, forcing users and crawlers through unnecessary 301 hops. Navigation menus, footer links, and contextual article links hardcoded to legacy paths add latency and dilute crawl efficiency. Worse, some pages may only be reachable via external backlinks if internal links break entirely, rendering them orphaned.
Orphaned pages receive no crawl priority and typically drop from the index within weeks, even if the URL itself is functional and redirected correctly from the old domain. High-value content that ranks well can vanish simply because no internal path leads to it after migration.
After deploying redirects, crawl the new site and export all internal links. Filter for any href attributes still pointing to the old domain or deprecated URL patterns. Update these in templates, widgets, and CMS content fields to point directly to new canonical URLs. Resubmit the sitemap and use 'Request Indexing' in Search Console for previously orphaned pages to expedite their return. For Canadian sites with bilingual navigation, verify that language toggle links and hreflang annotations now reference new URLs, not old ones.
Many teams declare victory within days of go-live if no immediate traffic collapse occurs, but indexing and ranking adjustments unfold over weeks. Google may take time to recrawl all redirected URLs, re-evaluate content in its new context, and redistribute link equity. Delayed issues include partial indexing, keyword cannibalisation between old and new URL versions still in the index, and algorithmic re-assessment of the domain's authority.
Without systematic monitoring, these problems surface only after they've compounded. A page stuck in 'Discovered – currently not indexed' status for three weeks represents lost opportunity; a redirect returning 302 instead of 301 leaks equity silently until someone notices months later.
Establish a monitoring protocol that runs for at least eight weeks post-launch. Track Google Search Console metrics daily: Index Coverage status, Core Web Vitals, manual actions, and Security Issues. Compare week-over-week organic traffic and rankings in Analytics and your rank tracker, segmented by page template and content type. Set up automated alerts for serverside errors, redirect chains, and orphaned pages using Screaming Frog's scheduled crawls. For Canadian multi-regional sites, validate that geo-targeted pages for Toronto, Vancouver, and Montreal retain their local rankings and aren't being replaced by generic national pages in regional SERPs. Document anomalies immediately and prioritise fixes by traffic impact rather than assuming issues will self-correct.
Indexing of redirected URLs typically begins within days if sitemaps are submitted and no crawl blocks exist, but full ranking stabilisation often takes four to twelve weeks. Google recrawls the old URLs, follows redirects, evaluates content on new URLs, and redistributes link equity gradually. High-authority sites with strong crawl budgets stabilise faster than newer domains. Monitor Index Coverage and traffic weekly rather than expecting overnight recovery.
Yes. Maintain the old domain with active 301 redirects for at least twelve months, ideally longer if budget permits. This ensures backlinks continue passing equity as external sites slowly update their links, and gives Google ample time to transfer all signals. Letting the domain expire risks it being acquired by a competitor or parked service, breaking all inbound links instantly and erasing years of equity.
A 301 redirect signals a permanent move and transfers link equity to the new URL, telling Google to index the destination and drop the old URL from results. A 302 indicates a temporary move, preserving the old URL in the index and passing little to no equity. Using 302s during migration prevents proper indexing of new pages and fractures ranking signals. Always verify server responses return 301 status codes for migration redirects.
Yes, but it requires explicit validation of hreflang annotations, redirect mappings for both /en/ and /fr/ URL structures, and separate monitoring of French keyword rankings. Ensure each old French URL redirects to its exact new equivalent, not a generic English homepage. Update hreflang tags to reference new URLs, and verify in Search Console that both language versions are indexed correctly. Quebec-specific landing pages need particular attention to preserve local rankings.
First, audit for technical blocks: Check Index Coverage in Search Console for noindex tags, robots.txt disallow rules, or server errors. Verify redirect status codes are 301, not 302 or chained. Confirm internal links point to new URLs and that XML sitemaps reference new pages. If technical factors are clean, compare old versus new page content and title tags for unintended changes. Traffic drops from content or UX degradation require different fixes than redirect issues, so isolate the variable causing the decline before implementing corrections.
Prioritise based on traffic, backlinks, and ranking value. URLs with clicks in the past twelve months, quality backlinks, or top-ten rankings for target keywords deserve exact one-to-one mappings. Low-traffic pages covering similar topics can redirect to a single stronger piece of content, consolidating equity. Outdated or irrelevant pages with no traffic or links can return 410 Gone status instead of redirecting, signaling intentional removal and freeing crawl budget.