Google Shows How Long Crawling, Indexing & Recovery Can Take

For years, one of the most frustrating parts of SEO has been the silence around timing. A new page goes live, and nobody can say with any confidence whether Google will discover it in hours or weeks. A core update hits, and the recovery conversation is pure guesswork. Clients ask “how long will this take?” and most SEOs have learned to answer with a shrug dressed up as professionalism: “it depends.”

That changed, at least partially, on October 2, 2026, when Google’s Gary Illyes shared real timing ranges for the most common search processes at the Search Central Live Deep Dive event in Barcelona. The data comes from an attendee recap by John Campbell of ROAST, since Google hasn’t published the official slides yet — but the numbers themselves are specific enough to actually be useful.

Here’s every range Illyes shared, broken down by stage, along with what each one means for how you plan, report, and set expectations.

Crawling And Indexing: From Discovery To Full Visibility

Key facts:

• New URL discovery: typically around 20 hours, but can take anywhere from weeks to never happening at all in the slowest cases.
• Refresh of already-known URLs: typically around 30 days, with the slowest cases also stretching to weeks or never.
• Sitemap processing: typically around 24 hours, but can take up to 14 days, or never complete, if Google flags quality issues.
• End-to-end indexing (crawl to index): typically around 1.5 hours, but can take months or never happen at all, depending on content quality signals.

Why This Matters

This is the first time many SEOs have seen Google put an actual number on “how long should indexing take.” The headline figure — 1.5 hours for end-to-end indexing in typical cases — is genuinely fast, and it confirms something many practitioners suspected: when indexing drags on for weeks, quality signals are usually the real bottleneck, not some arbitrary queue delay. If a client’s new page still isn’t indexed after a month, the conversation shouldn’t default to “Google is slow.” It should shift toward reviewing the page itself — thin content, duplicate signals, weak internal linking, or anything else that would make Google hesitate to treat it as worth indexing quickly.

The sitemap processing number is also worth flagging to anyone who treats sitemap submission as a formality. A typical 24-hour turnaround is fast, but the 14-day-or-never range for sites with quality issues is a real warning: a sitemap full of low-value or problematic URLs can actively slow down how Google treats the rest of your submissions.

Technical Changes: Canonicalization And Site Moves

Key facts:

• Canonicalization changes: typically 1 to 3 weeks, but can stretch to months when Google receives conflicting signals about which version of a page is canonical.
• Site moves: typically 1 to 3 months, with the slowest cases taking anywhere from 6 months to over a year. Smaller sites, however, can sometimes complete a move in just a few weeks.

Why This Matters

Anyone who has managed a domain migration knows this timeline intuitively, but having Google confirm it changes the conversation with stakeholders. A 1-to-3-month typical window for a site move means that panicking over a traffic dip in week two is premature — but it also means that if you’re still seeing major instability after three or four months, something in the migration likely needs auditing rather than just more patience.

The canonicalization number deserves particular attention from technical SEOs. “Months when signals conflict” is a direct warning about what happens when canonical tags, redirects, internal links, and sitemaps all point to slightly different versions of the truth. Cleaning up conflicting signals isn’t just good practice — based on this data, it’s the difference between a multi-week fix and a multi-month one.

Search Results: Title And Snippet Updates

Key facts:

• Title updates: typically 1 to 2 days to reflect in search results, but can take several weeks to months in slower cases.
• Snippet changes: also typically 1 to 2 days, with the same several-weeks-to-months range for slower cases.

Why This Matters

This is one of the more immediately useful ranges for day-to-day SEO work. If you’ve rewritten a title tag to improve click-through rate and it still hasn’t updated in search results after a week, that’s a reasonable point to start investigating rather than just waiting longer. On the other hand, this range also gives you language to set expectations with clients or stakeholders who want to see a title change reflected in search results the same day they ask for it — a 1-to-2-day typical window is fast by web standards, but it’s not instant, and “several weeks to months” in edge cases is a legitimate possibility worth mentioning upfront.

Removals: Search Console Requests And Manual Actions

Key facts:

• Search Console removal requests: typically around 2 hours, with the slowest cases taking up to roughly 24 hours.
• Manual action removal: typically 1 to 2 weeks after a successful reconsideration request, but can stretch to 4 to 6 or more weeks for sites that have been inactive.

