How long Google actually takes to index a page after an Indexing API push

Search for how long Google takes to index a page and you will find a hundred confident answers and no measurements. "A few hours to a few weeks." "Usually 3–7 days." "It depends on your crawl budget." These are not findings. They are the same folklore rewritten, and none of the sites publishing them are in a position to check, because checking requires submitting URLs to Google at scale and then going back to inspect what happened to each one.

That happens to be exactly what this product does all day. So instead of repeating the folklore, we instrumented it. This post is the result, and it is deliberately as much about the method as the number — a figure you cannot audit is worth no more than the guesses it replaces.

What the checks return

How the measurement works

Nothing here is modelled or extrapolated. A batch earns a reading by surviving a fixed procedure, and batches that do not complete it are simply absent from the sample rather than estimated into it.

1. A batch of URLs is pushed through Google's Indexing API and stamped with its submission time.
2. A cron picks the batch up again at 24 hours, then 48, then 72 — three checks, no more.
3. At each check it runs up to 50 of the batch's URLs through Google's URL Inspection API, the same official endpoint Search Console uses.
4. A URL counts as indexed only on a PASS verdict from Google. Not "crawled — currently not indexed", not "discovered". PASS.
5. The first check at which at least one URL in the batch returns PASS stamps the batch's time-to-first-index, in whole hours since submission.

// app/api/cron/recheck — the only place this figure is ever written.
if (indexed > 0 && !meta.firstIndexedAt) {
  nextMeta.firstIndexedAt = nowIso;
  nextMeta.timeToFirstIndexHours =
    Math.max(0, Math.round((now - b.createdAt.getTime()) / 3_600_000));
}

One detail matters more than any other when you cite this: the reading is per batch, not per URL. It records when the first page in a submission was confirmed indexed, not when all of them were. A batch of one URL and a batch of fifty are both one data point, and the fifty-URL batch is measured by its fastest member. That makes the figure a good answer to "how quickly does a push start working" and a poor answer to "how much of my site will be indexed by Thursday" — a different question, which we measure separately.

Who is in the sample, and who is missing

The sample is self-selected, and pretending otherwise would be the easiest way to turn a study into an advert. Only batches with re-checking enabled are measured at all, which biases the set toward people who care enough to watch their submissions — and people who watch tend to submit better pages.

• Batches with re-checking switched off never produce a reading, however fast they were indexed.
• Only the first 50 URLs of a batch are inspected, so very large batches are represented by a sample of themselves.
• A batch whose pages were never indexed within 72 hours produces no reading at all — so the figures describe how fast successful indexing happened, not how often indexing succeeds. The site-wide success rate is a separate measure and we publish it separately.
• Sites already trusted by Google are over-represented, because their owners are the ones running indexing tooling in the first place.

The third point is the one most likely to be misread, so to be explicit: this is not a claim about what share of submitted pages get indexed. It is a distribution of how long it took among the ones that did.

Why we publish a checkpoint share rather than an average

An average over a 24-hour-floored measurement is close to meaningless — it mostly reports where our cron happens to run. The share confirmed at each checkpoint is the honest shape of the data, because it says precisely what was observed: at this hour, we looked, and this fraction had been indexed. It is also the only form of the statistic that stays true if we later add a checkpoint.

For the same reason there is a minimum sample below which this page prints nothing at all. A percentage a dozen batches could move is an anecdote wearing a percent sign, and the threshold is enforced in code rather than by judgement, so no one has to remember it.

What you can and cannot take from this

• You can cite it as measured evidence that an Indexing API push is typically acted on quickly, with a stated method and sample size.
• You can use it to set expectations with a client instead of quoting a range someone invented in 2019.
• You cannot read it as a guarantee. Google decides what to index; the API is the strongest crawl hint available, not an instruction, and we have never claimed otherwise.
• You cannot compare it directly to a study that measured per-URL rather than per-batch, or that counted "crawled — currently not indexed" as a success. Most do one or the other.

Methodology in full

• Source: the time-to-first-index stamp written by our re-check cron, read across a rolling 180-day window so the figure describes how the product performs now rather than an all-time average dominated by its first months.
• Checkpoints: 24, 48 and 72 hours after submission. Shares are cumulative.
• Indexed verdict: PASS from Google's URL Inspection API, nothing weaker.
• Minimum sample: enforced in code. Below it this page shows a placeholder instead of a number.
• Aggregation: counts and percentiles only. No site, URL, account or email is read into this figure, and none could be recovered from it.
• Refresh: the figure is recomputed when the site is built and stamped with the date it was measured, so a citation always points at a specific edition.

If you want to check our arithmetic, the summarising function and its tests are in the codebase rather than in a spreadsheet we would have to be trusted about — including the rule that turns a thin sample into silence.