Google Search Console has a report called Page Indexing, and one row in it reads “Crawled - currently not indexed”. It means Googlebot fetched your page, read it, and chose not to store it. No error was thrown. Nothing on the page is broken.
That distinction is the whole post. Here are three URLs on a site that all return 200, all load fine, and all sit in that bucket:
https://example.com/blog/tag/marketing/
https://example.com/services/plumber-in-leeds/
https://example.com/blog/what-is-seo/An archive page, one of forty near-identical location pages, and a post about a topic the site had already covered twice. Nothing is wrong with any of them. Google just did not think any were worth an index slot.
Indexing is Google’s word for storing a page so it can appear in results. Crawling is only fetching it. This status is the gap between those two things, and the gap is a judgment call rather than a bug. Most advice for it tells you to rewrite the page and hit Request Indexing, which is why most advice for it does not work.
- Google fetched the page and declined it. There is a last crawl date, which is the tell that separates this from every similar status.
- It is a judgment, not an error. Nothing is blocked, broken or penalized, and the rest of your site is unaffected.
- Google says not to resubmit. Its documentation states there is no need to resubmit the URL for crawling.
- Most pages in the bucket should stay there. Tag archives, filtered views and thin variants are the usual contents.
- The work is sorting, not fixing. Decide which URLs you actually want indexed, improve those, and leave the rest alone. Sorting a few hundred URLs by hand is the tedious half, and it is the half ContextBolt SEO runs from your agent.
Where you are seeing this
If you landed here from a search and have not found the report yet, this is where it lives.
- Open Google Search Console: pick the property for your site.
- Click Indexing, then Pages: that is the Page Indexing report.
- Scroll to “Why pages aren’t indexed”: a table of reasons, each with a count.
- Click the “Crawled - currently not indexed” row: you get example URLs in that group.
One thing about that list catches people out every time. The number on the row and the number of URLs you can see are not the same, and there is a hard reason for that further down.
What the status actually means
Google’s own wording in the Page Indexing report documentation is two sentences long. 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.”
Three things follow from that, and all three get lost in the panic.
Googlebot did its job. The page is not blocked by robots.txt, not returning an error, not marked noindex. It was fetched and read. Every technical fix people reach for first is a fix for a problem this status proves you do not have.
A decision was made about the content. Something got weighed. Google’s How Search Works documentation is direct about this, and I quote the relevant list in full below.
Google is not asking you for anything. “No need to resubmit this URL for crawling” is not filler. It is the one instruction in the entry, and it rules out the action most people take first.
Read it that way and the report stops looking like a list of defects. It is a list of pages that lost an argument.
Check the last crawl date first
This takes ten seconds and it stops you fixing the wrong thing.
Open the URL in Search Console’s inspection tool and find the last crawl date.
The tell
- A date is there: you have this status. Google read the page.
- The field is empty: you have discovered, currently not indexed instead, where no fetch ever happened.
Those two rows sit next to each other in the same report and need opposite responses. Content advice belongs on this one and nowhere near the other one. If Google has never opened a page, rewriting it is optimizing for a reader who has not arrived.
There is a third neighbor worth ruling out too. If the inspection shows Google indexed a different URL instead of this one, you are looking at duplicate without user-selected canonical, which is a merge rather than a rejection.
What Google says makes a crawled page skippable
Google names three reasons a crawled page might not end up in the index.
- The quality of the content on the page is low.
- Robots meta rules disallow indexing.
- The design of the website might make indexing difficult.
The second one is ruled out by the status itself, because a noindex page is reported under its own reason. The third is rare and shows up as rendering problems you can see in the inspection tool. Which leaves the first, most of the time, for most sites.
Notice what is not on that list. Crawl budget is not there. Publishing frequency is not there. Sitemap membership is not there. Neither is page speed, schema markup or the number of words. People reason from all of those and then find the bucket inexplicable.
Here is the part nobody enjoys reading. When this bucket is large and growing, it is rarely a coincidence spread across a hundred individual pages. It is closer to one verdict about the site, printed one URL at a time. A site Google trusts gets its thin pages indexed anyway. A site it does not gets its decent pages held back too. That is uncomfortable and it is the most useful thing to know before you start editing anything.
Five patterns that fill this bucket
Nearly everything in a big crawled-not-indexed list is one of these.
Generated archive pages: tag pages, category page 7, author archives, date archives. Each one is a list of links to content that is already indexed. They exist because a CMS made them, not because anyone wanted them.
Near-identical variants: forty location pages where the city name is the only difference, or product variants whose copy is one attribute apart. Too different to be merged as duplicates, too similar to be worth storing separately.
Filtered and sorted views: faceted URLs that survived because nothing blocked them. Real pages, infinite in number, valuable to nobody.
Pages your own site never links to: if nothing in your navigation, no post and no hub page points at a URL, you have not voted for it either. Google notices the vote you did not cast.
Content that answers what you already answered: the third post covering the same question, usually written because a keyword tool suggested a slight rephrasing. Your own stronger page is the competitor here.
Read those five back and a pattern shows up. Four of them are pages nobody chose to make. That is the honest shape of most of these buckets, and it is why the number itself is a bad target.
Which ones to fix, and which to leave
Sorting is the actual work. Here is the split I use.
| Type of page | Worth acting on? | What to do |
|---|---|---|
| Archive, tag and filter URLs | No | Leave them. Add noindex only if the count bothers you |
| Near-duplicate location or variant pages | Sometimes | Merge into one strong page, or make each genuinely different |
| Orphaned pages you do want | Yes | Link to them from pages that already rank |
| Third post on a topic you already own | Yes | Consolidate into the strongest version and redirect |
| A page you genuinely believe in | Yes | Make it materially better, then wait without resubmitting |
“Materially better” is doing real work in that last row. Another 500 words is not materially better. A first-hand number, a test nobody else ran, a screenshot of the thing actually happening, those are. If the improved page could still have been written by anyone with the same search results open, nothing has changed about the judgment.
The fixes that do nothing
Four things that feel productive here and are not.
Request Indexing on the whole bucket: Google’s entry for this status says there is no need to resubmit. The tool is quota-limited and meant for a single page you just published. Running it over two hundred URLs spends an afternoon to change nothing.
Resubmitting your sitemap: Google already has it. A sitemap that has not changed carries no new information, and sitemap membership was never a reason to index anything.
Padding the word count: length has never been the criterion. A 400-word page that answers the question gets indexed. A 2,000-word page that restates the top three results does not.
Rewriting titles and meta descriptions: those affect how a page is presented in results. This page is not in the results. You are polishing a shop window on a building Google has not walked into.
The common thread is that all four are actions aimed at Google. The only thing that moves this status is a change aimed at a reader.
Running the check across a whole site
One warning before you plan an afternoon around this.
The report caps its examples. Google states the list “is limited to 1,000 items, and isn’t guaranteed to show all URLs in a given status, even when less than 1,000 items”. So the count on the row and the URLs you can inspect are two different numbers.
There is no API that closes the gap either. The Search Console API has exactly four resources: search analytics, sitemaps, sites, and URL inspection. None of them returns a list of URLs by index status. The report’s per-reason lists exist in the interface and nowhere else.
What you can do is go the other way. Generate your own list of URLs from a sitemap or a crawl, then inspect each one and keep the ones whose coverage state comes back as this status. Per-URL truth is available even when the per-status list is not. The published quota is 2,000 inspections per property per day, which covers most sites in one pass.
Doing that as a script means maintaining a script. Doing it in an agent means typing a sentence, which is the same move as running a full site audit that way.
Copy this prompt
Read my sitemap and inspect every URL against Search Console. List
only the URLs whose coverage state is "Crawled - currently not
indexed", and for each one show the last crawl date and how many
internal links point at it. Sort by internal links, ascending.That output is the sort job done for you. Zero internal links at the top is the orphan pile. Everything below it is a page you did link to and Google still passed on, which is the pile that deserves a real read.
Where the data comes from
This diagnosis needs two things. Your own index status, which Google gives you free, and somewhere for the readings to pile up, because a bucket of 60 URLs means nothing until you know whether it was 20 in June.
ContextBolt SEO is the tool I build. It puts a read-only Search Console connection and a full SEO toolkit inside the agent you already work in, so inspecting two hundred URLs is a sentence rather than two hundred tabs. The Search Console tools are free and never spend your monthly research credits. It is $35 a month with a 7-day free trial, and there is no dashboard to work in, because every lookup lands on a board that fills itself while you work somewhere else.
A quality judgment is exactly the kind of thing you have to measure twice. One reading tells you the number. Two readings, a month apart with a real change in between, tell you whether the change worked. That is the only feedback loop this status has.
What I would actually do
Take twenty URLs out of the bucket, not all of them.
Confirm each one has a last crawl date, so you know you are on the right status. Then read the list and put every URL in one of two piles, want indexed and do not care. Do that first, before opening a single page.
My guess is the second pile is bigger, and that most of it is archives and variants nobody asked for. Those are done. They cost you nothing sitting where they are.
Then take the want-indexed pile, which is probably five URLs rather than twenty, and ask one question about each. What does this page give a reader that nothing else already gives them? If the answer takes a while to find, you have your explanation, and it is not a technical one.
A number in a report is not a task. Somebody has to decide the page was worth making, and Googlebot already told you what it thinks.