JavaScript and CSS Check for crawlers
Each visit gets unique asset URLs. The server records which assets were fetched and whether JavaScript executed.
-
HTML ✓ loadedYour client made an HTTP request and received this page.
-
CSS ⌛ pendingDid your client fetch the linked stylesheet? Detected server-side via access logs.
-
JavaScript ⌛ pendingDid your client fetch and execute the script? The fetch is server-side; execution is confirmed by the script sending a beacon back.
-
Web Bot Auth ✗ not presentedYour client did not present a Web Bot Auth signature.
All checks complete — view aggregate results
This tool checks for JavaScript support by serving uniquely-tagged CSS and JS assets per session and recording whether each was fetched, whether the script was executed, and how long it took. This data is recorded in a public, aggregated report. Additionally, cryptographic bot-identity verification (Web Bot Auth) helps answer: is this bot really who it says it is, or a scraper using someone else's user-agent string?
For site owners and SEOs, the practical implications can be significant. While it's true that "Google renders JavaScript, so client-side rendering is fine," the crawler / bot landscape is much stupider than just Googlebot and Bingbot. The fetch-versus-execute data tells you which bots see your fully-hydrated page and which see an empty shell, which directly determines whether your content is indexable, citable, or summarizable.
For anyone optimizing for agentic browsers and AI grounding, this
test is foundational. Some fetch only raw HTML, some execute
JS headlessly, some explicitly request markdown via their Accept headers,
some are full Chromium instances.
Treating "AI" as one thing is a mistake. Concrete data on which agents execute scripts,
which negotiate for markdown, and which present verifiable identity lets you serve the right
variant to each, prerender for the ones that won't run your JS, and engineer for the way these
systems actually consume your content.