Site Migration: Crawled – Currently Not Indexed

1. What Happened? – Site Migration: Crawled – Currently Not Indexed

A case posted to the community in September 2026 is one of the cleanest illustrations of migration failure we have seen, precisely because the team did almost everything right.

A six-year-old domain was migrated to a new one in mid-June 2026 as part of a company rebrand. The checklist was exemplary: page-to-page 301 redirects, single hop, verified. Change of Address submitted three days before launch. Both properties verified and the old property kept live. A clean sitemap index. No manual actions, no security issues. Post-migration internal linking problems found and fixed within ten days.

Google responded exactly as the documentation says it should. Around 227 pages were indexed on the new domain by late July. The migration looked finished.

Then, in a single batch between 24 and 29 July, impressions fell to near zero and roughly 252 pages moved to “Crawled – currently not indexed.” The excluded set was not a random sample. It included the site’s best-performing pages from the old domain – pages that had held positions five to fifteen with six-figure impression counts – plus the contact page.

URL Inspection on every one of them reported the same thing: crawl allowed, fetch successful, indexing allowed, user-declared canonical matching Google-selected canonical. No technical barrier anywhere.

The team then did what every team does. They pruned thin taxonomy pages from the sitemap and noindexed them. They fixed a duplicate path variant. They removed malformed URLs a plugin had been emitting. They requested indexing manually on priority pages. They updated external profiles to point at the new domain. Validation was started on 12 August. It failed.

Three months in, the site is effectively invisible.

The community answer was that this is normal migration reprocessing – be patient, keep the redirects clean, strengthen internal links. That advice is not wrong, and Google’s own domain migration community guide supports it: migrations “rarely (if ever) happen as a single, clean ‘switch flip'”, and pages unique to a new domain “often get queued in ‘Crawled – currently not indexed'” while trust is established.

But it is an incomplete reading of this case, and the incompleteness is the reason the site is still down. Two details in the thread were never addressed, and both point somewhere other than patience.

2. Why Does It Matter? – Site Migration: Crawled – Currently Not Indexed

The failure pattern is the opposite of what teams plan for

Every migration runbook in the industry optimises for launch day. Redirects mapped, Change of Address filed, sitemaps swapped, analytics annotated. The go-live is treated as the risk event, and if traffic holds for a fortnight the project is declared a success and closed.

This case is the counter-example, and it is the common one. Indexing was perfect for five weeks. The failure arrived on a date when nobody was looking, long after the migration Slack channel had been archived and the contractor had invoiced.

Google’s own timeline expectations encourage this blind spot. The documentation says that for medium-sized websites “it can take a few weeks or more for Google to gradually start showing the new URLs instead of the old ones (and for larger sites, even longer)”, and to “expect temporary fluctuation in site ranking during the move”. Both statements are true. Both are also a perfect alibi for a real failure, because for the first eight weeks every symptom is indistinguishable from normal reprocessing.

The practical consequence: the monitoring window for a migration is at least six months, not six weeks. Almost nobody budgets for that.

Clean technical signals are a diagnosis, not a reassurance

This is the single most misread situation in technical SEO, and it is the trap this team fell into.

When URL Inspection reports crawl allowed, fetch successful, indexing allowed and canonical agreement – and the page still is not indexed – most teams read that as “we have done everything right, so this must be Google’s problem” and respond by re-requesting indexing and re-running validation.

The correct reading is the opposite. Green signals rule out the technical layer. “Crawled – currently not indexed” with no technical barrier is, as reported of Mueller’s guidance, a reflection of Google’s quality evaluation rather than a technical error. The diagnosis has already been delivered; the team just read it as a clean bill of health.

Every hour spent hunting for a technical barrier after that point is an hour wasted, but still billed for.

A rebrand is two migrations, and only one of them has a tool

This is the part that was missing from the thread entirely, and it is the reason we think this case is worth an article rather than a forum reply.

The old domain was crmforyourbusiness.com. The new one is hourless.net. That is not a domain change. That is a domain change and an entity change executed simultaneously.

Six years of accumulated signals – links, anchor text, brand mentions, directory entries, co-occurrence in content about CRM implementation – all describe an entity whose name contains the words “CRM for your business”. Every one of those signals now points, via redirect, at an entity called Hourless, which as far as Google’s systems are concerned did not exist in May.

Google has a tool for moving a domain. It has no tool for moving an identity. The Change of Address feature handles URL-level consolidation; it does nothing to tell Google that the organisation formerly described by one name is now described by another. That transfer happens slowly, through corroboration across the open web, and it is the part of a rebrand that no project plan ever costs.

For a CMO, this is the line that matters: the SEO risk of changing your name is larger than the SEO risk of changing your domain, and it is the one nobody models.

