**TL;DR** — Across 19 client sites in April and early May 2026 we measured edit-to-recitation latency: the time between publishing an edit to a cited paragraph and the Google AI Overview answer card reflecting that edit. Our cohort median was 11 days, with P25 at 4 days and P75 at 27 days — far slower than most teams assume, and slow enough that a flat monthly editorial cadence is routinely editing against a version of the page the composer is not yet serving. Two lag layers explained almost all of it: Google re-crawling the page (median 6 days) and the composer holding a cached extraction even after the re-crawl (a further median 4 days). A third pattern mattered more than either: edits that changed the claim propagated, while edits that only changed wording frequently never propagated at all — the composer kept the old paraphrase, and 23% of pure-wording edits had not surfaced after 30 days.
Why we ran the audit
Last month's cited-paragraph audit explicitly excluded any extraction where the matched paragraph had been edited in the prior 14 days, on the grounds that the post-edit period is a transient we did not want polluting the steady-state numbers. Several clients reasonably asked the obvious follow-up: how long is that transient, actually? If we edit the cited paragraph today, when does the answer card change? We had been answering "a week or two, probably" — a guess dressed up as a number — and a guess is a poor basis for an editorial calendar that costs real hours every month.
The second motivation is about cadence mismatch. Most editorial teams we work with run a monthly iteration: pull the citation report, decide which paragraphs to improve, ship the edits, read the result in next month's report. If the median edit takes 11 days to surface and a quarter of edits take 27 days or more, that monthly loop is partly measuring last month's edits and partly measuring noise. A team can conclude an edit "did not work," revert it, and ship a worse version of the page — all because they read the result before the composer had caught up. Latency you cannot see is latency that quietly corrupts every before-and-after comparison you run.
How we ran the measurement
19 client sites — 7 SaaS, 6 publisher, 4 DTC, 2 B2B services — across April and the first ten days of May 2026. For each site we selected a set of paragraphs currently being cited in an AI Overview, confirmed by our standing 60-query basket, made a single controlled edit to each, recorded the publish timestamp, and then captured the relevant answer card twice daily until it reflected the edit or 30 days elapsed. We instrumented two intermediate events as well: the page's re-crawl, read from server logs as a Googlebot hit and cross-checked against GSC's last-crawled field, and the index update, read via the GSC URL Inspection API. That gives three timestamps per edit — re-crawl, index update, recitation — and the gaps between them are the two lag layers.
Two normalisation moves matter. We classified every edit in advance as either a claim edit — the answer the paragraph gives actually changed, a number, a recommendation, a yes or no — or a wording edit, where the claim is identical and only the phrasing changed, and we report the two populations separately because they behave nothing alike. We also excluded any edit to a page that received an unrelated structural change during the measurement window — a new H2, a template update, a navigation change — because those confound the re-crawl signal. The reported numbers are for single, isolated, classified edits, which is the population an editorial team actually controls.
The shape of the latency distribution
Median edit-to-recitation latency was 11 days, with P25 at 4 days and P75 at 27 days. The distribution is long-tailed: 14% of edits took longer than 30 days to surface, and because our measurement window was 30 days the true P90 is a lower bound. Decomposed into the two layers, the re-crawl gap — publish to Googlebot re-crawl — had a median of 6 days, and the post-crawl gap — re-crawl to the answer card changing — had a median of 4 days. The index update sat almost exactly between them: pages were typically re-indexed 1–2 days after re-crawl, and the composer then took a further 2–3 days. Neither layer dominates, so you have to shorten both to move the headline number.
The split by edit type was the result that changed how we brief edits. Claim edits had a median latency of 8 days and a 30-day non-surfacing rate of 4%. Wording edits had a median latency of 19 days and a 30-day non-surfacing rate of 23% — nearly a quarter of pure-wording edits had not surfaced at all when the window closed. The composer, in other words, is far more willing to re-extract when the underlying answer has changed than when only the prose has. A wording edit that makes a paragraph cleaner but leaves the claim intact is, from the composer's perspective, often not worth re-extracting — it keeps the paraphrase it already has.
Driver one: re-crawl latency is the larger lag layer
The publish-to-re-crawl gap, median 6 days, was the single biggest component of total latency, and it varied enormously with how often Google already crawled the page. Pages in the most-crawled quartile of our sample — typically high-traffic pages on well-linked sites — were re-crawled within a median of 2 days. Pages in the least-crawled quartile — deep pages on smaller sites, often the long-tail commercial pages that pick up exactly one fan-out sub-query citation — waited a median of 16 days for a re-crawl. The composer cannot re-extract from a version it has not crawled, so for those pages the entire latency story is a crawl-budget story, and no amount of editing skill changes it.
The lever here is ordinary technical SEO, which is mildly deflating after a year of AI-specific tactics. Pages that re-crawled fast shared the familiar signals: internal links from frequently-crawled pages, presence in a fresh sitemap with an honest lastmod, and a server that responded quickly to Googlebot. We had one clean natural experiment — a client added internal links to twelve slow-crawled commercial pages from their high-traffic blog index, and over the following six weeks the median re-crawl latency on those twelve pages fell from 14 days to 5. The AI-search era did not retire crawl-budget hygiene; it raised the stakes on it, because a slow crawl now delays not just a ranking change but every answer-card correction you try to make.
Driver two: the composer holds a cached extraction after the crawl
Even after the page was re-crawled and re-indexed, the answer card did not change immediately — a further median of 4 days passed before the recitation reflected the edit. During that window the composer was serving an extraction from the pre-edit version of the page despite a newer version sitting in the index. This is a genuine second cache layer, distinct from the crawl, and it is the part of the latency that surprised us most: we had assumed that once the index updated, the answer card was a deterministic read off the current index. It is not. The composer's extraction is itself cached, and it refreshes on its own cadence.
We could not find a reliable lever to shorten the post-crawl gap — it looked close to a fixed cost, varying between 2 and 7 days with no signal we could tie it to. What we could do is stop misreading it. An edit that has been crawled and indexed but is not yet showing in the answer card is not a failed edit; it is an edit in the post-crawl window. We now check the GSC URL Inspection API before drawing any conclusion about an edit: if the page shows a crawl date after the edit, the edit has landed and the answer card will follow. Reverting an edit at that point is the single most common self-inflicted mistake we see in client editorial logs.
Driver three: wording-only edits often never propagate
The 23% non-surfacing rate on wording edits is the most operationally important finding in the audit, because it contradicts a habit a lot of editorial teams have. The instinct, when a citation is rendering as an awkward quote in the answer card, is to rewrite the paragraph more elegantly. But if the rewrite does not change the claim, the composer frequently keeps its existing paraphrase — it has already extracted a usable answer and sees no reason to re-extract a semantically identical one. The team ships a better paragraph, waits a month, sees the same awkward quote, and concludes AI search is capricious. It is not; the composer simply never looked at the new prose.
Two things reliably did force a re-extraction of a wording edit. Changing the structural position of the claim — moving it into the lead, or adding a query-matching H2 directly above it — propagated at the same rate as a claim edit, because the composer re-parses structure on re-crawl. And changing the claim even slightly — adding a date, sharpening a number from "around half" to "53%", naming the source — counts as a claim edit to the composer and propagates fast. The practical rule we now give writers: if you want the answer card to change, change the answer or change the structure. A pure prose polish is for the human reader on the page, and that is a fine reason to do it, but it is not a lever on the recitation.
What changed in our editorial process
Three changes. We added a latency budget to every edit: when we brief a change to a cited paragraph, we record the page's recent re-crawl cadence from GSC and set the review date 7 days past the expected re-crawl, not a flat 30 days after the edit. A page Google crawls weekly gets reviewed in two weeks; a slow-crawled page gets reviewed in five. Reading every edit on the same monthly cycle was guaranteeing that half our before-and-after comparisons were premature. We also classify every edit as claim or wording at brief time, and we no longer ship a pure-wording edit expecting a recitation change — if the goal is a better answer card, the brief has to include a claim or structural change.
We dropped one habit. Through 2025 our standing advice for a poorly-rendered citation was "rewrite the paragraph and re-measure next month." That advice was wrong about half the time — either the edit had not been crawled yet, or it was a wording edit the composer ignored. The new protocol checks the crawl date first via URL Inspection, only then reads the answer card, and only then decides whether the edit worked. It is three extra minutes per edit and it has roughly halved the rate at which clients revert edits that were actually fine.
- 01Budget for edit-to-recitation latency. Cohort median was 11 days and P75 was 27 — a flat monthly review cycle reads half of all edits before the composer has caught up.
- 02Treat re-crawl latency as a crawl-budget problem. The publish-to-re-crawl gap (median 6 days) was the larger lag layer, and one client cut it from 14 days to 5 with internal links alone.
- 03Check the GSC crawl date before judging an edit. After re-crawl the composer still holds a cached extraction for a median 4 more days — reverting an edit in that window is the most common self-inflicted mistake we see.
- 04Do not expect a wording-only edit to change the answer card. 23% never surfaced in 30 days; if you want the recitation to change, change the claim or the structure, not just the prose.
Where this argument breaks
For very high-authority pages that Google already crawls daily, the re-crawl layer nearly vanishes and total latency collapses to the 2–7 day post-crawl window — the budgeting advice still applies but the numbers are smaller and the variance lower. For sites under heavy crawl-budget pressure, large programmatic catalogues especially, the re-crawl gap can run to months and the latency is effectively unbounded; there the analysis becomes crawl-budget triage rather than an editorial-cadence question. Our measurement window was 30 days, so every figure for the long tail is a lower bound and the true P90 is unknown. In Chinese-language search, Baidu's re-crawl behaviour and 文心's extraction cadence are different again — Baidu re-crawls fresh-tagged pages faster but 文心's answer layer lags further behind the index, and the 11-day median does not transfer. Outside those carve-outs the lesson holds: the answer card you are looking at is a lagged view of a page you may have already changed, and an editorial process that does not budget for the lag will keep drawing the wrong conclusion from its own edits.