Understanding Indexation

Beta. A client admin turns Indexation on for a site from the Indexation page (sidebar → Indexation → Turn on Indexation). It reads your sitemap and uses the site's Search Console connection, read-only.

The question it answers

Of everything your sitemap publishes, what does Google actually know about, and which direction is that moving? Indexation tracks every sitemap URL through three layers of evidence:

1. Eligible — your own page says it may be indexed (no noindex, canonical points at itself, returns 200).
2. Indexed — Google confirms the page is in the index (URL Inspection).
3. Serving — the page earned at least one impression in the serving window (Search Analytics, default 90 days).

Results roll up per template (a URL pattern such as /elections/*/*/position/*) and per surface (programmatic, editorial, core). The surface selector at the top filters every number on the page. The site path scope used by Opportunities and Collisions does not apply here: Indexation always works on the whole sitemap.

The eight states

State	Meaning
No evidence yet	In the sitemap, but Google has given no signal: no impressions, and not yet checked with the URL Inspection API.
Discovered, not crawled	Google knows the URL exists but has not crawled it.
Crawled, not indexed	Google crawled the page and chose not to index it.
Excluded	Not eligible: noindex, canonical points elsewhere, redirect, 404, or blocked by robots.txt.
Indexed, not serving	In Google's index but no impressions in the serving window.
Serving	At least one impression in the serving window.
Decaying	No impressions in the serving window, but impressions in the window before it.
Dropped	Previously indexed or serving; inspection now says it is not in the index.

Search Analytics evidence outranks inspection: a URL with impressions is serving even if its last check is old. If the nightly Search Analytics pull hasn't run for three days, the page says so and states are shown as last known, not current.

Serving rate vs index rate

• Serving rate is observed: serving URLs ÷ in-sitemap URLs. If a Search Analytics day hit Google's row cap, the count is shown as a floor (≥).
• Index rate is partly estimated on large libraries. URLs with impressions are known to be indexed; URLs with no impressions ever can only be classified by checking them with Google, which is limited to 2,000 per property per day. Those URLs are checked in random order, so the checked subset is a fair sample. The displayed rate is confirmed indexed + (sample rate × unchecked) and always carries its band and an est. · N checked badge. Until anything has been checked, only the possible range is shown — never a number. On the template page, counts that come from checks (crawled-not-indexed, indexed-not-serving, …) are shown as “found among N checked” with an estimated total for the whole template.

Templates

Templates are detected from URL shapes: segments that behave like sections (/blog/article/, /position/) stay literal; segments that behave like entity slugs (/listings/{name}, region codes) become *. The most specific matching pattern wins. Admins can rename templates, edit patterns, set surfaces, merge, and archive them in the settings dialog. Editing a pattern starts a new cohort: the trend shows a break there and earlier snapshots are never recomputed.

Snapshots and trend

A snapshot records every template's counts and rates as an immutable point. Weekly snapshots run automatically (Sunday 23:00 Pacific). Take a manual snapshot with a label to mark an event such as a launch, and pin it so it is labelled on the trend. Snapshots can be relabelled or pinned later, but their numbers never change. A snapshot taken before any Search Analytics pull records serving as not measured, never as 0. Snapshots that came from an imported baseline are marked Imported baseline. Changing the serving window also starts a new line on the trend, because it changes what “serving” means.

Next: Inspection census and sampling