Gary Illyes showed Google's own timing ranges for crawling, indexing, site moves and core update recovery

A site owner waiting to see if a migration has worked, or if a page is coming back after a core update, has had to guess at normal timelines from one agency's prior work. John Campbell of ROAST published a recap on 2 October of a Google Search Central Live session in Barcelona where Gary Illyes showed Google's own internal typical and slowest times across crawling, indexing and serving. Search Engine Journal reported the same numbers on 4 October.

Illyes warned that the processes are linked, Campbell writes, so a delay in crawling carries into indexing. The sample size and measurement period behind "typical" are not stated, and the recap flags that caveat.

Crawling and indexing ranges

Campbell's recap lists discovery of a new URL at about 20 hours typical and weeks to never at the slowest. A refresh of a known URL is about 30 days typical. Sitemap processing is about 24 hours, up to 14 days or never at the slowest, and the recap flags that "never" case as a quality judgement. End-to-end indexing is about 1.5 hours typical, months or never for low-quality pages.

Canonicalisation changes take 1 to 3 weeks typically and months when signals conflict. A site move is 1 to 3 months typical and 6 months to over a year at the slowest, with small moves finishing in a few weeks. Structured data updates are hours to 1 to 2 weeks, and weeks or never when quality is in question.

Serving and recovery ranges

A removal request filed by the site owner in Search Console takes about 2 hours, up to 24. A title or snippet update is 1 to 2 days typical, several weeks to months at the slowest. A manual action removal is 1 to 2 weeks typically, 4 to 6 weeks or much longer for dormant sites.

Core update recovery is 3 to 6 months typically and 6 months to a year at the slowest, with the slowest case marked as the next core update. Core updates themselves take 2 to 4 weeks to roll out, Campbell writes. Spam updates roll out in 1 to 2 days, and recovery from a spam update is 1 to 2 weeks on a continuous spam system and months when the system refreshes in batches.

What is missing from the tables

Neither Campbell's recap nor Google's event pages give the sample size, the time period behind the figures, or a definition of what counts as typical, Search Engine Journal notes. Five of the slowest times are listed as "never", three of them with "quality" in parentheses. The recap's tables leave out the fastest times Illyes said each process had, so only typical and slowest are published.

The slides from Illyes' session do not appear on Google's Search Central events page as of Search Engine Journal's publication.

Teams working on migrations and recovery now have a Google-sourced range to compare their own numbers against. A site move still open at 3 months is at the high end of what Google calls typical, and anything beyond that falls into the slowest band, where the recap says the window stretches past a year. Core update recovery sitting at month 4 is still inside the typical window; a page that has not moved after 6 months is in the slowest band, and the recap frames that case as waiting for the next core update to resolve.

Source

• Primary source: John Campbell / ROAST, Google Search Central Live Deep Dive, Barcelona, Day 3 Recap, 2 October 2026
• Reporting: Search Engine Journal, Google Shows How Long Crawling, Indexing & Recovery Can Take, 4 October 2026