Does Google's "Request indexing" button actually work? 10 of 11 URLs we clicked on August 25 were indexed within 27 hours, each with the live-test fetch as its last crawl. 0 of the 9 we did not click. One page stuck for 38 days went in overnight

Method, stated before the numbers

Five days ago we published a count of Googlebot visits to eight new posts: zero at 24 to 75 hours, while OpenAI's fetcher had read all eight inside 12 hours. Since then the count of sitemap URLs Google reports as not indexed has sat at 18 to 20 of about 150. The only lever left that we had not measured is the one in Search Console's URL Inspection tool. Google's own help page describes it in one line: "Request that a URL be crawled by Google", and adds that if the page passes a quick check "it will be submitted to the indexing queue", with a daily limit on requests (URL Inspection Tool help). It does not say how long the queue is or whether the queue ends in the index.

So we set up a read with a denominator. On 2026-08-25 at 09:02 Eastern (13:02 UTC) our scheduled indexation task inspected all 149 sitemap URLs through the API and found 20 not indexed: 15 "Discovered - currently not indexed" and 5 "URL is unknown to Google". It then clicked "Request indexing" on as many of them as Google's quota allowed, 11, and printed the list in order. The other 9 were left alone. That gives two cohorts that were in the same state at the same moment on the same site, differing only in whether a button was pressed. Nothing else changed on the site that day except one new post, which is counted separately below.

Two instruments then read the result. Our crawler ledger records every bot-shaped request to askedabout.com with its path, user agent and timestamp (the ledger, its classifier and its exclusions are described in the fetch-speed post); a user agent that says Googlebot is counted as Googlebot, which is a limit we return to. And the URL Inspection API was read twice on 2026-08-26, at 16:41 and again at 16:45 UTC, for all 20 URLs plus the two posts shipped since. The 16:45 read is the one in the tables; the 16:41 read is kept because it disagrees with it.

What the ledger saw during the twenty minutes of clicking

Between 13:18:49 and 13:37:32 UTC Googlebot made 28 requests: 11 content pages, 15 fetches of robots.txt and 2 of sitemap.xml. The 11 content fetches include 10 of the 11 URLs on the task's list, in the task's order, spaced a median of 121 seconds apart (range 117 to 241; two pairs landed in the same second, which is why 10 fetches span 8 timestamps). Almost every content fetch is preceded by a robots.txt fetch within about a minute. That cadence is a live test executing once per click, and it is why we said yesterday that a fetch proves the click registered, not that Google decided to recrawl anything.

Read the last two columns together. For all ten indexed URLs, the crawl time Search Console reports is the live-test fetch, second for second. Google did not come back later and crawl the page "properly"; the fetch the button triggered is the crawl the index was built from. Our ledger has no other Googlebot request on any of these ten between the live test and the read, with one exception: URL 4 was fetched again at 12:52:12 UTC on 08-26, robots.txt first, and Search Console still reports the 08-25 second as its last crawl at 16:45. Either the API lags a day on that field or the second fetch did not replace the indexed copy. We do not know which.

Ages are worth a sentence. Four of the eleven had been published 28 to 39 days earlier and had sat at "Discovered" the whole time; the other seven were 5 to 7 days old. Time in the queue made no visible difference: the oldest four and the newest six all went in the same night.

The one that did not fetch, and the one that fetched but was not on the list

URL 9, the Reddit-citation post, is the only one of the 11 with no Googlebot request on the ledger that day, and the only one still not indexed. The task's log says its 12th request attempt returned "Quota Exceeded" and that the click on a different post failed twice on a transient error; it does not say which of the 11 printed URLs, if any, was affected. What we can say is that fetch and index moved together on all 11: fetched and indexed, 10; not fetched and not indexed, 1.

The ledger also holds a 12th content fetch that the printed list does not: /data/ai-answers-change-every-time at 13:19:05 UTC, two minutes before URL 1. That page was already indexed (Search Console had its last crawl at 2026-08-07 on the morning sweep). By 16:45 on 08-26 its reported last crawl had moved to 13:19:05 on 08-25, so that fetch was a live test too, on a page that did not need one. Whether the task ran an inspection with a live test on it, or clicked and did not print it, we cannot tell from the log. It is counted, and it does not change either cohort.

The nine we did not click

