Google’s Gary Illyes just gave SEO teams the numbers they’ve been guessing at for years. At Search Central Live Deep Dive Europe in Barcelona, he broke out typical and slowest timing ranges for almost every search process that matters: discovering a URL, indexing it, moving a site, updating titles, and recovering from a core update.
The figures come from a recap of the Oct. 2 session by John Campbell of ROAST, one of the event’s community speakers. Each process carried a fastest, typical and slowest range based on Google’s internal analysis.
The timings that matter
A brand-new URL typically takes about 20 hours to be discovered. A URL Google already knows takes about 30 days to refresh. End-to-end indexing — the point where ‘all the critical processes finish successfully’ — is where delays really stack up, according to the recap.
Title and snippet updates land in one to two days in typical cases, but can stretch to weeks or months at the slow end. A removal request submitted in Search Console takes about two hours, or 24 hours at the slowest.
Site moves and recovery: think in months
Google’s own documentation says small to medium sites usually move within a few weeks, while larger sites need more time. Campbell’s recap flags that a site move still unresolved at three months sits at the high end of the typical range.
The number every SEO should memorize is core update recovery: typically three to six months, with a slowest case of six months to a year — effectively the next core update. Google’s documentation agrees that confirming overall site improvement can take several months.
Manual action removal typically takes one to two weeks, four to six weeks at the slowest, and much longer for dormant sites. Canonical changes can leave pages in a duplicate cluster for up to two weeks after a content fix.
The fine print
Before you turn these into client deadlines, read the caveats:
- No sample size, time period, or definition of ‘typical’ was shared.
- The recap’s fastest times were left out of the tables.
- Five slowest times are listed as ‘never’ — three add ‘(quality)’ for sitemap processing, end-to-end indexing and structured data updates.
Illyes also warned that these processes are interconnected. Crawling has to happen before indexing, so an early delay pushes everything else further out.
Use slowest times as your risk line
These ranges are reference points, not promises. When a change is inside the typical window, hold the line with clients. When it passes the slow end, that’s your signal to audit technical signals — and, for core updates, to accept you may be waiting for the next one.
In practice, that means benchmarking a site move or title change against both the typical and slowest figures before you commit to a date. It also means tracking crawl status first, because that’s where the queue starts.
Source: Search Engine Journal
