Crawled, currently not indexed: the two sentences Google actually publishes, and the five causes you can diagnose yourself
Google's documentation for this status names no cause and tells you not to resubmit the URL, so almost everything written about it is inference, and the useful work is on your own data.
Published by AI Knows Us · Updated 20 October 2026
"Crawled - currently not indexed" in the Search Console page indexing report means Google fetched your page, read it, and chose not to store it. That is the whole of what Google says. Its documentation for the report, read on 20 October 2026, gives the status two sentences: "The page was crawled by Google but not indexed. It may or may not be indexed in the future; no need to resubmit this URL for crawling." No cause, no threshold, no timescale, and an explicit instruction not to resubmit. Every list of causes you will read, including the one further down this page, is inference from the pattern of which pages get this status. Knowing which part is documented and which part is inference is what stops you fixing the wrong thing.
What the status does rule out, which is most of the usual suspects
The word "crawled" is doing a lot of work. For a page to reach this status, Googlebot requested the URL and got a usable response. So before you look at anything else, cross these off:
- Not a robots.txt block. That has its own status, "Blocked by robots.txt".
- Not a noindex tag. That is reported as "URL marked noindex".
- Not a server error or an access problem. 401, 403, 404, 5xx and soft 404 all have their own statuses.
- Not a canonical conflict Google has already resolved. That is reported as "Duplicate without user-selected canonical" or "Alternate page with proper canonical tag".
- Not a crawl scheduling delay. That is the neighbouring status, and the distinction matters more than anything else on this page.
Crawled is not Discovered, and the fix is the opposite
These two statuses sit next to each other in the report and send you in different directions.
| Crawled, currently not indexed | Discovered, currently not indexed | |
|---|---|---|
| What Google did | Fetched the page and read it | Found the URL and has not fetched it |
| Google's documented explanation | None given | "Typically, Google wanted to crawl the URL but this was expected to overload the site; therefore Google rescheduled the crawl" |
| Last crawl date in the report | Present | Empty, as the documentation notes |
| Where the work goes | The page: what it contains and whether it duplicates something | The site: server response time, crawl capacity, internal links to the URL |
Treating a crawled page as a crawl capacity problem is the most common wasted week on this status. If you genuinely have a discovery and capacity problem as well, the request side is covered in crawl budget optimisation.
The five causes that are diagnosable from your own data
- The page says what another page of yours already says. Not a byte-level duplicate, a substantive one. Two service pages with the trade noun swapped, two location pages with the place swapped, a tag archive that reproduces a category. Open both and read them side by side. If you cannot name a question only one of them answers, you have your answer.
- It is a template output rather than a page. Faceted listings, filter combinations, paginated archives, author pages, empty search result pages and tag pages are created by the thousand and get read as near-identical. These are the pages that fill this report on large sites.
- It is thin against the competing results, not thin in the abstract. Word count is not the test. Open the three results currently ranking for the query and ask what they contain that your page does not: a number, a worked example, a table, a step somebody actually needs.
- Nothing on your own site points at it. A page reachable only from a sitemap carries no internal signal that it matters. Inbound internal links are the cheapest and most reliable thing to change here.
- The item has no URL of its own. Listings built as endless feeds put real content behind an interaction, so there is nothing stable to index even though the container crawls fine. Giving every batch its own address is the fix, and it is worked through in infinite scroll and SEO.
The order to work in
- Confirm the status on the URL itself, with URL Inspection rather than from the report summary, and note the last crawl date.
- Check what Google received. Use the live test and view the tested page. A page whose content arrives only after a script runs is a different problem wearing this status.
- Look at the canonical Google picked. If it chose another URL, you are in a duplication conversation, not an indexing one.
- Decide whether the page should exist. This is the step people skip. On most sites a large share of these URLs should be consolidated into one strong page or removed from the sitemap, and that is a win rather than a loss.
- For the pages that should exist, change them substantively, then add internal links from pages that are already indexed.
- Request indexing once, and then leave it. Google's documentation says there is no need to resubmit the URL, and the recrawl guidance says one request per URL is enough. The two documented ways to ask, and the quota on each, are in how to ask Google to recrawl a URL.
- Re-read the report in two to four weeks, as a count by template rather than as a list of URLs. The number per template is the measurement that tells you whether the change worked.
Read it as a proportion, not as a list
This status is not an error, and a count of zero is not the target on a site of any size. Export the report, group the URLs by template, and compare the indexed and not-indexed counts within each group. One template at ninety per cent not indexed is a finding. Four thousand filter URLs sitting in this status while every service page is indexed is the report working as intended, and the right response there is to stop generating the URLs. The wider method for reading the report, and the other checks that answer "is this page in the index", are in how to check which of your pages Google has indexed.
Questions about crawled, currently not indexed
How long does this status last?
Google gives no timescale and says the page may or may not be indexed in future. In practice, the useful clock starts when you change the page: give it two to four weeks after a substantive change and one indexing request, then read the report again.
Should I keep clicking Request Indexing?
No. Google's documentation for this status says there is no need to resubmit, and its recrawl guidance says repeated requests do not speed anything up. One request after a real change, then wait.
Does it mean my content is bad?
It means Google did not find enough in it that is not already in its index. That is often about overlap rather than quality: a well written page that repeats another page of yours lands here, and consolidating the two is the fix.
Is this a penalty?
No. It is a storage decision reported in a diagnostic, and it appears on healthy sites every day. A manual action is reported separately, in its own Search Console report.
Can a page in this status still get traffic?
Not from Google Search, because a page that is not indexed cannot be served in results. It can still receive direct, referral and social visits, so read the index status in Search Console and treat your analytics session count as a separate measurement of a separate thing.
Why do brand new pages show up here?
Because the first crawl often happens before the page has any internal links pointing at it and before Google has anything to compare it against. Link to it from a page that is already indexed, and check again in a fortnight rather than the same afternoon.
Does fixing this help with anything other than Google?
Yes, and that is the part most people miss. Consolidating near-duplicates and giving every item a stable address makes the page easier to retrieve for everything that reads the web, not just one crawler.
The index nobody shows you a report for
This status is a rare piece of generosity: a search engine telling you, in writing, that it read your page and decided not to keep it. Nothing does that for the assistants. When somebody asks ChatGPT or Gemini to recommend a supplier in your category, the pages that get quoted are the ones those systems retrieved and found worth using, and there is no report listing the pages they read and set aside. The mechanics are familiar though, because they are the same mechanics: one address per subject, a substantive difference from everything near it, and an internal path to it from somewhere that already carries weight. AI Knows Us runs those buying questions against the assistants and records which pages each answer was built from, which turns the silent version of this problem into a list you can work through.