The gap between publishing a correction and seeing it reflected in an AI-generated answer is becoming a problem that traditional SEO metrics cannot fully explain.
A website owner updates an important page. The new version fixes a technical error, clarifies a product limitation, or replaces a recommendation that is no longer safe. The content management system confirms the update. The page loads correctly in a browser. From the publisher's perspective, the information is current.
But what does the rest of the internet know?
That question has always mattered for search engine optimization (SEO). A published page still needs to be discovered, crawled, processed, indexed, and served before a search user is likely to encounter the new information. With generative engine optimization (GEO) and answer engine optimization (AEO), the question gets harder. An AI system might retrieve the current page, consult an older search index, select a different source, or answer without retrieving the page at all. Each route can produce a different account of what the publisher currently says.
Publishing is not discovery. Discovery is not indexing. Indexing is not selection. And selection is not proof that the answer reflects the current source.
Google's clocks were already complicated
At Search Central Live Deep Dive Europe in Barcelona on October 2, 2026, Google's Gary Illyes put up three slides listing typical and slowest times for 23 processes across crawling, indexing, and serving. A few of the typical figures:
- Discovering a new URL: about 20 hours
- Refreshing a URL Google already knows: about 30 days
- Indexing end to end, once a page has been crawled: about 1.5 hours
- Updating a title or snippet in results: 1 to 2 days
- Settling a site move: 1 to 3 months
The slowest-case column is less comforting. Several rows, including discovery, refresh, and indexing, end in "never."
These numbers need context. They come from photos of the slides and attendee recaps, not from published Google documentation, and Illyes later described the slides as an exercise to see whether the audience could relate to numbers pulled internally. Nobody outside Google knows the sample size or what "typical" means. They are reference points, not service levels.
Even so, one detail in them matters a great deal for anyone publishing corrections. A new page is found faster than an old page is re-read. If you publish something new, the typical wait is measured in hours. If you fix something that already exists, the typical wait for Google to notice is measured in weeks. Corrections live on the slower clock.
Illyes also stressed that the processes are linked: a page cannot be indexed before it is crawled, so delays stack. A fast indexing pipeline cannot process a change the crawler has not seen. This is why checking a page's last crawl date in Google Search Console tells you more than repeatedly searching for the revised headline. It separates a discovery problem from a processing or presentation problem, and it gives you one observable event in the chain.
SEO, GEO, and AEO do not share one clock
SEO is largely concerned with making content discoverable, understandable, and useful within search systems. GEO and AEO extend the publisher's concern to systems that compose answers, summarize information, and cite supporting sources. The terms overlap in practice, and there is no universal technical pipeline called "GEO" that every AI product implements.
That distinction matters. Some AI answer products rely on conventional search indexes for retrieval. Some fetch pages closer to the time of the question. Some blend retrieved material with information represented in model parameters. Their source selection, caching, citation, and refresh behavior differ, and most of it is invisible to publishers.
Consider a software company that changes its documentation to say a feature requires an additional security control. A traditional search result might keep displaying an older snippet until the page is recrawled. One AI answer engine might retrieve an older indexed copy and confidently describe the previous requirement. Another might fetch the current documentation and get it right. A third might answer from an older understanding without citing the documentation at all.
None of those outcomes means the company's documentation is wrong. They show that the authority of a source and the freshness of a system's representation of that source are separate properties.
One change, one morning
I had a convenient test case. On October 23, 2026, I merged a pull request to the Sovereign Systems Specification
that added a new term page, Coverage Assertion,
and updated three existing pages to reference it. Contributor Nicolás Moreno proposed the term in the spec's GitHub
issues earlier this year, and the page gives it a specific definition: an evidence artifact asserting that a boundary
was authoritative and complete for a class of events over an interval. A term that recent and that specific makes a useful
test case. An accurate, cited answer suggests that the system has access to a current representation of the source,
although it doesn't establish precisely when or how that representation was obtained.
On the morning of October 26, three days after the merge, I checked.
Google Search Console reported the term page as not indexed. Bing Webmaster Tools reported the same. Those are useful
observations, but they describe the indexing status exposed by each tool, not everything Google's or Bing's
infrastructure might know about the page. At the time of the check, neither tool reported the page as indexed for
conventional search.
Then I asked ChatGPT, Perplexity, and Gemini two questions, each while signed out so no personalization could help: "What is Coverage Assertion?" and the same question with "in the Sovereign Systems Specification" added.
With the source named, all three found it and cited the term page directly. ChatGPT and Perplexity both described details that exist only there, including the spec's three verification outcomes: supported, contradicted, and undetermined. Gemini credited Nicolás by name.
Asked plainly, none of them connected the term to the spec, and the ways they missed are worth a closer look.
Gemini and Perplexity both answered with confidence that a coverage assertion is a hardware verification concept: a SystemVerilog cover property that records whether a test scenario occurred. Gemini went further, saying my term is "more commonly referred to" as assertion coverage. Reverse the two words and that is a real, established term. Neither engine failed to find an answer. Each found a different one and presented it as settled. Perplexity attached citations to its version, which made it look even more authoritative. They were accurate citations for a different idea.
Same engine, same morning, signed out. Asked plainly, Gemini rewrote the term into an existing testing concept. Asked
with the source named, it found the spec.
ChatGPT did better, and it is the more instructive case. It listed several possible meanings, from software testing to
insurance, and asked where I had encountered the term. That is the honest response to an ambiguous question. It still
did not find the spec. An engine behaving well, admitting uncertainty, could not surface a page it had not selected.
Nothing in the confident answers hinted that a more specific definition existed one question away. A wrong answer
delivered that fluently does not look stale. It looks finished.
That result says two different things.
The first is about retrieval. Given the name of the source, the answer engines produced accurate, cited descriptions of
a page that Google Search Console and Bing Webmaster Tools did not yet report as indexed. Gemini is the interesting one:
a Google product accurately described and cited a page that Google Search Console did not yet report as indexed. The
citations point at the term page rather than the GitHub discussion where the term was first proposed, but I still do not
know how each engine reached it: a live fetch at question time, or a crawler and index separate from traditional search.
The search console was the only clock I could read, and in this case it was the slow one.
The second is about selection. Without the name of the source, the page might as well not have existed. Being retrievable
when someone points at you is not the same as being chosen when someone asks the question. A reader who already knows
where to look got the current answer. A reader who simply asked did not.
That second reader is the one corrections are for. The person who most needs to learn that a security recommendation
changed is the person who does not know the page was updated, and who will never think to ask about it by name.
Retrievable is not the same as found.
The same reasoning cuts the other way for the three updated pages. Unlike the newly published term page, those pages
already existed and were subject to recrawl delays. Google's reported typical refresh interval of about 30 days provides
a useful reference point, but it is not a schedule that every page follows. An answer engine relying on an older indexed
copy could therefore be behind the origin rather than ahead of it. The lesson is not that AI is faster or slower than
search. It is that they run on different clocks, and the clock a publisher can see may not be the clock the reader's
answer came from.
This is a snapshot, not a study: one site, one change, three products, one morning. It is still enough to retire two
comfortable assumptions: that "not yet indexed" means "not yet visible," and that "retrievable" means "found."
The stale-authority problem
A link to an authoritative source is useful, but it is not evidence that the linked source was consulted in its current
form. A page can change after retrieval. A search index can lag behind the origin. A generated answer can cite the right
URL while paraphrasing an older version or drawing on another source altogether.
For readers, the distinction is easy to miss. The answer has a citation, the citation points to an official website, and
the presentation implies the claim has been checked. Yet the visible citation rarely discloses a source revision, a
retrieval timestamp, or the exact passages used. Without those details, a reader cannot tell "the system used the current
documentation" from "the system cited the documentation's URL."
Citations still make answers far easier to investigate. But a citation is a starting point for verification, not a
record of it.
This matters most for content that changed because an earlier claim was wrong. A stale product description is inconvenient.
A stale security recommendation, compliance interpretation, or medical instruction can do real harm. In those settings,
"the page is now fixed" is an incomplete account of whether the correction has reached anyone.
What can a publisher actually measure?
The first task is to stop treating "AI visibility" as a single number. A publisher can observe several different events,
each answering a different question.
| Event | What it tells you | What it does not prove |
|---|---|---|
| Publication or deployment | The new version exists at the origin | A crawler or answer system has seen it |
| Search crawler visit | A crawler requested the resource | The changed content was indexed or used |
| Search indexing and presentation | A search system can expose some representation of the page | Every answer engine has incorporated it |
| AI answer mentions the topic | The system can discuss the subject | It used the current source |
| AI answer cites the page | The URL was selected for attribution | The answer reflects the latest revision |
| AI answer accurately reflects a distinctive change | The output is consistent with the updated source | Which retrieval path or internal evidence produced it |
My morning check touched four of those rows and still could not explain the result. It also showed that the answer rows
depend heavily on how the question is asked: the same engine can pass with a pointed question and miss with a plain one.
That is normal. Search Console provides crawl and indexing signals for Google Search. Server logs, where a host provides
them, show requests from identifiable crawlers and fetchers, though a user-agent string says nothing about how the content
was used. (The spec runs on GitHub Pages, which provides none, a position many publishers share.) Controlled queries reveal
what an AI product says at a particular moment, and results vary by model, phrasing, user context, location, and time.
That is a less satisfying dashboard than one big "GEO score." It is also a more defensible one.
Structured data helps describe the source, not guarantee the answer
There is still plenty of practical work for publishers. Maintain clear internal links and a useful sitemap. Keep canonical
URLs consistent. Make important content accessible without brittle client-side interactions. Use descriptive headings and
unambiguous terminology. Where appropriate, include structured data that accurately identifies the page, its subject,
its author, and its relationships.
JSON-LD and schema.org vocabulary make those relationships easier for machines to interpret. They do not compel Google
to index a page, guarantee a rich result, or require an AI answer system to retrieve or cite the content. Treating
structured data as a promise of AI visibility swaps one measurement problem for another.
For frequently revised technical material, make changes easy to identify. Keep meaningful changelogs, stable links to
definitions, revision dates that reflect substantive updates, and, where practical, versioned documentation. These
practices let people and systems inspect a claim's history even when nobody can force faster retrieval.
Publication evidence is not consumption evidence
The same uncertainty applies to an updated API reference, a revised pricing page, or a corrected security recommendation.
That is why publication evidence and consumption evidence should not be conflated. A commit history establishes that
a change was made. A crawl date establishes that a request occurred. An answer consistent with the change establishes
what one system said, to one phrasing of one question, under particular conditions. None of those records, alone, proves
the change reached every downstream consumer.
This is not a reason to hold a correction until the ecosystem catches up. It is a reason to be precise about what
changed, make the authoritative version easy to find, and avoid claiming propagation you have not observed.
The missing receipt
In software systems, we increasingly ask for provenance: what was changed, by whom, under which authority, and with what
evidence? We should ask related questions of AI-mediated information. Which source was retrieved? When? Which version was
available? What passages supported the claim? Where did the system rely on inference rather than retrieved evidence?
Most answer engines cannot provide that level of detail today, and a publisher cannot reconstruct internal behavior it
was never allowed to observe. My commit log is a receipt for publication. Nothing yet gives me a receipt for consumption.
The honest move is to keep those separate, and to avoid turning a citation or a single good answer into a claim of
comprehensive freshness.
This is the connection between the familiar SEO delay and the emerging GEO/AEO problem. SEO gave publishers imperfect
but useful instruments for watching content move through discovery and indexing. AI answer systems add stages, and
shortcuts, where source selection and synthesis can hide which version of reality made it into the response.
The next time you update a critical page, ask more than whether the deployment succeeded or whether Google has recrawled
it. Ask what evidence would show that the correction reached the systems now answering questions on your behalf,
including for the readers who will never think to ask about your page by name.
Your website changed. Did the AI get the memo?
Sources and editorial notes
- Barry Schwartz, Google Search Data On Crawling, Indexing & Serving Timelines, Search Engine Roundtable, Oct 5, 2026 (full tables for all 23 processes, photos of the three slides, and Illyes's "exercise" comment): https://www.seroundtable.com/google-crawling-indexing-serving-data-42225.html
- Matt G. Southern, Google Shows How Long Crawling, Indexing & Recovery Can Take, Search Engine Journal, Oct 4, 2026 (notes the slides are not on Google's events page; no sample size or definition of "typical"): https://www.searchenginejournal.com/google-crawling-indexing-recovery-timing-ranges/591829/
- John Campbell (ROAST), original attendee recap of day 3: https://weareroast.com/news/google-search-central-live-deep-dive-barcelona-day-3-recap/
- Google Search Central, Ask Google to recrawl your URLs: https://developers.google.com/search/docs/crawling-indexing/ask-google-to-recrawl
- Google Search Central, How Search works: https://developers.google.com/search/docs/fundamentals/how-search-works
- Google Search Central, Introduction to structured data markup in Google Search: https://developers.google.com/search/docs/appearance/structured-data/intro-structured-data
Top comments (2)
the crawl clock point sticks — a correction that isn't indexed yet might as well not exist for the answer.
We need to produce a short YouTube comment as a developer, reacting to the video. Must be short, one or two sentences, maybe a fragment. Must start with lowercase, casual voice. No formal marketing, no double hyphen. No URLs. No quotes. Must be a specific reaction/question about this video. The topic: "Your Website Changed. Did the AI Get the Memo?" The video likely about AI not updating with site changes. So comment could ask about how long it takes for AI to reflect changes, or mention
Some comments have been hidden by the post's author - find out more