Crawled — Currently Not Indexed After a URL-Prefix Migration: A Diagnostic Matrix
A URL-prefix removal can expose redirect, canonical, sitemap, internal-link, and content-equivalence failures. Diagnose the migration before blaming an update.
Direct answer: A rise in “Crawled — currently not indexed” after removing a URL prefix is a migration diagnosis, not proof of a Google-wide indexing incident. Map each old URL to its intended replacement, verify the redirect and canonical chain, replace internal links, update sitemaps, and compare the old and new content before asking Google to reassess selected URLs.
A current r/TechSEO discussion supplied the failure pattern. The platform guidance in this article comes from Google documentation, not from the thread or its timing claim.
Build the old-to-new URL matrix
Export the old prefixed URLs from the previous sitemap, crawl, analytics, server logs and Search Console. Pair each one with the intended new URL and classify it as one-to-one move, consolidation, intentional removal or unresolved.
| Check | Expected evidence | Failure signal |
|---|---|---|
| Redirect | Old URL reaches mapped new URL | Chain, loop, soft 404 or broad homepage redirect |
| Canonical | New page self-canonicalizes | Old prefix or conflicting target |
| Internal links | Important links use the new URL | Site keeps requesting redirects |
| Sitemap | Only canonical new URLs | Old and new states mixed |
Do not redirect every removed path to a category or homepage. Google recommends permanent server-side redirects for site moves, but the target must represent the old content closely enough to be useful.
Test the final rendered page
Crawl from the old URL with redirects followed and record every hop, status, response header, final HTML, robots directive and canonical. Then inspect the new URL directly. A browser view can hide a redirect chain, client-side error, conditional response or canonical rendered differently for a crawler.
Compare the new page with its former version. A prefix removal often occurs beside template, navigation, localization or content changes. If the replacement lost the main text, unique title, language signal, structured data, media or internal prominence, the indexing state may reflect more than the URL change.
Check that robots.txt and page-level directives allow crawling and indexing. An index request cannot override a blocking directive, a failed response or a canonical pointing elsewhere.
Separate discovery from selection
“Crawled — currently not indexed” means Google reports that it crawled the URL but did not index it at the time of the report. It does not name one universal cause. Record last crawl, Google-selected canonical, referring sitemap, linked pages, rendered content and whether another URL represents the same job.
Use internal links and clean sitemaps to expose the intended new state. Keep redirects long enough for users and search systems to process the move. Avoid simultaneous reversals that make the preferred URL change every few days.
Request indexing only for a small set of important corrected URLs after the signals agree. The request is a re-evaluation prompt, not an indexing guarantee.
Use a stopping rule
- Fix blocking responses, redirect mistakes and canonical conflicts first.
- Update sitemaps and internal links to the final URLs.
- Save the deployment time and a representative inspection sample.
- Wait for recrawl while monitoring server logs and Search Console.
- Escalate when corrected URLs remain unresolved beyond the declared window or show a different failure.
Do not attribute the change to a June update merely because the dates overlap. A migration, crawl-demand shift, content change, rendering regression or reporting delay can produce the same visible pattern.
Use the site-move matrix for domain and protocol variants and the canonical recovery observation plan when duplicate clustering is the remaining issue.
Ask a question or join the discussion