Why This Matters

The removal request numbers are genuinely reassuring — a 2-hour typical turnaround for Search Console removal requests means this remains one of the fastest, most reliable levers SEOs have for emergency situations, like a page that was accidentally indexed with sensitive content.

The manual action timeline is more nuanced. A 1-to-2-week typical recovery window after a successful reconsideration request is useful to know, but the 4-to-6-week-plus range for inactive sites is an important caveat. If a site has been dormant and then gets hit with a manual action, or is trying to recover from one, the process of re-establishing enough activity and trust signals appears to meaningfully slow down how quickly Google processes the recovery.

Core Update Recovery: The Timeline Everyone Actually Wants

Key facts:

• Core update recovery: typically 3 to 6 months, but in the slowest cases can take anywhere from 6 months until the next core update rolls out — effectively an indefinite wait tied to Google’s next major algorithm refresh.

Why This Matters

This is probably the single most-requested piece of information in all of SEO, and now there’s an actual range to point to. A 3-to-6-month typical recovery window confirms what many experienced SEOs have learned through years of client work: core update recovery is not a quick fix, and anyone promising faster results is either overselling or doesn’t understand how these updates work.

The “6 months to the next core update” framing for slower cases is particularly important to internalize. It suggests that for some sites, recovery isn’t really a matter of waiting out a fixed clock — it’s tied to Google re-evaluating the site during a subsequent update cycle. That reframes the recovery conversation from “how many days until we’re back” to “what do we need to fix before the next core update gives us a chance to recover.”

The Big Picture: Delays Compound Across Stages

Perhaps the most important point Illyes made wasn’t any single number — it was the reminder that these stages are interconnected. Delays in one stage carry into the next, because a page has to be crawled before it can be indexed, and it has to be indexed before any title, snippet, or ranking change can show up in search results.

This matters because it’s easy to look at one range in isolation and think “that’s fast” or “that’s slow,” without accounting for the fact that a real-world SEO issue often involves several of these stages stacking on top of each other. A new page with weak internal linking might face a slower-than-typical discovery time, which then delays indexing, which then delays how quickly any title or snippet optimization on that page can actually show up in search results. Looked at individually, each stage might seem reasonable. Added together, the total wait can feel far longer than any single number in Illyes’ breakdown would suggest.

How To Actually Use These Numbers

Having real ranges changes how a few common SEO conversations should go:

1. Set client expectations with specifics, not vague reassurance. Instead of “it takes time,” you can now say “typical indexing is around 1.5 hours once crawled, but sitemap or quality issues can push that to months” — which is both more credible and more actionable.
2. Use the ranges as a diagnostic trigger, not just a waiting period. If a process is taking meaningfully longer than the typical range, that’s a signal to actually investigate rather than simply wait longer.
3. Separate “slow because of scale” from “slow because of quality.” The recurring theme across almost every range Illyes shared is that the slowest cases are tied to quality signals, conflicting technical signals, or site inactivity — not simply random bad luck.
4. Reset expectations around core update recovery specifically. A 3-to-6-month typical window, with some cases extending to the next core update entirely, should shape how far out any post-update action plan is scoped.

Conclusion: A Rare Moment Of Real Transparency

Google doesn’t often hand the SEO community concrete numbers like this, which is exactly why this data point from Search Central Live Deep Dive Europe is worth holding onto. It won’t settle every argument about why a specific page isn’t ranking or indexing on a specific timeline — Google itself frames these as typical ranges with wide variance on the slow end — but it gives SEOs and site owners a real benchmark to set expectations against, instead of relying purely on anecdote and guesswork.

Key Takeaways

• Typical end-to-end indexing takes about 1.5 hours, but quality issues can stretch that to months or indefinitely.
• Core update recovery typically takes 3 to 6 months, and in slower cases may not resolve until the next core update rolls out.
• Site moves typically take 1 to 3 months, though smaller sites can sometimes complete the process in just weeks.
• Search Console removal requests remain fast, typically processing in around 2 hours.
• Delays compound across stages, since crawling, indexing, and visibility changes are sequentially dependent on each other.