Google’s Gary Illyes presented typical and slowest timings for crawling, indexing, site moves and core update recovery on October 2, 2026, the closing day of the Barcelona Deep Dive edition of Search Central Live. Search Engine Journal’s Matt G. Southern reported the figures on October 4, drawing on a recap by John Campbell of ROAST, an agency. Google has not published the slides, so every number below comes from the talk as reported.
Illyes warned that the stages depend on each other. Crawling comes before indexing, so a hold-up early in the chain pushes back everything after it. According to ROAST’s recap, every process carried three timings (fastest, typical, slowest), and the underlying data is Google’s own internal study. Southern notes that the tables he saw omit the fastest column.
The ranges, as the recap lists them:
| Process | Typical | Slowest |
|---|---|---|
| New URL discovery | About 20 hours | ”Weeks to never” |
| Known URL refresh | About 30 days | ”Weeks to never” |
| Sitemap processing | About 24 hours | ”Up to 14 days, or never (quality)“ |
| Indexing, end to end | About 1.5 hours | ”Months, or never (quality)“ |
| Canonicalization change | 1 to 3 weeks | ”Months (conflicting signals)“ |
| Site move | 1 to 3 months | ”6 months to 1 year+“ |
| Title change | 1 to 2 days | ”Several weeks to months” |
| Snippet change | 1 to 2 days | ”Several weeks to months” |
| Search Console removal | About 2 hours | About 24 hours |
| Manual action removal | 1 to 2 weeks | ”4 to 6 weeks or longer for dormant sites” |
| Core update recovery | 3 to 6 months | ”6 months to 1 year (next core update)” |
Two details sharpen the table. The recap treats end-to-end indexing as complete only once “all the critical processes finish successfully.” And the core update row measures recovery, not rollout. According to ROAST’s recap, core updates themselves need two to four weeks to roll out, so the recovery clock runs separately and far longer.
Southern flags what the tables leave unstated: no sample size, no time period, and no definition of typical, in either the recap or Google’s event pages. He also counts five slowest entries containing “never.” Three carry a quality qualifier, covering sitemaps, indexing and structured data updates. ROAST’s recap reads the pattern this way: quick technical fixes will not help when Google does not think the page is worth it.
Here is how to use the ranges with clients and stakeholders. Treat the typical figure as the moment to start checking, and the slowest figure as the ceiling you describe in advance. A single promised date is the wrong format. A range tied to a named stage is accurate and defensible.
The compounding problem matters most for new URLs and migrations. Discovery, crawling, indexing and display each carry their own window, and a page stuck early cannot advance to a later stage. A stakeholder who watches a title update appear in the typical one to two days may assume everything else moves at that pace. Illyes’s warning says otherwise, and the site move row shows how wide the gap gets: one to three months typical, six months to a year or more in the worst case.
Diagnose by stage, not by outcome. Ask whether the URL was discovered, whether it was crawled, whether it was indexed, and whether its signals conflict. Southern writes that a site move still unresolved after three months sits near the top of the typical range, which is a reason to investigate rather than a verdict of failure. Where the slowest entry names quality, waiting or resubmitting will not substitute for improving the page.
For any migration or recovery plan in the coming quarter, put the typical and slowest ranges in the project brief and report progress against whichever stage is stuck. That keeps a normal delay from being read as a fault, and a quality problem from being read as a delay.
Based on Search Engine Journal’s October 4, 2026 report by Matt G. Southern, which drew on ROAST’s recap by John Campbell of Gary Illyes’s October 2, 2026 session in Barcelona.
