How Long Does Google Take to Index a Page? Its Own Numbers

Search for how long Google takes to index a page and the first page of results is Reddit, a Google support thread, a Squarespace forum, Quora and a handful of agency explainers. I checked on 8 October 2026. Not one of them carries a number from Google.

Six days earlier, on 2 October 2026, Gary Illyes put those numbers on a slide. At Search Central Live Deep Dive in Barcelona he showed typical and slowest times for the processes behind crawling, indexing and serving. The recap says the times are based on Google's internal analysis.

This piece gives you the whole set, and what to do with it:

• The short answer, with the arithmetic shown.
• All three timing tables in full: crawling, indexing and serving.
• How far to trust figures Google never published itself.
• What to tell a client, a boss or yourself about new pages, canonical changes, site moves and core update recovery.
• What the tables leave out.

How long does it take Google to index a page?

Google typically takes about a day to index a new page. In the figures reported from Barcelona, discovery of a new URL typically takes about 20 hours and indexing, end to end, typically takes about 1.5 hours.

Add them and you get roughly 21.5 hours. That sum is my arithmetic on two typical rows, not something Google stated. The slowest cases are a different planet: discovery can take weeks or never happen, and indexing can take months or never happen.

• Typical, new page: about 20 hours to be discovered, then about 1.5 hours to be indexed.
• Slowest, new page: weeks to never for discovery, months or never for indexing.
• Typical, existing page: about 30 days before Google refreshes a URL it already knows.

Where these numbers come from

Be clear about what this is before you quote it in a deck. Google published no official recap of the event, and these figures are not in Google's documentation. They are slides, photographed and transcribed by people in the room. I was not one of them.

• The primary record is an attendee's. John Campbell, Head of Innovation at ROAST, wrote a recap for each day. The timing tables are in his day three recap.
• Two outlets reproduced them. Search Engine Roundtable on 5 October and PPC Land on 3 October.
• Illyes framed it as an exercise. He told Search Engine Roundtable the slides were “an exercise to see if the audience can relate to the numbers” Google had pulled internally.
• One column is missing. According to the recap, each process had a fastest, a typical and a slowest time. Nobody reproduced the fastest column, so it is not here either.

So read the tables as Google's own internal view, reported second hand. That is still far more than anyone had a fortnight ago. It is not a service level, and Google has promised nothing.

Crawling: how long Google takes to find and refetch a URL

Crawling comes first, and it is where the question of how often Google crawls a site gets its answer. A known URL is typically refreshed about every 30 days. A new one is typically discovered in about 20 hours.

Three rows deserve a second look:

• robots.txt is the tightest row in the set. About 24 hours typical, 25 hours slowest. If you unblock something today, expect Google to act on it tomorrow. A blocked file on another host is a separate trap, covered in whose robots.txt applies to third-party files.
• Sitemaps are not instant. Sitemap processing typically takes about 24 hours, and up to 14 days or never at the slow end, with quality given as the reason.
• Crawl capacity is lopsided. A capacity update typically takes 4 hours to 1 to 2 weeks, and 1 to 3 weeks in recovery. The recap adds that capacity can drop within seconds when Google backs off a struggling server.

That last one is the expensive asymmetry. Capacity falls in seconds and comes back over weeks, which is why a burst of throttling responses costs more than it looks. We cover it in what a 429 status code does to Googlebot, and the Crawl Stats report is where you see it happen.

Indexing: from fetched to in the index

Indexing is the fast stage when it works. About 1.5 hours, end to end, is the typical figure. The recap notes that “end to end” means all critical processes finish successfully.

The rows that change how you plan work:

• Rendering waits in a queue. Seconds to render, hours in the queue, and days to weeks at the slow end. JavaScript-dependent content inherits that wait.
• Canonical changes take 1 to 3 weeks. Months when signals conflict. The canonicalisation timeline post walks through what conflicting means.
• Site moves take 1 to 3 months. The slowest case is 6 months to more than a year. The slides noted a small site move can be done in a few weeks.
• Removal is slow too. Typically 1 to 3 weeks through indexing, and months at worst.

Serving: when searchers see the change

Serving is the stage people forget. A page can be crawled and indexed and still show last month's title, because what appears in results updates on its own clock.

• Titles and snippets: typically 1 to 2 days, and several weeks to months at the slow end.
• Owner removals are the fastest thing in the set: about 2 hours typical, 24 hours slowest, through Search Console.
• Core update recovery: typically 3 to 6 months. The slowest case is 6 months to 1 year, tied to the next core update.
• Rollouts are a different number. The slides put core update rollouts at 2 to 4 weeks and spam update rollouts at 1 to 2 days. A spam update change, a separate row, is 1 to 2 weeks typical.

The delays stack: two worked examples

The caveat reported alongside the slides matters more than any single row. Many of these processes are linked. A page cannot be indexed until it is crawled, so the delays stack up.

Here are two sums you can check against the tables. Both are my arithmetic on typical figures, and both assume the stages run one after another, which the slides do not spell out.

• A new page. Discovery at about 20 hours plus indexing at about 1.5 hours is about 21.5 hours. Allow another 1 to 2 days if you are waiting on the title and snippet to settle.
• A title change on an old page. Refresh at about 30 days, plus meta annotations at 45 to 90 minutes, plus a title update at 1 to 2 days, is about 31 to 32 days if nothing prompts an earlier recrawl.

