Crawled, Currently Not Indexed: What Each Google Status Means for Your Site

Crawled, Currently Not Indexed Means Google Judged Your Page and Passed

Here is what it looked like on our own site. On 2026-10-15, five of our 105 pages carried that status: the five English service pages, the same five since 2026-08-28, while their French twins were indexed. Same template, same length, different language. The difference was not the writing. On that day no indexed page on the site linked to them in its body. Google had seen five pages nobody vouched for.

SEOTesting's guide to the status reports that weak internal links and thin or duplicated content are the usual causes, and we agree with the first cause on our data; the second we could rule out with one column, which we come to below. Our Local SEO Foundation service exists because a service page nothing links to is the most common page we see in this status on a small business site: it was written, it was published, and nothing pointed at it.

The status looks scarier than it is. It is a note that says "seen, not kept". Every other row in the report is either a queue or a page that is supposed to be out.

Why Discovered and Crawled Are Different Problems

"Discovered, currently not indexed" means Google has the address and has not fetched it. That is a crawl-priority question: Google will come when it has a reason. "Crawled, currently not indexed" means it came and did not keep the page. That is a content and link judgement. Launchcodex's list of indexing issues points out that treating one as the other wastes weeks, and we agree; the fix for a queue is patience and links, the fix for a judgement is a change.

Our counts show the queue moving on its own. On 2026-10-07 we had 64 pages discovered and not indexed. On 2026-10-15, 16. The recrawls that cleared them are dated 2026-10-12 to 2026-10-15, and none of those pages changed. The 5 crawled pages stayed at 5 on both reads. Onely's guide to the discovered status shows the split the same way, queue on one side and evaluation on the other, and we read our own table as the clearest example of it we have.

One instruction for each. Discovered: wait, add links from pages Google already holds, and put a true date on the sitemap entry. On 2026-10-14 only 31 of our 105 sitemap entries carried a lastmod, which gave Google 74 reasons not to hurry. Crawled: change the page or what points at it, then ask for a fresh look.

Why Validate Fix Does Nothing for Crawled Pages

You press Validate Fix and Google re-checks what it already decided. It prompts a recrawl of the rows in that report and it does not force indexing. For a page Google has not fetched, a fetch changes the decision, so validation can move a discovered page. For a page Google has fetched and judged, a re-check of the same page returns the same verdict. Onely's guide, linked above, makes the same point about repeated requests, and indexernow's fix page shows why re-requesting a crawled page without a change does nothing; we agree, and our own sequence is the test.

Around 2026-10-07 we clicked Validate Fix on 77 pages. We did not note the time, so treat that as recollection. In the eight days that followed, the indexed count rose from 19 to 80. The five crawled pages were never recrawled and did not move. We did not validate them for that status, on purpose, because the page Google would re-check was the same page with the same missing links.

Request Indexing is the other button, and it is different: it asks for a fresh fetch of the page as it is now. It only makes sense after the page or its links have changed. As of the evening of 2026-10-15 we had not yet clicked it on the five pages, so no re-index is claimed here. The links went in first; the request comes next; the dates come after.

The Dashboard Count Versus the API Count

We opened the Page indexing report for our site on 2026-10-15 and it showed 82 rows under "Why pages aren't indexed": excluded by noindex 12, page with redirect 4, redirect error 2, not found 1, crawled not indexed 29, discovered not indexed 34. The same afternoon, a script that asks Google's URL Inspection API about each of the 105 pages in our sitemap returned 25 not indexed.

Both are right, because they count different things. The dashboard counts every address Google has ever found on the whole domain property: the www host, the bare host, the French tree, every subdomain, every old path, every redirect. The API counts the pages you ask about, and it answers for each one as Google holds it now. Our script, search-read.ts, reads the sitemap, asks about each page in turn, and writes the verdict, the last crawl date and the canonical Google chose next to the one the page declares. Matthew Edgar's walkthrough of the report points out that its rows refresh on Google's schedule, not yours, and that a discovered row can clear within days; we agree, and the per-page read is how we stopped waiting on the refresh.

For an owner, the lesson is the order of work. The dashboard tells you there is something to look at. The per-page read tells you which page. Our seo checklist for new website shows the eight checks we ran before touching any single page, with what each one found on 2026-10-14.

