Investigation
The Validate Click, the Recrawls, and What the Dates Actually Prove
On or about 2026-10-07 I clicked Validate Fix on 77 URLs. I did not write down the time, so take the date as recollection. Between that read and the one on 2026-10-15, indexed went from 19 of 103 to 80 of 105. The API’s last-crawl column dates the recrawls 2026-10-12 to 2026-10-15.
What do the dates prove? That the recrawls happened after the click. Not that the click caused them. In the same window I added dates to the sitemap, fixed four canonicals, and changed links, and any of those is a reason for Google to return. I will publish the coincidence, not a causal story. The strongest thing I can say is that 48 of the 64 discovered pages left that status and most of them are indexed now, and that the five crawled pages did not move at all, which is exactly what validation should produce if it re-checks a decision without changing its inputs.
The contrast with flowingkhaos is the useful part. Its aftermath page shows 1 to 24 indexed in six hours with no recrawl at all, because the fix was telling Google the address it already held. clevrstart’s 19 to 80 took eight days and needed Google to come back. Same dashboard, two different mechanisms, two different clocks. A Blogger owner in the Search Central community reported being stuck in “crawled, not indexed” for three months after repeated validations and a clean live test; as I read it, that is the crawled clock, where validation re-asks the same question of the same page, and the only thing that would have moved it is a change on the site.
The Five Service Pages That Did Not Move, and the Links Behind Them
The five pages are /services/ai-agent, /services/chatbot, /services/booking-software, /services/blog and /services/professional-website. “Crawled, currently not indexed” on both reads. Last crawl 2026-08-28 or 29. Never fetched since. Their French twins under /fr/services are indexed.
On 2026-10-15 I crawled the live site for links to them. The home page carried zero links to any service page. /tools, /info, /about and /work: zero. The services catalogue linked each one twice, /pricing once, and /industries linked one. That was the whole inbound link graph for the pages that sell the business. The catalogue page itself was not indexed. So from Google’s side, the five pages were reachable only from pages Google did not hold.
The crawl stats say the same thing from the other direction. Between 2026-09-25 and 10-03, Googlebot visited on 2 of 9 days, with 10 and 19 requests. 96.5 percent of those requests were refresh, a return to pages Google already had; 3.5 percent were discovery. A site that had just published dozens of pages was getting almost no discovery crawl, because nothing on the indexed pages pointed outward.
SERPWizard’s guide to the discovered status lists internal linking and crawl budget among the causes, and seorevive’s 2026 version reports that orphan pages are the most common case it sees. I agree with both, and I would add the thing the guides cannot show: the data that proved it on my site was a grep over the HTML of five indexed pages, not anything in Search Console. The dashboard told me the pages were not indexed. The link crawl told me why.
Dashboard 82, API 25: Reading the Two Counts Without Panicking
The same afternoon, the Page indexing dashboard said 82 pages were not indexed: excluded by noindex 12, page with redirect 4, redirect error 2, not found 1, crawled not indexed 29, discovered not indexed 34, with validation marked “Started”. The API read of the 105 sitemap URLs said 25.
Both are right. The dashboard counts every URL Google ever met on the domain property, which covers www and bare, http and https, /fr, and every subdomain. The API counts the URLs I asked about. The 57 in between, checked with one curl each: bookings.clevrstart.com answers 200 with a robots meta of noindex, nofollow, nocache, on purpose. agents.clevrstart.com answers 200 with noindex. ian and cms answer 307 to a login. clevrstart.com and http:// answer 308 to https://www. /en is 404 because English lives at the root. The old sitemap addresses, /sitemap-index.xml, /fr/sitemap.xml and /sitemap-0.xml, answer 404 and still show up in PostHog hits. None of those rows is a page I want ranked. All of them inflate the number that looks like a verdict.
Google said as much fourteen years ago. The Search Central blog post that explained the index status data shows that “not selected” and “blocked by robots” URLs are counted alongside indexed ones, and that the total ever crawled is a different number from the total indexed. The report has been redesigned since; the populations have not.
The flowingkhaos investigation page shows the cost of reading the wrong column: six hours and one branch spent believing “1 of 26 indexed” when the google_canonical column in the same CSV said the pages were indexed at the other address. On clevrstart I read that column first. The dashboard total went in a screenshot; the per-URL CSV went in the fix.