A domain change is among the riskiest SEO operations a business can undertake. This guide covers the technical, structural, and timing mistakes that most often destroy traffic during a migration—and how to avoid them before irreversible damage occurs.
The most common domain change error is treating redirects as an afterthought. A 302 temporary redirect instead of a 301 permanent tells Google the old domain might return, so ranking signals remain split. Worse, many migrations produce redirect chains—old domain to a middleware URL, then to the new domain—which dilute PageRank and increase latency. Google follows redirects, but each hop is a friction point.
Map every old URL to its new equivalent in a spreadsheet before touching DNS. Use exact one-to-one 301 redirects wherever possible. If your URL structure changes, that mapping becomes critical: you cannot rely on blanket rules alone. Test with a crawler like Screaming Frog before the DNS cutover. Confirm status codes return 301, not 302 or 307. Verify no chains exist. A single misconfigured .htaccess wildcard or server block can cascade into hundreds of orphaned pages losing all authority. Quebec-based businesses migrating bilingual sites must map both /en/ and /fr/ trees independently; automated rules often break on language-path logic.
Google Search Console's Change of Address tool exists specifically for domain migrations, yet a surprising number of migrations skip it entirely. Without verifying ownership of both the old and new domains in GSC and submitting the formal request, Google treats your migration as two unrelated sites. Reindexing becomes speculative rather than guided.
Verify both properties in Search Console before launch. Immediately after redirects go live, submit the Change of Address request from the old property. This tells Google to transfer signals and accelerates index replacement. Keep the old domain's GSC property active for at least six months post-migration to monitor residual traffic and redirect errors. If you let the old domain expire or remove verification prematurely, you lose diagnostic visibility into what's breaking. Canadian agencies often see this mistake with clients who assume redirects alone are sufficient. They're not. The Change of Address signal is a ranked input Google uses to expedite trust transfer.
Changing your domain and redesigning your URL architecture in the same deployment multiplies risk exponentially. Each change introduces variables that complicate diagnosis when traffic drops. If rankings crater, you won't know whether it's the domain migration, the new URL patterns, the content reorganization, or redirect mapping errors.
Migrate the domain first with URLs mirrored exactly as they were. Once traffic stabilizes and the new domain is fully indexed, then consider URL structure changes as a separate project with its own redirect layer. This staged approach isolates variables. If you must change structure during migration, invest heavily in the redirect map: every old URL needs an explicit 301 to the semantically equivalent new URL. Do not use regex catch-alls unless paths are perfectly parallel. E-commerce sites with thousands of product URLs are especially vulnerable here. A botched category restructure during a domain change can orphan entire product catalogs, and Google interprets mass 404s as site quality problems, not migration intent.
After redirects go live, every internal link and canonical tag on the new domain must point to the new domain. If your new site's navigation, footer, XML sitemaps, or canonical tags still reference the old domain, you're sending mixed signals. Search engines see the new domain making 301 requests to itself via the old domain, a circular reference that screams uncertainty.
Audit internal links before launch. Use find-and-replace in your CMS database or template files to update hardcoded references. Regenerate XML sitemaps to reflect new URLs. Set canonical tags to self-referencing new URLs. Check hreflang annotations if you run multilingual properties—Canadian sites serving both English and French often hardcode old domain hrefs in alternate tags. Post-launch, crawl the new domain and filter for any outbound links to the old domain. These should only exist as edge cases or legacy content you plan to update. Persistent backward-pointing internals waste crawl budget and dilute the authority consolidation you're trying to achieve. This mistake is invisible to users but corrosive to rankings.
Timing a domain change during your peak season or launching the new domain with thin, incomplete, or untested content are both high-consequence errors. Peak periods mean higher crawl demand and user volume, which surfaces bugs faster but also amplifies revenue loss if things break. Launching with placeholder pages, missing metadata, or broken functionality signals to Google that the new domain is lower quality than the old.
Schedule migrations during low-traffic windows when your team has bandwidth to monitor closely. Stage the new domain in a development environment and crawl it exhaustively. Verify all content, images, structured data, and metadata are production-ready. Run load tests. Check mobile rendering. If you're a SaaS company or retailer, ensure checkout flows and forms work end-to-end. The new domain should be functionally superior or at minimum equivalent to the old. Google's quality algorithms compare the new domain to the old. If the new version is visibly incomplete, you risk being treated as a net-new site with no inherited authority, even if redirects are perfect. Montreal-based agencies have seen e-commerce clients lose 40-60 percent of organic traffic for months because they migrated to a half-built Shopify instance with missing alt text and broken category filters.
A domain change is not a one-day event. The first two weeks post-migration are critical for catching redirect failures, 404 spikes, and indexation stalls. Many businesses deploy redirects and walk away, assuming success. Meanwhile, soft 404s proliferate, orphaned pages accumulate, and crawl errors compound.
Monitor Google Search Console's Coverage and Experience reports daily for the first month. Watch for 404 errors on URLs that should redirect. Check server logs or CDN analytics to confirm 301s are firing correctly. Use a crawler to verify the new domain weekly and compare against a pre-migration baseline. If certain sections aren't getting indexed, investigate canonical conflicts, noindex tags, or robots.txt blocks that survived the migration. Ottawa-based enterprises migrating from legacy CMSs often discover hardcoded noindex directives in old templates that carried over. Redirect decay is real: CDN rules, server updates, or CMS plugin changes can silently break redirects weeks after launch. Sustained monitoring is the only way to catch and fix these regressions before they become entrenched ranking losses.
Google typically begins transferring signals within days if redirects and Search Console Change of Address are configured correctly, but full index replacement and ranking stabilization can take four to eight weeks. Complex sites with hundreds of thousands of URLs or weak crawl budgets may take longer. The process is not instant, and rankings often fluctuate during the transition as Google reassesses authority on the new domain.
Keep the old domain registered and serving 301 redirects for at least one year, ideally longer. This ensures all inbound links continue to pass authority and any residual traffic or bookmarks get funneled correctly. Letting the old domain expire risks it being purchased by a competitor or redirected elsewhere, which can create spam associations or break backlinks you've relied on for years.
Partial migrations are possible but complex. If you move a subdirectory or product category to a new domain, you need precise 301 redirects for those URLs and must ensure internal linking across both domains is logical. Google may treat the split as two separate entities, diluting authority. It's generally cleaner to migrate the entire site or keep everything on one domain unless there's a strong business case for separation.
A 302 indicates a temporary move, so Google may not transfer ranking signals and could continue indexing the old domain. If you catch this early, switch all 302s to 301s immediately and resubmit the Change of Address in Search Console. If weeks have passed, expect a delay in signal transfer and possible ranking volatility as Google reassesses. The damage is usually reversible but extends the migration timeline.
Blanket rules work only if your URL structure is perfectly parallel between old and new domains. If paths, parameters, or subdirectories differ at all, you need explicit URL-to-URL mappings. Missing or incorrect mappings lead to 404s, and Google interprets large-scale 404s as content removal, not migration. Build a comprehensive redirect map in a spreadsheet and test it with a crawler before deployment.
Paid traffic follows redirects just like organic visitors, so 301s will funnel clicks to the new domain. However, update destination URLs in all active ad campaigns immediately to avoid redirect latency and tracking parameter issues. Social shares and bookmarks will also follow 301s, but updating your social profiles, email signatures, and any hardcoded links in email campaigns is essential to prevent confusion and ensure analytics attribution remains clean.