indexing.io

Check & monitor · Time to index

Track time to index from publish to indexed, page by page

Everyone wants faster indexing, but almost no one measures it. Without a real number for how long a page takes to go from published to indexed, you cannot tell whether a change helped, whether one section indexes faster than another, or whether your indexing is quietly getting worse.

Submit · monitor coverage · official methods only

Coverage Console
White-hat · official methods
Presets

Ready to check coverage

Paste a sitemap to sweep every URL for index status, then submit the missing ones through the official Google Indexing API and Bing IndexNow.

Not indexed Discovered, not indexed Indexed ✓

Coverage

indexed

Submitting via

Avg time to index

URLs submitted

Now eligible

Live, interactive · sample data · official methods only

Official Google Indexing API · Bing IndexNow · verified sitemaps · no spam, no PBNs

In short

Time to index is the elapsed time between a URL being published or submitted and that URL first appearing in a search engine's index. There is no published benchmark from Google, because the figure depends entirely on site authority, crawl demand and internal linking: strong news sites see minutes, a new blog often waits weeks, and some pages never index at all. The only way to know your own number is to record the publish timestamp and the first confirmed indexed timestamp for every URL, then read the distribution rather than a single anecdote.

Last updated July 2026

Indexing tracks time to index for every page across Google and Bing. It records when each URL was published or submitted and when it actually got indexed, then shows the time-to-index distribution across your site and trends over time. Submission still runs through the official Google Indexing API, IndexNow and sitemaps, all white-hat. We never claim to force indexing, because the search engines decide that, but you finally have a hard number to prove your indexing is improving and to spot where it is not.

GOOGLE API INDEXNOW SITEMAPS COVERAGE RE-CRAWL

Official methods only

White hat · no spam, no PBNs

Why it works

What your team gets with time to index

Publish to indexed

Every page is timed from the moment it is published or submitted to the moment it is actually indexed, on both engines.

Distribution and trends

See the spread of time-to-index across your site and how it moves over time, so improvements and regressions are obvious.

Prove what works

With a hard number per page, you can tell whether a sitemap change or template fix actually sped up indexing.

What it handles

Submitted, monitored and fixed, automatically

Indexing submits your URLs through the official Google Indexing API, Bing IndexNow and clean XML sitemaps, watches coverage across both engines, and flags any page that drops out with a plain-English reason so you can resubmit and get it back.

  • Records time from publish to indexed per page
  • Tracks time to index on Google and Bing
  • Shows the distribution across your whole site
  • Reveals trends so you can prove improvement
  • Pairs measurement with official submission
COVERAGE Live

Not indexed yet

/blog/seo-guide-2026 is discovered but not indexed

crawled, not indexed resubmit

thin content signal, queued for re-crawl via the Indexing API

1 Submitted to Google Indexing API OK
2 Pinged Bing via IndexNow OK
Google + Bing · one status Official · white hat

Why Indexing

One place to submit, monitor and fix coverage

Not a black-hat indexer that risks your site, not a free checker that only tells you the bad news. Indexing unifies official submission and live coverage monitoring, the white-hat way, across Google and Bing.

Submits the official way

Bulk-submit through the Google Indexing API, Bing IndexNow and clean XML sitemaps. We speed discovery and re-crawl using methods the engines support, never spam, PBNs or black-hat tricks.

Monitors coverage live

You do not refresh a search bar one URL at a time. Indexing watches which pages are in Google and Bing, catches anything that drops out, and tracks time-to-index across your whole site.

Diagnoses and resubmits

Every non-indexed page comes with a plain-English reason, then auto-resubmits through the official API so it gets another shot. Google still decides, but nothing waits in the dark.

At a glance

What typical time to index looks like, and what moves it

These are the patterns we see across monitored sites, not Google guarantees. Google publishes no target and explicitly says indexing is never promised. Treat the ranges as a way to judge whether your own numbers are normal for your situation.

Site situation Typical time to index What is actually driving it
Established news or high-authority publisher Minutes to a few hours High crawl demand. Google already fetches these sites constantly and expects new URLs.
Active site publishing weekly, good internal links 1 to 7 days Regular crawl rhythm plus a clear path from pages Google already crawls often.
New domain, few backlinks 2 weeks to 2 months, sometimes never Almost no crawl demand yet. Discovery is the bottleneck, not the content.
Large catalog or programmatic pages Highly uneven, days to never Crawl budget is spread thin. Google indexes a subset and leaves the rest at Discovered.
Page updated rather than newly published Days to weeks for the change to show Re-crawl frequency depends on how often that URL has changed meaningfully in the past.
Page with a quality, duplicate or canonical problem Never, regardless of submission Crawled and rejected. No amount of resubmitting changes a content decision.

Why an average time to index is worth more than any anecdote