The second sum explains a familiar complaint: the title was changed three weeks ago and Google still shows the old one. On these figures, that is inside typical. Nothing is broken. Google has simply not come back yet.

What “never (quality)” means

The word never appears again and again in the slowest column, and on three rows it carries a label: quality. Those rows are sitemap processing, indexing end to end, and structured data updates.

Read literally, it means the slowest case is not slow. It is a decision. Google can fetch a page, understand it, and decline to index it, and no amount of waiting changes that outcome.

Search Console shows the same split in its own vocabulary. If a page sits in “Discovered – currently not indexed” or “Crawled – currently not indexed”, the two statuses point at different stages. We unpack both in crawled versus discovered, currently not indexed.

Typical versus slowest is the real story

Reading the recaps, what stood out to me was not the typical column. It was the distance between the two columns, which on several rows is the distance between hours and never.

The gap falls into three shapes:

• Narrow gaps are mechanical. A robots.txt update runs from about 24 hours to 25 hours. An owner removal runs from about 2 hours to 24 hours. These are scheduled jobs.
• Wide gaps are judgement. Discovery runs from about 20 hours to never. Indexing runs from about 1.5 hours to never. Whether Google wants the page decides which end you get.
• Long typical times are re-evaluation. A site move at 1 to 3 months and a core update change at 3 to 6 months are slow even when everything goes right.

What this means for you

The practical use of these tables is expectation setting. Each row gives you a number to promise against and a point at which to stop waiting.

If you run an agency

• New pages: tell clients about a day is typical and that no date is guaranteed. Write a few weeks into the plan as the point where you investigate rather than wait.
• Canonical changes: quote 1 to 3 weeks. Do not report a fix as failed in week one, and do not report it as done either.
• Site moves: quote 1 to 3 months, and put the slowest case of 6 months to more than a year in the proposal. Our guide to tracking a site migration in Search Console sets the verdict at month three for the same reason.
• Core update recovery: quote 3 to 6 months. A recovery retainer reviewed after six weeks is being reviewed before the typical case could show a result.

If you work in-house

• New pages: a page published on launch morning is not typically in the index that morning. On the 21.5 hour sum, publish at least a day ahead of the campaign.
• Canonical changes: schedule the check for three weeks out. If signals conflict, the reported slowest case is months, so audit redirects, internal links and sitemaps together.
• Site moves: tell leadership before the switch that transit typically runs 1 to 3 months. That conversation is much harder to have in week five.
• Server health: protect crawl capacity. It can drop within seconds and takes 1 to 3 weeks in recovery, so a bad deploy has a long tail.

If you are a founder

• New pages: about a day is normal. Before you worry, run the URL through the free page indexability checker to confirm nothing on your side is blocking it.
• Canonical changes: if a developer fixes duplicate URLs, give it 1 to 3 weeks before judging the work.
• Site moves: a rebrand or domain change typically costs 1 to 3 months of transit. Time it away from your busiest quarter.
• Core update recovery: 3 to 6 months is typical. Plan your runway around quarters, not weeks.

What the tables do not tell you

A table of numbers invites more confidence than it has earned. Here is what these ones leave open.

• What typical means. Nobody reported whether it is a median, a mean or a common range, or how many URLs sit behind it.
• How your site compares. The figures are not broken out by site size, site type or how often a site publishes.
• The fastest case. That column existed on the slides and was not reproduced, so there is no reported floor.
• Where each clock starts. The rows are not defined precisely enough to know which ones overlap. That is why the sums above are labelled as arithmetic.
• Anything about ranking. Indexed means eligible to appear. None of these rows says how long a page takes to rank well.
• A separate track for AI answers. The recaps report the opposite: Search, AI Overviews and AI Mode rely on the same Googlebot. It is one reason llms.txt is optional.

A note on demand. “Google indexing” draws about 3,600 US searches a month, while the full question draws about 30 (DataForSEO, US, October 2026). Plenty of people want this answer. Very few have had a sourced one.

Finding your own typical and slowest

Google's typical is an aggregate. Your typical is a property of your site, and you can only see it by putting two views side by side: which URLs exist and how they are linked, and which of them Google has actually started showing.

That is the join we built CrawlRaven around. It reads Search Console and GA4 alongside a 200-point crawl, so a page that exists, is linked and still earns no impressions weeks later stands out as a slowest-column case instead of hiding in a status count. Then you know whether to wait or to work.

Sources used in this post

Google published no official recap of the event. Every Barcelona figure here is attendee-reported, read from the pages below on 8 October 2026.

• ROAST: Search Central Live Deep Dive Barcelona, day 3 recap (serving, and the timing tables)
• ROAST: Search Central Live Deep Dive Barcelona, day 1 recap (crawling)
• ROAST: Search Central Live Deep Dive Barcelona, day 2 recap (indexing)
• Search Engine Roundtable: Google crawling, indexing and serving timing data, with the Illyes quote
• PPC Land: Google says new pages take about 20 hours to be found
• Google Search Central blog: Search Central Live Deep Dive Europe 2026 announcement

Related reading on CrawlRaven

• Crawled versus discovered, currently not indexed
• How long canonicalisation changes take
• The 429 status code and Googlebot's crawl capacity
• robots.txt on third-party hosts
• llms.txt versus WebMCP
• The Search Console Crawl Stats report
• Tracking a site migration in Search Console