What can't be measured without a browser?
The honest boundary of server-side analysis — what needs JavaScript execution, and why saying so beats guessing.
Anything that only exists after JavaScript runs: client-rendered content, computed layout, real interaction behaviour, and genuine rendering performance. A server-side audit sees the HTML as delivered — which, importantly, is also what most AI crawlers see.
The two different views of a page
Every page exists in two forms, and confusing them is behind a large share of "why does my site not appear anywhere" questions.
- As delivered. The HTML the server sends. What an HTTP client receives, and what most AI crawlers work from.
- As rendered. What exists after scripts run, the DOM is modified and styles are computed. What a person sees.
On a server-rendered site these are nearly the same. On a client-rendered application they can be wildly different — an empty container in the first, a complete page in the second.
What needs a browser
| Property | Why a browser is required |
|---|---|
| Client-rendered content | It does not exist until scripts execute |
| Computed layout and contrast | Requires the CSS cascade to be resolved against a viewport |
| Core Web Vitals | LCP, CLS and INP are rendering and interaction measurements |
| JavaScript errors | Only observable at runtime |
| Interaction behaviour | Menus, modals, focus traps — all require events |
| Cookies set by script | Only appear once the script runs |
| Lazy-loaded content | Requires scroll and viewport intersection |
| Consent banner behaviour | What loads before and after consent is a runtime question |
What does not need one
Worth stating, because it is most of what determines whether a site works for machines:
- Every response header — security, caching, cookies, content type.
- The entire TLS handshake: protocol, cipher, certificate, chain.
- All DNS: A, AAAA, MX, NS, CAA, SPF, DMARC.
- robots.txt and its resolution per crawler and per path.
- The delivered HTML: metadata, headings, structured data, alt attributes, link structure.
- Redirect behaviour and canonical directives.
- Server response timing.
The honest way to report the gap
A check that requires rendering should not be quietly skipped, and it certainly should not be scored as a pass. It should return a distinct state — requires_browser — that says: this is not a failure of your site or of the tool, it is a statement about where the fact lives.
This matters for agents especially. A tool that silently omits browser-dependent checks teaches a model that those areas are fine. A tool that names them lets the model say "this was not evaluated, and here is why".
Covering the difference
- Use server-side measurement for configuration, transport, DNS, crawler access and delivered content — the things that decide whether machines can use your site at all.
- Compare delivered against rendered yourself:
curl -sLyour page and search for text you can see in a browser. A mismatch is the finding. - Use a browser-based tool for Core Web Vitals, computed contrast and interaction testing.
- Test accessibility with a real assistive technology as well — automated checks of either kind catch perhaps a third of real barriers.
Step two takes ten seconds and resolves more AI-visibility questions than any other single check.
What our audit reports about this
Every item below is measured directly, not inferred. Run it against your own site and the result names the exact rule or header responsible.
- Checks that genuinely require rendering are returned as
requires_browserrather than skipped or scored as passes. - How much of your visible text is present in the delivered HTML versus added by JavaScript.
- A published coverage statement naming rendering, Core Web Vitals and field data as explicitly out of scope.
- Everything observable without a browser — headers, TLS, DNS, robots resolution, delivered markup — measured directly.
For agents and scripts, the same measurement is at
/api/v1/summary?url=yoursite.com —
see the API documentation.
Related questions
Is a server-side audit worse than a browser-based one?
It is different, and for machine-readability questions it is the more relevant view, because most AI crawlers do not render either. For rendering performance and computed layout, a browser-based tool is the right instrument. They are complements.
Why not run a headless browser?
It is a substantial infrastructure commitment, and it would change the honest boundary of what is claimed. Rather than partially render and imply completeness, browser-dependent checks are declared out of scope with the reason.
How do I know if my content needs JavaScript?
Run curl -sL on your page and search for a distinctive sentence you can see in a browser. If it is not there, it is built client-side and most AI crawlers will never see it.
Does Google see the rendered version?
Googlebot does render, on a second pass, with delay and not always completely. Most AI crawlers do not render at all — which is why a client-rendered site can rank acceptably in Google while being invisible to every AI assistant.
Read next
Does JavaScript hurt AI crawlers?
Yes, more than it hurts search engines. If your content only exists after JavaScript runs, most AI crawlers see an empty page.
ReadWhat should an AI agent do when it cannot determine something?
Why "not checked" and "passed" must never be the same answer, and how a well-built tool keeps them apart.
ReadWhy does my audit score disagree with Lighthouse?
Two tools measuring genuinely different things — and why expecting them to agree is the actual mistake.
ReadWhat is evidence-based website analysis?
The difference between a tool that tells you a verdict and one that shows you what it saw — and why the second is worth insisting on.
Read