Does Google AI Overviews search the web live? What Google says, and a repeatable freshness test

Live web search is not one thing, and the question cannot be answered yes or no. An answer can be built from a model's training, from an index of pages crawled earlier, from a fresh retrieval at the moment you asked, or from a mixture of all three, and from the outside you cannot tell which happened. What you can do is measure the delay: publish a page with a fact that exists nowhere else, verify the date it was indexed, then ask the question daily until the fact appears in an answer. We publish no median for that delay, because we have exactly one verified first appearance, on one page, on one assistant: ChatGPT cited a clawlaw.in page fourteen days after publication, on 6 August 2026. One page is not a median and we will not present it as one.

This is the page where the temptation to overclaim is strongest, because a number like fourteen days is easy to remember and travels well. It also happens to be a single observation, from ChatGPT rather than AI Overviews, with no failure set published beside it. So here is the test in full, and an honest account of what we have and have not run.

What live web search could mean

Six different mechanisms get described with the same phrase. They have different implications for your website, so separate them before you test anything.

• Answering from model weights. The system uses what it absorbed during training. Nothing published after that is available to it.
• Answering from a search index. It consults an index of pages crawled at some earlier time. Your page has to be crawled and indexed first, and the index may lag the page.
• Retrieval at question time. The system issues its own search when you ask, and reads what comes back.
• Retrieval of a cached copy. It retrieves at question time but reads a stored version of the page rather than fetching it again.
• A cached answer. The answer itself was generated earlier for the same or a similar query and is being shown again.
• A mixture, decided per query. Some questions get retrieval and some do not, by a rule that is not published.

The sixth one is the reality you should plan for, and there is a measured reason to believe it. On 27 July 2026 we asked ChatGPT 78 buyer questions with no brand named for the clawlaw.in programme, and it then confirmed it had run no live web search for any of them. Zero of 78. The whole reading described what the model remembered rather than what it could find. A system capable of searching does not always search.

There is a second, harder lesson about asking. In the aiknowsus.com audit of September 2026, Perplexity withdrew its own earlier statement when asked how many of the questions it had actually searched for, saying it could not honestly substantiate the claim that it had run a live search for each one, and in another batch that its claim to have searched all five was not adequately supported. That happened in three separate batches. So a system's own account of whether it searched is a claim to be recorded, not a measurement to be trusted.

What Google's documentation says

Google's public help material describes AI Overviews as appearing for some searches, drawing on its search results, and linking out to pages that support the answer. It does not publish a rule for when a fresh retrieval happens, how long a page takes to become eligible, or whether an Overview you are shown was generated for you at that moment.

We are deliberately not quoting the documentation as a dated passage. Help pages are edited and a paraphrase with no date next to it is exactly the sort of source this page tells you to distrust. Read the current page yourself on the day you need it, and if it now says something that contradicts this page, tell us and we will correct this page.

A freshness test readers can reproduce

This is the protocol, and it is written to survive somebody checking it. It needs ten pages minimum to produce anything worth calling a result.

One. Build a test panel of at least ten pages. Fewer than ten and you will have anecdotes. Each page must answer one real buyer question and each must be genuinely useful, because a page published only to be measured is a page nobody will cite.

Two. Put a unique verifiable fact on each page. A specific coverage count, a dated price, a named process step: something that exists on your page and nowhere else, so an answer containing it can only have come from you. This is what makes first appearance detectable at all.

Three. Record the publication timestamp for each page, to the minute, from your own system.

Four. Verify indexing and record that date separately. Use URL Inspection and log the first date the page is confirmed indexed. Time to first appearance is measured from the indexing date, not the publication date, because a page that was never indexed did not fail to be cited, it failed to be crawled. Both dates go in the sheet.

Five. Write one query per page and freeze it. No brand name in the query. A brand name turns the test into a lookup and destroys it, which is exactly what happened to the run we discarded on 27 July 2026 for clawlaw.in, where a wrapper naming the brand ranked it first on almost every question.

Six. Ask daily, under identical recorded conditions, and capture a screenshot every day whether or not the page appeared. The days it did not appear are half the data.

Seven. Score first appearance with a written rule. We use three levels and record all three: the unique fact appears in the answer text, the page URL appears in the supporting links, or both. State which level your headline number refers to.

Eight. Stop at a preset horizon and record failures. Choose 60 days before you start. Pages that never appeared are reported as a count, not dropped. A median calculated only over the pages that succeeded is one of the most misleading numbers in this whole field.

Nine. Test on more than one system and report each separately. They select sources differently and a result from one is not evidence about another.