Batch exclusions on a fixed date behave differently from gradual re-evaluation

Quality re-evaluation of a new domain is typically gradual – pages trickle in and out as confidence builds. What this site experienced was 252 pages leaving the index inside a five-day window.

A batch event on a fixed date has a different set of candidate causes: a systems update rolling through, a canonical or duplicate-consolidation pass re-resolving the site, or a site-level signal changing. It is worth noting that 2026 has seen sustained deindexing volatility; a parallel trend of pages moving into “Crawled – currently not indexed” has been building since early April 2026, alongside confirmed-by-trackers but unannounced ranking movement in May.

The honest position is that we cannot attribute this particular batch to a particular update from the outside. But the shape of the event is diagnostic, and “be patient” is not an adequate response to it.

The remediation is frequently the second incident

Look again at what the team did after the drop. They pruned pages from the sitemap and applied noindex. They changed URL paths. They removed URLs a plugin was emitting.

Some of that was certainly correct. But making several structural changes at once, during an active re-evaluation, on a domain that has not yet earned trust, has two costs. It destroys your ability to attribute any subsequent movement to any specific change. And if a single commercially important URL was caught in that taxonomy prune – now absent from the sitemap and carrying a noindex – the team has manufactured a genuine technical barrier on top of a quality problem.

The follow-up detail in the thread is consistent with exactly that: the excluded URLs report no referring sitemap, despite the sitemap that should contain them being processed successfully.

That is not a quality signal. That is a discovery signal, and it is fixable this week.

3. Who Is Affected? – Site Migration: Crawled – Currently Not Indexed

• Any organisation planning a rebrand. The highest-risk group by a distance, and the one least likely to be reading technical SEO content. If the company name is changing, the domain is changing, and both are landing on the same date, you are running two migrations simultaneously and only one of them is on the project plan.
• Companies migrating away from descriptive or keyword-adjacent domains. crmforyourbusiness.com carried its category in its name. Six years of links and mentions reinforced that association. Moving to an abstract brand name is strategically defensible and search-hostile in the short term, and the gap between those two facts needs to be budgeted in months of reduced visibility, not argued away.
• Mid-size sites in the 200 to 5,000 URL range. Large enough that manual per-URL recovery is impractical, small enough that they have no dedicated technical SEO function and no log analysis. This is where migration failures go undiagnosed for quarters.
• Enterprise organisations post-merger or post-acquisition. Consolidating two sites onto one domain compounds every risk in this article, usually with a fixed legal deadline for retiring the acquired brand and no flexibility to keep the old domain live.
• Anyone whose CMS emits URLs they did not author. Plugin-generated malformed URLs, faceted parameters, tracking variants, printer-friendly duplicates. On an established domain these are an inefficiency. On a newly migrated domain with no trust, they are a pile of junk presented to a crawler that is actively deciding how much of your site is worth processing – which is a crawl budget problem layered on top of a trust problem. We covered the mechanics of that in crawl budget for large aggregators.
• Teams where the migration is owned by an agency or contractor on a fixed engagement. The failure mode arrives after the engagement closes. Nobody is contractually watching.
• Who is less affected: sites migrating within the same domain (HTTP to HTTPS, www to non-www, path restructures). Google does not require a Change of Address for those, and the entity signal is untouched. They are not risk-free, but they are a different and smaller problem.

4. What Should Businesses Do?

The order matters. Diagnosis first, because the technical and the trust failures need opposite treatments and applying the wrong one costs a quarter.

4A. Everyone: establish which failure you actually have

Run this before anyone opens a ticket.

• Check whether discovery is broken. For a sample of your excluded URLs, open URL Inspection and look at the referring sitemap field. If it says none, and you believe the URL is in a submitted sitemap, discovery is broken and the quality question is premature. This is the check the community thread never ran, and it is the highest-value ten minutes available.
• Check whether the exclusion was gradual or batched. Export Page Indexing data and plot excluded URLs by date. A gradual slope is consistent with normal re-evaluation. A cliff inside a few days is not, and tells you to go looking for a site-level event on that date – a deploy, a plugin update, a CDN change, a robots.txt change, a template change – before you accept “be patient”.
• Check what is in the excluded set. If the excluded pages are your highest-value commercial pages and your contact page, that is not a page-level content-quality judgement. A contact page is not thin content in any meaningful sense. A set that heterogeneous points at a site-level evaluation, not a page-level one.
• Check the old property honestly. On the old domain, redirected URLs will show under Page with redirect in the Excluded section, and the indexed count will fall. That is correct and expected behaviour, not damage – Google’s guidance is that you should see “a drop in indexed URL counts on the old site and an increase of indexing on the new site”. Do not diagnose this as deindexing. But if old URLs are showing as Crawled – currently not indexed rather than Page with redirect, that is a different and real signal that the redirect is not being processed as a redirect.
• Check the ranking update history. Google publishes a ranking updates list on the Dashboard. Correlate your cliff date against it. If it lines up with a confirmed update, your recovery timeline is tied to the next one, and that changes what you tell the board.

