BotView lab note ·
Same page, different HTML: a JavaScript rendering test
We built two versions of a help page. Both displayed the same 105 words when JavaScript ran. When we disabled scripts, one still displayed the whole page. The other was empty.
This is a controlled example, not a survey of websites or a test of any search engine. It demonstrates why a screenshot alone cannot tell you whether content depends on JavaScript.
One change: where the content lives
The example is an invented help page about exporting invoices. In the first version, the server sends an empty <main> element. An inline script inserts the article. In the second, the server sends the article inside <main> already.
The words, styles and browser viewport are the same. Neither version needs a login, an external script or an API request. This removes those possible sources of failure and isolates the rendering difference.
What we measured
| Page version | JavaScript | HTTP status | Visible words |
|---|---|---|---|
| JavaScript-only | Off | 200 | 0 |
| JavaScript-only | On | 200 | 105 |
| HTML-first | Off | 200 | 105 |
| HTML-first | On | 200 | 105 |
All four requests returned HTTP 200. None produced a JavaScript error. A successful HTTP response did not establish that the main content was visible without scripts.
With scripts disabled
With scripts enabled, both versions displayed the same article. The downloads include those screenshots too.
What this means for a real page
If important content appears only after JavaScript runs, a consumer that does not execute that script needs another way to extract it. Serving the content as HTML removes that particular dependency.
Google documents a rendering stage that can process JavaScript. An empty result with scripts disabled therefore does not prove Google cannot index a page. For a site you manage, compare the initial HTML with the rendered page and check Google’s own result in Search Console’s URL Inspection. Google’s JavaScript SEO documentation explains the crawl, render and index stages.
Start with a page whose answer matters: a product description, pricing explanation or support article. Check its main text and links before deciding whether to change how it is rendered.
What we did not test
No Googlebot, OpenAI or Anthropic crawler visited these fixtures. We used a regular Chromium user agent. The test measures visible text inside one element, not indexing, rankings, citations or every way a parser could recover content.
In fact, the JavaScript-only fixture contains the article as a string inside its script. A tool that inspects script data could recover it. Our result is specifically that the main element stays empty when the script does not run.
There are two fixtures and one browser load per condition. That is enough to reproduce this example, but it says nothing about how common the problem is across the web.
Repeat the experiment
We served both fixtures from a local HTTP server and opened each in a fresh Playwright browser context with JavaScript on and off. The browser was Chromium 145.0.7632.6, at an 860 × 780 viewport. After the load event, we read main.innerText, normalized whitespace and counted space-separated words. The script asserts that all three non-empty results have identical text.
- Measurements, extracted text and fixture SHA-256 hashes (JSON)
- Reproduction script (Node.js and Playwright)
- JavaScript-only HTML source · HTML-first source
- JavaScript-only screenshot, scripts on · HTML-first screenshot, scripts on
In a folder with Node.js 22 or later, save the reproduction script and run:
npm install [email protected]
npx playwright install chromium
node reproduce.mjs ./resultsThe script writes only to the chosen output directory and requests only its local fixture server. This note and its measurements were prepared with automated tooling; the source and results are provided so the claims can be checked.