Why are JavaScript-rendered pages invisible to AI agents?

Most AI agents fetch the HTML your server returns and read it as text. They do not execute JavaScript. On a page built as a JavaScript application, that HTML contains a navigation bar, a loading message, an empty container the app will fill, and script tags. The agent gets a few dozen words and no product, price, article or answer.

The page is not broken. It is rendered in the wrong place for this visitor.

What the agent actually receives

Fetch any page the way a bot does, with a plain HTTP client and no browser, and count the readable words. On a server-rendered page the count is the article or product copy. On a client-rendered page the count is the header, the footer and "Loading". The content exists only after a browser downloads the bundle, runs it, calls your API and paints the result. Simple bots and crawlers, AI search indexers and retrieval bots skip every one of those steps.

This is the single most common reason a brand's own site is absent from AI answers while third-party pages about the brand are present. The third-party page was readable. The brand's page was a shell.

The common failures

Which agents render JavaScript

A small number of computer-use agents drive a real browser and will see your rendered page, slowly and at high token cost. Everything else, which is the bulk of fetches, does not. The high-volume readers in our logs on tollbit.com (ChatGPT-User, Claude-User, PerplexityBot, Amazonbot, meta-webindexer, OAI-SearchBot) are plain fetchers. Googlebot does render JavaScript, which is why a page can pass every SEO check and still be unreadable to AI.

The fixes, in order

  1. Server-render the content. The HTML the server returns should contain the words. Frameworks that support server rendering can do this per route without a rewrite.
  2. Slim the HTML. Rendering is necessary, not sufficient. A rendered page padded with scripts, trackers and layout markup is expensive to read. In our public comparison, one Forbes article went from 1,201 KB of HTML to 41 KB of Markdown (97% smaller), a Goal.com article from 378 KB to 13.2 KB, and across ten articles the reduction ran from 56% to 97.5%. Tokens are the agent's budget.
  3. Pre-compute the answers. Write the facts an assistant will quote into the page as sentences: the price, what it fits, when it ships, how it compares. A configurator makes the human do the work. For an agent, do the work in advance.
  4. Replace embedded documents with text. Spec sheets as HTML tables. Slides as headings and bullets.

Rendering for bots without touching the app

An agent site avoids re-platforming the front end. Identified AI agents are routed by a CDN or WAF rule to a subdomain on your domain where TollBit renders the page server-side, strips what agents do not need, and returns readable HTML or Markdown. The human application is unchanged, Googlebot is never routed, and the Agent Site CMS lets you edit the bot-facing version of any page, or publish an agent-only page, with no engineering ticket. Same facts, cleaner format, bots only.

Frequently asked questions

Googlebot renders my pages fine. Isn't that enough? For search, yes. For AI agents, no. Google runs a rendering service most AI bots do not have, so passing Google's mobile-friendly and indexing checks says nothing about what ChatGPT-User or Claude-User receive.

How do I check what an agent sees on my site? Request the page with a command-line HTTP client and an AI user agent string, then count the words in the response that a person would consider content. Under a hundred words on a product or article page means the page is a shell to agents.

Does an llms.txt file solve this? No. llms.txt is a hint file some agents may read. It does not change what any fetch of your actual pages returns, and in observed network logs it sees marginal fetch volume compared with ordinary HTML.

Related