If you have ever published a new page and then checked Google Search Console every hour, only to see “Discovered, currently not indexed,” you are definitely not alone. For years, website owners and SEO professionals have had little concrete information about how long Google actually takes to crawl, index, and serve new content.
That changed on October 2, 2026, when Google finally shared specific figures for Google Indexing time. During Search Central Live Deep Dive Europe in Barcelona, Google’s Gary Illyes provided real numbers for different stages of the search process, including typical and longest expected timeframes for crawling, indexing, and serving content.
For an industry that has spent years trying to estimate why a page has not appeared in Google yet, these figures provide one of the clearest answers Google has publicly offered.
In this guide, we’ll break down the Google Indexing time figures Illyes shared, explain what each timeframe means in practical terms, and look at how these insights can influence your content publishing strategy, website migrations, and recovery plans when pages are slow to appear in search results.
What Illyes Actually Shared, and Why It Matters
Illyes framed the data as, in his own words, “an exercise to see if the audience can relate to the numbers.” That framing matters, because it tells you what this is not: it is not a documented service-level agreement, it does not come with a published methodology or sample size, and Google has not turned it into an official blog post you can bookmark and cite forever. It is a conference talk from one of Google’s most visible search engineers, breaking crawling, indexing, and serving into their component steps, each with a typical duration and a worst-case duration.
That is still genuinely useful. Most of what the SEO industry knows about Google’s internal timing comes from forum answers, inference, and trial and error. Having Google itself say “here is roughly how long each stage takes, and here is how bad it can get” gives you something concrete to plan against, instead of a guess dressed up as a best practice.
Crawling: How Fast Does Googlebot Actually Show Up?
Crawling is the part everyone obsesses over, and the numbers explain why it feels inconsistent. A brand-new URL that Google has never seen before gets discovered in about 20 hours in the typical case. In the slowest cases, that stretches to weeks, or never happens at all. The gap between those two outcomes is almost always about signals: a new page sitting on a site Google already trusts and crawls often will tend toward the fast end, while a new page with no internal links pointing to it and no sitemap entry can sit in limbo indefinitely.
Refreshing a URL Google already knows about is a different story: about 30 days typical. That number alone explains a lot of frustration. If you update an old blog post and expect Google to notice within a day, the honest answer is that a month is the normal baseline, not the exception. If you need a faster refresh, requesting indexing manually through Search Console or strengthening internal links to that page are the two levers that actually move the needle.
Sitemap processing runs about 24 hours typically, with up to 14 days or never for sitemaps Google considers low quality. robots.txt updates were the standout number in the whole presentation: about 24 hours typical, and only 25 hours in the slowest case. That is a remarkably tight, reliable window, which means if you are managing crawl rules during a migration or a staging-to-production switch, robots.txt is one of the few levers you can trust to take effect quickly and predictably.
Crawl capacity and crawl demand updates – the internal dials that decide how much of your site Googlebot is willing to hit and how often – move on a wider range: anywhere from four hours to one or two weeks typical, and one to three weeks at the slowest for capacity, with crawl demand updates stretching to weeks or months in edge cases. These are the settings behind the scenes that explain why a site redesign or a sudden spike in new pages does not get crawled at full speed overnight.
Indexing: Where the Real Mystery Lives
Indexing is where most of the “why isn’t this live yet” anxiety actually comes from, and the breakdown shows why: it is not one step, it is several.
Rendering – the step where Google executes JavaScript to see the final version of your page – takes seconds to hours typically, but days to weeks in the slowest cases. This is exactly why JavaScript-heavy pages have historically been harder to get indexed quickly: rendering is an extra queue your page has to pass through before Google can even read what is on it. Meta annotations, like canonical tags, process fast: 45 to 90 minutes typical, one to four days at the slowest. Link annotation processing is slower and more variable, ranging from minutes to one to three weeks typically, and months in rare cases.
Put all of that together and full, end-to-end indexing lands at about 1.5 hours in the typical case. That number alone is worth sitting with: for a healthy, well-signaled page, Google can genuinely go from crawl to fully indexed in under two hours. The slowest case, though, is months, or never. Illyes was direct about what drives that gap: “never” is usually tied to quality, not bad luck or a technical glitch.
Two specific scenarios deserve their own mention because they show up constantly in support forums. A full site move – a domain change, a replatform, a restructure of your URLs – takes one to three months typically to fully settle, and six months to over a year in the slowest cases. Canonicalization changes, where you are telling Google which version of a page is the real one, take one to three weeks typically, stretching to months when signals conflict with each other, such as a sitemap pointing one way and your internal links pointing another.
Serving: What Happens After You Are Already in the Index
Being indexed is not the end of the timeline. “Serving” covers everything that happens to a page once it is already in Google’s index, and this is where the most consequential numbers for working SEOs show up.
If you need something removed from Search fast, the Search Console removal tool is genuinely quick: about two hours typically, 24 hours at the slowest. That is the one process in this entire presentation you can rely on almost like a light switch, which is useful to know the next time you need to pull down a page with sensitive or incorrect information.
Title and snippet updates are slower and messier: one to two days typically, but several weeks to months in the slowest cases. That is the explanation for a complaint nearly every SEO has made at some point: you rewrote a title tag, and Google is still showing the old one weeks later. It is not broken. It is just on the slow end of a process that is already inconsistent by design.
The two numbers that matter most for anyone managing a site through a rough patch are core update recovery and spam update recovery. Core update recovery runs three to six months typically, and six months to a full year at the slowest – essentially, until the next core update gives Google another chance to reassess your site. Spam update recovery is faster but still not quick: one to two weeks typically, months in the worst cases. If you are reporting to a client or a boss after a core update hit your traffic, “give it three to six months” is now a number you can attribute directly to Google, not just SEO folklore.
Why “Never” Keeps Showing Up
Across almost every category in this data, the slowest-case column eventually just says “never.” Illyes was clear that this is usually tied to quality. A page can sit perpetually undiscovered, unrendered, or unindexed not because Google is broken, but because nothing about the page gives Google a reason to finish the job.
That lines up with Google’s own recent updates to its helpful content guidance, which now define “main content” explicitly and grade pages on effort, originality, talent, and accuracy. Thin, templated, or mass-produced pages are exactly the kind of content that stalls out at the “never” end of these timelines, because there is nothing about them that earns a faster pass through the queue. Illyes also pointed out that many of these processes are linked, so delays compound: slow discovery delays rendering, slow rendering delays indexing, and slow indexing delays every serving-side update that depends on it.
What to Actually Do With These Numbers
A few practical habits fall directly out of this data:
- Give new, well-linked content at least 20 to 24 hours before you worry about discovery, but do not panic until you are past a week. If a week passes with nothing, check your sitemap and internal links before assuming something is broken.
- If you are planning a domain move or a full replatform, budget one to three months minimum for Google to fully catch up, and say that out loud to stakeholders before launch, not after traffic dips.
- If a core update hit your traffic, treat three to six months as the realistic floor for recovery, not days or weeks. Setting that expectation early avoids a lot of unnecessary panic in monthly reporting.
- Use the Search Console removal tool with confidence when you need something gone fast. It is the one process here that behaves close to instantly.
- Do not expect faster reindexing to fix a quality problem. If a page is stuck at “never,” the fix is almost always about the content itself, not another resubmission.
The Honest Limits of This Data
It is worth being direct about what this is not. Google has not published this as an official blog post; there is no disclosed methodology or sample size, and nothing here is a guarantee that your specific site will behave the same way. This is Gary Illyes’s own framing from a conference stage, intended, in his words, to help the audience relate to the numbers – not a documented commitment from Google that you can hold them to.
Treat it as the most candid approximation Google has ever given in public, not as a service-level agreement. It is still more concrete than almost anything the industry has had to work with before, which is exactly why it is worth building into how you plan content, migrations, and recovery timelines going forward.
Leave a response