Google’s Gary Illyes revealed internal benchmarks for crawling, indexing, and recovery timing during the Search Central Live Deep Dive Europe. The data includes a 20-hour typical discovery time and a 3-6 month core update recovery window, providing a baseline for identifying technical stalls. (core update recovery: the period of time a site takes to stabilize or improve following a major algorithmic change by the search engine.) If you manage client sites requiring technical fixes, these benchmarks define when a process is officially “stuck” versus in progress.
Is this for you?
If you manage client websites, these benchmarks define when a technical process is officially stuck versus still in progress based on internal Google timing.
- If you are an SEO practitioner, the 3-month high end benchmark helps determine if a site move is still in progress.
- If you are a growth engineer, the 2-week window helps verify when a duplicate cluster should clear after a canonical change.
- If you are a digital marketing leader, the 6-month to 1-year window helps set realistic expectations for core update recovery.
- Skip this if you are a beginner blogger as the data focuses on internal infrastructure rather than content writing.
- Skip this if you are a social media marketer as the data is strictly for organic search.
What you can do now
- Compare a new URL's discovery status against the 20-hour window to see if it has officially stalled.
- Check if a canonical fix has been processed by comparing your results against the 2-week window.
- Check your removal request status against the 2-hour or 24-hour limits to see if it is delayed.
Key figures
- Typical new URL discovery
- 20 hours
- Known URL refresh
- 30 days
- Title and snippet updates
- 1-2 days
- Typical core update recovery
- 3-6 months
- Slowest core update recovery
- 6 months to 1 year
Technical SEO specialists monitoring crawl latency
SEO practitioners who manage client expectations can use the 3-month “high end” benchmark for site moves to determine if a process is still in progress. Technical SEO specialists monitoring crawl latency can use the 20-hour discovery window to identify when a new URL has officially stalled. (crawl latency: the delay between a page being available and the search engine system discovering that page.) Growth engineers auditing technical health can use the 2-week canonical change window to verify when a duplicate cluster should clear. (canonical change: technical updates to the canonical tag used to tell search engines which version of a page is the primary one.) Digital marketing leaders overseeing recovery can use the 6-month to 1-year window to set realistic expectations after a core update.
Beginner bloggers who focus on content writing should skip this content, as the data focuses on internal infrastructure; general guides on Google Search Console would serve them better. Social media marketers focusing on non-search platforms should skip this as the data is strictly for organic search; platform-specific marketing guides would be more useful.
Google’s 20-hour discovery and 30-day refresh cycles
Google’s 20-hour discovery window serves as the typical timeframe for the system to find a new URL. A known URL requires a significantly longer 30-day window for a typical refresh. Google prioritizes new URL discovery significantly faster than the re-evaluation of existing URLs, as typical discovery takes 20 hours while a refresh takes 30 days.
End-to-end indexing occurs only when all critical processes finish successfully.
End-to-end indexing occurs only when all critical processes finish successfully. (End-to-end indexing: the complete process of a page being crawled and successfully added to the search engine database.) Crawling delays in early stages accumulate, meaning a page must be crawled before it can be indexed. “A page must be crawled by Google before it can be indexed, so delays accumulate,” Gary Illyes stated.
The 2-week window for canonical changes
Canonical changes—technical updates to the canonical tag—can remain in a duplicate cluster for up to 2 weeks following content fixes. This duration represents the standard window for Google to re-evaluate the relationship between URLs. Growth engineers can use this 2-week period to verify if a canonical fix has been processed or if the technical implementation requires a review.
Core update recovery: 3-6 months to 1 year
Core update recovery typically takes 3-6 months for a site to stabilize or improve. The slowest cases can take 6 months to 1 year, which indicates a wait for the next core update. Structural site migrations are resolved by Google much faster than the algorithmic stabilization following a core update, with site moves taking a few weeks and core update recovery taking 3-6 months.
The 3-6 month recovery window holds as long as the site remains in the “typical” quality bracket; however, if a site is flagged for quality issues, the “never” status for end-to-end indexing takes precedence. Guessing wrong on the 3-6 month recovery window leads to premature client churn; guessing wrong on the 20-hour discovery window leads to unnecessary support tickets.
Removal requests in 2 hours or 24 hours
Removal requests in Search Console typically take 2 hours to process. The slowest removal requests reach a 24-hour limit. Standard content removals are processed nearly instantly, while policy-based manual action removals require a much longer evaluation window, as removal requests take 2 hours and manual action removals take 1-2 weeks.
Manual action removals typically take 1-2 weeks
Manual action removals typically take 1-2 weeks, though they can take 4-6 weeks at the slowest. Dormant sites may experience even longer delays. These figures allow technical teams to distinguish between standard content requests and policy-based removals.
The “never” status for sitemaps and structured data
Sitemaps, end-to-end indexing, and structured data updates may carry a “never” status in the slowest cases. (Sitemaps: files that list the pages of a website to help search engines find and crawl content.) (structured data: a specific format for offering information about a page to help search engines understand content better.) This status is specifically tied to “quality” constraints within Google’s system. Google did not specify the sample size, the time period, or the definition of “typical” used in these internal analyses.
Callum’s 3-month site move example
Callum owns a small business website and moved his domain 3 months ago. Callum checks the 3-month “high end” benchmark for site moves to see if the move is complete. Callum determines the process is still within the expected range because the source notes that a site move at three months is the high end of the typical timeframe. If Callum had moved the domain 6 months ago, he would have identified it as a “slowest case” requiring a deeper investigation.
=”Applications for growth engineers and SEO practitioners
| Use Case | Who it serves |
|---|---|
| Setting internal SLAs for technical tickets | SEO practitioners |
| Identifying “stuck” requests in Search Console | Growth engineers |
| Predicting recovery timelines for clients | Digital marketing leaders |
| Auditing the success of a site migration | Growth engineers |
| Diagnosing persistent structured data issues | SEO practitioners |
Replacing anecdotal wait times with Google data
Anecdotal wait times are replaced by Google’s internal benchmarks, which is better because it allows for objective SLA definition rather than subjective guesswork. Google’s data provides a definitive range for when a technical change is in progress versus when it has stalled. This shift moves SEO operations from guessing to measuring against Google’s own internal analysis.
Google's crawling, indexing, and recovery timing ranges: what is known and what is not yet disclosed
- What changed, and where — which regions, languages or devices?
- The original report did not say which regions, languages or devices changed.
- Who gets it, and when?
- The original report did not say who gets it and when.
- What effect does it have on traffic or clicks, and what is the evidence?
- The original report did not say what effect it has on traffic or clicks.
- What do site owners need to change — markup, settings or content?
- The original report did not say what site owners need to change.
- Can it be measured or reported, and where?
- The original report did not say where it can be measured or reported.
- Can site owners opt out or control it?
- The original report did not say if site owners can opt out or control it.
- How long until a title update shows up?
- Title and snippet updates take one to two days in the typical case the attendee recap lists.
Original reporting: Google Shows How Long Crawling, Indexing & Recovery Can Take via @sejournal, @MattGSouthern (Search Engine Journal), on 4 October 2026.