When Search Console shows pages not indexed, the dashboard and API can disagree: 82 rows versus 25 unindexed. Learn to sort rows into fix, ignore or wait.
Google Search Console Not Indexed: 82 Rows Are Not 82 Problems
Let’s get one thing straight: a “google search console not indexed” count is not a verdict on your site. On 2026-10-15 the Page indexing dashboard for clevrstart.com showed 82 rows under “Why pages aren’t indexed”. The same afternoon I asked Google’s URL Inspection API about every one of the 105 URLs in the sitemap, and it returned 25 that were not indexed. Same site, same day, two numbers. Neither is wrong. They count different things.
The dashboard counts every URL Google has ever met on the whole domain property: the www host, the bare host, the French tree under /fr, every subdomain, every old path, every redirect. It also refreshes every few days. The API inspects the exact URLs you ask about, live, one call each. So the dashboard’s 82 were: excluded by noindex 12, page with redirect 4, redirect error 2, not found 1, crawled but not indexed 29, discovered but not indexed 34. The API’s 25 were 16 discovered, 5 crawled, 4 unknown. The 57 rows in between are the dashboard’s extra URLs, old paths, redirects and noindex addresses the sitemap never named.
My answer, and the rest of this column argues for it: read the API per sitemap URL, treat each status as an instruction, and stop reading the dashboard total as a score. One instruction in particular: for “Crawled, currently not indexed”, the Validate Fix button only re-asks a question Google already answered. Encited’s guide to that status points out the same thing from the other side: according to them, Google already fetched and read the page, so asking for another crawl changes nothing until the page changes. I agree with that reading, and I have five pages that prove it.
I could be wrong about the cause on your site. I don’t know your site. I know two of mine, with dates, and the method that found those dates is what SEO in the age of AI: get your pages indexed, from the API shows step by step, from the first API read to the request.
Two Populations, One Report: Why the Dashboard and the API Disagree
The Page indexing report is a census of a territory. The territory is the domain property, which for clevrstart is sc-domain:clevrstart.com. That property covers www and bare, http and https, /fr, and every subdomain: bookings, agents, the admin hosts, all of it. Any URL Googlebot ever fetched from any of them is a row. The report is rebuilt on Google’s schedule, every few days, and the performance data behind it lags about three days. What you see is a snapshot of a crowd, some of whom moved out months ago. Google’s own crawling and indexing documentation says it does not guarantee that it will crawl, index or serve any page, which I read as: the report describes what happened, it promises nothing about what will.
The URL Inspection API is a roll call. You give it a URL, it tells you what Google holds for that URL right now: the verdict, the coverage state, the last crawl time, the canonical Google chose and the canonical you declared. I run it from a script in my own operating system, search-read.ts, which reads the sitemap, calls the API once per URL in sequence, and writes a CSV with those columns: url, verdict, coverage, last_crawl, google_canonical, user_canonical. A run over 105 URLs takes about ten minutes. Once it died ten minutes in on a single API 500 with nothing written; the script now retries once and skips the URL instead.
The two populations overlap, but the dashboard adds everything the sitemap never named. Matthew Edgar’s walkthrough of the report makes a point I keep coming back to: a “discovered, currently not indexed” row can be a false positive that clears within days, and the check is your own logs, not the row. The per-URL read is the same idea with less friction: before you trust a count, ask about each page.
One more thing the dashboard hides: the canonical Google chose. On both of my reads, zero of the clevrstart rows had a google_canonical different from the page’s own. That column settled the bilingual duplicate-content worry in one query. The report never shows it as a column.
Sorting the 82: Which Rows Are Yours to Fix
Sort the dashboard into three piles: fix, ignore, wait. I did it with curl on 2026-10-15, one request per host.
Excluded by noindex, 12 rows. bookings.clevrstart.com answers 200 with a robots meta of noindex, nofollow, nocache. agents.clevrstart.com answers 200 with noindex. Those are app surfaces, not pages. The noindex is deliberate. Pile: ignore. Noxster’s status guide points out that Google does not need every URL indexed, and I agree: a booking app’s login screen is the clearest case of a row that belongs in the ignore pile.
Page with redirect, 4, and redirect error, 2. ian.clevrstart.com and cms.clevrstart.com answer 307 to a login. clevrstart.com and http:// answer 308 to https://www. /en answers 404 because the English tree lives at the root. Pile: ignore, after checking each one once, which I did.
Not found, 1. The old sitemap addresses, /sitemap-index.xml, /fr/sitemap.xml and /sitemap-0.xml, all answer 404 and still appear in PostHog hits, so something out there remembers them. Pile: ignore, but remove the stale sitemap submissions in Search Console so Google stops asking.
That leaves 63 rows the sitemap also knows about, which the API put at 25 by the time it ran. The difference is the dashboard’s refresh lag. Pile: wait for 16 of them, fix for 5, and inspect the 4 unknown.
| Status in the dashboard | What it was in our data | Instruction |
|---|---|---|
| Excluded by noindex | App subdomains answering noindex on purpose | Ignore |
| Page with redirect, redirect error | Login hosts on 307, bare and http on 308 | Ignore, after one curl each |
| Not found | Old sitemap paths still requested | Remove the stale submissions |
| Discovered, not indexed | Pages Google knew and had not fetched | Wait, check the recrawl date |
| Crawled, not indexed | Five English service pages | Change the page and its links |
While sorting I found one real defect: the four legal pages (privacy and terms, both languages) emitted a relative canonical and no hreflang. Fixed in commit 605cba5 on 2026-10-14, verified live the next day. Nothing in the dashboard pointed at it. The per-URL canonical columns did.
Status as Instruction: Crawled Versus Discovered, Not Indexed
I read these two statuses as two different instructions, and most guides blur them.
“Crawled, currently not indexed” means Google fetched the page, read it, and chose not to keep it. On clevrstart the five pages with that status were the same five on both reads: /services/ai-agent, /services/chatbot, /services/booking-software, /services/blog and /services/professional-website. Last crawl 2026-08-28 or 29. Never fetched again. Their French twins under /fr/services are indexed. Google’s Page indexing report documentation says such a page “may or may not be indexed in the future; no need to resubmit this URL for crawling”, and SEO Ninja’s guide agrees with that reading and adds the usual causes: thin content, rendering, weak internal links. That is Google’s text and their list, not my finding. My instruction is sharper: change something before you ask again, because the page as crawled was judged.
What was there to change? I crawled the live site for links. The home page, /tools, /info, /about and /work carried zero links to any service page. Only /services linked them, twice each, and /pricing once each; /industries linked one. Five pages, no inbound body links from anything indexed, on a site Googlebot visited on 2 of 9 days in late September with 96.5 percent of its requests marked refresh and 3.5 percent discovery. Google was not refusing the pages. It was never given a reason to return. A Search Central thread from someone who reported they had moved content to a subdomain and sat in this status for months despite “several validations” shows the same shape, as I read it: validations sent, no change to what links where.
“Discovered, currently not indexed” means Google knows the URL and has not fetched it. On 2026-10-07 clevrstart had 64 of those. By 2026-10-15, 16. The dashboard still said 34 with validation “Started”, because the dashboard had not caught up. The recrawls that cleared them are dated 2026-10-12 to 2026-10-15 in the API’s last_crawl column. Instruction for that status: wait, and check the date, not the count.
Source: Our own measurements
Why Validate Fix Did Nothing for Our Five Pages (and What the 19-to-80 Rise Does and Doesn’t Prove)
On or about 2026-10-07 I clicked Validate Fix on 77 URLs. I did not write the time down, so take the date as my recollection. Between 2026-10-07 and 2026-10-15 the indexed count went from 19 of 103 to 80 of 105. The recrawls are dated 10-12 to 10-15, after the click.
Did the click cause it? I can say the rise coincided with it. I cannot say more, because I changed other things in the same window: lastmod dates, the legal-page canonicals, body links. A rise that follows a click is not a rise the click caused, and I would rather publish the coincidence than a story.
What I can say with no hedge: the five “Crawled, currently not indexed” pages did not move. Validation asks Google to re-check a decision. For “discovered” pages that decision was “not fetched yet”, and a fetch changes it. For “crawled” pages the decision was “fetched and declined”, and the page I asked it to re-check was the same page with the same zero inbound links. Raúl Revuelta, answering a publisher in the Search Central community who reported that indexed pages had suddenly turned to “crawled, currently not indexed” with no changes, points out that resubmitting the sitemap or requesting indexing again is unlikely to change the outcome once Google has evaluated the page. I agree, and the five pages are my test of it.
So on 2026-10-15 I changed the thing that was missing. The footer on every page now lists every service page in its own language, seven in English and eight in French, commit 694d211, live within the hour of the read. Then, and only then, does a request make sense.
The Other Shape: flowingkhaos Jumped in Six Hours Without a Recrawl
The other site taught the opposite lesson the week before, which is why I distrust any single rule about indexing time.
flowingkhaos.com had 26 URLs in its sitemap. At 22:13 UTC on 2026-10-07 the API said 1 indexed, 21 “duplicate without user-selected canonical”, 4 unknown. At 00:22 UTC on 2026-10-08, 24 indexed, 0 duplicates, 2 unknown. Six hours. No recrawl; the crawl dates in the CSV were September’s.
What changed was the sitemap. Every page answered at two addresses, /column and /column/, joined by a 307 from Cloudflare’s assets layer. A 307 is temporary, so Google kept both, chose the slashless one, and indexed it. The sitemap submitted the slash one, so every sitemap URL was a duplicate of a page Google already held. The repair, written up in the Astro trailing slash fix, was one URL form everywhere, a 301 at the zone, Always Use HTTPS, HSTS, a lastmod on every entry and a dated TechArticle node per page. The zone settings were confirmed live on 2026-10-15 with one curl each.
The 2026-10-15 read on flowingkhaos: 34 of 36 indexed, including ten pages published after the fix, all in. October 1 to 15: 74 impressions and 1 click, against 25 impressions and 0 clicks for the whole of September. The aftermath page carries the full table.
Two sites, two shapes. One needed Google to come back, and the levers were dates and links. The other needed me to tell Google the address it already had. The dashboard showed both as a wall of red. The API showed which wall I was looking at.
Dashed line: sitemap, 26 URLs, 26 URLs
Source: Our own measurements
The Live Test: Five Service Pages, Request Indexing Not Yet Clicked
As of the evening of 2026-10-15 I have not clicked Request Indexing on the five English service pages, nor on /services and /fr/services/referencement-local, which the API lists as unknown even though both answer 200. The footer links are live. The clock starts at the click, and I will publish the dates as they land.
My expectation, labelled as what it is: a page with nothing broken, serving the purpose it was made for, gets indexed within about 48 hours of a request, and real rankings take two to five weeks on a domain with no history. That is experience from other sites, not a measurement from these two. The measurements I do have are the ones above: eight days from validation to 80 of 105, six hours from a sitemap correction to 24 of 26, and a week from publish to indexed for ten new pages. The timing argument, with every date, is in How long my sites take to get indexed, with the dates.
One warning from my own past. In 2024 I bought four cheap domains with a domain rating between 0 and 25, pointed a Medium article’s canonical at my unindexed site, added the site to the four domains’ schema sameAs and cross-linked them. Within weeks my own site went from no impressions to thousands a month, from memory; I kept no export. I would not do it today; I would build the entity properly, with a Business Profile, sameAs on real profiles and one canonical per page. I mention it because it was the day I learned that canonicals and links are instructions, which is the whole point here.
The takeaway fits on one line. Open Search Console for the property, which shows the dashboard total, then ask the API per URL, because the data that points at a fix sits in the per-URL columns, not in the total. Sort each sitemap URL into fix, ignore or wait. Change the page before you ask Google to look again, and never press Validate Fix on “crawled, currently not indexed” and call it work.
Sources
- Fix Crawled - Currently Not Indexed in Google Search Console
- Crawled Currently Not Indexed: Causes and Fixes
- Crawled vs Discovered: Google Search Console Indexing Statuses | SEO Company Los Angeles | Noxster SEO
- Previously indexed pages are suddenly marked as non-indexed in Search Console without any changes - Google Search Central Community
- Crawled - currently not indexed after moving to subdomain - Google Search Central Community
- Page Indexing Report in Google Search Console - Matthew Edgar
- SEO in the age of AI: get your pages indexed, from the API
- How long my sites take to get indexed, with the dates
- Astro trailing slash on Cloudflare: fix the 307 and sitemap duplicates
- Aftermath — Astro trailing slash on Cloudflare: fix the 307 and sitemap duplicates
- Astro trailing slash on Cloudflare: fix the 307 and sitemap duplicates — flowingkhaos
Questions, answered
- Why does Search Console's not-indexed count differ from the URL Inspection API?
- The dashboard counts every URL Google has ever met across the whole domain property, including subdomains, redirects and old paths, and refreshes every few days. The API inspects only the exact URLs you ask about, live, one call each. Neither number is wrong; they count different things.
- What should I do about 'Discovered, currently not indexed'?
- Wait, and check the API's last crawl date rather than the dashboard count. On the author's site 64 such pages on 2026-10-07 dropped to 16 by 2026-10-15 while the dashboard still showed 34.
- How fast can indexing improve?
- It varies by site and problem. On one site the indexed count rose from 19 to 80 of 105 over eight days after a validation click and other changes; another site went from 1 to 24 indexed in six hours after fixing duplicate sitemap URLs caused by a trailing-slash 307.