Google’s Gary Illyes showed timing ranges for common Search processes at Search Central Live Deep Dive Europe in Barcelona, from discovering a new URL to settling a site move. The ranges also cover changes made on a website, including title updates and canonical changes.
The figures come from a recap of the Oct. 2 session by John Campbell of ROAST, one of the event’s community speakers. The recap says each process had a fastest, typical, and slowest time, based on Google’s internal analysis. The slides don’t appear on Google’s Search Central events page as of publication.
Illyes warned that many of the processes are interconnected, as Campbell notes. A page must be crawled by Google before it can be indexed, so delays accumulate.
Crawling & Indexing Ranges
Campbell’s recap lists about 20 hours as the typical time for Google to discover a new URL and about 30 days to refresh one it already knows.
Typical vs. slowest timelines shared during Gary Illyes’ Search Central Live session.
CRAWLING • INDEXING • SITE MOVES
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)
Indexing (end to end)
~1.5 hours
Months, or never (quality)
Canonicalization change
1–3 weeks
Months (conflicting signals)
Site move
1–3 months
6 months to 1 year+
RESULTS • REMOVALS • RECOVERY
Title change
1–2 days
Several weeks to months
Snippet change
1–2 days
Several weeks to months
Search Console removal
~2 hours
~24 hours
Manual action removal
1–2 weeks
4–6 weeks or longer for dormant sites
Core update recovery
3–6 months
6 months to 1 year (next core update)
Reported ranges are reference points, not deadlines.
Delays in one stage can carry into the next.
The recap defines end-to-end indexing as the point when “all the critical processes finish successfully.” It also notes that a small site move can be done in a few weeks.
Google’s site-move documentation mentions that for small to medium-sized websites, most pages typically take a few weeks to move, while larger sites need more time. When it comes to canonical changes, Google’s troubleshooting guide notes that pages can remain in a duplicate cluster for up to two weeks following content fixes, a detail added by Google in July.
Search Results And Recovery
Title and snippet updates take one to two days in the typical case the attendee recap lists, and several weeks to months at the slowest. A site owner’s removal request in Search Console takes about two hours, or 24 hours at the slowest.
Manual action removal takes one to two weeks in the typical case and four to six weeks at the slowest, or much longer for dormant sites.
The core update row focuses on recovery after a change, rather than the duration of the update process itself. Typically, it takes about three to six months to recover, according to the recap, with a slowest case of six months to a year, which is indicated as the “next core update” in the table.
Google’s documentation on core updates mentions that some changes can show effects within a few days, but confirming overall site improvement might take several months. If you don’t see effects after a few months, it could mean you’re waiting for the next core update, as explained in the documentation.
What The Tables Don’t Show
Neither the attendee recap nor Google’s event pages give a sample size, time period, or definition of what counts as typical. The recap’s tables also leave out the fastest times it says each process had.
Five of the slowest times in the recap’s tables include “never.” Three of those, for sitemap processing, end-to-end indexing, and structured data updates, add “quality” in parentheses.
Why This Matters
SEO teams frequently need to inform clients whether a technical adjustment is still in progress or has become stuck within Google’s systems. The estimates reported from Illyes’ session serve as reference points for site moves, canonical changes, title updates, and recovery from core updates. A site move that remains unresolved at three months is at the high end of the typical timeframe, according to the attendee recap. In the slowest cases the recap lists, the process can take anywhere from six months to over a year.
Teams planning a site move or core update recovery can compare progress against typical and slowest times in the attendee recap, which shows ranges rather than deadlines. As Illyes warned, delays in early stages like crawling can affect later stages.