Write the answer down before anyone changes anything.

4B. For the development team: fix discovery, then stop changing things

Byte-match your sitemap URLs against your canonical URLs. “No referring sitemap” almost always means the string in the sitemap is not identical to the string being inspected. The usual culprits:

• Trailing slash present in one and absent in the other
• http in the sitemap, https served
• www mismatch
• Uppercase characters in the path
• Percent-encoding differences (%20 versus +, encoded versus literal non-ASCII)
• A ?ref= or similar parameter surviving into one version

Write this as a test rather than a manual check:

js

// Assert that every canonical URL emitted by the site
// appears byte-identical in a submitted sitemap.
const sitemapUrls = new Set(await loadAllSitemapUrls());   // follow the index file
const canonicals  = await loadAllCanonicalUrls();          // from a full crawl

const orphans = canonicals.filter(u => !sitemapUrls.has(u));
if (orphans.length) {
  throw new Error(`${orphans.length} canonical URLs absent from sitemaps:\n` +
    orphans.slice(0, 20).join('\n'));
}

• Verify the sitemap index actually resolves. Fetch the index file as Googlebot, then fetch every child sitemap it references. A child sitemap returning 404, 500, a redirect, or a cached stale copy from your CDN will silently orphan every URL inside it while the index file still reports as processed.
• Audit lastmod values. Invalid dates, future dates, or a lastmod that updates on every build regardless of whether content changed will all degrade how much Google trusts the file. Set it from genuine content modification time.
• Confirm nothing commercially important was caught in the crawl. Cross-reference any recently applied noindex tags and any URLs removed from sitemaps against your revenue and impression data from before the drop. This is the check that finds self-inflicted damage, and in our experience it finds something roughly half the time.
• Verify redirects are still single-hop and still correct. Google flags this explicitly: “We frequently see people redirecting to the wrong (non-existent) URLs on the new site.” Re-crawl the full old-URL list and assert a single 301 to a live 200. Chains accumulate silently as new rules are added.
• Keep the old domain and its redirects live. Google’s instruction is to “keep the redirects for as long as possible, generally at least 1 year”, because that is how long signal transfer, recrawling and third-party link reassignment can take. Retiring the old domain at the twelve-month mark to save a registration fee is a false economy that has ended more than one recovery.
• Stop the plugin emitting malformed URLs, permanently. Not by removing the URLs after the fact, but by preventing their generation. Then let the bad ones 404 – Google treats a 404 as a strong signal not to crawl that URL again, whereas blocked URLs stay in the crawl queue far longer.
• Then freeze. One change at a time, with a two-week observation window between changes. A re-evaluation you keep perturbing never resolves, and you learn nothing about what worked.

4C. For the content and marketing team: rebuild the entity, not the pages

If the diagnostic in 4A ruled out discovery, the remaining problem is that Google does not yet know who this site is. That is your work, and it is not a technical ticket.

• Treat the name change as its own project with its own plan. The domain moved in one instruction. The identity moves through corroboration. Everything that describes your organisation on the open web needs to say the new name, and the more of it that says both names together – “Hourless, formerly CRM For Your Business” – the faster the association forms.
• Work the highest-authority mentions first. Partner and vendor directories, industry bodies, chambers of commerce, review platforms, Wikipedia and Wikidata where you qualify, press coverage, conference speaker listings, your team’s LinkedIn profiles, customer case studies hosted elsewhere. The team in this case updated their partner directory and business profiles – that is exactly right, and it needs to keep going for months, not be a one-week sprint.

Update Organization markup with the name history. This is the one place you can state the relationship explicitly:

json

{
  "@context": "https://schema.org",
  "@type": "Organization",
  "@id": "https://example.com/#organization",
  "name": "Hourless",
  "alternateName": "CRM For Your Business",
  "url": "https://example.com/",
  "logo": "https://example.com/logo.png",
  "sameAs": [
    "https://www.linkedin.com/company/example",
    "https://x.com/example",
    "https://www.crunchbase.com/organization/example"
  ]
}

sameAs should list profiles you control and have already updated. Pointing it at a stale profile that still carries the old name works against you.

