How to Do SEO After Domain Migration
On this page
- Reframe the drop before you diagnose it
- The canonical-conflict trap
- Read the not-indexed reasons
- Hunt the stray old-domain references
- Confirm Change of Address and the structural basics
- Outreach, not disavow
- Monitor and narrate
- Frequently Asked Questions
- My redirects all work but traffic still dropped. What is wrong?
- Should I disavow the links to my old domain?
- Sources
- Related posts:
After a domain change, traffic drops not because the redirects are broken but because Google has to re-consolidate years of accumulated trust signals onto a new identity, a process measured in months rather than days. Your job in the recovery window is not to speed Google up, which you cannot do, but to remove every conflicting signal that stalls consolidation, the most insidious of which is a CDN-level canonical header still pointing back to the old domain, and to manage the recovery narrative so the business understands this as a known cost of brand consolidation rather than a sign that something broke.
This post owns the post-move forensics: diagnosing why a completed migration is underperforming, the canonical-conflict failure modes, the stalled-consolidation checks, backlink-outreach priority, and recovery monitoring. The at-launch release mechanics, including filing the Change of Address as part of executing the move, belong to the live-migration playbook; here, Change of Address appears only as a recovery checkpoint to confirm or repair when consolidation has stalled. Three boundaries are worth stating plainly. A redesign on the same domain, where templates or URLs change but the brand identity does not, is a different case. Merging two separate domains into one is its own case. This post is specifically one brand identity moving to a new domain and recovering afterward.
Reframe the drop before you diagnose it
The first deliverable is interpretation, not action. A temporary traffic loss after a domain move is the expected pattern, not necessarily a failure, because Google is recalculating which signals attach to the new domain and that recalculation takes time. Moving from a stronger, older domain to a newer or weaker one extends the timeline and may not recover to one hundred percent, since some of the lost performance was tied to the age and history of the old identity. Setting that expectation up front prevents the panicked re-redirecting that often makes recovery worse.
The canonical-conflict trap
The single highest-value diagnostic is the HTTP-header canonical check, because it catches a failure that looks invisible in the page source.
A correctly configured migration sends a 301 from every old URL saying “go to the new domain,” and the new pages carry an HTML canonical pointing to themselves. But a CDN or cache layer can inject a rel=canonical HTTP response header, and that header can point back to the old domain. When the HTTP-header canonical and the HTML canonical disagree, the conflicting signals can leave Google indexing neither version cleanly. Teams check the HTML source, see the canonical is correct, and never think to inspect the response headers where the contradiction actually lives.
Check the canonical in the HTTP headers, not just the HTML, for any page that is stuck. Request the URL and read the full response header set; if a Link: rel=”canonical” header references the old domain, clear the CDN cache and fix the layer that is emitting it. This is the check that most often unsticks a stalled migration.
Read the not-indexed reasons
The Page Indexing report in Search Console tells you what stage each stuck page is in, and each reason implies a different cause. “Page with redirect” on a new-domain URL is wrong and suggests a redirect loop or a misrouted rule. “Duplicate without user-selected canonical” points back at exactly the canonical conflict above, where Google sees competing signals and has not committed to your preferred version. “Crawled – currently not indexed” on new-domain pages suggests Google has visited but is withholding judgment while it consolidates, which is often a waiting problem rather than a fixable one, though it is worth confirming the page is not thin or near-duplicate. Read the reasons, group the stuck URLs by reason, and treat each group according to what it implies rather than applying one blanket fix.
Hunt the stray old-domain references
A find-and-replace across the codebase never catches everything, and the survivors leak signals to the dead domain. Links built dynamically in JavaScript, URLs stored in database fields, hardcoded references inside PDFs and whitepapers, canonical or hreflang tags generated by a template that still has the old host, and absolute links in syndicated or cached content all tend to survive the migration. Crawl the new site to surface internal links and resources still pointing at the old domain, and check the assets that a code search misses, especially downloadable documents, which crawlers and humans both follow to a domain you are trying to retire.
Confirm Change of Address and the structural basics
Verify that the Change of Address was filed at launch and is still valid. The tool lives in Search Console settings and signals Google that the move is intentional, which helps it transfer signals; Google forwards those signals for one hundred and eighty days after you start the move, then stops treating the old and new sites as related, so the filing has to be in place during the window that matters. If the filing lapsed, expired, or was never completed, file or re-file it now as a recovery step. While you are there, confirm trailing-slash consistency so /page and /page/ are not splitting signals, and confirm the 301s still resolve cleanly without chains, because a redirect that has decayed into a chain or a soft 404 stalls equity transfer.
Outreach, not disavow
Redirects pass equity, but a direct link to the new domain is a cleaner signal than an inherited one routed through a 301. Identify your top referring domains and reach out to update the most valuable links to point directly at the new URLs, prioritizing by the authority and traffic of the referring page rather than trying to convert the entire backlink profile. Do not disavow old-domain links. They are assets being transferred, not toxic links, and disavowing them would discard exactly the equity the migration is trying to preserve. Reserve the disavow tool for genuinely toxic links, which is its only purpose.
Monitor and narrate
Track indexed count, impressions, and average position weekly against a pre-move baseline, watching the new domain climb as the old domain’s residual presence fades. The pattern you want to see is the new domain’s indexed pages and impressions rising while the old domain’s decline, which together indicate consolidation is progressing. Recovery timelines are crawl-dependent and not promisable, so report progress as a trend rather than a date.
The other deliverable is the executive narrative. Frame the dip as the known, temporary cost of consolidating a brand onto a new domain, not as “we broke the site,” and pair it with the weekly trend so stakeholders see the trajectory rather than only the trough. Managing that story is as much a part of the recovery as any technical fix, because it buys the time the consolidation actually requires.
Frequently Asked Questions
My redirects all work but traffic still dropped. What is wrong?
Often nothing is broken; Google is re-consolidating trust onto the new domain, which takes months. But check two things first: the canonical in the HTTP response headers, in case a CDN is injecting one that points to the old domain, and whether the Change of Address filing is still valid. A correct 301 contradicted by a stale canonical header is the classic invisible stall.
Should I disavow the links to my old domain?
No. Those links are equity being transferred to the new domain through your 301s, not toxic links. Disavowing them discards the value the migration is meant to preserve. Use disavow only for genuinely toxic links, and instead reach out to your most valuable referring domains to update them to point at the new URLs directly.
Sources
Google Search Central, “Site moves with URL changes”: https://developers.google.com/search/docs/crawling-indexing/site-move-with-url-changes
Google Search Console Help, “Change of Address tool”: https://support.google.com/webmasters/answer/9370220
Google Search Central, “Page Indexing report”: https://support.google.com/webmasters/answer/7440203