Ask five SEOs how long Google takes to index and you get five numbers, all true for their own sites and useless for yours. Indexing speed is not a property of Google, it is a property of the relationship between Google and your specific domain: how much it wants your content, how reliably your server answers, and how easily a new URL can be reached from pages it already crawls daily. That is why a benchmark you read in a blog post cannot tell you whether four days is good or terrible for you.

A measured distribution can. Once you have publish and indexed timestamps for a few hundred URLs, the shape of the data answers questions no single page ever will. A tight cluster around two days with a long tail means most content flows fine and a specific template is stuck. A flat spread from one day to five weeks means crawl demand is the constraint. A large group that never indexes at all is not a speed problem, it is a quality or duplication problem wearing a speed problem's clothes, and no amount of faster submission will move it.

  • Google publishes no expected time to index and makes no guarantee.
  • Your number depends on crawl demand for your domain, not on a universal rate.
  • Distributions expose patterns. Single-page anecdotes never do.
  • Pages that never index are a separate problem from pages that index slowly.

How time to index is actually measured

The start of the clock is whichever came first: the moment the URL was published, or the moment it was submitted through the Indexing API, IndexNow or a sitemap. The end is the first check that confirms the URL is in the index. Between those two points the URL is polled on a schedule, so the recorded time is accurate to the polling interval rather than to the second, which is far more precision than any decision here requires.

The check itself matters more than the arithmetic. The site: operator is an estimate, and Google has said so repeatedly, so a tool built on it will report indexing that has not happened and miss indexing that has. Reading index status from Search Console data and the URL Inspection API, which is capped at 2,000 queries per day per property, gives an answer that comes from the index itself. Bing is tracked separately, because the two engines routinely disagree about the same URL and averaging them hides exactly the signal you want.

  • Clock starts at publish or first submission, whichever is earlier.
  • Clock stops at the first confirmed index appearance, per engine.
  • Status comes from index data, never from a site: search estimate.
  • Google and Bing are measured separately, since they disagree often.

Using the number to prove a change worked

The real payoff is that indexing work stops being a matter of opinion. You add internal links from your top pages to a slow section, split a bloated sitemap by content type, cut the render-blocking JavaScript that delayed Googlebot, or start submitting through the official API. Each is a plausible improvement, and without a baseline none of them can be proven. With one, you compare the median time to index for URLs published before and after the change and get an answer within a couple of weeks.

It also works as an early warning. Time to index degrades before coverage does: crawl rate drops first, the median stretches from three days to nine, and only later do pages start missing the index entirely. A site publishing a hundred URLs a week will feel that as a vague sense that things got slower, about a month after it started. A tracked median flags it the week it happens, while the cause is still a recent deploy you can identify rather than an archaeology project.

  • Compare medians before and after a change instead of arguing about it.
  • Segment by template or section. Site-wide averages hide the stuck part.
  • A stretching median is an early signal of crawl or server trouble.
  • Pair it with index coverage: speed and completeness fail differently.

Keep reading

Good questions

Questions about time to index

Indexing records when each URL was published or submitted and when it was first confirmed indexed, then reports the gap. You see this per page and as a distribution across your site, so you can measure and improve indexing speed rather than guess at it.
Yes. Because time to index is tracked over time, you can compare before and after a sitemap, template or submission change and see whether it helped. The numbers come from official signals, and the search engines still decide when each page is indexed.
There is no fixed answer and Google publishes no target. In practice, established sites with frequent crawling often see new pages indexed within a day, active sites with good internal linking within a week, and new domains anywhere from two weeks to never. The variable is crawl demand for your domain, which is why measuring your own number matters more than any benchmark.
Usually discovery rather than rejection. If Search Console shows Discovered, currently not indexed, Google knows the URL exists but has not spent a crawl on it, which points at weak internal linking or low crawl demand. If it shows Crawled, currently not indexed, Google fetched the page and chose not to keep it, which is a content or duplication issue that resubmitting will not fix.
Submission speeds up discovery, not the indexing decision. Pushing a URL through the official Google Indexing API, Bing IndexNow or a sitemap tells search engines the page exists sooner than they would find it themselves, which usually shortens time to index measurably. It has no effect on a page Google has already crawled and judged not worth indexing.
Good is whatever is improving relative to your own baseline. A useful working target for an active site is a median under seven days with fewer than ten percent of URLs never indexing. If your median is stable and your never-indexed share is small, indexing speed is not your bottleneck and effort is better spent elsewhere.

Explore more

More ways teams get every page indexed

Stop guessing. Get every page indexed and keep it that way.

Bulk-submit your URLs through the official Google and Bing channels, monitor coverage, and resubmit anything that drops out, automatically. White hat only, so we speed discovery without ever guaranteeing what Google chooses to index.

See pricing

Google Indexing API · Bing IndexNow · sitemaps · coverage monitoring · official methods only