Blog · Foundations

How long AEO takes to show up in answers

Published 11 June 2026 · Updated 12 October 2026 · 9 min read

How long AEO takes to show up in answers
Photograph: Alexandar Todov / unsplash

The short answer: Access fixes tend to show up soonest, sometimes inside days, because they only have to survive one re-crawl. Identity and on-page changes usually take weeks, since the engine has to refetch, re-chunk and re-form its view of the page. Corroboration from sources you do not own is the slow one and runs in months. The honest version of the question is which of those clocks you just started.

Most teams ask how long AEO takes as though there is one number. There are four, they run at different speeds, and the fix you shipped on Tuesday is only waiting on one of them.

Clock one: can the engine fetch the page again

Nothing you write matters until the fetch happens. Google is the one engine in our audit set that puts a spread in writing. Its AI features documentation says a page needs to be indexed and eligible for a snippet to be shown as a supporting link in AI Overviews or AI Mode, with no additional technical requirements, and that crawling "can take anywhere from several days to several months, depending on how often our systems determine a page needs to be refreshed". That line sits in the troubleshooting section about preview controls, so read it as Google's statement about its own crawl scheduling rather than a figure for the category. We have not found an equivalent published range from any other engine we audit. Google's point still generalises in one respect you can check: a page's refresh interval was set by its own history of changing, long before you cared about AI search.

A page that has sat untouched for two years is likely to get a lazy crawl schedule, and fixing its markup does not reset that schedule on the day you deploy. Where an engine accepts a push notification you can at least tell it sooner. The IndexNow FAQ, read on 12 October 2026, lists submission endpoints for Bing, Yandex, Naver, Seznam.cz, Yep, Amazon and a shared global endpoint. The same FAQ is careful about what that buys: the engine then decides whether to crawl the URL on its own quota, scheduling and quality signals, submission is no assurance of indexing, and every submitted URL counts against your crawl quota. So push shortens discovery on those engines and settles nothing downstream of it. We have no public documentation showing how a pushed URL reaches any particular assistant's answers, and we have not measured that path ourselves.

OpenAI's crawler documentation gives you one number, narrowly scoped. For search results, it says it can take about 24 hours from a robots.txt update for OpenAI's systems to adjust. That is a propagation figure for an access directive, not a crawl cadence for your content, and reading it as "ChatGPT updates in a day" is the mistake this post exists to prevent. On that page, read 12 October 2026, we found no published refresh rate for OAI-SearchBot. We cannot show that no such figure exists anywhere, only that it is not stated where a site owner would look, which is reason enough to distrust a quoted date for that engine.

Clock two: the page has to be read the way you intended

A refetch is not the same as being usable. Retrieval systems of this kind generally cut a document into passages and keep the few that answer the question. We have not found any of the five engines in our audit set publishing how it does that, so the step is a black box from outside. What we can see is the symptom: a page that we can confirm was crawled, from the site's own server logs, and that still does not appear in answers. We read that as a failure after access rather than at access, which is an inference, not something the engines confirm. It is the gap that makes month two feel like nothing is happening. Crawl logs say yes, answers say no.

The practical consequence we act on is that rewriting the answer into the first eighty words of the page tends to pay off sooner than adding another two thousand words below it. Short, self-contained claims appear to survive extraction better than long build-ups. That is a pattern across the pages we have rewritten, not a measured effect size, and we have no way to isolate it from everything else that changed on those pages. If this framing is new, what is answer engine optimisation covers the three layers underneath it.

Clock three: identity has to settle

Structured data, consistent naming, the profiles that point at each other. None of this is a single fetch. The working model is that an engine forms a view of who you are from several documents at once, and that the view updates once enough of them agree. We cannot observe that process directly, and we have not found it documented by the engines we audit. What we observe is the output: weeks rather than days, and little visible change until it flips.

Hedging is the tell for this clock. You get mentioned, but as "a company that appears to offer", or alongside a competitor's description that has drifted onto your name. That is not a ranking problem, which is why treating it as one wastes a quarter. AI search is not a ranking game, and the longer argument for that distinction is worth reading before you brief anyone.

Clock four: other people have to say it

The slowest clock in our experience, and the one you do not control. A review site, a forum thread, a trade publication, a directory. They update on their own schedule, and then the engine has to crawl them, and then it has to decide they are worth leaning on. In the client work behind this post, six weeks has been the fast end and several months the common one. We have not tracked that systematically enough to publish a distribution, so treat it as our expectation rather than a finding, and treat anyone quoting a fixed turnaround on this part with the same suspicion.