The Rows That Are Supposed to Be Excluded

Most of the 82 rows were working as intended.

Excluded by noindex, 12. Our bookings subdomain answers with a robots tag of noindex, nofollow, nocache. Our agents subdomain answers with noindex. Both on purpose: they are app screens, not pages. Instruction: none, unless a page you want ranked carries the tag.

Page with redirect, 4, and redirect error, 2. The bare domain and http redirect to https://www. Two admin subdomains redirect to a login. Instruction: none. The English tree lives at the root, so /en answers 404, and that is not a ranking page either.

Not found, 1. An old sitemap address. Our previous sitemap addresses, /sitemap-index.xml, /fr/sitemap.xml and /sitemap-0.xml, all answer 404 and still show up in our analytics as requests. Instruction: remove the stale submission in Search Console so Google stops asking.

Google's Page indexing report documentation shows each of these reasons by name, and we agree with its reading of the excluded rows: they are information, not errors. That leaves the two statuses that are yours: discovered and crawled. Everything else in the list is a page that is supposed to be out, and the report is confirming it. Our tools pages and our hosting page sit in the indexed rows for the same reason the subdomains sit in the excluded ones: each is where we meant it to be.

What the Site Pattern Says: Links, Canonicals and Quality

Read the crawled status across the site, not one page at a time. Digital Applied reports that John Mueller said on the 16 July 2026 office hours that the status can be a site-wide quality concern, and Marie Haynes' long piece argues that commodity content is usually the cause and recovery is hard at scale. We take both seriously. On a site with hundreds of thin pages, they are probably right. On ours, the pattern said something narrower.

Five pages. All service pages. All English. All with French twins that were indexed. And on 2026-10-15 the home page, /tools, /info, /about and /work linked to zero of them; our services catalogue linked each one twice and the pricing page once. SEOTesting's weak-internal-links cause, cited above, fits that pattern exactly, and the quality explanation does not, because the same text in French was kept.

We could also rule out duplicates. On both reads, zero pages had a canonical chosen by Google different from the one the page declared. A bilingual site worries about that, and one column settled it. We found one real defect while looking: four legal pages emitted a relative canonical and no hreflang, fixed in commit 605cba5 on 2026-10-14 and verified live the next day. It was not the cause of the five, and it was worth fixing anyway.

The Five Stuck Pages and the Footer Fix Still on Test

The five pages are /services/ai-agent, /services/chatbot, /services/booking-software, /services/blog and /services/professional-website. On 2026-10-15, within the hour of the read, every page on the site got a Services list in its footer, seven links in English and eight in French, commit 694d211, verified live.

The test is still running. Request Indexing had not been clicked on the five pages as of the evening of 2026-10-15. Our expectation, which we label as experience and not as a measurement, is about 48 hours to indexed for a page with nothing broken after a request, and two to five weeks before real rankings on a site with no history. Our research for this page found no reliable published figure for indexing time after a fix, and no confirmed daily quota for Request Indexing, so we publish our own dates as they land and nothing before.

One other site of ours shows the opposite shape, and we include it so one case does not become a law. flowingkhaos.com went from 1 of 26 pages indexed on 2026-10-07 to 34 of 36 on 2026-10-15, most of it within six hours, because the sitemap had named every page with a trailing slash while Google held the version without. A sitemap correction, not a recrawl. The method that told the two shapes apart, from the first read to the request, is what SEO in the age of AI: get your pages indexed, from the API shows step by step. The do and don't list for a local business, including the mistake we made ourselves in 2024, is in Local SEO: what to do and what not to do.

Your One-Instruction-Per-Status Checklist

Here is your table, one line per status, in the order you will meet them.

According to the inspection screen in Search Console, which shows the verdict and the last crawl date for one address, Request Indexing is one address at a time; we agree it belongs last, after the change. A Search Central community thread on pages crawled but not indexed shows the same pattern from the other side: an owner asking why repeated requests changed nothing, and the answer pointing back at the site. We agree with that answer.

The status is a signal to read, not a verdict on your business. The honest next step is to check the whole site before touching one page, and the eight checks, in the order we ran them, are on the indexing checklist linked above.