"I fixed it. Why hasn't Google noticed?" It's the question most site owners ask the moment a technical fix, a content update, or a new page doesn't show results overnight, and it's really a question about google search timing. For a long time, the honest answer was a shrug: Google rarely publishes concrete numbers for how long its own systems take. That changed on October 2, 2026, when Google's Gary Illyes presented more than 20 internal timing ranges at Search Central Live Deep Dive Europe in Barcelona, covering everything from discovering a brand-new URL to recovering from a core update.
The short version: most changes land within hours to days, the slow end can run to months, and for a handful of processes, content quality decides whether a page ever makes it at all. This guide walks through what was shared, what Google's own published documentation says separately, and what realistic expectations look like once you're past the "did I break something" stage and into the "how long do I actually wait" stage.
Where These Timing Numbers Actually Come From
The figures didn't come from a Google blog post or a Search Central help page. They came from a conference session, reported afterward by John Campbell of ROAST, one of the event's community speakers, and picked up independently by both Search Engine Journal and Search Engine Roundtable. According to that recap, Illyes showed each process with a fastest, typical, and slowest time, based on Google's internal analysis, and he reportedly told Search Engine Roundtable afterward, "mind that this was an exercise to see if the audience can relate to the numbers we pulled internally and put in those slides."
That framing matters for how you use this data. Neither the recap nor Google's own event pages define what counts as "typical," and no sample size or measurement window was reported. Treat every number below as a reference point for setting expectations, not a service-level agreement you can hold Google to. Illyes also flagged a structural caveat worth keeping in mind throughout: many of these processes are linked, so a page can't be indexed before it's crawled, and it can't be served in results before it's indexed. Delays at an early stage carry forward into every stage after it.
Crawling: How Long It Takes Google to Find Your Content
Crawling is the discovery step, and it's where most "why hasn't Google seen this" questions actually start. A brand-new URL is typically found in about 20 hours, according to the recap, but a page Google already knows about is only revisited on a roughly 30-day refresh cycle. That gap surprises a lot of site owners who expect an edited page to reflect the update the same day it goes live.
| Process | Typical | Slowest |
|---|---|---|
| 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) |
| robots.txt update | ~24 hours | 25 hours |
| Crawl capacity update | 4 hours to 1–2 weeks | 1–3 weeks (in recovery) |
| Crawl demand update | ~20 hours | Weeks to months |
Crawl capacity is the most volatile row in that table. It can drop within seconds whenever Google's systems back off, which typically happens when a server starts struggling to keep up with request volume. Recovering that capacity afterward takes one to three weeks in the slowest cases the recap describes, which is a meaningful penalty for a server problem that might have lasted only a few hours.
A few practical habits follow directly from these ranges:
- Submit new and updated URLs through your sitemap. Keep it free of redirects and dead links. Google evaluates each submitted URL independently, and a sitemap helps discovery without guaranteeing that every listed page gets crawled or indexed.
- Don't expect an edit to an already-known page to register the same day. The roughly 30-day refresh cycle is the baseline to plan around.
- Keep your server fast and stable. A slow or error-prone server is exactly the condition that triggers Google to pull back, which is what drives the one-to-three-week crawl-capacity recovery window.
Indexing: How Long It Takes Google to Understand Your Content
Once a page is crawled, indexing it end to end typically takes about 1.5 hours, according to the recap. But "end to end" is a specific, demanding definition: it means every critical sub-process involved in understanding that page, including rendering and annotation, has finished successfully. Structural changes, like a new canonical signal or a full site move, operate on a completely different clock measured in weeks or months rather than hours.
| Process | Typical | Slowest |
|---|---|---|
| Rendering | Seconds to render, hours in the queue | Days to weeks |
| Meta annotations | 45–90 minutes | 1–4 days |
| Link annotations | Minutes to 1–3 weeks | Months |
| Indexing (end to end) | ~1.5 hours | Months, or never (quality) |
| Removal | 1–3 weeks | Months |
| Canonicalization change | 1–3 weeks | Months (conflicting signals) |
| Site move | 1–3 months | 6 months to 1 year+ |
| Structured data updates | Hours to 1–2 weeks | Weeks, or never (quality) |
| Images | Hours to days | Weeks to months |
| Videos | Hours to days | Weeks to months (deep analysis) |
Two fixes make the biggest difference in this stage:
- Put key content in the HTML, not behind heavy client-side rendering. Rendering can finish in seconds, but a page still waits in a queue for hours before that happens, and the slowest cases stretch to days or weeks.
- Send one clear, consistent canonical signal per page. Conflicting signals are specifically what pushes canonicalization from its one-to-three-week typical window toward the months-long slowest case in the table above.
Quality acts as a gate throughout this stage, too. Several of the slowest outcomes above end in "never" rather than a delayed date, and no amount of additional waiting fixes a quality problem once crawling and rendering have already succeeded.
Serving and Recovery: How Long Changes Take to Show Up
The serving stage covers what a searcher actually sees, and it's where recovery timelines live. Title and snippet updates are comparatively fast, typically appearing within one to two days, according to the recap. Recovering visibility after a core update sits at the opposite end, with a typical window of three to six months.
| Process | Typical | Slowest |
|---|---|---|
| Search Console removal (owner) | ~2 hours | 24 hours |
| Snippet update | 1–2 days | Several weeks to months |
| Title update | 1–2 days | Several weeks to months |
| Text result image update | 1–2 weeks | Several weeks to months |
| Manual action removal | 1–2 weeks | 4–6 weeks, or much longer for dormant sites |
| Core update change | 3–6 months to recover | 6 months to 1 year (next core update) |
| Spam update change | 1–2 weeks (continuous) | Months (batch refreshes) |
Two rows here tend to cause the most frustration, and they deserve different expectations. If you need something removed from results quickly, Search Console's owner removal tool is genuinely fast, working in about two hours on the typical end. Core update recovery is the opposite case: it's a quarter-or-longer commitment, and the recap's "slowest" outcome for that row is explicitly the next core update, which can mean waiting six months to a year for confirmation either way.
Core updates themselves roll out over two to four weeks, while spam updates typically complete in one to two days, according to the recap, which is a useful distinction when you're trying to figure out which kind of update actually touched your traffic. Plan accordingly: after a core update hit, budget a quarter or more of steady improvement work rather than looking for a single fix that reverses the drop overnight.
How Google's Own Documentation Compares
The session recap is secondhand information from a conference, so it's worth checking it against what Google has actually published. The comparison mostly holds up, with a couple of useful nuances.
Google's own site-move documentation states that for medium-sized websites, it typically takes a few weeks or more for new URLs to gradually replace old ones in search results, with larger sites taking longer still. That's consistent with the recap's one-to-three-month typical range for a full site move, and Illyes reportedly added directly that a small, well-executed site move can be done in a few weeks.
Google's core updates documentation adds a detail the recap's table doesn't fully capture: some changes can show measurable effects within a few days of a core update, even though confirming the full, sustained effect across a site can take several months. The documentation also states plainly that if you haven't seen any change after a few months, it may simply mean you're waiting for the next core update rather than that your changes failed. Both of these details are useful texture around the "3–6 months" figure, since they clarify that recovery isn't always a single switch that flips at the three-month mark.
Why Delays Compound Across Stages
The single most important caveat in the entire dataset is one line: these processes are linked. A page has to clear discovery before it can be crawled, clear crawling before it can be indexed, and clear indexing before it can appear in results. None of the typical times in the tables above describe a full, real-world journey from publish to visible; they describe one stage in isolation.
Stacked together, a brand-new page's realistic best-case timeline looks like this:
- Discovery: roughly 20 hours before Google finds the URL.
- Indexing: up to another 1.5 hours once crawling completes.
- Serving: typically another one to two days before title and snippet details settle into their final form.
Added up, that's a best case measured in roughly two to three days, not a single day, and that's before any stage lands in its slower range. The moment one does, every stage after it inherits that delay, which is why a page that seems stuck for weeks is rarely failing at just one step.
Five of the slowest-case outcomes in the full 23-row dataset Search Engine Roundtable reported end in the word "never," and three of those specifically cite quality as the reason: sitemap processing, end-to-end indexing, and structured data updates. Speed problems are usually fixable with patience. A quality problem is a different kind of blocker entirely, and no amount of additional waiting resolves it.
What This Means for AI Search Visibility
Google's AI features don't operate on a separate, parallel index. AI Overviews and AI Mode draw from pages that are already crawled, indexed, and eligible to appear in classic Search, which is why Google extended its generative AI performance report inside Search Console to all websites worldwide as of August 31, 2026. If a page can't clear the ordinary crawling and indexing timelines described above, it isn't available for Google's AI surfaces either.
That dependency raises the stakes on the "never (quality)" outcomes specifically. A page that waits a full month for its refresh cycle, or one that never gets indexed because of thin or duplicate content, isn't just missing from a traditional results page. It's a page that no classic search result, AI Overview, or AI Mode answer can cite, because none of those surfaces can draw on a page that isn't in the index to begin with.
It's also worth remembering that Google is only one surface among several a buyer relies on. Standalone AI assistants like ChatGPT, Claude, and Perplexity retrieve and synthesize differently than Google's own AI features, and consistency across them isn't guaranteed just because a page performs well in Search. BrandGhost's own research across these engines has found that two AI assistants frequently disagree on which brand to recommend first for the same prompt, a reminder that clearing Google's crawling and indexing timelines is the foundation, not the finish line. From there, it's worth checking separately where a brand stands across each AI engine a buyer consults.
A Practical Framework for Setting Realistic Expectations
Rather than treating every one of these numbers as a fixed rule, it helps to sort them into three categories and respond to each differently.
- Fast, predictable processes (robots.txt updates, Search Console removals, meta annotations): if these are taking meaningfully longer than their typical range, something is likely misconfigured, and it's worth checking directly rather than waiting it out.
- Slow-but-normal processes (page refresh cycles, canonicalization changes, structured data updates): these just take time. A known page sitting at three weeks without a refresh isn't necessarily broken; it may simply be mid-cycle.
- Quality-gated processes (indexing end to end, sitemap processing, structured data): if one of these stalls well past its typical window, more patience won't help. The more productive move is reviewing the content itself against Google's standard for being genuinely useful to readers, since that's the stated gate for several "never" outcomes in the dataset.
Matching your response to the right category saves the most common mistake teams make with timing data like this: either panicking over a delay that's completely normal, or waiting out a quality problem that patience was never going to fix.
The Bottom Line
None of this changes the fundamentals of good SEO practice, but it does put real numbers behind advice that used to be mostly intuition. New content generally gets a first look within about a day, meaningful structural changes take weeks to months, and full recovery from a core update is a quarter-or-longer process rather than a single event. The numbers come from a conference recap rather than official documentation, so treat them as planning references, not deadlines, and cross-check anything mission-critical against Google's own published guidance where it exists. Publishing and maintaining content on a steady, patient schedule remains the most reliable way to work with these timelines rather than against them, whether the destination is a classic search result or an AI-generated answer drawing from the same index.