How Long Does Google Take to Index a New Page?

Crawled, indexed, ranking: three states, not one process

Almost every argument about indexing speed is really a confusion between three different things, and Google's own documentation separates them in a single sentence: “Google Search works in three stages, and not all pages make it through each stage.”

Crawling is the fetch. Google “downloads text, images, and videos from pages it found on the internet with automated programs called crawlers”. Nothing about your page is in any index at this point. Something merely arrived at a data centre.

Indexing is the decision. Google “analyzes the text, images, and video files on the page, and stores the information in the Google index, which is a large database”. This is where a page can quietly fail, and where Google is most explicit that no promise exists: “Indexing isn't guaranteed; not every page that Google processes will be indexed.”

Serving is the ranking question, and a different one again. Google “returns information that's relevant to the user's query”. A page can be fully indexed and never surface for any query a human would type, which is a positioning problem rather than an indexing problem, and no amount of resubmission touches it.

The practical value of keeping these apart is that they have different remedies. Discovery problems are fixed with links and sitemaps. Crawl problems are usually server problems. Indexing refusals are content and duplication problems. Ranking problems are competitive problems. Treating all four as “Google hasn't indexed it yet” is how people spend three weeks clicking a button that does nothing.

There is a fourth state that most people never think about and that matters a great deal for placements: being indexed but not being the canonical. During indexing, Google “determines if a page is a duplicate of another page on the internet or canonical”, and it describes the process as clustering — “we first group together … the pages that we found on the internet that have similar content, and then we select the one that's most representative of the group”. For syndicated coverage, a wire release carried on forty sites, or a contributed article republished by a partner, this is the stage that decides which copy exists as far as search is concerned.

The only number Google actually publishes

Here it is, in full, from Google's page on asking it to recrawl a URL: “Crawling can take anywhere from a few days to a few weeks.”

That is the whole of the official guidance on timing, and three things about it are worth noticing.

First, it is about crawling. Indexing happens after crawling and has no published range at all, because Google does not commit to doing it.

Second, the range is wide enough to be almost useless as a planning figure — days to weeks is an order of magnitude — and that width is honest rather than evasive. Crawl scheduling depends on how often the site changes, how fast the server responds, how the URL was discovered and what Google's crawlers have capacity for at that moment.

Third, the same page closes the door on guarantees: “Requesting a crawl does not guarantee that inclusion in search results will happen instantly or even at all. Our systems prioritize the fast inclusion of high quality, useful content.” The second sentence is the one to read twice. Google is saying that speed of inclusion is itself a judgement about the content, not a queue position.

Google Search Essentials repeats the point at the level of the whole rulebook: “It's important to note that just because a page meets all of these requirements and best practices, doesn't mean that Google will crawl, index, or serve its content.”

So the defensible answer to the question in the title is: days to weeks for the fetch, no published figure for the index, and no guarantee of either. Everything more precise than that comes from measurement, and we deal with the state of the measurement evidence below.

Where a URL stops, in Google's own vocabulary

Search Console's Page Indexing report is the most useful diagnostic here because its status names are Google's own description of the failure modes. The two that matter most are easy to confuse and mean opposite things.

“Discovered — currently not indexed”: “The page was found by Google, but not crawled yet. Typically, Google wanted to crawl the URL but this was expected to overload the site; therefore Google rescheduled the crawl.” This is a capacity signal. Google found the URL, wanted it, and backed off because of your server. The fix is hosting and response time, not content.

“Crawled — currently not indexed”: “The page was crawled by Google but not indexed. It may or may not be indexed in the future; no need to resubmit this URL for crawling.” This is a judgement. Google has the page and has declined, for now, to store it. The explicit instruction not to resubmit tells you that resubmission is not the lever.

Two canonicalisation statuses account for a great deal of what people mistake for non-indexing. “Duplicate without user-selected canonical”: “This page is a duplicate of another page, although it doesn't indicate a preferred canonical page. Google has chosen the other page as the canonical for this page, and so will not serve this page in Search.” And “Alternate page with proper canonical tag”, where Google says the page “correctly points to the canonical page, which is indexed, so there is nothing you need to do”. The second is not a problem at all, and is routinely reported as one.

