TS01Access and indexing

Does this URL return the expected page?

Spot an incorrect response or unexpected content. Know what to fix, then check the result against the same criteria.

Check a URL

In the app: HTTP reading + confirmation
You provide: Public URL and expected page
Allow for: Two readings and your confirmation

Check a URL

Understand

A 200 response. But which page?

“200 OK” can hide the wrong page. TS01 checks the HTTP response and expected content separately for a public reference URL.

Fictional exampleThe right address. The wrong content.

HTTP response200 OK

Received content

“Sign in to continue”

The photography workshop page responds. But the expected workshop is missing.

According to Google

A 2xx status lets Google process received content; it does not guarantee indexing. Error content served with 200 can be treated as a soft 404.

How HTTP status codes affect Google’s crawlers Source accessed on 2026-10-26

Check

The response received. The page expected.

In TSEP Control

The app retrieves the response, follows allowed redirects and shows the destination, HTTP status and readable text. After your confirmation, it reads the page again to compare it with the saved expectation.

Your contribution

Confirm the intended public reference use, destination and distinctive text identifying the right page. A wrong response never automatically becomes your reference.

With your own tools

In browser network tools or with a GET request, record the final destination, HTTP status and received content. Compare them with the expected page, rather than relying on 200 alone.

Evidence to retain

Intent, complete GET trace and retained body; reasoned findings for A01–A02.

What this result covers

One URL, the response received at test time and the declared expectation. This result does not cover the whole site, JavaScript rendering or actual indexing.

Act

The right content. At the right address.

Restore the expected HTTP response or content according to the reported difference.

Recheck

Same address. A fresh reading.

After correction, rerun the check from its result. Criteria remain the same; previous results, dates and evidence are retained. If your expectation changes, prepare a new check.

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: Restore the expected HTTP response or content according to the reported difference.
NT · Not established: The response is incomplete, the expectation is missing or the received format is unsupported. This is not a demonstrated SEO error: complete the expectation or repeat the reading.
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 references2 references

Detailed method and rules2 rules

Control method and criteria

Method
Send a GET request, follow redirects and record the final status code.

Acceptance criteria
Each GET reaches a final 200 response for the expected resource; retain timestamp and redirect chain.

Non-applicability
No public canonical page in the declared scope.

Detailed rules

TS01-A01 · Final GET returns 200

Protocol assessment mode : automatic. App availability is shown on the control card.

Scope
Each public page designated canonical, in the declared request context.

Evidence
Intent per URL; command and tool version; dated GET trace, URLs and statuses of every hop, final headers and truncation indicators.

Method
Perform a GET without conditional caching; record every hop and final response. Declare agent, headers, cookies/authentication, network, time and time/size/redirect bounds.

Acceptance criteria
A complete final 200 response is observed. An observed final 204, 206, 4xx or 5xx contradicts this expectation; HEAD alone or 304 without a representation is insufficient.

When the result remains inconclusive
Timeout, DNS/TLS failure, interrupted chain, reached bound, incomplete capture, HEAD only or 304 without a retained body: inconclusive, without an inferred SEO fault.

Non-applicability
No atomic exemption when the control applies.

Assumptions
Request context and bounds are declared before the test; 200 is a TSEP requirement for this population.

Limitations
Neither continuous availability nor an actual Googlebot response. An observed chain does not validate TS02.

TS01-A02 · Expected final resource

Protocol assessment mode : automatic. App availability is shown on the control card.

Scope
Each final response whose content can be compared to intent.

Evidence
HTTP trace, complete body and dated prior intent with URL, reference digest and any markers/stability policy; extraction, computed values and tool/version. Hash after transfer and content decoding, before any transformation. Literal case-sensitive markers within each decoded HTML source-text segment: character references resolved; comments, script/style, tags and attributes excluded; segments never concatenated across markup. For text/plain, the entire decoded body. No whitespace normalization or regular expressions. The distinct parsed profile normalizes source CRLF/CR to LF before reference expansion without changing criteria; retain both projections, contexts, positions, reported errors, results and tools. Identical contexts are referenced without removing segments; trees can be reconstructed from the body and exact tools.

Method
First compare final URL with expected_final_url, then complete-body SHA-256 with expected_body_sha256. Fix references, any stable policy and markers before measurement. The changed non-stable body branch uses the historical reader unless prior identity_reader: html-tree-markers-v1 selects two whole-document static hypotheses, byte-attributed parsed segments and literal criteria. Hashing still covers the unchanged complete body. Draft.6 excludes attributable structural ASCII whitespace under html or across only body/html end tags, retaining original intervals and bytes; see migration-0.3.0-draft.6. The distinct html-tree-markers-v2 profile excludes noscript segments from all marker matching, including rechecks. The v1 profile retains its historical semantics. An intent must explicitly name the selected profile before the new capture. The distinct html-tree-markers-v3 profile covers main-document HTML text: attributed noscript/iframe/foreign-subtree exclusions; an excluded forbidden marker prevents pass; only duplicate-attribute parse5 errors are admitted, with no directive interpretation. ASCII whitespace across ignored end tags requires exact reconstruction. See migration-0.3.0-draft.7 for limits and explicit migration.

Acceptance criteria
Different final URL: fail. At the same URL, identical digest: pass. Otherwise, representation: stable requires fail. Otherwise, under the historical reader, valid markers yield fail if any required marker is missing or any forbidden marker is present. Pass requires at least one required marker, all required markers present and all forbidden markers absent. Forbidden-only markers all absent: inconclusive. Without markers or declared stability: inconclusive. HTTP status does not replace this comparison. Under html-tree-markers-v1, each complete reading compares all markers; both pass gives pass, both fail gives fail, every other pair is inconclusive. URL, hash and stability precedence remains unchanged.

When the result remains inconclusive
Missing/truncated capture, unknown decoding, missing/invalid reference URL or subsequent intent: inconclusive. At an identical URL, missing/invalid reference digest: inconclusive. When digests differ without stability, absent, empty, malformed or contradictory markers, unresolved extraction, or forbidden-only markers all absent: inconclusive. A different URL remains fail even without a reference digest. For the parsed profile: divergent hypotheses, reported parse5 errors, nonblank foreign text outside exclusions, unsupported frames/contexts, unattributable spans, unavailable runtime or exceeded bound remain inconclusive without fallback.

Non-applicability
No atomic exemption when the control applies.

Assumptions
The owner fixes a reference representation before collection; its business relevance remains their responsibility. Comparison is automatic; defining intent is not. Any selected profile and its criteria are declared in new intent before capture; no silent selection or conversion of historical intents.

Limitations
A changed digest alone does not prove wrong content. Source-text extraction measures neither CSS/DOM visibility nor semantic similarity; title and CSS-hidden text may count. Appropriate markers and a correct reference remain the owner’s responsibility. Wrong intent can validate wrong content. No engine soft-404 classification, indexing or undeclared routes. The new profile retains title/textarea/options/hidden text, excludes HTML/SVG scripts/styles and inactive templates; its contract specifies refusals. No browser behavior, complete HTML validity or new Edikka assessment follows.

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

Put it into practice

← Back to controls