TS25Content and rendering

Is essential content present at the right stage?

Critical content exists in source HTML or becomes observable after rendering.

Prepare evidence

In the app: Evidence import
You provide: HTML, rendering and expected elements
Allow for: Depends on evidence needed

Prepare evidence

Understand

The HTML received. The page rendered.

Critical content exists in source HTML or becomes observable after rendering.

According to Google

Google processes JavaScript applications through crawling, rendering and indexing. Initial-response content and rendered content should therefore be distinguished.

Understand the JavaScript SEO basics Source accessed on 2026-10-26

Check

Before JavaScript. After JavaScript.

In TSEP Control

You import evidence for this control. The engine assesses it within the declared scope; missing items remain visible.

Your contribution

Define the scope and expectations before collection. Gather the items below and supply the requested reviews.

With your own tools

Retain response HTML and the rendered DOM for the same URLs and conditions. Compare critical elements; Search Console inspection can supplement your rendering observation.

Evidence to retain

Prior plan, HTTP/DOM originals, fingerprints, conditions, per-item/stage values, actually supplied reviews and dates.

What this result covers

Declared scope only, static hypotheses without execution; unauthenticated reviews and attribution. No inferred Google rendering, CSS visibility, truth, structured validity, indexing or global conformity.

Act

Essentials available. At the expected stage.

Make each critical element available at the intended stage and retain the corresponding captures.

Recheck

Two fresh captures. The same comparison.

After correction, gather new evidence with the same scope and expectations. Retain both dated observations to compare what changed.

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: Make each critical element available at the intended stage and retain the corresponding captures.
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

Understand the JavaScript SEO basicsdevelopers.google.com · new tab

Detailed method and rules2 rules

Control method and criteria

Method
Check five role dispositions, then items in static source hypotheses and planned rendered states; retain originals, exclusions and bound supplied reviews.

Acceptance criteria
Two passing rules within supplied scope: motivated coverage and presence under prior policies. Any qualified independent failure yields NC; otherwise unknowns yield NT.

Non-applicability
No native NA; motivated out-of-scope roles retained, never equivalent to control NA.

Detailed rules

TS25-A01 · Prior critical scope and five role dispositions.

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

Scope
Critical items and stage policies declared before capture, profile critical-stage-presence-v1.

Evidence
Prior plan, HTTP/DOM originals, fingerprints, conditions, per-item/stage values, actually supplied reviews and dates.

Method
Check five role dispositions, then items in static source hypotheses and planned rendered states; retain originals, exclusions and bound supplied reviews.

Acceptance criteria
Pass requires motivated population, five exact decisions and a prior bound supported review. Bound contradiction review: fail. Missing, unbound or unknown review: inconclusive.

When the result remains inconclusive
Missing or invalid plan/capture/review, unsupported role, conflicting readings, unqualified rendered context, extra/duplicate states, exceeded bounds. An independent failure remains fail. Draft.44 / reader3: supplied TS25 review fields reviewer, assistance and reason are each limited to8192 raw UTF8 bytes before strip or normalization; each entire review object, including additional fields, to32768 compact UTF8 JSON bytes. Admission checks every supplied review, including unused ones. An overrun is technical refusal before publication, never public C or NT; exact originals are not rewritten. Each native rule diagnostic is bounded to4MiB of sorted compact UTF8 JSON, including A01 and error returns. Overflow produces an explicitly incomplete compact diagnostic retaining an independently established fail, otherwise inconclusive; never pass. Transport refuses that marker and also caps the sum of actual serialized TS25 observation artifacts per target at4MiB (UTF8 JSON indent2, trailing newline), for requested rules. Individual maxima do not guarantee that every combination satisfies aggregate bounds. Other controls and the shared validator are unchanged.

Non-applicability
No native NA; motivated out-of-scope roles retained, never equivalent to control NA.

Assumptions
1–32 items,0–16 prior states, window<=24h, HTTP<=30s; five explicit roles. Two HTML hypotheses must agree; required states combine with qualified-failure precedence. Supplied review, no authentication.

Limitations
Declared scope only, static hypotheses without execution; unauthenticated reviews and attribution. No inferred Google rendering, CSS visibility, truth, structured validity, indexing or global conformity.

TS25-A02 · Critical presence under each item’s source/render policy.

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

Scope
Critical items and stage policies declared before capture, profile critical-stage-presence-v1.

Evidence
Prior plan, HTTP/DOM originals, fingerprints, conditions, per-item/stage values, actually supplied reviews and dates.

Method
Check five role dispositions, then items in static source hypotheses and planned rendered states; retain originals, exclusions and bound supplied reviews.

Acceptance criteria
Pass requires all items present under their policy and qualified state coverage. Independently qualified absence: fail despite another unknown. Otherwise inconclusive.

When the result remains inconclusive
Missing or invalid plan/capture/review, unsupported role, conflicting readings, unqualified rendered context, extra/duplicate states, exceeded bounds. An independent failure remains fail. A non-object render container remains unknown; it does not erase an independently required qualified source absence. Draft.44 / reader3: supplied TS25 review fields reviewer, assistance and reason are each limited to8192 raw UTF8 bytes before strip or normalization; each entire review object, including additional fields, to32768 compact UTF8 JSON bytes. Admission checks every supplied review, including unused ones. An overrun is technical refusal before publication, never public C or NT; exact originals are not rewritten. Each native rule diagnostic is bounded to4MiB of sorted compact UTF8 JSON, including A01 and error returns. Overflow produces an explicitly incomplete compact diagnostic retaining an independently established fail, otherwise inconclusive; never pass. Transport refuses that marker and also caps the sum of actual serialized TS25 observation artifacts per target at4MiB (UTF8 JSON indent2, trailing newline), for requested rules. Individual maxima do not guarantee that every combination satisfies aggregate bounds. Other controls and the shared validator are unchanged.

Non-applicability
No native NA; motivated out-of-scope roles retained, never equivalent to control NA.

Rule version 0.2.0-rc.1 · Public protocol reference · Versioned source

Put it into practice

← Back to controls