Then there is the self-inflicted case. On noindex, Google notes the usual reason a blocked page is still showing: “If the page is blocked by a robots.txt file or the crawler can't access the page, the crawler will never see the noindex rule, and the page can still appear in search results, for example if other pages link to it.” Blocking crawling and blocking indexing are different operations, and doing the first prevents the second from being read. The same asymmetry underlies the questions in whether blocking a crawler removes you from search.

Why a page can be crawled and never indexed

This is the case that surprises people, so it is worth being blunt: Google fetching your page is not Google wanting your page. The documentation sets out the refusal in plain terms and offers no appeal process.

From the sources above, four documented mechanisms produce a crawled-but-unindexed page. It is a duplicate, and another copy was selected as canonical for the cluster. It carries a noindex rule, in which case Google's help text says, with some humour, “If you do not want this page indexed, congratulations!” It is an alternate of a canonical that is itself indexed, which is working as designed. Or it simply was not judged worth storing, which is the residual category behind “may or may not be indexed in the future”.

Google does not publish criteria for that last one, and we are not going to invent them. What it does publish is the adjacent statement that its systems “prioritize the fast inclusion of high quality, useful content”, which implies a quality assessment operating on inclusion speed and inclusion itself. Read alongside the guidance on thin and mass-produced material — the subject of what scaled content abuse is and whether site reputation abuse applies to placements — the picture is of an index that is selective rather than exhaustive.

For anyone buying placements, two consequences follow directly. A syndicated wire release published identically on many sites is a textbook duplicate cluster, and most of those copies will be indexed as cluster members that Google “will not serve”. And a placement behind a paywall has its own access rules, which we cover in whether paywalled coverage gets indexed. Neither is an indexing delay. Both are indexing outcomes.

One more clarification on the Search Console tool itself, because it is a common source of false comfort. The URL Inspection report states that “this is not a live test — the results shown are from most recently indexed version of a page, not the live version on the web”, and that “'URL is on Google' doesn't actually guarantee that your page will appear in Search results”, since the report does not check quality guidelines, manual actions or security issues. A green tick in that panel means the page is in the index, not that it is working.

What actually speeds it up, and what does not

Sorting the documented levers from the folklore is most of the practical value here.

Documented, and worth doing

Being discoverable. Discovery is the stage you control most. Google's guidance on recrawling directs you to sitemaps for volume: “If you have large numbers of URLs, submit a sitemap. A sitemap is an important way for Google to discover URLs on your site.” But it is honest about the limits — “Submitting a sitemap is merely a hint: it doesn't guarantee that Google will download the sitemap or use the sitemap for crawling URLs on the site” — and about what it ignores: “Google ignores priority and changefreq values.” The single format limits are 50MB uncompressed or 50,000 URLs.

An accurate lastmod. Google says it “uses the lastmod value if it's consistently and verifiably (for example by comparing to the last modification of the page) accurate”, and defines the threshold as “the last significant update to the page” — main content, structured data or links, but not a changed copyright date. A CMS that stamps today's date on every page in the sitemap every night is not signalling freshness; it is teaching Google to disregard the field.

Internal and external links. Nothing in the documentation gives a timing figure for this, but discovery is link-driven by construction, and a URL linked from a page Google already crawls frequently is found sooner than an orphan. This is also the honest mechanism behind the familiar observation that coverage on a large, frequently crawled publication is indexed quickly while the same text on a new domain is not.

A server that answers quickly. “Discovered — currently not indexed” exists precisely because Google throttles itself against slow hosts. The Crawl Stats report shows “the total number of crawl requests issued for URLs on your site, whether successful or not”, the average response time for resources fetched, and host status, which reports “whether or not Google encountered availability issues when trying to crawl your site”. If host status is flagging problems, that is the work.

Requesting indexing, once. The URL Inspection tool accepts a crawl request if you are an owner or full user of the property. Then the caveats bite: “There's a quota for submitting individual URLs and requesting a recrawl multiple times for the same URL won't get it crawled any faster”, and there is “a daily limit to how many index requests you can submit”.

Not documented to work, or documented not to

Resubmitting repeatedly. Documented not to work, in two separate places, in Google's own words. This is the most common wasted effort in the whole subject.