• Publish the rebrand story and keep it linked. A dated announcement page naming both entities, linked from the footer or about page, is a durable corroborating signal for humans and machines. Most companies publish one, leave it up for a month, then quietly unlink it.
• Earn genuinely new signals under the new name. Guest contributions, podcast appearances, original research, coverage. Redirects transfer what you had – Google is explicit that “301 and other permanent redirects don’t cause a loss in PageRank” – but they cannot create recognition for a name that has never been used. New coverage under the new brand is the only thing that does.
• Do not request indexing repeatedly. It does not influence a quality evaluation, and Google’s migration guidance is blunt that crawl budget cannot be manually inflated. Repeated manual submission is activity that feels like progress.
• Reset the internal expectation. Google says a small to medium site takes a few weeks for most pages to move and larger sites take longer, and that old URLs remaining indexed for extended periods – “sometimes for years” – is entirely normal. Brief your stakeholders on a six to twelve month timeline at the outset. A CMO told the truth in month one is an ally; a CMO surprised in month three is looking for someone to blame.

4D. If you are already in the hole: the recovery sequence

1. Freeze all changes for one week. Establish a clean baseline.
2. Run the 4A diagnostic and write down the answer.
3. Fix discovery only – sitemap byte-matching, child sitemap resolution, accidental noindex, broken redirect chains. Nothing else.
4. Resubmit sitemaps once. Not daily. Google’s guidance warns against submitting the same unchanged sitemap multiple times per day.
5. Observe for three weeks before touching anything further. Validation attempts on an unchanged state will keep failing and tell you nothing.
6. Then start the entity programme in 4C, and expect it to run for two quarters.
7. Report monthly on indexed coverage of your priority URL set, not on rankings. Rankings are downstream and move for unrelated reasons; indexed coverage of the pages you care about is the metric that reflects whether recovery is happening.

4E. Preventing it: the pre-migration runbook

1. Split the rebrand from the migration where the business will tolerate it. Move the domain first, establish the new domain, then change the name – or the reverse. Two sequenced changes are diagnosable. One simultaneous change is not.
2. Freeze the CMS. No plugin updates, no template changes, no taxonomy restructuring for eight weeks either side of go-live. The junk-URL problem in this case is a direct consequence of a live plugin doing something unexpected at the worst possible moment.
3. Provision server headroom. Google notes that after a migration it “will temporarily crawl your new site more heavily than usual”. A migration that triggers 5xx responses under crawl load is a migration that goes backwards.
4. Ship a clean sitemap containing only new URLs before go-live, submit after the redirects are live, and remove the old sitemap once Google is using the new one.
5. Build the URL map from server logs and analytics, not from a crawl alone. A crawl finds what is linked. Logs find what is requested and what still earns traffic.
6. Baseline everything before you move. Indexed URL count, impressions by page, positions for your top 200 URLs, referring domains. You cannot prove a recovery against a baseline you never took.
7. Contract the monitoring, not just the migration. Whoever runs the move should be retained through month six. The failure arrives after launch, and an engagement that ends at go-live is structurally unable to catch it.
8. Set a review gate at week six. Diarised, owned, with the 4A diagnostic as its agenda. In this case, that one meeting would have caught the event inside days rather than months.

5. What We’re Watching Next

Indexing volatility staying elevated. The deindexing trend running through 2026 has made migration diagnosis materially harder, because the background noise now looks like the signal. When Mueller’s response to a wave of deindexing reports is that “some sites go up, some sites go down”, teams need their own diagnostic framework rather than waiting for confirmation that something happened.

Entity recognition becoming the binding constraint. As AI surfaces mediate more discovery, being a recognised entity matters more than holding a position. A rebrand that Google’s systems have not yet resolved is invisible to every system that decides what to recommend, not just to the ten blue links. We expect entity transfer to become a named, costed workstream in rebrand projects within two years, in the same way redirect mapping did.

Migration monitoring windows lengthening in practice. The six-week project model is already obsolete and the market has not caught up. We expect migration engagements to be quoted with six-month monitoring as standard, because the alternative is the pattern in this case.

More self-inflicted damage during recovery. Panic remediation – bulk noindex, sitemap pruning, URL restructuring, repeated validation – is the predictable response to a drop and frequently makes recovery slower. The discipline of freezing, diagnosing and changing one thing at a time is rare and worth more than any individual fix.

Better tooling for the sitemap-orphan problem. “No referring sitemap” is a common, high-impact and almost entirely undiagnosed condition. It is detectable with a set-difference between canonicals and sitemap entries, and we would expect it to appear in mainstream crawlers as a first-class check.

6. About Szymaniak Digital

Szymaniak Digital is an enterprise AI SEO consultancy working with senior marketing teams and the engineering teams who ship for them. We plan and monitor domain migrations and rebrands, diagnose indexing failures at the log and signal level, and write remediation specs developers can implement without a translation layer.

If you are planning a rebrand, the cheapest hour you will spend on it is the one before the domain moves. If you are three months past one and your best pages are sitting in “Crawled – currently not indexed”, that is diagnosable – and the diagnosis is usually not the one the forums give you. Book a migration review. Contact Us!