Google’s Gary Illyes showed timing ranges, based on Google’s internal analysis, for crawling and indexing, site moves, canonical changes, and core update recovery at Search Central Live Deep Dive Europe in Barcelona on October 2, 2026. The data, recapped by community speaker John Campbell of ROAST, runs from roughly 20 hours for new URL discovery to “never” in the slowest cases for some processes, such as structured data updates and end-to-end indexing.
What timing ranges did Google show for crawling and indexing?
Campbell’s recap of the October 2 session 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. Each process had a fastest, typical, and slowest time based on Google’s internal analysis, though the recap leaves out the fastest times. Illyes warned that many of these processes are interconnected: a page must be crawled before it can be indexed, so delays accumulate.
- New URL discovery: ~20 hours (typical)
- Known URL refresh: ~30 days (typical)
- Title and snippet updates: 1-2 days (typical); several weeks to months (slowest)
- Search Console removal request: ~2 hours (typical); up to 24 hours (slowest)
- Manual action removal: 1-2 weeks (typical); 4-6 weeks (slowest); much longer for dormant sites
- Sitemap processing: “never (quality)” listed as a possible slowest case
- Structured data updates: “never (quality)” listed as a possible slowest case
- End-to-end indexing: “never (quality)” listed as a possible slowest case
Five of the slowest-case entries in the recap include “never.” Three of those, covering sitemap processing, end-to-end indexing, and structured data updates, add “quality” in parentheses, which suggests quality problems can stop those processes from ever completing. The recap defines end-to-end indexing as the point when “all the critical processes finish successfully,” per the SEJ report.
Neither the attendee recap nor Google’s event pages provide a sample size, time period, or definition of what counts as “typical.” The slides from Illyes’ session do not appear on Google’s Search Central events page as of the SEJ article’s October 4 publication date.
How long do site moves and canonical changes take?
For a small site move, Campbell’s recap indicates the process can complete in a few weeks. A move still unresolved at three months sits at the high end of the typical timeframe, per the recap. Slowest cases run from six months to over a year. Google’s site-move documentation, cited by SEJ, notes that for small to medium-sized websites most pages typically take a few weeks to move, while larger sites need more time.
For canonical changes (where you designate which version of a page is the authoritative one for search engines), Google’s troubleshooting guide notes that pages can remain in a “duplicate cluster” for up to two weeks after content fixes. Google added this detail to its documentation in July, per the SEJ report.
What does core update recovery typically look like?
The timing data for core updates covers recovery after a site change, not the duration of the update itself. According to Campbell’s recap, typical recovery takes three to six months. The slowest case is six months to a year, labeled “next core update” in the recap’s table.
Google’s documentation on core updates, cited by SEJ, notes that some changes can show effects within a few days, but confirming overall site improvement may take several months. If there is no effect after a few months, the documentation says the site may be waiting for the next core update.
What this means for AI-search visibility
In Hingewise’s view, the clearest takeaway is that Google’s own AI answers, such as AI Overviews, can only draw on pages Google has crawled and indexed. These ranges therefore set the pace for how quickly a change to your site can show up there.
The gap between new URL discovery (roughly 20 hours, typical) and known URL refresh (roughly 30 days, typical) has a less obvious implication for content teams targeting AI citations. When you update an existing page to add clearer definitions, fresher data, or better-structured answers, the typical refresh time means Google may not re-process it for about a month. During that window, the older version likely stays in retrieval pools (the indexed content that AI search tools draw on when composing answers). In Hingewise’s view, that makes checking AI citations a week after a rewrite too early to judge whether it worked. A brand-new page is not a shortcut either: discovery in about 20 hours is only the first step before indexing.
The “never (quality)” entries for structured data, sitemap processing, and end-to-end indexing point to a harder constraint. Quality signals likely act as a gate at the indexing level, before content ever reaches the stage where AI tools retrieve it. A page that Google’s systems flag for quality may not enter the retrieval pool at all, making it invisible to Google’s AI answers regardless of how well it is structured or how often it is updated. Addressing quality is a prerequisite for AI-search visibility, not a secondary concern.
Hingewise’s read: the three-to-six-month core update recovery window is also a realistic floor for any meaningful shift in how often Google’s AI answers cite a brand. Brands that took a traffic hit from a core update should not expect their presence in those answers to rebound faster than the underlying index recovers. Recovery is a pipeline, not a switch.
One thing to follow: Before the event, Google’s Search Central Blog said Search Central Live Deep Dive Europe 2026 would bring “brand new, mostly AI focused topics.” Whether Illyes’ timing data, and any AI-specific context around it, will be published formally beyond Campbell’s attendee recap remains unclear as of October 4.
Before setting timeline expectations with your team or clients, check:
- Has a site move been running for more than three months? If so, it sits at the upper end of Google’s typical range, per Campbell’s recap.
- Are there any unresolved manual actions? Removal typically takes 1-2 weeks, up to 4-6 weeks, and longer for dormant sites.
- Have duplicate content issues been resolved? Pages can stay in a “duplicate cluster” for up to two weeks after fixes, per Google’s troubleshooting documentation.
- For title or snippet changes, allow at least 1-2 days before expecting results; the slowest cases run several weeks to months.
- For core update recovery, the recap lists three to six months as typical, so judging whether changes worked much earlier than that is likely premature.
- Check whether quality issues could be blocking structured data or sitemap processing; both list “never (quality)” as the slowest case in the recap.
Sources: Search Engine Journal, October 4, 2026; Google Search Central Blog, September 2026.
This article was drafted with AI assistance from the sources cited above and checked against them before publishing. The "What this means for AI-search visibility" section is Hingewise's editorial analysis, built on the frameworks and positions we use in our GEO work. How we work: Editorial policy.