The Indexing API. Not available for this. Google restricts it: the API “can only be used to crawl pages with either JobPosting or BroadcastEvent embedded in a VideoObject”, and it is described as being for sites “with many short-lived pages like job postings or livestream videos”. Using it for articles is outside its stated scope.

Worrying about crawl budget. Google scopes its crawl budget guidance explicitly, calling it “an advanced guide” for “large sites (1 million+ unique pages) with content that changes moderately often (once a week)” and “medium or larger sites (10,000+ unique pages) with very rapidly changing content (daily)”. It describes a crawl capacity limit, which “limits the total amount of time your server spends holding connections open for Google”, and a crawl demand that varies by crawler. Notably, nothing in that document claims crawl rate affects ranking. A company site publishing four pages a month is not budget-constrained, and pruning pages to “save crawl budget” on such a site is solving a problem it does not have.

Structured data as an indexing accelerant. Markup governs how a page can be presented once indexed, not whether it is indexed. We looked at the adjacent claim in whether schema markup affects citation.

IndexNow, for Google. IndexNow is a real protocol with real participants, and it is not Google's. It accepts single URLs by HTTP GET or batches of up to 10,000 by POST, requires a key file of 8 to 128 hexadecimal characters at your domain root, and returns 429 for “Too Many Requests (potential Spam)”. Its own documentation is careful about what a success means: “The HTTP 200 response code only indicates that the search engine has received your URL.” Worth implementing for the engines that support it; not an answer to a question about Google.

Beyond Google: the corpora that are not search engines

If the reason you care about indexing speed is that you want an assistant to be able to cite a page, Google's index is one route and not the only one.

Google's own AI features documentation ties the two together for its products: a page “must be indexed and eligible to be shown in Google Search with a snippet, fulfilling the Search technical requirements” to be shown as a supporting link in AI Overviews or AI Mode, and there are “no additional requirements … nor other special optimizations necessary”. For Google, indexing latency is AI-citation latency.

Common Crawl works on a different clock, and unusually for this subject it publishes exact figures. Its September 2026 archive, CC-MAIN-2026-39, was released on 19 September 2026, contains 2.17 billion pages, or 361.4 TiB of uncompressed content, and was crawled between 4 and 17 September. Of those, 587.2 million URLs were “new URLs, not visited in any of our prior crawls” — about 27% of the archive. So a page published in early September that was linked and reachable could be in a public corpus within a fortnight of publication; a page published on 18 September waits for the next release. That is a discrete monthly window rather than a continuous process, and it is the closest thing to a hard, published number anywhere in this guide. What that corpus is and is not used for is the subject of what Common Crawl is.

The timing of assistant citation specifically — as distinct from indexing — is covered in how fast coverage reaches AI answers, and the difference between ranking and being cited in ranking in Google versus being cited by AI.

A note on pages that were indexed and then were not

A separate question gets filed under the same heading: a page that was indexed and has stopped appearing. The diagnostics differ.

If the URL Inspection tool still reports the URL as on Google, the page is indexed and the change is in serving, not indexing. Broad ranking movements have their own machinery, described in what happens in a Google core update, where Google's documented position is that there is nothing specific to fix. If the tool reports the URL as not on Google, and the page has not changed, check the canonical first: a duplicate cluster can be re-evaluated and a different copy selected. And if the page has genuinely gone from a publisher's site, that is the subject of how long a placement stays findable rather than an indexing question at all.

The one thing worth doing in all three cases is establishing which state the page is actually in before changing anything, because the four states have four unrelated remedies and guessing wastes weeks.

Methodology and limitations

