Google has shared unusually specific internal timing data for some of the most common crawling, indexing and Search recovery processes. During Search Central Live Deep Dive in Barcelona, Gary Illyes presented typical and worst-case ranges based on Google's own internal analysis, offering SEO teams a clearer benchmark for how long changes can realistically take.
The numbers are not service-level guarantees. Illyes stressed that many processes depend on earlier stages completing successfully, which means delays can accumulate. The presentation also repeatedly attached the possibility of “never” to some worst-case outcomes when Google does not consider a page or resource worth processing.
A new URL is typically discovered in about 20 hours
Google's internal data puts typical discovery of a new URL at roughly 20 hours, while sitemap processing is around 24 hours. At the slow end, discovery can take weeks or may never happen, and sitemap processing can take up to 14 days or fail to progress for quality-related reasons.
This distinction is important because sitemap submission is not equivalent to indexing. A sitemap helps Google discover URLs, but the URL still has to move through crawling and subsequent indexing systems.
End-to-end indexing can take around 90 minutes
Once the necessary processing succeeds, Google's typical end-to-end indexing time is about 1.5 hours. Rendering itself can happen in seconds, although pages may wait hours in a rendering queue. Meta annotations typically take 45 to 90 minutes, while link annotations can range from minutes to one to three weeks.
The headline number therefore needs context. Ninety minutes does not mean a newly published URL will necessarily appear in Google's index 90 minutes after publication. Discovery and crawling must happen first, and each dependent stage can introduce its own delay.
Canonical changes typically need one to three weeks
Google's typical range for a canonicalisation change is one to three weeks. Conflicting signals can push the process into months. That helps explain why technically correct canonical changes may not immediately be reflected in Search Console or search results after deployment.
The same principle applies to migrations on a much larger timescale. Google's internal figures put a typical site move at one to three months, while difficult migrations can require six months to a year or more to settle fully.
Core update recovery is measured in months
For changes associated with core updates, Google presented a typical recovery window of three to six months, with slower cases potentially taking six months to a year and depending on a subsequent core update. Spam update changes were presented separately, with a typical range of one to two weeks for continuous systems and potentially months where batch refreshes are involved.
This gives SEO teams a useful reality check. A site that makes substantial quality improvements after a core update should not necessarily expect those improvements to translate into full recovery within days or even a few weeks.
Quality can turn a delay into “never”
The most consequential part of the presentation may not be the fastest numbers but the worst-case column. Google indicated that URL discovery, indexing and structured data processing can in some circumstances fail to complete at all, with quality explicitly appearing as a reason.
That changes how indexing problems should be diagnosed. If Google can crawl a page but repeatedly chooses not to complete indexing, purely technical interventions may not solve the problem. The page may need stronger originality, usefulness, differentiation or overall quality rather than another submission request.
SEO timelines are a chain, not a stopwatch
The presentation makes clear why there is no universal answer to “how long does Google take?” A new page must first be discovered, then crawled, rendered and processed before end-to-end indexing can complete. A site migration introduces additional canonicalisation and signal-transfer work. Recovery from a quality update operates on an even longer cycle.
Because those systems depend on one another, a delay at the beginning propagates downstream. A 90-minute indexing process is irrelevant if Google does not discover the URL for 20 hours—or if quality signals ultimately prevent the page from being indexed at all.
Better benchmarks for technical SEO teams
These internal ranges provide useful escalation thresholds. A newly published URL not discovered after a few hours is not automatically a problem when Google's typical figure is around 20 hours. A canonical change that has not settled after several days may still be inside the normal one-to-three-week range. And a migration should be judged on a multi-month timeline rather than expected to stabilize immediately.
The numbers also reinforce a broader theme from the Barcelona event: Google's crawling, indexing, ranking and AI Search systems remain connected to the same underlying Search infrastructure. Day 1 of the event emphasized that Googlebot supports traditional Search as well as AI Overviews and AI Mode, while Day 2 went deeper into rendering, indexing, canonicalisation and structured data.
For SEOs, the practical lesson is simple: measure delays against the correct stage of Google's pipeline, allow realistic processing time, and do not assume that every indexing problem is a technical one. Google's own internal timing data now makes that distinction much easier to quantify.