Client-side rendering is invisible to most agents

What the agent actually receives

A browser loads your HTML, runs the bundle, waits for the API calls, and paints the page. Most AI fetchers stop after the first step. They pull the response body, strip the tags, and feed the text to a model. Whether they run JavaScript at all depends on the operator, and none of them wait for a client-side app to hydrate the way a person does.

So the question is not 'is my content good' but 'is my content in the response body'. View source, not inspect element. If the text of your page is not in view source, the model has not seen it.

How Qomvia measures it

The Content is server-rendered check under Machine access takes the raw HTML of your homepage, removes markup, scripts and styles, and counts the characters of readable text left. 1,500 or more passes. Between 400 and 1,500 is partial: a hero headline and a footer made it, the substance did not. Under 400 is a fail with the note 'Raw HTML is effectively empty'.

The thresholds are deliberately low. A homepage with a paragraph of positioning, a few section headings and a footer clears 1,500 characters. Pages that fail are almost always single-page applications, headless storefronts whose product data arrives from a GraphQL call, or marketing sites built on a client-only framework.

# Roughly what the check does: fetch, strip tags, count characters
curl -sS -A "QomviaBot/1.0" https://www.example.com/ \
  | sed -e 's/<script[^>]*>.*<\/script>//g' -e 's/<[^>]*>//g' \
  | tr -s ' \n' \
  | wc -c

Three ways to fix it, in order of effort

1. Server-side or static rendering. Every major framework supports it: Next.js server components or static generation, Nuxt SSR, SvelteKit, Astro, Remix. The page arrives complete and hydrates on top. This is the fix that also improves TTFB and Core Web Vitals.
2. Pre-render for bots. A rendering proxy detects declared crawlers and serves a pre-executed snapshot. It works, but it creates two versions of the site and a rule set that has to know every agent name. Google calls this dynamic rendering a workaround, not a long-term solution.
3. Put the substance in JSON-LD. If the shell cannot change, at least the structured data can: Product, Article, Organization, FAQPage blocks in the head are read by agents without rendering. This is a floor, not a fix; prose that lives only in the app is still invisible.

Whichever route you take, test it the way agents read: with a declared crawler user agent and no JavaScript, as in the bot protection article. A site can be server-rendered and still hand an agent a challenge page.

Why this compounds

Server rendering is upstream of almost every legibility check. There is no main content to extract, no heading hierarchy to chunk, no title and description to attribute a citation to, if the response is empty. A single fix moves several checks at once, which is why it sits high in the list of what a site loses first.

Questions

Googlebot renders JavaScript. Do AI crawlers?

Google does, in a second rendering pass. The AI operators do not document a rendering step for their search and user-fetch agents, and in practice their fetchers read the initial HTML. Build for the response body, not the rendered DOM.

My homepage passes but product pages are client-rendered. Does that matter?

Yes. Qomvia scores the homepage and any category or product pages it can reach. More importantly, the product page is the one a shopping agent needs to read.

Is dynamic rendering for bots cloaking?

Not if the content is the same as what a user sees after rendering. It becomes a problem when the bot version differs in substance from the browser version.