Google Indexing Cohort Monitoring by Publication Date

Direct answer: A tutorial for building a repeatable cohort ledger that tracks a defined group of newly published URLs from submission through indexing and early performance, with fixed checkpoints, a pre-set maturity window, and a stop rule that tells you when to act or wait.

Define the cohort before you look at any report

If you publish a batch of pages and then inspect them one by one, you end up with a pile of single-URL observations and no way to tell whether the group is progressing normally or stalling.

The central question this tutorial answers is: how do I monitor whether a defined group of newly published URLs is progressing from submission to indexing and early search visibility, without misreading one state as another?

The answer is a cohort ledger. A cohort is a fixed set of URLs that share a publication date range and a page type.

The ledger records each URL’s state at fixed checkpoints, keeps six states in separate columns, and applies a maturity window and a stop rule that were written down before you looked at any report.

Three boundaries shape everything below. First, submission does not guarantee indexing; Google states this directly in its guidance on [asking Google to recrawl URLs](https://developers. google. com/search/docs/crawling-indexing/ask-google-to-recrawl).

Second, crawling and indexing timing is uncertain by design, as described in the [Google crawling and indexing FAQ](https://developers. google. com/search/help/crawling-index-faq).

Third, page-level evidence and property-level evidence answer different questions, a distinction Google makes in its [Search Console coverage guidance](https://developers. google. com/search/docs/monitor-debug/search-console-start#coverage).

By the end you will have a ledger schema, a checkpoint cadence, a maturity window, and a stop-rule table that converts a reading into one recorded action or an explicit decision to wait.

Separate the six states and their evidence sources

A cohort is only useful if its members are comparable. Two attributes create that comparability: a publication date range and a page type.

The publication date range is the window in which the URLs went live. Keep it narrow enough that the whole group faces roughly the same conditions.

If you mix pages published months apart, you cannot tell whether a slow page is slow because of its own state or because it entered the queue at a different time.

Page type keeps templates comparable. A product page, a documentation article, and a category page have different internal linking, different content volume, and different crawl incentives. Mixing them produces a cohort whose average describes nothing.

If you must monitor multiple page types, create one cohort per type and keep the ledgers separate.

Fix membership at creation. Write down the URL list and the count, then treat that list as closed. When you add a URL later, log it as a membership change with a date rather than silently merging it into the original group.

Silent drift is the most common way a cohort stops being a cohort.

Before opening any report, write one definition row:

This row is the decision input for everything that follows. Without it, later state readings are not comparable, and a comparison of incomparable things is not evidence.

Build the cohort ledger and checkpoint cadence

The most common monitoring error is collapsing states. A page that was submitted is not crawled; a page that was crawled is not indexed; a page that is indexed is not necessarily receiving impressions.

Each state has its own evidence source, and each observation belongs in exactly one column.

| State | What it means | Evidence source | |—|—|—| | Submitted | The URL was offered to Google through a submission method | Sitemap submission, per [build and submit a sitemap](https://developers.google.com/search/docs/crawling-indexing/sitemaps/build-sitemap) | | Discovered | Google has seen the URL in a submitted sitemap | Sitemap processing counts, per the [Sitemaps report](https://support.google.com/webmasters/answer/7451001?hl=en) | | Crawled | Google requested the URL from your host | Crawl-request history, per the [Crawl Stats report](https://support.google.com/webmasters/answer/9679690?hl=en) | | Indexed | The URL is eligible to appear in search results | Page-level inspection and the property index report, per [URL Inspection](https://support.google.com/webmasters/answer/9012289?hl=en) and the [Page Indexing report](https://support.google.com/webmasters/answer/7440203?hl=en) | | Impressions | The URL appeared in search results for some query | Search-performance data, per the [Search Console reports overview](https://support.google.com/webmasters/answer/9133276?hl=en) | | Ranking | The URL’s position for a specific query | Search-performance data, query by query |

Read the table as a set of non-equivalences. Submission is not indexing. Crawl is not indexing. Impressions are not indexing. Ranking is not indexing. Each row is a separate observation with a separate source, and no row can be inferred from the row above it.

One practical consequence: when you record a state, record the source you used. A ledger cell that says "indexed" without saying whether it came from page-level inspection or a property-level count cannot be audited later.

Read discovery and crawl evidence first

The ledger is a table where each row is one URL and each checkpoint adds a set of state columns. The schema below is the required artifact for this tutorial; use it as the actual structure of your ledger rather than a description of one.

Checkpoints are at fixed intervals. Choose the interval before the first reading and keep it. Fixed intervals make checkpoint-to-checkpoint comparison meaningful; irregular readings make a slow week look like a trend.

Record blanks as unknown, not as failures. A state you did not check is not evidence that the state is negative. If you skip the crawl column at checkpoint two, write "unknown" and move on.

Do not backfill it later from memory, and do not edit past checkpoints. The ledger’s value comes from being a record of what you actually observed on a given date.

Read index evidence at page and property level

Discovery and crawl are the earliest observable stages, and they are the stages where you have the least justification for drawing conclusions.

Sitemap processing shows discovered URL counts. That tells you whether Google has seen the URLs you offered. It does not tell you whether those URLs will be crawled, and it does not tell you anything about indexing.

Treat a rising discovered count as confirmation that submission worked, nothing more.

Crawl-request history shows host-level crawl activity. This is aggregate evidence about your host, not per-URL proof.

A crawl request in the report does not confirm that a specific cohort URL was fetched, and the absence of crawl activity in a given period is not proof that a URL was excluded. The [Crawl Stats report](https://support. google. com/webmasters/answer/9679690.

hl=en) describes crawl requests, host status, response codes, and file types; it is not a per-URL index check.

At this stage, write checkpoint notes that keep the three observations apart. A useful note format is: discovered count, crawl requests observed, index count. Three numbers, three sources, no inference between them.

Timing is uncertain by design. Google’s [crawling and indexing FAQ](https://developers. google. com/search/help/crawling-index-faq) describes discovery, crawling, and indexing without promising a schedule, and this tutorial does not supply one either.

If a cohort shows discovery but no crawl activity at an early checkpoint, the correct ledger entry is "discovered, crawl unknown or not observed," not "stalled."

Keep performance states out of the indexing judgment

Index evidence comes from two sources with different scopes, and using either one outside its scope produces a wrong conclusion.

Page-level inspection reports a single URL’s indexed state along with crawl details and live eligibility. It is the right tool for answering "what is the state of this specific URL."

It is the wrong tool for describing a cohort, because one URL’s result says nothing about the other rows in the ledger.

Property-level reporting aggregates indexed and non-indexed states across the property. It is the right tool for answering "how is the property distributed across index states."

It is the wrong tool for identifying which URL changed, because the aggregate does not attribute movement to a specific row.

| Question | Use page-level inspection | Use property-level reporting | |—|—|—| | Is this specific URL indexed. | Yes | No | | Did this URL’s state change since the last checkpoint. | Yes | No | | How many cohort URLs are indexed today. | Only by checking each URL | Yes, as a property count | | Which URL moved between states. | Yes | No |

The practical routine is to use page-level inspection to fill the indexed_state column for each cohort URL, and to use property-level reporting as context for whether the property as a whole is shifting.

Record both, but never let the property count stand in for a row’s state.

One more boundary: non-indexed states in the property report are report categories, not diagnoses. A category label tells you how Google classified the URL at the time of reporting; it does not tell you why, and it does not tell you what to change.

If you want a diagnosis, that is a separate investigation with its own evidence.

Set the maturity window

Impressions and ranking are downstream observations. They require prior index eligibility, and they are query-specific in a way that index state is not.

Impressions mean the URL appeared in search results for some query. That implies the URL was eligible to appear, but it does not confirm a specific index state at a specific checkpoint, and it does not tell you which query produced the impression.

Ranking position is even narrower: it is a position for one query, and a cohort does not have a single position.

Two ledger rules follow.

First, read performance columns only after index columns. If you fill impressions_state before indexed_state at a checkpoint, you will be tempted to use impressions as a proxy for indexing.

Record them in order so the dependency is visible in the ledger itself.

Second, do not treat zero impressions as proof of non-indexing. A page can be indexed and receive no impressions in a period for reasons that have nothing to do with its index state.

The correct entry is "no impressions observed," which is an observation about the period, not a conclusion about the index.

This separation also protects you from a common reporting error: describing a cohort as "not working" because early impressions are low, when the index columns show the cohort is still mid-transition.

Performance is a later observation, and it should be read later.

Apply stop rules and choose one action

A maturity window is a pre-committed observation period. You declare it before the first checkpoint, and you do not judge the cohort’s outcome until it expires.

The window length is a policy choice, not a measured constant. This tutorial does not supply a number of days, because the sources describe timing as uncertain rather than quantified. What matters is that you choose a length, write it down, and hold to it.

A window that gets extended whenever results are disappointing is not a window; it is a way of never reaching a conclusion.

Write the window as a statement with three parts: the start date, the number of checkpoints inside the window, and the review date.

For example, a cohort might be declared with a start date, four fixed checkpoints, and a review date at the end of the fourth interval. The specific values are yours; the commitment is the point.

Inside the window, the ledger records states and nothing else. No verdicts, no "this cohort failed," no mid-window recrawl requests driven by impatience. If a checkpoint shows an unexpected reading, record it and note it for the review.

The review is where interpretation happens.

Window expiry is the trigger for the stop-rule review. That is the moment the ledger stops being a record and becomes a decision input.

A stop rule is a written condition that maps a cohort reading to exactly one action. Write the rules before the review so the reading does not choose the rule.

Two rules govern the table. First, one condition maps to one action; if a cohort meets two conditions, resolve the earlier stage first, because later stages depend on it. Second, waiting is a valid outcome.

A stop rule that always produces an action is not a stop rule; it is a schedule for churn.

A recrawl request is a bounded action, not a guarantee. Google’s guidance on [asking Google to recrawl URLs](https://developers. google.

com/search/docs/crawling-indexing/ask-google-to-recrawl) states that submission does not guarantee indexing, and the same boundary applies here. Request the recrawl, log the date, and let the next checkpoint tell you what happened.

Log every action against the cohort with its date. An action recorded at the time it was taken can be evaluated later; an action reconstructed from memory cannot.

When the next cohort is created, the previous cohort’s action log is the only honest input for adjusting your window length or your stop-rule thresholds.

What the ledger gives you that single-URL checks do not

The chain is short and each link depends on the one before it. A cohort defined by publication date range and page type makes its members comparable. Six separated states, each bound to its own evidence source, make observations non-interchangeable.

A ledger with fixed checkpoints makes readings comparable across time. Reading discovery and crawl before index, and index before performance, keeps the dependency order visible. A maturity window set in advance prevents early readings from becoming verdicts.

A stop rule converts the reading at window expiry into one recorded action or an explicit decision to wait.

None of this makes indexing predictable. The sources describe crawling and indexing timing as uncertain, and no ledger changes that.

What the ledger changes is your position: instead of reacting to a single URL’s state on a single day, you are reading a defined group against a written standard, and you know in advance what you will do with the result.

Next step

Create your first cohort ledger now: fill in the definition row for one publication date range and one page type, copy the fifteen-column schema into your tracking file, and schedule the first checkpoint date.