If your old domain still shows in Google, or comes back months after a move, the most likely explanation is slow signal consolidation plus a fixable setup problem, not a penalty. Google's John Mueller said on 13 October 2026 that domain moves "sometimes... take a particularly long time to be fully processed," and Google's documentation says to submit Change of Address for every verified variant of the old domain. This guide, current as of 14 October 2026, gives a diagnostic order, a decision table and what not to do.
Key Takeaways
- An old domain appearing in a
site:search or in Search Console for months is common; redirects do not instantly remove old URLs from the index. - Mueller advised setting up Change of Address for both www and non-www versions, and Google reportedly updated documentation to say so.
- Change of Address effects last 180 days per Google's help page, and a Search Central community guide says there is no formal "completed" status.
- Never noindex, block, 404 or remove the old domain during the move; that cuts signal transfer.
- If new-domain pages show "Crawled - currently not indexed", treat it as a quality and discoverability question, not only a migration one.
- Diagnose in order: redirects, canonicals, sitemaps, internal links, Change of Address, then content quality.
The case that started this
On 13 October 2026, Search Engine Roundtable summarised a Reddit thread. A site owner renamed and moved domains early in 2026, set up redirects and Change of Address, and saw traffic recover by April at roughly 5,000 impressions a day. About four months later, over 5,000 pages on the new domain were marked "Crawled, currently not indexed", impressions fell to around 20 a week, and Search Console began showing impressions on the old domain again.
Mueller replied that things can take a long time and advised Change of Address for both www and non-www. Marie Haynes suggested a migration can trigger a fresh quality evaluation, and Barry Schwartz suggested a Google-side issue was possible, noting other reports of migrations going wrong months later. Those are theories, not findings. Search Engine Journal's report adds its own analysis of common causes, which it does not attribute to Google.
Why an old domain can linger at all
A Search Central community guide explains the mechanism. Redirects do not remove old URLs from the index. Google keeps fetching content via the redirect and treats the old URL as the main entry until signals transfer. Change of Address requests stay active for 180 days, and old URLs can remain indexed for years as a safety buffer. This is a community guide, not an official policy page, so I treat it as explanatory rather than binding.
Google's own site move documentation says a move is complete only after Googlebot has visited every old and new URL at least once, and that small and medium sites may take weeks or more. So "months" is not automatically a failure.
The diagnostic order
I work through these in order, because early causes are cheap to fix.
1. Test the redirects with real URLs
Google's redirect documentation treats 301 and 308 as permanent and 302, 303 and 307 as temporary, where Google may keep the source page in results. It also warns that JavaScript redirects may never be seen if rendering fails. A temporary code on a permanent move is a common reason an old URL stays visible.
Take 30 old URLs across templates (home, category, article, product, PDF). For each, confirm a single server-side 301 or 308 to the exact equivalent new URL. Google advises avoiding chains, ideally no more than three hops and fewer than five at most, and not sending many old URLs to one unrelated page such as the homepage. Registrar-level redirects that drop the path are a classic culprit, per SEJ's analysis.
2. Check canonicals and absolute links
Google's canonicalization documentation lists protocol, redirects, sitemap inclusion and rel="canonical" as canonicalization factors, and says a canonical tag is "a hint, not a rule". That is why mixed signals, such as a redirect pointing one way and a sitemap or canonical pointing the other, can leave Google choosing the old URL.
Search the new site's templates, navigation, schema and content for hard-coded old-domain URLs. Check that every new page has a self-referencing canonical on the new domain. A leftover old canonical sends the opposite signal to your redirect.
3. Check sitemaps
The new sitemap should list only new URLs. An XML sitemap that still lists the old domain sends conflicting signals, again per SEJ. Submit sitemaps for both properties. The community guide notes "Couldn't fetch" usually means Google has not processed the file yet.
4. Confirm Change of Address for every variant
Google's Change of Address help page says you must own both properties, use domain-level properties, and include www and other verified variants because the tool does not move subdomains. Its effects last 180 days, and Google recommends keeping redirects for at least that long, and considering keeping the old domain registered for at least a year. After 180 days Google treats the old site as unrelated to the new one, so a request that has expired is worth noticing.
Google's documentation says to submit requests for every verified variant of the old domain, including www and non-www versions and subdomains, even unused ones. It also says not to use the tool for HTTP to HTTPS, www to non-www on the same domain, or path moves.
5. Look at what you did to the old domain
Avoid 404s, noindex tags, robots.txt blocks or the Removals tool on the old domain, per the community guide. These can cut signal transfer and make both domains drop.
6. Only then, question content quality
If new-domain URLs are "Crawled - currently not indexed", the guide says treat the new domain like a standalone site: check soft 404s, speed, internal links and whether pages add distinct value. Compare against my content audit routine.
Cheap checks first: redirects and canonicals before theories about quality.
Symptom-to-cause table
| Symptom | Most likely causes | First check |
|---|---|---|
site:old-domain still shows pages | Normal consolidation lag | Wait; verify redirects and Change of Address are active |
| Old domain shows in Search Console performance | Google chose old URLs as canonical | Canonicals, sitemap, internal links to new URLs |
| New pages "Crawled - currently not indexed" | Low crawl priority, thin or duplicate content, soft 404s | URL Inspection on a sample; content distinctiveness |
| Traffic recovered, then dropped months later | Reprocessing, possible quality re-evaluation, or Google-side issue (theories) | Log and compare; escalate with evidence |
| Only some sections affected | Broken mapping for specific templates | Redirect test by template |
| Old PDFs or images indexed | Files not redirected | Include file types in redirect map |
What evidence to collect before asking for help
Mueller asked the Reddit poster to message him directly, so Google does look at well-documented cases. Prepare a one-page evidence pack:
- the migration date and what changed (domain, CMS, URL structure);
- a redirect test sheet with 30 sample URLs and status codes;
- a Search Console screenshot of both properties' performance with dates;
- URL Inspection results for five old and five new URLs;
- a list of Change of Address requests with the verified variants.
Use log file analysis to confirm Googlebot is requesting new URLs and following redirects. Do not post private client data in public forums.
An evidence pack makes it easier for anyone, including Google, to see the problem.
What not to do
- Do not remove or block the old domain to "force" the switch.
- Do not change several things at once. Google's guide says change one thing at a time, such as domain, CMS or layout.
- Do not file repeated Change of Address requests hoping for a reset.
- Do not assume it is a penalty. Check Manual Actions, but a migration lag is not a manual action.
- Do not rely on a single
site:check. Schwartz notes old-domain results in asite:search are expected behaviour.
How long should I wait?
Google says redirects should be kept "generally at least 1 year" and indefinitely if possible. For smaller sites, expect weeks for most pages. Beyond four months with new pages unindexed, escalate your diagnostic rather than wait. For planning a move, see the companion site migration checklist.
FAQ
Why is my old domain still showing in Google after a migration?
Redirects do not delete old URLs from the index. Google keeps the old URLs until signals consolidate on the new ones, which can take weeks to months. Check redirects, canonicals, sitemaps and Change of Address first.
Is it normal for an old domain to reappear after four months?
It is not unusual enough to panic. Mueller said processing can take a particularly long time. A reappearance with new pages deindexed deserves investigation, since Search Engine Roundtable notes similar reports from others.
Should I set up Change of Address for www and non-www?
Yes. Google's documentation says to submit a request for every verified variant of the old domain, including subdomains and www and non-www versions. Mueller gave the same advice in the Reddit thread.
How long does a Change of Address last?
A Search Central community guide says requests remain active for 180 days and then expire, with no formal completed status. Keep your redirects in place regardless; Google recommends at least a year.
What does "Crawled - currently not indexed" mean on a new domain?
Google fetched the page but chose not to index it. After a migration, that can reflect low crawl priority, thin or duplicate content or technical issues. Treat the new domain like a standalone site and check quality and internal links.
Could this be a Google bug?
Possibly. Barry Schwartz suggested it, citing reports from others, but it is his hypothesis and not Google's confirmation. Collect evidence and share it politely with Google through official channels.
Should I 404 the old domain to push Google along?
No. Blocking, noindexing, 404ing or removing the old domain can cut off signal transfer and cause both domains to drop, according to the community guide.
Can I fix this by resubmitting the sitemap?
Submitting sitemaps for both domains is good practice, but Google may not read them promptly. Clean redirects, correct canonicals and strong internal links matter more.
Does a domain migration trigger a new quality evaluation?
Marie Haynes theorises it does, and that Google may be stricter about what it indexes afterwards. That is a theory, not something Google has confirmed, but it is a reason to audit thin pages on the new site.
Work with me
I'm Younus Fardeen, an organic growth and AEO marketer with 4+ years of marketing experience across edtech and startups. If a migration has gone sideways or you are planning one, see my work and reach me through the contact form at https://younusfardeen.in.