Google’s Crawling and Indexing Timelines: Insights for SEO Teams and Site Owners
Google Reveals How Long Crawling, Indexing, and Recovery Actually Take
Google's Gary Illyes shared internal timing ranges for crawling, indexing, site moves, and core update recovery at Search Central Live Deep Dive Europe in Barcelona on October 2, 2026 — giving SEO teams their clearest benchmark data yet.
The figures, recapped by John Campbell of ROAST, one of the event's community speakers, represent the first time Google has publicly attached typical and slowest timeframes to its core Search processes. For an industry that routinely fields client questions about why rankings haven't moved, the data lands at a critical moment.
Inside Google's Timing Data
Campbell's recap lists roughly 20 processes across crawling, indexing, search result updates, and recovery. Each process includes a typical and slowest timeframe drawn from Google's internal analysis. The slides had not appeared on Google's Search Central events page as of publication.
New URL Discovery and Refresh Cycles
For new URL discovery, the typical time is approximately 20 hours. Refreshing a URL Google already knows takes about 30 days in the typical case. Sitemap processing lands at roughly 24 hours but can stretch up to 14 days — or never — with "never" directly tied to quality signals rather than technical failure.
End-to-end indexing, defined in the recap as the point when "all the critical processes finish successfully," takes about 1.5 hours in the typical case. At the slowest end, it can take months or never happen at all, again depending on quality.
Understanding how these timelines interact with broader technical SEO fundamentals and best practices is essential for diagnosing where delays are occurring and why.
Canonical Changes and Duplicate Clusters
Canonical changes take one to three weeks typically and several months at the slowest when conflicting signals are present. Google's own troubleshooting guide notes that pages can remain in a duplicate cluster for up to two weeks following content fixes — a detail Google added to its documentation in July.
Conflicting signals are the primary driver of slowest-case canonical outcomes. If structured data, internal linking, and HTTP headers point in different directions, Google's systems have to reconcile competing inputs before acting — which extends timelines considerably.
Search Results and Recovery Timelines
Title, Snippet, and Removal Requests
Title and snippet changes are among the faster processes. The recap lists a typical time of one to two days for both, though the slowest case stretches to several weeks or months.
Search Console removal requests resolve in about two hours typically and no longer than 24 hours at the slowest. Manual action removal takes one to two weeks in most cases but extends to four to six weeks or longer for dormant sites.
Core Update Recovery
Core update recovery draws the most attention for site owners chasing ranking improvements. According to the recap, recovery typically takes three to six months. The slowest case is six months to a year, noted in the table as aligning with the "next core update."
Google's own documentation supports this framing. The company has acknowledged that some changes show effects within days but that confirming overall site improvement may take several months. If no movement appears after a few months, the documentation suggests waiting for the next core update cycle.
Illyes also flagged a key structural point that Campbell highlighted in the recap: many of these processes are linked. A page must be crawled before it can be indexed. Delays in the crawling stage carry forward into indexing, and delays there carry into when changes appear in search results. This cascading dependency is frequently overlooked when teams diagnose stalled performance.
For site owners working to increase organic search traffic to their website, understanding these compounding delays is as important as the optimisation work itself — because even well-executed changes can take months to register in rankings.
What the Data Doesn't Tell You
The Missing Variables
The recap's tables leave out the fastest times Illyes reportedly showed for each process. Neither the attendee recap nor Google's event pages provide a sample size, measurement period, or definition of what "typical" means in statistical terms.
Five of the slowest times in the recap include "never" as a possible outcome. Three of those — covering sitemap processing, end-to-end indexing, and structured data updates — add "quality" in parentheses, suggesting content quality is the deciding variable rather than a technical bottleneck. This is a meaningful distinction: teams chasing a technical fix may be solving the wrong problem entirely.
Site Move Nuance
Site move timelines carry their own nuance. The recap lists one to three months as typical and six months to over a year at the slowest. However, it also notes that a small site move can complete in a few weeks. Google's site-move documentation aligns with this, stating that small to medium-sized websites typically complete a move in a few weeks while larger sites require more time.
The reported ranges are reference points, not guarantees or deadlines.
For teams managing complex migrations or multi-domain restructuring, Google's own tools for growing and monitoring search performance remain the most direct source of crawl and indexing signal data during and after a move.
What This Means for SEO Teams and Site Owners
SEO professionals regularly face client pressure to explain whether a technical change is still processing or has stalled inside Google's systems. The Illyes data gives teams a defensible framework for those conversations.
A site move unresolved at the three-month mark sits at the upper edge of the typical range. Anything beyond six months enters slowest-case territory. For core update recovery, a site still showing no improvement at the six-month mark may simply be waiting for the next core update to register the change — not a signal that the work failed.
Here is how readers can put this information to use:
- Set client expectations early. Share these ranges at the start of a project to frame realistic timelines for site moves, canonical fixes, or recovery from a manual action.
- Use the table as a diagnostic tool. If a process has exceeded the typical range, treat it as a signal to audit for quality issues or conflicting signals rather than assuming a technical error.
- Build core update recovery into annual planning. Recovery cycles of three to six months mean that a site hit by one core update may not show improvement until the following update — a reality that requires budget and timeline adjustments well in advance.
Google's internal timing data does not change how Search works — but it does change how teams should communicate, plan, and diagnose. For the first time, there are publicly attributed numbers behind processes that previously had no formal reference point. Used correctly, these ranges shift the conversation from speculation to structured expectation-setting.
For further context on Google's crawling and indexing processes, Google's Search Central documentation provides detailed technical guidance directly from the source.
