TS02Access and indexing

Does this address lead straight to the right page?

Find chains, loops and wrong destinations after a migration or address change.

Check a redirect

In the app: HTTP route + confirmed plan
You provide: Starting URL and destination
Allow for: Depends on the route and plan timeouts

Check a redirect

Understand

The right page. Without needless detours.

A working redirect can still take a detour. TS02 compares the actual route with the confirmed plan: destination, number of redirects, permitted status codes and absence of a loop.

From /ancienne-offre to /offre: the observed route goes through /catalogue then /offres, with three 301 redirects before the 200 response. The expected route goes straight to /offre, with one 301 redirect before the 200 response. — Same destination. *Two fewer intermediate steps.*In this example, the plan expects one redirect. The result always depends on the confirmed plan.

According to Google

Google distinguishes permanent and temporary redirects. The TSEP check also compares the route with the plan you confirmed.

Redirects and Google Search Source accessed on 2026-10-27

Check

The actual route. The intended plan.

In TSEP Control

The app follows redirects from the selected starting address and records HTTP status codes within the plan’s limits. From an analysis, it suggests http/https, www and trailing-slash variants: you choose the starting address to test.

Your contribution

Confirm the expected destination and permitted route before collection. By default: one permanent 301 or 308 redirect, then 200. Also check permitted domains and collection limits.

With your own tools

Record each response and its Location header with network tools or curl. Test relevant variants separately and compare the route with the approved plan.

Evidence to retain

The approved plan, complete HTTP chain and final destination. Each selected starting address has its own test.

What this result covers

The tested address and its route, at test time, from the TSEP client. This does not automatically cover every variant, the whole site, destination-content relevance or an actual Googlebot visit.

Act

A direct link. To the destination.

Point the rule directly to the final destination and update internal links.

Recheck

Same starting point. Fewer detours?

From the result, “Recheck this redirect” proposes the same starting address and expectations. Confirm the new test; earlier results are retained. The comparison can show, for example, a change from three redirects to one.

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: At least one check criterion is not met: the plan may have been rejected or the observed route may differ from the confirmed expectation. Read the reason before making a fix.
NT · Not established: The required evidence does not support a conclusion, for example when a review is missing or collection cannot establish the route. Read the report’s limits and reason; a collection stop does not by itself establish a site error.
NA · Not applicable: Use only when non-applicability is justified under the rules. An address without redirects may also satisfy a plan that expects zero redirects.

Sources and references1 reference

Redirects and Google Searchdevelopers.google.com · new tab

Detailed method and rules2 rules

Control method and criteria

Method
Test HTTP/HTTPS, host, trailing-slash and legacy URL variants, including the redirect count.

Acceptance criteria
Each tested variant follows the approved destination and hop count without a loop; the owner confirms intent.

Non-applicability
No redirects or expected variants, supported by an inventory.

Detailed rules

TS02-A01 · Previously approved redirect plan

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

Scope
Variants and legacy URLs with a declared expected behavior.

Evidence
Plan, context, declared owner identity and role, date, decision, reason, assistance and review provenance; exact digest of examined criteria.

Method
Declare source, final destination, allowed redirect and terminal statuses, minimum/maximum redirect count and context. Check the supplied owner review, reasoned, dated between declaration and capture and digest-bound to plan/context.

Acceptance criteria
The owner explicitly approves the applicable plan before capture. Explicit rejection bound to the same plan is fail; missing or unattributable review remains inconclusive.

When the result remains inconclusive
Missing, invalid or late plan; absent, unbound or mistimed review; unsupported mechanism. The tool supplies no human approval.

Non-applicability
No atomic exemption. Whole-control non-applicability needs a separate positive inventory; a missing capture does not establish it.

Assumptions
The owner supplies criteria before capture; a laboratory author may supply an explicitly synthetic review. A digest binds records without authenticating a person.

Limitations
A valid redirect does not prove the semantic relevance of its destination. The executable reference covers bounded server-side HTTP trajectories; other mechanisms remain unestablished, without exempting the control.

TS02-A02 · HTTP trajectory matches the plan

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

Scope
Variants and legacy URLs with a declared expected behavior.

Evidence
Original HTTP requests/responses per hop, URL, completeness, client and context; prior plan. Proven contradictions survive later gaps and absent A01 approval.

Method
Read each attributable GET exchange in order, resolve Location, retain codes and URLs, count redirects and check terminal destination/status. Compare with the pre-capture plan without reconstructing missing responses. Prior profile http-trajectory-headers-v1 may conclude from complete headers after an attributable collector-2 byte-limit stop; the body remains incomplete and unevaluated.

Acceptance criteria
The complete chain matches declared destination, statuses and bounds, without a loop. A forbidden type, exceeded maximum, redirect without Location or return to a visited URL is fail as soon as a complete prefix establishes it. Wrong terminal destination/status or insufficient count is fail after an attributable terminal response.

When the result remains inconclusive
Unfinished chain without contradiction, collection limit, ambiguous Location, unsupported fragment/syntax, conditional/authenticated request, incomplete or unattributable capture. A collection limit does not prove a loop; exceeding an intended maximum is distinct. Bounded exception: prefix at the exact attributed byte limit with one overflow byte, without ambiguous headers or contradictory framing, under the explicit new profile only.

Non-applicability
No atomic exemption. Whole-control non-applicability needs a separate positive inventory; a missing capture does not establish it.

Assumptions
The owner supplies criteria before capture; a laboratory author may supply an explicitly synthetic review. A digest binds records without authenticating a person.

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

Put it into practice

← Back to controls