JavaScript Rendering

In a client-side-rendered app, the initial HTML is a near-empty shell; the visible content materializes only after JavaScript runs in the browser. Googlebot invests in a rendering pipeline that executes JavaScript, eventually. Most AI crawlers do not: GPTBot, ClaudeBot, PerplexityBot and the retrieval fetchers generally read the raw HTML response and move on. If your product descriptions, comparisons and documentation exist only post-render, AI engines receive a blank page, and content that does not exist for the crawler can never be cited, regardless of its quality.

The decisive test: fetch a page with JavaScript disabled, or curl it, and inspect the raw HTML. If headlines, body copy and key facts are present, AI crawlers can read you. If you see an empty root div and script tags, you have an AI visibility problem hiding behind a perfectly normal-looking site. Frameworks like Next.js and Nuxt make this recoverable through server-side rendering or static generation, and pre-rendering services can patch older stacks. Watch for partial failures too: pages where the shell renders but pricing tables, FAQs or structured data are injected client-side.

The rule is simple: anything you want cited must be in the initial HTML response. Server-side rendering, static site generation or pre-rendering all satisfy this; pure client-side rendering does not. Prioritize money pages, documentation and comparison content first. After shipping a fix, confirm AI crawlers return and fetch the now-readable pages, since crawl activity is the earliest evidence of recovery. Geonimo's page optimization audits include checking that key content is server-rendered and machine-readable, alongside citability factors.