How long Google takes to crawl, index and update results

Google’s Gary Illyes showed a set of timing tables at Search Central Live Deep Dive Europe in Barcelona on 2 October 2026. They give a typical and a slowest time for 23 processes, from discovering a new URL to recovering from a core update. We have the tables only as ROAST’s John Campbell recapped them: they are not Google documentation, and Search Engine Journal reports the slides are not on Google’s events page. This is a reference copy of those tables, the caveats that come with them, and a comparison with what Google’s own pages say.

According to the recap, each process had a fastest, a typical and a slowest time, based on Google’s internal analysis. The recap prints only the typical and slowest columns. Search Engine Roundtable’s Barry Schwartz reprinted the same rows, and we checked every row against both pages.

How long does crawling take?#

Six rows cover discovery, refresh, sitemaps, robots.txt and the two crawl settings.

Process	Typical	Slowest
Discovery (new URL)	~20 hours	Weeks to never
Refresh (known URL)	~30 days	Weeks to never
Sitemap processing	~24 hours	Up to 14 days, or never (quality)
robots.txt update	~24 hours	25 hours
Crawl capacity update	4 hours to 1-2 weeks	1-3 weeks (in recovery)
Crawl demand update	~20 hours	Weeks to months

The recap adds one line under the table: crawl capacity can drop in seconds when Google backs off, for example if your server struggles.

How long does indexing take?#

Ten rows cover rendering, annotations, indexing itself, removals, canonical changes, site moves, structured data and media.

Process	Typical	Slowest
Rendering	Seconds to render, hours in the queue	Days to weeks
Meta annotations	45-90 minutes	1-4 days
Link annotations	Minutes to 1-3 weeks	Months
Indexing (end to end)	~1.5 hours	Months or never (quality)
Removal	1-3 weeks	Months
Canonicalisation change	1-3 weeks	Months (conflicting signals)
Site move	1-3 months	6 months to 1 year+
Structured data updates	Hours to 1-2 weeks	Weeks or never (quality)
Images	Hours to days	Weeks to months
Videos	Hours to days	Weeks to months (deep analysis)

The recap defines end to end as all the critical processes finishing successfully, and adds that a small site move can be done in a few weeks.

How long does serving take?#

Seven rows cover how changes reach the results page and how long recovery takes.

Process	Typical	Slowest
Removal in Search Console (owner)	~2 hours	24 hours
Snippet update	1-2 days	Several weeks to months
Title update	1-2 days	Several weeks to months
Text result image update	1-2 weeks	Several weeks to months
Manual action removal	1-2 weeks	4-6 weeks, or much longer for dormant sites
Core update change	3-6 months to recover	6 months to 1 year (next core update)
Spam update change	1-2 weeks (continuous)	Months (batch refreshes)

Below the table, the recap says core updates take 2-4 weeks to roll out and spam updates roll out in 1-2 days. The core update row measures recovery after a change, not the length of the rollout. For what Google said about spam updates at the same event, see our report on the spam update session.

What do the tables not tell us?#

Typical is undefined. Search Engine Journal notes that neither the recap nor Google’s event pages define it, and that no sample size or measurement period is reported. We cannot tell whether typical means a median, a mode or a rough impression, or over which sites and which weeks.

The fastest times are missing. The recap says each process had one, and prints only the other two columns, as Search Engine Journal also points out.

Five slowest entries say never. Discovery and refresh say weeks to never. Sitemap processing, end-to-end indexing and structured data updates add quality in brackets. The recap reads this as Google deciding a page is not worth the work, so a fast technical fix does not help.

The processes are linked. Illyes cautioned, per the recap, that a page cannot be indexed until it has been crawled, so delays stack up. A slow stage early on shifts every later stage.

They are ranges, not deadlines. Search Engine Journal says the same of the reported ranges. Schwartz reports that Illyes told him the slides were an exercise to see if the audience can relate to the numbers pulled internally.

How do they match Google’s docs?#

Google’s pages state a few of these timings, in looser words. Where they overlap, they do not contradict the tables.

• Site moves. The site move guide says a small to medium website can take a few weeks for most pages to move, and larger sites take longer. The recap puts a typical move at 1-3 months and notes a small one can finish in a few weeks.
• Core updates. Google’s core updates page says some changes can take effect in a few days, but it could take several months for its systems to confirm a site is producing helpful, reliable content. If a few months pass with no effect, it says that could mean waiting for the next core update. The recap’s 3-6 months, and 6 months to 1 year for the next core update, fit that language and add numbers the page does not give.
• Canonical changes. The canonicalization troubleshooting guide says Google might hold pages in a duplicate cluster for up to two weeks after content fixes. The recap’s typical 1-3 weeks sits around that, and its slowest case, months with conflicting signals, goes beyond it.

The three Google pages we read give no timing for a title update or a manual action removal, so those rows have no documented counterpart here.

How should you read them?#

This section is our reading, not Google’s guidance, and it rests on tables whose basis is unknown.

• Use them to spot a stuck change, not to promise a date. A site move still unresolved at three months sits at the high end of typical, as Search Engine Journal reads it. At six months it is in the slowest range. Check the redirect map and the old URLs before blaming the clock.
• Do not re-edit a title or snippet inside the typical window. One to two days is the typical figure, so a second change after a few hours cannot yet show the first.
• Fix the crawl layer first. A broken sitemap or a robots.txt mistake delays every stage after it. Validate the file with the XML sitemap validator before you wait for the sitemap row.
• Check canonical signals when a change drags. The slowest canonical case is conflicting signals, so run your URLs through the canonical chain resolver.
• Date a recovery from the update, not from your fix. Compare your drop with the Google update checker and expect the 3-6 months the recap lists.
• Read never as a quality prompt. If a page sits unindexed far past the typical time, the recap’s reading points at the page, not the plumbing. This is a technical SEO and indexing question, but also a content one.