Every figure and quotation above comes from primary platform documentation read on 26 September 2026: Google Search Central's in-depth guide to how Google Search works, its Search Essentials overview, its page on asking Google to recrawl URLs, its crawl budget guide, its sitemap building guide, its block-indexing guide, its AI features guidance and its Indexing API quickstart; Google Search Console Help's Page Indexing report, URL Inspection tool and Crawl Stats report pages; the IndexNow protocol documentation; and Common Crawl's release notes for CC-MAIN-2026-39. Four limitations matter. First, and most importantly for the title question, we could not open an independent measurement of indexing latency with a stated and reproducible method. Studies of indexing speed are published periodically by SEO tool vendors, whose commercial interest is in demonstrating a problem their product addresses, and we were unable to retrieve one at a working URL during this research; rather than cite a figure at second hand, we have left the quantitative answer where Google leaves it, at “a few days to a few weeks” for crawling and unspecified for indexing. Readers who see a confident median quoted somewhere should ask who measured it, over what sample of sites and when. Second, this guide is about Google. Bing, Brave, Mojeek and the various assistant-specific crawlers each schedule differently, and we could not retrieve Bing's webmaster guidelines at a working URL to quote its position. Third, Google's documentation changes without notice and these quotations are dated accordingly; the substance has been stable for years, but the wording is not a contract. Fourth, nothing here should be read as a distribution: Google publishes no data on what share of new URLs stop at each stage, so the sequence charts above are ordered, not weighted, and are labelled as such.

Conclusion

The question has an answer and it is less satisfying than the question deserves. Google's published range for crawling is a few days to a few weeks. For indexing it publishes no range, because it declines to promise indexing at all — twice, in two different documents, in unambiguous language. The useful move is therefore to stop asking how long and start asking which state the page is in, because Search Console names the states and each one has a different remedy: discovery is fixed with links and sitemaps, crawl rescheduling with a faster server, duplication with canonicals and distinct content, and refusal with better content or a different page. Requesting indexing repeatedly is documented not to help. The Indexing API is documented not to apply. Crawl budget, on Google's own definition, is not most sites' problem. And if the real goal is to be citable by an assistant rather than to rank, Google states one condition for its own AI features — indexed and snippet-eligible — which makes indexing the whole game there, and Common Crawl's monthly releases give the one hard published number in the subject: 2.17 billion pages, 587.2 million of them never seen before, in a corpus crawled across a fortnight in early September 2026.

Frequently Asked Questions

Sources

1. documentation Google Search Central, In-depth guide to how Google Search works. The three stages; “not all pages make it through each stage”; “indexing isn't guaranteed”; canonicalisation and clustering. Read 26 September 2026.
2. documentation Google Search Central, Ask Google to recrawl your URLs. “Crawling can take anywhere from a few days to a few weeks”; the submission quota; the statement that inclusion is not guaranteed “instantly or even at all”. Read 26 September 2026.
3. documentation Google Search Central, Google Search Essentials. “Just because a page meets all of these requirements and best practices, doesn't mean that Google will crawl, index, or serve its content.” Read 26 September 2026.
4. documentation Google Search Console Help, Page Indexing report. Verbatim status definitions for “Discovered — currently not indexed”, “Crawled — currently not indexed”, the two canonical statuses and the noindex status. Read 26 September 2026.
5. documentation Google Search Console Help, URL Inspection tool. Indexed version versus live test; “'URL is on Google' doesn't actually guarantee that your page will appear in Search results”; daily index-request limit. Read 26 September 2026.
6. documentation Google Search Central, Large site owner's guide to managing your crawl budget. Site-size thresholds; crawl capacity limit and crawl demand. Read 26 September 2026.
7. documentation Google Search Central, Build and submit a sitemap. “Merely a hint”; 50MB / 50,000 URL limits; lastmod conditions; priority and changefreq ignored. Read 26 September 2026.
8. documentation Google Search Central, Block search indexing with noindex. Why a robots.txt block prevents the noindex rule from being seen. Read 26 September 2026.
9. documentation Google Search Central, Indexing API quickstart. Restriction to JobPosting and BroadcastEvent in a VideoObject. Read 26 September 2026.
10. documentation Google Search Console Help, Crawl Stats report. Crawl requests, average response time and host status definitions. Read 26 September 2026.
11. documentation Google Search Central, Top ways to ensure your content performs well in Google's AI experiences. AI Overviews and AI Mode eligibility condition. Read 26 September 2026.
12. protocol IndexNow documentation. Single and batch submission, key file requirements, 429 rate limiting, and the statement that a 200 response “only indicates that the search engine has received your URL”. Read 26 September 2026.
13. operator Common Crawl, September 2026 crawl archive now available (CC-MAIN-2026-39), released 19 September 2026. 2.17 billion pages, 361.4 TiB uncompressed, crawled 4–17 September 2026, 587.2 million previously unseen URLs.