Same site, same morning, same not-indexed state, no button. Between 2026-08-18 and the read, Googlebot made 0 requests to any of the nine. The AI fetchers had been to all of them: OAI-SearchBot on 9 of 9, PerplexityBot on 9 of 9, ClaudeBot on 9 of 9, Amazonbot on 9 of 9, and ChatGPT-User, the fetcher that fires when a ChatGPT user is actually shown a page, on 3.

The two posts published after the sweep (2026-08-25 and this morning) are in the same condition: Discovered or unknown depending on the read, 0 Googlebot requests, and OAI-SearchBot already on the older one. Nothing on the ledger between 12:30 and 14:30 UTC today looks like a second batch of clicks; the 7 Googlebot rows in that window are robots.txt, sitemap.xml, three already-indexed pages and the re-fetch of URL 4 noted above.

Search Console gave two answers four minutes apart

We read the API twice by accident (the first pass was thrown away by a path error and re-run), and the accident is the most useful thing in this post for anyone who tracks indexation daily. Between 16:41 and 16:45 UTC, 6 of the 12 not-indexed URLs changed state: three went from "Discovered" to "unknown to Google", three went the other way. None of the 10 indexed URLs changed. The two states are not a progression a page moves through; on this evidence they are two answers the API gives about the same unindexed page depending on which copy of Google's data answers the call. Our own daily notes for the past week describe URLs "regressing" from Discovered to unknown and "flipping back". Those were probably this, and we are saying so.

Why this matters if you care about AI visibility

• For a small site, the button is a real lever, and the ordinary path is not. Ten pages that Google's regular crawling had left alone for 5 to 39 days were indexed inside a day of one click each, and nine identical pages without the click are still out. If you have a handful of URLs stuck at Discovered, spend the daily quota on them before you spend an afternoon on internal links or sitemap tweaks. The quota is the constraint: 11 here, and Google's page says only that a limit exists.
• The fetch the button triggers is the crawl Google indexes from. Every indexed URL reports the live-test second as its last crawl. So the page you request is the page that goes in: if the title, the structured data or the body is wrong at the moment you click, that is what Google keeps until something else moves it. Check the live page first.
• AI engines and Google are on different clocks, and this is the second time we have measured it. OpenAI's, Perplexity's and Anthropic's fetchers had read all 9 untreated pages, and ChatGPT had shown 3 of them to users, while Google had not requested any of them once. Being cited by an answer engine and being in Google's index are separate outcomes with separate levers, and only one of them has a button.

If you want to know whether the engines currently cite your business at all, before worrying about which index it is in, the free 60-second check asks four of them the way a customer would and shows you the sources they used.

Limits

• Eleven and nine are small cohorts on one site, and the cohorts were chosen by quota order, not at random. The task printed its list in the order it worked through the sweep, so the treated set skews toward older URLs (four were over 27 days stuck; none of the untreated were over 5). That could favour the treated cohort if age helps, though the seven newest treated URLs went in just as fast.
• "Submitted and indexed" is Search Console's word, not ours. Google's help page says "URL is on Google" does not guarantee the page appears in results. We have not yet seen an impression on any of the ten in the Search Console performance report; that data lags about two days and is a separate read.
• The ledger trusts the user agent. A request that calls itself Googlebot from a US address in the live-test cadence is almost certainly Google, and the API's last-crawl field agreeing to the second makes that near-certain for the ten, but we did not reverse-DNS the addresses.
• One read at 27 hours. We do not know whether the ten went in at hour 1 or hour 26; the next scheduled sweep is the first point that could narrow it, and it cannot narrow it much.
• The task's own log does not name which URL hit "Quota Exceeded" or which click failed on the transient error, so URL 9's missing fetch has two possible causes and we have not chosen between them.

What we will publish next

This read was pre-registered before the data came in, with the decision rule written down on 2026-08-26 morning: on 2026-08-28, "M of 11 treated indexed vs N of 9 untreated"; M of 3 or more with N of 0 means the lever works and becomes the standing step for every new post; M of 0 means the live test is theatre. Today's reading is M 10, N 0. The 08-28 read is still the one that counts, and it will also say whether any of the nine untreated URLs went in on their own in the meantime, which would weaken the comparison. The cut script and artifact are `content/news/request_indexing_cut.mjs` and `content/news/request-indexing-cut-2026-08-26.json` in our repository; the twelve self-checks in the artifact assert every number above, including the second-for-second match between the ledger and Search Console.