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.

Thirty-nine days later: the same 20 URLs, re-read on 2026-10-03

We re-read every URL in both cohorts on 2026-10-03 at 16:50 UTC, 39 days after the last click, with the same two instruments: Search Console's URL Inspection API for index state and last-crawl time, and the crawler ledger for every request whose user agent names Googlebot since 2026-08-25 13:38 UTC (probe and spoofed rows excluded). Search Console's performance report was read for the same URLs over 2026-09-03 to 2026-10-01, the 28 days the API serves complete. The cohorts are read from the 08-26 artifact, not chosen today. Between the two reads sits the pre-registered 72-hour read, published 2026-08-28: 10 of 11 clicked URLs indexed, 2 of 9 unclicked indexed on one organic Googlebot fetch each.

The equal impression totals are a coincidence of the window, and 178 impressions across eleven pages in 28 days is small either way. The column is there because at the 27-hour read neither cohort had appeared in results once; now both do.

The nine we did not click, 39 days on

Six of the nine went in, each after an organic Googlebot fetch: two on 2026-08-27, which the 08-28 post reported, one on 08-30, and three between 09-07 and 09-10, so 2 to 16 days after the test. We made no further Request-indexing clicks; the task that pressed the button on 08-25 was gone from the machine before the 08-28 read. The three Googlebot has never requested read Discovered, Discovered and unknown to Google, with 0 Googlebot rows in 39 days; each of them was fetched by OpenAI's, Perplexity's, Anthropic's and Amazon's crawlers in the test week, as the table above records, and the answer engines have not been waiting for Google since.

URL 9 of the clicked list, the Reddit-citation post, was the one clicked URL with no fetch on the day. Googlebot first requested it on 2026-09-11 at 13:03:36 UTC, 17 days after the click; Search Console reports a last crawl of 2026-09-12 19:27:29 UTC, and it is indexed. The click did nothing visible for it. The organic fetch did.

The ten clicked pages, 39 days on

All 11 are indexed. The last-crawl field, which at 27 hours and at 75 hours still reported the click second on all 10 fetched URLs, has moved on all 10, and on every one of them the time it now reports matches a Googlebot row on our ledger to the second. On 4 of the 10 it is the newest row we hold; on the other 6 it names an earlier fetch while the ledger holds later ones (the robots.txt post reports 2026-08-26 12:52:12 UTC and was fetched again on 2026-09-26). So the question the 08-28 post left open, whether Googlebot's later requests count as crawls of record, is answered for the clicked pages: they do, on a delay we did not measure. The ledger and Search Console describe the same fetches; Search Console reports them late.

The button moved the fetch date, not the outcome. At 27 hours the cohorts stood at 10 of 11 against 0 of 9; at 39 days they stand at 11 of 11 against 6 of 9, and the line between indexed and not indexed is no longer the click but the fetch: 17 of the 17 pages Googlebot requested are indexed, 0 of the 3 it did not request are. What the click bought was time. The clicked pages went in overnight; the unclicked pages that went in waited 2 to 16 days; three are still waiting at 39. For a page that has to be in the index this week the button is still the lever. For the question of whether an unclicked page gets in on its own, the answer on this site is two in three, so far.

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. At the 27-hour read we had not seen an impression on any of the ten; over 2026-09-03 to 2026-10-01 the eleven clicked URLs drew 178 impressions and 1 click, the six indexed unclicked URLs 178 and 0.
• 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 75-hour and 39-day re-reads are above; neither narrows the hour.
• 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 was published 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. The 08-28 read is published as Do pages you never request indexing for get indexed on their own? 2 of 9 went in on single organic Googlebot fetches in 3 days: M 10, N 2, with the internal-linking change shipped that day and its own read. The 39-day re-read above was added on 2026-10-03; its script and artifact are `content/news/request_indexing_39d_cut.mjs` and `content/news/request-indexing-39d-cut-2026-10-03.json` in our repository, 8 of 8 self-checks. The 08-26 cut script and artifact, `content/news/request_indexing_cut.mjs` and `content/news/request-indexing-cut-2026-08-26.json`, are unchanged.