“Crawled — currently not indexed” means Google fetched the page but did not index it. The status alone does not identify the cause. Google's Page indexing documentation also says these URLs do not need to be resubmitted for crawling.
After a migration, compare affected pages with equivalent pages that are indexed. Look for something the migration actually changed: redirects, content, canonicals, page responses, or the links that lead to them.
Compare old and new versions
Choose a small sample from each affected page type. Include the old URL, its intended replacement, and a similar new page that is indexed.
| Check | Old URL | Affected new URL | Similar indexed URL |
|---|---|---|---|
| Status, redirect hops, and final destination | |||
| Canonical in source and rendered HTML | |||
| Google-selected canonical and inspection date | |||
| Robots directives in headers and HTML | |||
| Main heading, text, and product or article identity | |||
| Rendered content and links | |||
| Links from navigation, categories, or related pages | |||
| Sitemap entry and modification date | |||
| Last verified Googlebot request and response |
An empty cell is an unanswered check. Record the expected result before changing the implementation.
Include the less obvious routes
A sample of working product pages can miss a migration problem. Also include:
- an exact old-to-new redirect;
- several old pages intentionally combined into one;
- a retired URL with no replacement;
- a page whose path stayed the same;
- a new page introduced during the migration;
- a parameter, locale, preview, or alias URL;
- a genuinely missing page from each major template.
A 301 is only correct if it sends the visitor to the right replacement. A catch-all redirect to the homepage can pass a status check while losing the page's purpose.
Match each finding to a fix
| What differs on affected pages? | What to investigate |
|---|---|
| Old URLs redirect to the wrong page or through long chains | Redirect mappings and the routing configuration |
| Canonicals, links, or sitemaps promote different URLs | The templates and settings producing those values |
| Primary content disappears or changes after rendering | Data fetching, rendering errors, cache behavior, and access to resources |
| Several pages repeat the same content | Whether to combine them or give each a distinct purpose |
| Important pages lost links from categories or navigation | The missing links and pagination paths |
| No relevant difference is found | Whether Google has processed the new response yet; avoid another speculative release |
A content rewrite is appropriate when the comparison shows what a page lacks or repeats. The indexing label itself is not a reason to rewrite every page.
Check the repair at three points
At deployment: save the before-and-after responses for the chosen URLs. Check statuses, headers, raw and rendered content, links, and sitemap entries against production after any necessary cache purge.
After Google recrawls: record the request time and URL Inspection's crawl date, fetch result, and canonical fields. Compare that result with the corrected live page.
When indexing data updates: compare the affected pages with the indexed sample and intentionally retired URLs. Keep crawling, indexing, and ranking separate when reporting the result.
You can verify a redirect or rendering repair immediately. Google's later indexing decision takes its own time. Repeatedly changing the same template before Google has seen the previous correction makes the result harder to interpret.