research withRon

Technical checklist

JavaScript rendering and crawler checklist

Test the page a crawler receives before debating content strategy. The answer may be missing from the HTML that matters.

10 / 25

Updated August 13, 2026

9 min read · free

The short answer

A rendering audit compares raw server HTML, rendered DOM, crawler-specific delivery, and visible page content to confirm that the same primary facts, links, metadata, and status are available in every eligible path.

Business outcome

You find invisible content, client-only links, soft errors, blocked resources, and bot challenges before they waste an AEO campaign.

The process

Build it in five passes

01

Start with the response

Request the canonical URL without executing JavaScript. Record status, redirect chain, content type, canonical, robots directives, language, title, description, structured data, primary text, and internal links. A 200 response can still be a soft error or an empty application shell.

02

Compare the rendered DOM

Load the page in a browser with JavaScript and compare the primary facts, heading structure, links, canonical, and structured data. Flag content that appears only after an interaction, long timer, personalization, or failed API request.

03

Test crawler delivery

Check representative search and user-retrieval user agents through the CDN and origin. Look for challenges, 403s, 429s, different HTML, geography behavior, and consent overlays. Do not spoof a provider for operational allowlisting without appropriate verification.

04

Inspect links and discovery

Ensure navigation uses crawlable anchor elements with real href values, important pages receive contextual internal links, and canonical URLs appear in the sitemap. Client-side click handlers alone are a poor discovery mechanism.

05

Fix the durable source

Put decision-critical facts and links in server-rendered or statically generated HTML when practical. Align visible text and structured data. After release, repeat all response, render, crawler, and internal-link checks on the production host.

Before it ships

Quality checklist

  • The raw response includes the page's main answer and a descriptive H1.
  • Canonical and indexing directives match before and after rendering.
  • Decision-critical links are real anchors with stable href values.
  • Crawler requests are not challenged, throttled, or served an empty shell.
  • Structured data describes facts visible on the same page.
  • The canonical URL is internally linked and included in the sitemap.

Copyable artifact

Four-view rendering comparison

Complete one column per delivery view and investigate every material difference.

URL: [canonical URL]
AUDIT DATE: [YYYY-MM-DD]

FIELD                         RAW HTML | RENDERED DOM | SEARCH AGENT | USER AGENT
HTTP status                   [ ]        [ ]            [ ]            [ ]
Final URL                     [ ]        [ ]            [ ]            [ ]
Canonical                     [ ]        [ ]            [ ]            [ ]
Robots directive              [ ]        [ ]            [ ]            [ ]
Title                         [ ]        [ ]            [ ]            [ ]
H1                            [ ]        [ ]            [ ]            [ ]
Primary answer present        [ ]        [ ]            [ ]            [ ]
Key fact table present        [ ]        [ ]            [ ]            [ ]
Internal links present        [ ]        [ ]            [ ]            [ ]
Structured data present       [ ]        [ ]            [ ]            [ ]
Consent or bot challenge      [ ]        [ ]            [ ]            [ ]

MATERIAL DIFFERENCES: [list]
ROOT CAUSE: [template, API, CDN, consent, hydration, other]
OWNER / DUE DATE: [name / date]

Validation

How you know it is ready

  1. 01The decision-critical answer is present in raw HTML and visible after rendering.
  2. 02Canonical, status, and indexing directives are consistent across views.
  3. 03Production retesting shows the same meaningful content through eligible delivery paths.

Do not overclaim

Google can render JavaScript, but rendering still adds dependencies and failure modes. Other systems may fetch differently. This checklist reduces access risk; it does not imply identical processing by every engine.

Questions

What teams usually ask

Does all content need to be server-rendered?

Not necessarily. Prioritize the main answer, entity facts, internal links, canonical metadata, and content needed to understand the page. Test the actual delivery path instead of applying a universal rule.

Is view-source enough for the audit?

No. Compare raw HTML with the rendered DOM and delivery through your CDN. Each view can reveal a different failure.

What is the highest-risk rendering pattern?

Decision-critical content that appears only after interaction, personalization, a fragile API call, or a client-side state transition is easy to miss or misinterpret.

Sources reviewed

Primary guidance and Ron research

Keep working

Related field assets

Browse all 25 →