"Crawled - currently not indexed" means Google fetched the page and decided not to add it to the index, for now. Google says it may be indexed later and there is no need to resubmit. Sort the URL list first, since many pages rightly stay out. For the pages you want, check duplicates, what Google actually rendered, how prominently the page is linked, and whether it has a reason to exist.
Key takeaways
- Documented meaning: the page was crawled but not indexed, it may be indexed later, and there is no need to resubmit it.
- Not every URL on the list is a problem. Tag archives, parameter variants and utility pages are often rightly left out. Sort the list before fixing anything.
- Quality is sometimes the cause, not always. Asked whether the status is often or only sometimes a quality signal, John Mueller answered "Sometimes", and advised thinking about overall quality rather than fixing URLs individually.
- A raw-HTML check separates a rendering problem from a quality problem. If the page's main text is not in the first response, Google may have crawled an empty shell.
- Check in order: sort, duplicates, rendered content, links and page value, then change something and wait.
- Improve, merge or remove first. Request indexing once after a real change, not repeatedly.
What the status says, and what has been said about it
| Claim | Status | Basis |
|---|---|---|
| The page was crawled by Google but not indexed; it may get indexed later | Documented | Google's Page indexing report help |
| There is no need to resubmit the URL for crawling | Documented | Same help page |
| Validation after a fix typically takes up to about two weeks and can take much longer | Documented | Same help page |
| The status is "sometimes" a quality signal, and the response is to think about overall quality, not fix URLs individually | Reported | Mueller on Search Off the Record, July 2026 report |
| Every crawled page ends up indexed | Not supported | Google's own wording is "may get indexed later", not "will" |
Nothing in Google's description presents this as a penalty. It records a decision for that URL, at that crawl. The reported quote is secondhand, so read it as a direction rather than a rule.
Step 1: sort the list before you fix anything
Export the URL list from the Page indexing report and sort it by page type. Most sites find that a good share of it was never meant to be indexed. The sibling guide has a short script that groups an export by path and by query string.
| Page type | Usually | Action |
|---|---|---|
| Tag, category or archive pages that repeat post excerpts | Reasonably out | Leave them, or noindex them deliberately |
| Sort, filter and tracking-parameter variants | Reasonably out | Canonicalise to the main URL and stop linking the variants |
| Two pages answering the same question | Out for a reason | Merge into the stronger page and 301 the other |
| Thin or templated pages (a few lines, same shell) | Likely a quality call | Improve, merge or remove |
| Old posts with no traffic and no links | Likely a priority call | Refresh, merge or prune |
| New pages with real substance | Often just waiting | Strengthen internal links, check again in a week or two |
| Pages whose text is missing from the raw HTML | A rendering problem | Fix rendering (see Step 3) |
If you decide a page should be removed from search, use the order in the noindex vs disallow guide: noindex first, block later, never the reverse.
Step 2: is it a duplicate of something you already have?
Take the page's topic and ask what else on your site answers the same question. If an
indexed page does, Google has little reason to add a second one. A quick test is to
search for a distinctive sentence from the page in quotes with
site:yourdomain.com in front. If a different URL comes back, you have found
the page Google preferred. The search is approximate, so treat it as a hint. The fix is
usually to merge the two into the stronger page and redirect the weaker one, rather than
to rewrite both. If both URLs have to stay live, make the signals agree: the canonical guide has a checker script.
Step 3: did Google see the content?
Google crawls the HTML first and renders JavaScript separately, as the two-wave indexing guide explains. If your main text only exists after JavaScript runs, the first pass can see a near-empty shell. Check the raw HTML that the server sends:
curl -s https://example.com/your-page/ | grep -c "a distinctive sentence from the page"
A result of 0 means that sentence is not in the first response. Then use the
URL Inspection tool to view the HTML and screenshot Google has for the page. If the
content is missing there too, this is a rendering problem, not a quality judgement, and
rendering the content on the server removes it.
Step 4: does anything link to it, and does it deserve to be found?
A page linked from nowhere but the sitemap gives Google no signal that it matters. Check the inbound links with the script in the Discovered guide, and add contextual links from pages that are crawled often. Then ask the harder question honestly: does this page say something the indexed pages on the topic do not? Mueller's advice was to step back and think about quality overall. In practice that means a named author, dates, sources, and something original: a measurement, a worked example, a decision rule. The trust checks in the audit checklist are a reasonable starting point.
Step 5: change something, then wait
Google says there is no need to resubmit these URLs. After a real change, such as merging two pages, adding substance or fixing rendering, request indexing once for the updated URL. Google's recrawl help says repeated requests for the same URL won't get it crawled faster, and that crawling can take a few days to a few weeks. If you use "Validate fix" on the issue, the help page says it typically takes up to about two weeks and should not be clicked again until it succeeds or fails.
The Search Console API has no endpoint for the bulk Page indexing report, so the export stays manual. For checking a short list afterwards, the Search Console extension can inspect single URLs.