TS09Access and indexing

Does each exclusion have a reason and an owner?

Check that an intentional exclusion is explained and its implementation can be observed on one representative page.

Check my register

In the app: Register + HTTP reading
You provide: URL, planned method and register
Allow for: Reading and confirmation

Check my register

Understand

An exclusion. A reason to keep it.

Check that an intentional exclusion is explained and its implementation can be observed on one representative page.

According to Google

To apply noindex, Google needs to crawl the page and read the directive. The exclusion’s rationale, owner and review are TSEP tracking criteria.

Block Search indexing with noindex Source accessed on 2026-10-26

Check

What was decided. What was applied.

In TSEP Control

A comparison of your intention, register and received responses: HTTP status, noindex directives or robots.txt rule depending on the planned method. Evidence and the native result can be downloaded. An observed contradiction remains a discrepancy; missing evidence remains unverified.

Your contribution

A representative URL, its page family, the planned method, then your register: rationale, owner and review date. Confirm the scope before the page and its robots.txt are read without login.

With your own tools

Maintain a register of excluded page families with reason, owner and review date. For a representative URL, record the HTTP status, noindex or robots.txt rule matching the chosen method.

What this result covers

One representative page at capture time, and the supplied register. This proves neither the whole family, nor actual exclusion from Google, nor JavaScript rendering. Disallow prevents crawling; it does not by itself guarantee removal from the index. Your review of the scope and rationale remains personal. The application does not invent it: if missing, that point remains incomplete. Historical dossiers retain the method of their version.

Act

The same intent. From register to site.

Align the observed mechanism with the decision and complete its rationale, owner or review date.

Recheck

A review date. A decision to revisit.

Repeat the workflow with the same scope after correction. Date the new observation and retain earlier evidence.

Your reference points

To go further.

Statuses, sources and method.

Understand the statusesC · NC · NT · NA

The same legend in guides, analysis and demo. Each status depends on the control’s evidence and rules.

C · Verified: The criterion is met within the assessed scope. Keep dated evidence for the next comparison.
NC · To correct: Align the observed mechanism with the decision and complete its rationale, owner or review date.
NT · Not established: Evidence or confirmations are insufficient to conclude. Supply what is missing; this status does not establish an SEO error.
NA · Not applicable: The control does not apply to the scope under its rules, with a retained justification. Missing evidence alone does not make it non-applicable.

Sources and references1 reference

Block Search indexing with noindexdevelopers.google.com · new tab

Detailed method and rules1 rule

Control method and criteria

Method
Tie each excluded family to a rule, owner and review date.

Acceptance criteria
Every exclusion in scope has a mechanism, rationale, owner and review date.

Non-applicability
No intentional exclusions, with a policy inventory provided.

Detailed rules

TS09-A01 · Exclusion register and ownership

Protocol assessment mode : assisted, with supplied evidence and declarations. App availability is shown on the control card.

Scope
Explicitly selected TS09 items; url-policy-v1 profile defined in docs/url-policy-evidence.md.

Evidence
Prior plan, original bytes and SHA-256, dates/context, atomic observations, reasoned human review bound to the entire dossier. Kinds: configuration, intent.

Method
Read the native exclusion-register-v1 JSON register; compare each selected family with its prior mechanism, then require owner, rationale and review date. Require an evidence-bound review. The url-exclusion-observed-v2 profile requires a register, one representative HTTP response and robots.txt per family, followed by a review explicitly bound to the displayed evidence. A native contradiction remains NC without a review; a match without review remains NT. This sample does not establish the entire family, Google index state or confidentiality.

Acceptance criteria
Mechanisms agree and every family has governance information; supplied review supports the scope. A mechanism mismatch fails.

When the result remains inconclusive
Missing or ambiguous fields, missing register or unbound review are inconclusive. Review date is a declared calendar date, not evidence that review occurred.

Non-applicability
No atomic exemption in this profile. Empty population or absent evidence: NT, never automatic NA.

Assumptions
Supplied population and provenance; review assumes scope sufficiency and business judgment. Content, imported verdicts or hashes never prove authenticity.

Limitations
Bounded offline reading, without collection, browser execution, generated human judgment or real audit. Reviewed source scope only; no site completeness, indexing, ranking or causality inferred.

Rule version 0.3.0-draft.8 · Public protocol reference · Versioned source

Put it into practice

← Back to controls