TL;DR
- On 2 October 2026 Gary Illyes showed internal timing tables at Search Central Live Deep Dive Europe in Barcelona, per a recap by John Campbell of ROAST.
- Typical times in the recap: new URL discovery about 20 hours, end-to-end indexing about 1.5 hours, site move 1-3 months, core update recovery 3-6 months.
- The slowest cases include 'never', and the recap ties most of them to quality, not to technical queues.
- Google has not published the figures and the recap gives no methodology or sample size, so they are not guarantees.
Google analyst Gary Illyes showed internal timing data on 2 October 2026, at the close of Search Central Live Deep Dive Europe in Barcelona, and the headline figures are about 20 hours for Google to discover a new URL, about 1.5 hours for end-to-end indexing once the processes run, 1 to 3 months for a site move to settle and 3 to 6 months to recover from a core update. Those numbers come from a recap by John Campbell of the agency ROAST, relayed by PPC Land on 3 October. Google has not published them, and the recap gives no methodology or sample size, so treat them as an attendee's account of a conference slide, not as a service-level promise.
What was shown in Barcelona, and by whom
Search Central Live Deep Dive Europe ran from 30 September to 2 October 2026 in Barcelona. According to PPC Land, ROAST published one recap per day, written by John Campbell, the agency's Head of Innovation and AI: crawling on day one, indexing on day two, and serving and ranking on day three. On the third day, 2 October, Gary Illyes put up tables listing how long a set of processes take across crawling, indexing and serving. The recap calls this "brand new information" and says the times "are based on Google's internal analysis".
Two limits come with that. First, the recap says each process had a fastest, a typical and a slowest time, but the tables it reproduces carry only the typical and slowest columns, so everything below rests on those two. Second, PPC Land states that none of the recaps is a Google publication. RA searched for a Google blog post or documentation page that carries these figures and found none.
The crawling timings
In the crawling table as reproduced by PPC Land on 3 October, discovery of a new URL is listed at about 20 hours typical, with the slowest cases running from weeks to never. Refresh of a known URL is listed at about 30 days typical, with the same "weeks to never" tail. Sitemap processing is about 24 hours typical and up to 14 days at the slow end, or never where quality is the reason.
The robots.txt row is the tightest in the set: about 24 hours typical and 25 hours slowest. The table also lists crawl capacity updates at 4 hours to 1-2 weeks typical and 1-3 weeks when a site is in recovery, and crawl demand updates at about 20 hours typical and weeks to months slowest. The recap adds that crawl capacity can drop within seconds when Google backs off from a struggling server, while the way back runs from one to three weeks.
The indexing and serving timings
On the indexing side, the recap lists end-to-end indexing at about 1.5 hours typical and "months or never (quality)" at the slow end. It defines end to end narrowly: "all the critical processes finish successfully". Canonicalisation changes are 1-3 weeks typical and months at the slow end, with conflicting signals given as the reason. Site moves are 1-3 months typical and 6 months to 1 year or more at the slow end, although the recap notes that a small site move can be done in a few weeks. Removal is 1-3 weeks typical and months slowest. Structured data updates are hours to 1-2 weeks typical and weeks or never, again with quality as the reason.
In the serving table, removal through Search Console by the site owner is about 2 hours typical and 24 hours slowest. Snippet and title updates are 1-2 days typical and several weeks to months slowest. Manual action removal is 1-2 weeks typical and 4-6 weeks slowest, or much longer for dormant sites. Core update change is 3-6 months to recover typical and 6 months to 1 year slowest, where the slow case means waiting for the next core update. Spam update change is 1-2 weeks typical and months slowest.
A selection of the figures in one table
The table below collects the rows most useful for planning. Every figure is as listed in the ROAST recap of Gary Illyes' session, reported by PPC Land on 3 October 2026.
| Process | Typical | Slowest |
|---|---|---|
| Discovery of a new URL | about 20 hours | weeks to never |
| Refresh of a known URL | 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) |
| Site move | 1-3 months | 6 months to 1 year or more |
| Canonicalisation change | 1-3 weeks | months (conflicting signals) |
| Core update recovery | 3-6 months | 6 months to 1 year (next core update) |
| Manual action removal | 1-2 weeks | 4-6 weeks, much longer for dormant sites |
Why "never" is the important word
According to the recap, Illyes attached one caveat to the tables: many of the processes are linked, and a page cannot be indexed until it has been crawled, so delays stack. The recap's own commentary, placed under a separate "Why this matters" heading, observes that "never" shows up often and is usually tied to quality, and that "Fast technical fixes don't help if Google doesn't think the page is worth it." PPC Land points out that this second sentence is the recap author's reading, not a quotation from Illyes.
That distinction matters when the figures are used with clients. The "never" entries sit in the discovery, refresh, sitemap, indexing and structured data rows. In several of them the table itself names quality as the reason. A page that is still not indexed after a long wait is therefore, on this evidence, more likely to be a page Google has judged not worth the effort than a page stuck in a queue. That is an inference from the recap, not something Illyes is reported to have said in those words.
How the figures sit beside Google's earlier public statements
PPC Land set several rows against material it had already reported. The recap gives spam updates a rollout of 1-2 days, yet Google's 2026 spam updates have varied: the March update finished in 19.5 hours, June took two days, August three, and the September update that began on 24 September carries a window of up to two weeks, the longest of the year. Illyes spoke eight days into that window, and PPC Land says whether it had finished by then is not stated in the material it had.
On canonicalisation, PPC Land notes that Google updated its troubleshooting guide on 10 July 2026 to say its systems may take up to two weeks to recognise a fix in a cluster of duplicate pages. That falls inside the 1-3 weeks on the Barcelona slide. PPC Land also separates rollout length from recovery time: recent core updates took 12 to 18 days to roll out, which is a different measurement from the 3-6 months the table gives for recovery.
What the recap and PPC Land do not say
- No methodology, sample size, time period or definition of "typical" and "slowest" is given. It is not stated whether typical means a median, a mean or something else.
- The fastest column the recap mentions is not in the reproduced tables.
- Google has not published the figures, and RA found no first-party confirmation of them.
- The recap does not say these are guarantees, and a typical value is not a deadline for any individual URL.
- Nothing in the source is specific to Thailand, to any language or to any kind of site.
What this means for Thai marketers
The following is RA's analysis, not a statement from the source. The source does not mention Thailand. The ranges are still useful as a reality check for the questions Thai agencies and in-house teams are asked every week: why a new landing page is not showing yet, when a migration will settle, and whether a core update drop will reverse.
For a new page, a discovery time of about 20 hours means a page published on Monday morning is not unusual if it appears in Search Console only on Tuesday. Waiting a day or two before reporting a problem is consistent with the figures. Submitting a sitemap does not change the picture much, because sitemap processing is itself listed at about 24 hours typical.
For a migration, the 1-3 month typical range and the 6 months to a year slow case argue for setting expectations at the start of a project, and for planning reporting so that a dip in the first weeks is not read as failure. The recap also notes that a small move can be done in a few weeks, so the size of the site matters.
For a core update drop, the 3-6 month typical recovery, and the 6-12 month case when a site must wait for the next core update, mean that a quick technical fix is unlikely to be what brings traffic back. Combined with the recap's reading of "never", the practical work is a content quality review, not a crawl tweak.
What to check in your own account: compare the time between publish date and first impression in Search Console for a sample of recent URLs against the 20-hour and 1.5-hour figures. Pages that fall far outside the typical range, and that Search Console reports as discovered but not indexed, are the ones worth reviewing for quality before anyone touches the sitemap or requests indexing again.
Frequently asked questions
How long does Google take to find a new page?
About 20 hours in the typical case, according to the ROAST recap of Gary Illyes' 2 October 2026 session. The same table lists the slowest cases as weeks to never, and it is a third-party recap, not a Google publication.
Has Google published these timings?
No, RA found no Google blog post or help page carrying them. They come from John Campbell's recap of a talk at Search Central Live Deep Dive Europe, relayed by PPC Land on 3 October 2026, with no methodology or sample size given.
How long does a core update recovery take?
The recap lists 3 to 6 months as typical and 6 months to 1 year as the slowest case, where a site has to wait for the next core update. It is not a guarantee, and the recap does not say what share of sites recover at all.
Does a fast technical fix guarantee faster indexing?
No. The recap author's reading, which PPC Land attributes to the recap and not to Illyes, is that fast technical fixes do not help if Google does not think the page is worth it. The "never" outcomes in the table are mostly tied to quality.
Is this specific to Thailand or to Thai-language sites?
The source does not say. The figures are presented as general internal timings, and any use for Thai sites is RA's own interpretation.
Next step
If a migration, a recovery or a batch of unindexed pages needs a plan, the SEO service page describes how Relevant Audience approaches technical and content work, and the team can review which of the timings above apply to your site.
