Your migration worked and traffic came back. Then, four months later, Google put the old domain back in results and moved more than 5,000 new-domain pages to "Crawled, currently not indexed." A site owner described exactly this on Reddit, as covered by Search Engine Journal, and the case makes a useful template for an audit.
According to that report, the move happened at the start of 2026 and traffic recovered around April, with the new domain at roughly 5,000 impressions per day. Four months later, the new domain dropped to about 20 impressions per week. Searchers who clicked the old URLs still landed on the new ones through redirects.
Treat it as a canonicalization problem, not a verdict
The report does not confirm why this happened. John Mueller replied: "Sometimes things just take a particularly long time to be fully processed." He offered to look at the domains if the owner sent them privately. He also pointed to one fix: set up Change of Address in Search Console for both the www and non-www versions, so Google can fully migrate the domain.
The article adds that approaching a troubled migration as a canonicalization issue is not unreasonable. Canonicalization is Google choosing one URL or domain to index and rank over the alternatives. That suggests a working hypothesis: something on your site, or on the web pointing at you, gives Google a reason to prefer the old host.
This is an inference, not a confirmed diagnosis. The audit below tests whether it applies to your site.
Why Google might reverse a migration months later
Search Engine Journal's report does not explain the mechanism, so treat these as candidates to test, not known causes:
- Change of Address covers only one host variant, leaving the other unmigrated.
- Hardcoded links to the old host still sit in templates or content.
- Redirects fail on certain paths.
- The old sitemap is still submitted.
- Canonical tags point back to the old domain.
- External links to the old www or non-www version keep nudging Google toward it, as the article suggests.
Any one of these can look harmless while traffic is recovering. Together, they may give Google conflicting signals about which host is the real one.
The audit, in priority order
Run these checks in sequence. Each has a verification method, so you finish with evidence instead of guesses.
Step 1: Confirm Change of Address for both www and non-www
Start here, because it is the one fix Mueller named. Open Search Console and list the properties that exist for the old site. You want a verified property for each host variant that has ever served content, such as www and non-www. Check Google's current Change of Address documentation for the exact property types it requires.
To verify, open Settings on each old property and read the Change of Address status. Both should name the new site as the destination. If one variant shows no submission, submit it and note the date, so you can measure what changes afterward.
Step 2: Crawl the new site for hardcoded links to the old host
The article flags absolute internal URLs as a way old-domain links sneak in. They can appear in site navigation, footer navigation, or contextual links within content. A link like https://old-example.com/page tells Google the old host still matters, while a relative path such as /page avoids the problem. The article's advice is to crawl the old domain with Screaming Frog before migrating, to catch stray absolute links early.
If you did not, crawl the new domain now with Screaming Frog or a similar crawler. Filter the internal links export for any destination on the old hostname. Then check the "Inlinks" detail to see which templates or posts contain them.
Also search your database or CMS for the old domain string, since a crawler may not surface every place a URL is stored. Fix at the template level first, then in content. We cover related ground in see also: how to tell if google indexing is stuck or just slow.
Step 3: Test redirect paths and chains
The article raises several redirect risks:
- A registrar-level redirect that doesn't preserve URL paths
- HTTPS forwarding that fails when the old domain has no SSL certificate
- Chained redirects
- Redirects that fail when the new site's navigational structure changes
Test a sample of old URLs, not just the homepage. Include top landing pages, deep posts, URLs with parameters, and both http and https on both hostnames.
Use curl to see every hop:
curl -sIL https://www.old-example.com/blog/some-post/ | grep -iE "^(HTTP|location)"
You want one hop to a 301, then a 200 on the exact equivalent URL. Two or more hops, a redirect to the new homepage, or a certificate error all need fixing. For scale, run a list of old URLs through a crawler in list mode and export the redirect chains report.
Step 4: Check sitemap host consistency
According to the article, XML sitemaps communicate preferred canonical URLs to Google, so a sitemap that still lists the old domain can send conflicting signals. Google's own migration guidance says, "Submitting a sitemap can help make the discovery process quicker, and it's fine to move your site in sections." That advice assumes the sitemap names the correct domain.
Open the Sitemaps report in both properties. The new property should list a sitemap containing only new-host, indexable, 200-status URLs. Open the sitemap file and scan for the old hostname. Also confirm that robots.txt on the new domain doesn't reference an old sitemap location.
Whether to keep an old-domain sitemap submitted during a move is a judgment call, so follow Google's current migration guidance. Avoid an old sitemap that lists URLs which no longer return what Google expects.
Step 5: Audit canonical tags and compare declared versus selected
View source on several new-domain pages and confirm each rel=canonical points to the same URL on the new host. Then run your crawler's canonicals report and filter for any canonical pointing to the old domain, a different protocol, or a different hostname variant. Check HTTP headers as well, since canonicals can be set there, and review SEO plugin settings that may store a base URL.
Next, use URL Inspection. Inspect a new-domain URL and compare the user-declared canonical with the Google-selected canonical. If they differ and Google selects an old-domain URL, you have direct evidence of the conflict. This pairs well with go deeper on how to fact-check ai-generated metadata before publishing.
For pages marked "Crawled, currently not indexed," canonical details may be limited. In that case, also inspect the equivalent old URL in the old property and see which canonical Google selects.
Signal-to-tool reference table
| Signal | What to check | Tool or report | Healthy result | |---|---|---|---| | Change of Address | Submitted for www and non-www old properties | Search Console, Settings, Change of address | Both variants show the new site as the destination | | Hardcoded links | Old-host URLs in templates and content | Crawler inlinks export, database search | No internal links to the old hostname | | Redirects | One hop, 301, same path, valid HTTPS | curl -I, crawler redirect chains report | Single 301 to the equivalent URL returning 200 | | Sitemaps | New host only, valid URLs | Sitemaps report, sitemap file, robots.txt | No old hostname in the new sitemap | | Canonicals | Self-referencing on the new host | Crawler canonicals report, view source, URL Inspection | Declared and Google-selected canonicals match |
A hypothetical worked example
This example is illustrative. It is modeled on the symptoms in the Reddit report, and the findings below are invented to show how the audit reads. They are not real results.
Symptoms: The new domain shows thousands of URLs as "Crawled, currently not indexed." The old domain shows impressions again. Old URLs redirect when opened in a browser.
Findings:
- Change of Address was filed from the non-www old property only. The www property shows no submission.
- A crawl of the new site finds the old hostname in a sitewide footer "Popular posts" widget.
- curl on a sample of old URLs shows that http requests on the www host take two hops before reaching the new page.
- The new sitemap is clean, but an old plugin-generated sitemap is still submitted in the old property.
- Canonicals are correct on posts. URL Inspection on an old URL shows the Google-selected canonical as the old URL itself, even though it redirects.
Fixes:
- Submit Change of Address for the www property.
- Replace the footer widget's absolute links with new-host or relative links.
- Collapse the two-hop redirect into one.
- Remove the stale sitemap.
- Re-inspect a sample of URLs in both properties and request indexing for key pages.
Also read: related topic: how to build an ai visibility prompt set by tag (template)
In a real case, you could not know which of these mattered most. Fix everything you find, log the dates, and watch the Page indexing report for changes.
When to wait and when to escalate
Wait if the audit is clean and nothing changed recently. Mueller said processing can take a particularly long time, and Search Engine Journal's headline says migrations can exceed four months. Waiting makes sense only after you have ruled out the five conflicts above.
Fix now if you find any conflict. Waiting will not resolve a bad redirect, a stray canonical, or a missing Change of Address submission.
Escalate if the audit is clean and the new domain still sits in "not indexed" while the old one ranks. Mueller offered to look at the Reddit owner's domains privately, so asking Google for help is a reasonable step. Bring both domains, the migration date, the Change of Address dates, and your curl and URL Inspection evidence. Specific evidence gives anyone who looks a place to start.
Avoid redoing the migration. Nothing in the report suggests it would help.
What to expect next
No fix here guarantees a recovery or a timeline, and the report does not confirm the cause of the Reddit case. After your changes, expect a slow, uneven re-evaluation.
Each week, track the new domain's indexed page count, the old domain's impressions, and the Google-selected canonical on a fixed sample of URLs. If the old domain's visibility declines and the selected canonicals move to the new host, the fixes are likely working, even if full recovery takes months.