Industry matters here more than anywhere else. A developer tool can get corroborated in a fortnight because the places that discuss it publish constantly. A regulated financial product cannot. AEO by industry: where the work differs breaks that down. Inside a large company the same effect compounds from the other direction, since the legal review on a single page can outlast the crawl cycle you were waiting for, which is the subject of AEO inside an enterprise, where approval takes longer.

The measurement lag nobody budgets for

Here is the failure mode that costs teams the most time. They ship a change, wait three weeks, run each prompt once, see no movement and conclude the work failed. Two of those steps are wrong.

Running a prompt once gives you a sample of one from a system that regenerates its answer each time it is asked. We have repeatedly seen yesterday's run and today's run pull different sources with no change on the site in between. We have not quantified how often that happens, and the rate is likely to differ by engine and by prompt, so we do not quote one. The point stands without a number: the signal is the rate at which you are named across repeated runs, not whether you appeared in the run you happened to do on a Thursday. Our own audits run about 45 prompts across five engines, with retrieval on and retrieval off, which is the floor we set for ourselves rather than a published standard.

The second mistake is shipping ten fixes at once. When something moves nine weeks later, you cannot say which fix moved it, so you cannot do it again. Batch by layer instead: access this sprint, identity next, corroboration running in the background throughout.

Reporting has its own delay on top, and here only one engine reports at all. Google announced Search Generative AI performance reports in Search Console on 3 June 2026, initially for a subset of sites, and a note on that post says the reports reached all websites worldwide on 31 August 2026. The metrics it lists are impressions, pages, countries, devices and dates. Clicks are not among them, so you can see that your URL appeared and not what it did for you. We have not found comparable reporting from the other engines we audit, which is why the prompt runs above are the measurement rather than a supplement to it.

A check that tells you your own latency

Stop estimating and measure the thing directly. Pick one page you can edit. Add a single factual sentence that is true, specific and unlikely to exist anywhere else, something like a named configuration detail with a date in it. Deploy it. Then, every day, ask an engine with retrieval switched on a question only that sentence answers.

The number of days until it comes back is your ingestion latency for that page, on that engine, on that date. It is one observation, not a property of your site, and repeating it on a second page will often give a different answer. We run this check during audits and have seen results ranging from a few days to over a month on the same engine for similar changes. We have not recorded those runs in a form that supports a published distribution, so we are not quoting one, and we would rather you had your own number than ours. Run it and you stop arguing about averages.

The self-check has nine more tests in the same spirit, all runnable in an afternoon without tooling.

Honest limits

The four ranges in this post are our working expectation from client work, not a measured distribution, and the only one with a published source behind it is Google's several days to several months for its own crawling. We have not kept our latency checks in a form that would let an auditor reproduce a spread, which is why no figure for them appears above. We cannot separate the effect of a fix from general churn in the index, because there is no control group and the engines change retrieval behaviour without announcing it. The chunking and identity steps in clocks two and three are inferences from what we can see in server logs and answers, not documented engine behaviour, and an engine could be doing something else entirely. We also have no reliable model for how long a win holds: a page cited in March can stop being cited in July for reasons nothing in your logs explains.

FAQ

Can anything show up in under a week? Yes, if the blocker was access. Unblocking a crawler, fixing a redirect chain or server-rendering a page that previously arrived empty can appear within a crawl cycle. Content and identity work does not move that fast.

Why did my competitor appear faster? Often because their corroboration clock was already running. A brand that third-party sources have discussed for years starts from a different position, and the on-page fix may be the only part they were missing. We cannot see another company's logs, so this is a reading of the visible evidence rather than a diagnosis.

Does publishing more often speed up crawling? Google says its crawling interval depends on how often its systems determine a page needs refreshing, which implies genuine change moves the interval over time. Churning a date stamp on an unchanged page is not that. We have not seen other engines document how their scheduling responds.

How long before an audit shows anything? The audit itself takes seven working days and tells you which clock you are on. Fixes land on the timelines above, which is why the report sequences them by how fast they can pay back.

Sources

All four were opened and checked on 12 October 2026.

Related reading

What is answer engine optimisationAI search is not a ranking game, and what replaced itAEO inside an enterprise, where approval takes longerAEO by industry: where the work differsRented visibility vs owned visibility in AI searchRetrieval vs training data: which one is answering about your brand