Ten. Publish the whole panel, including the pages that never appeared, the indexing dates, and the query for each. Without the failures, your median is not a median.

Results by time since publication or update

We publish no median time from indexing to first appearance. The reason is stated plainly: our panel is one page, on one assistant, and it was not AI Overviews. Under the rule in step eight, a median over a panel of one with no disclosed failure set is not a statistic. We would rather have an empty cell than a memorable wrong number.

Here is the single observation, in full, so you can see both what it shows and what it cannot.

On 6 August 2026, ChatGPT cited clawlaw.in/blog/how-to-check-a-companys-court-cases-in-india as a source for a vendor due diligence question. That page had been published fourteen days earlier. The same question set, run blind on 27 July 2026, had named the company nowhere in that zone. This is the one dated result in the whole clawlaw.in programme that has a public URL behind it, which is why it is quotable at all.

What it shows: a new page on an established domain can be reached and used by an assistant within about two weeks of publication, for a question where the domain had previously not appeared.

What it cannot show: a typical delay, a delay for a new domain, a delay for AI Overviews specifically, or a delay for any other page. The indexing date for that page was not separately logged at the time, which is a defect in our own record and the reason step four exists in the protocol above.

We are running the panel version of this test on our own domain, and when it is complete the result will be published here as a median with the panel size, the failure count, the engines and the dates, or not published at all.

Limitations: one page is not the whole web

Seven limits, and the first four are the ones that get ignored.

• A panel measures your domain, not the web. Domain age, existing traffic and internal linking all plausibly affect the delay, and your result carries all of them.
• First appearance is only detectable if the fact is unique to you. If the same fact exists on five other sites, an answer containing it proves nothing about your page.
• A median over successes only is a false number. Report the failure count in the same sentence.
• Absence on a day is not absence. Answers vary between identical runs, so a page can appear on day 12, vanish on day 13 and return on day 15.
• Systems change without notice, so a delay measured in September says nothing guaranteed about December.
• Asking the system whether it searched is not evidence. Three batches of retraction in September 2026, described above.
• Nothing here gets you a position in an answer, and no measured delay implies one.

Sources and change log

The observations on this page come from the clawlaw.in programme of July and August 2026, recorded in GEO_BASELINE_RESULTS_2026-07-27.md including its interim check section, and from the aiknowsus.com audit of September 2026 across 24 batches and 72 conversations. The 6 August 2026 citation can be verified from outside, since the page and the URL are public. The count of zero live searches across 78 questions and the three retractions are recorded in our capture files and cannot be checked from outside until those files are published.

Version: 29 September 2026, first publication. This page gets updated when our ten page panel completes, when any figure is corrected, and if Google's documentation changes in a way that contradicts anything above.

Common questions

So does it search live or not?

Sometimes, by a rule that is not published, and you cannot tell from the outside which mechanism produced the answer you are looking at. The one hard measurement we hold is in the other direction: across 78 questions on 27 July 2026, ChatGPT confirmed it had searched for none of them.

If I update an old page, does that count as fresh?

Test it as a separate arm of the panel, because an update to an indexed page and a brand new URL are different events. Put a new unique fact in the update, record the update timestamp, and score it the same way. We have not run that arm and we are not going to guess at the answer.

Why measure from indexing rather than from publishing?

Because two very different failures look identical otherwise. A page that was never crawled and a page that was crawled and not used both show up as never appeared. Logging the indexing date separates them, and the second case is the only one that tells you something about the page's content.

Can I speed this up by submitting the page for indexing?

Submitting for indexing addresses the crawl part, which is worth doing and is not the same as being chosen as a source. Record it in the sheet as an action with its date so that the two effects can be told apart later.

Ten pages sounds like a lot of work for one number. Is it worth it?

Only if the pages are ones you wanted anyway. Build the panel out of pages you were going to write, each answering a real buyer question, and the measurement becomes a by product of work that has its own value. Publishing ten pages purely to measure a delay is not a good use of a month.

Data and reproduction instructions

To reproduce: ten pages, one unique fact each, publication and indexing timestamps logged separately, one frozen blind query per page, daily capture with screenshots including the negative days, a 60 day horizon set in advance, the three level appearance rule, at least two systems reported separately, and the full panel published with its failures. Everything in that list is inside your own control and none of it requires a tool.

Our own panel data will be published when the run finishes. The one existing observation is already public through the cited URL, and the capture files behind the rest of the programme are being prepared for release.

What to do first

Pick the next page you were going to publish anyway, and before it goes live, put one fact on it that exists nowhere else, write down the publication time, and check the indexing date every day until it is confirmed. That single habit costs nothing and it turns every page you publish from this week into a data point you can use later.