How Long Does Google Take to Index a New Page? Google's Own Numbers

By Idea to Traffic Editorial Team · Published October 7, 2026 · Last updated October 7, 2026

Almost every new site owner hits the same wall: the site is live, the sitemap is submitted, and Google still shows nothing. The usual answers online range from "a few days" to "be patient for six months", which is not much help when you are deciding whether something is broken. In early October 2026 Google finally put rough numbers on it. Gary Illyes showed a set of internal timing tables on stage at Search Central Live Deep Dive in Barcelona on October 2, and the figures were reported by attendees and then by Search Engine Roundtable, Search Engine Journal and PPC Land.

The slides are not an official Google document, and Illyes described them as an exercise to see if the audience could relate to numbers pulled internally. "Typical" was not defined and no sample size was given. Treat them as Google's own ballpark, which is still far better than guessing.

The numbers that matter for a new site

Out of roughly 30 rows across crawling, indexing and serving, these are the ones that decide when a fresh page shows up. Each pair is the typical time first and the slowest time second.

Illyes also made the point that these steps stack. A page cannot be indexed before it is crawled, and it cannot be crawled before it is discovered. So for a healthy page on a healthy site, the realistic sum is about a day to discover, a short wait in the render queue, and roughly 1.5 hours to index. Call it one to three days from publishing to appearing for an exact title search.

What "never" actually means

The word "never" appears in five of the slowest-case cells, and three of them carry the label "quality". That is the most useful thing in the whole set of tables. It tells you the long tail is not a queue you can wait out. If Google decides a page or a section is not worth the resources, the page can sit in "Discovered, currently not indexed" or "Crawled, currently not indexed" indefinitely, and resubmitting it does not change the decision.

Google also said on Day 1 of the same event that crawl demand depends on site quality, how often URLs change and how popular they are, and that when Google does not yet know the quality of a URL it leans on the aggregate quality of the parent path. In plain terms: a new page inside a folder full of thin pages inherits that folder's reputation. One weak section can slow discovery for everything published under it.

So the practical rule is simple. If a page is past the typical window by a wide margin, stop thinking "slow" and start thinking "something is blocking it, or Google does not want it".

A timeline to check against

Use this as a checklist for any new page. The day counts are built from the typical figures above, with some slack added.

1. Day 0. Publish, confirm the page returns a 200 status, and make sure it is linked from at least one page Google already knows, such as your home page or a hub page. A sitemap alone is weaker than a real internal link.
2. Day 1 to 2. In Search Console, open URL Inspection, paste the URL and look at the top line. "URL is not on Google" with "Discovery: no referring sitemaps detected" means it has not been found yet. Click Test Live URL to make sure Google can fetch and render it.
3. Day 3 to 7. Search for the exact page title in quotes. If it appears, you are done. If the inspection tool says "Crawled, currently not indexed", the page was seen and declined, so look at the content, not the plumbing.
4. Day 14. This is the slowest figure for sitemap processing. Go to Indexing, then Sitemaps, and check that the status says Success and that the discovered page count matches what you expect. If it still says "Couldn't fetch" after two weeks, the problem is the sitemap URL or the server, not patience.
5. Day 30 and beyond. Anything still missing after a month is past the typical window by a factor of 20 or more. That points at a block or a quality decision, which the next section covers.

Five checks before you blame Google

Most "Google is slow" cases on new sites turn out to be a technical block that makes the wait infinite. Run these from a terminal. Replace example.com with your domain.

# 1. Status code and redirects. You want a single 200, not a chain.
curl -sI https://example.com/your-new-page | head -n 5

# 2. A noindex in the HTTP headers, which Search Console users often miss.
curl -sI https://example.com/your-new-page | grep -i x-robots-tag

# 3. A noindex in the HTML itself.
curl -s https://example.com/your-new-page | grep -io '<meta[^>]*robots[^>]*>'

# 4. robots.txt rules that block the path.
curl -s https://example.com/robots.txt

# 5. The canonical tag. It should point at this exact URL.
curl -s https://example.com/your-new-page | grep -io '<link[^>]*canonical[^>]*>'

On Cloudflare Pages, check two things that catch people often. First, preview deployments on the pages.dev subdomain send X-Robots-Tag: noindex, which is correct for previews but means you should always test the production domain. Second, a _headers file copied from another project can carry a noindex rule onto the live site. If you would rather not run these one at a time, the free site checker runs the status, robots, noindex, canonical and sitemap checks in one pass.

What does not speed it up

A few habits waste time because they target the wrong step.

• Clicking Request Indexing every day. It queues one URL for a crawl. It does not override a quality decision, and repeated requests for the same URL do not stack.
• Pinging the sitemap. Google retired the sitemap ping endpoint in 2023. Submit the sitemap once in Search Console and keep the Sitemap: line in robots.txt. After that, Google fetches it on its own schedule.
• Resubmitting an unchanged sitemap. Processing already takes about 24 hours at the typical end. Resubmitting the same file does not jump the queue.
• Publishing 200 pages on day one. Because new URLs are judged partly by the path they sit under, a burst of thin pages can drag down the whole folder. Ten strong pages that link to each other will usually get indexed faster than 200 weak ones.

For Bing, the picture is different. Bing supports IndexNow, which lets you notify it of new URLs directly. Google does not use IndexNow, so it helps Bing and other participating engines only.

Updates and recoveries take longer than first indexing

The same tables show why fixing an existing page feels slower than launching a new one. A known URL is recrawled about every 30 days at the typical end, so an edit to an old article may not register for weeks unless you request a recrawl. A canonical change takes 1 to 3 weeks typically. A small site move can be done in a few weeks, but the typical figure for a site move is 1 to 3 months. Recovery from a core update is listed at 3 to 6 months typically, and up to a year if you have to wait for the next core update. If you just made a fix and see no change after a week, that is expected, not a sign the fix failed.

Where this question came from

• Search Engine Roundtable: How long it takes Google Search for crawling, indexing and serving
• Search Engine Journal: Google shows how long crawling, indexing and recovery can take
• PPC Land: Google says new pages take about 20 hours to be found, some never are

Questions about Google indexing times