SSR, SSG, or CSR: which rendering modes AI crawlers can actually read

AI crawlers read the HTML your server sends on the first response and nothing that JavaScript adds afterward. That one fact sorts every rendering mode into two buckets. Server-side rendering (SSR), static site generation (SSG), and incremental static regeneration (ISR) put your content in that first response, so GPTBot, ClaudeBot, and PerplexityBot can read it. Client-side rendering (CSR) ships an empty shell and builds the page in the browser, so those crawlers see the shell. If you want to be quoted by ChatGPT, Claude, or Perplexity, the words you want quoted have to exist before any script runs.

The rest of this guide explains where that fact comes from, how each mode behaves in practice, the five-minute test that tells you which bucket your pages are in, and the semantic HTML upgrade that turns a readable page into a quotable one.

The evidence: AI crawlers fetch JavaScript but do not run it

The clearest public measurement is a December 2024 study by Vercel and the technical SEO consultancy MERJ, which analyzed AI crawler traffic across Vercel's network. In the month studied, GPTBot made 569 million fetches, Anthropic's Claude crawler made 370 million, AppleBot 314 million, and PerplexityBot 24.4 million. Their conclusion was unambiguous: none of the major AI crawlers rendered JavaScript. ChatGPT's crawler did download JavaScript files in 11.50 percent of its requests and Claude's in 23.84 percent, but it fetched them as text and never executed them. The two crawlers in the study that did render were Google's and Apple's, both of which run browser-based crawlers.

Google, for its part, renders JavaScript but does it in a second phase. Its own documentation describes three phases, crawling, rendering, and indexing, and says a page waiting for rendering "may stay on this queue for a few seconds, but it can take longer than that." The same page adds the line that matters most here: server-side or pre-rendering "is still a great idea because it makes your website faster for users and crawlers, and not all bots can run JavaScript."

Put those together and the picture is simple. Google will usually see a client-rendered page, later. The AI engines that are now a real share of discovery will not see it at all. We explain the downstream cost in why your site is invisible to ChatGPT; this guide is about choosing the mode that avoids it.

Each rendering mode, judged by what a crawler receives

Two rows deserve a closer look because they fool good teams. The hybrid case is a common failure on modern stacks: the framework server-renders a beautiful shell, then a data hook fetches the pricing table, the FAQ, or the product description in the browser. The page passes a visual review and fails the crawler. Streaming SSR is the reverse case: it looks risky because content arrives late, but the late content is still part of the one HTTP response, so a crawler that reads the whole body receives it.

Dynamic rendering, serving a pre-rendered snapshot to bots and a client app to people, is not on the list on purpose. Google now describes it as "a workaround and not a long-term solution" and recommends server-side rendering, static rendering, or hydration instead. It also doubles your surface for drift, because the version the bot sees is not the version people use.

A five-minute test for any page

You do not need a tool to find out which bucket a page is in. You need the page's raw HTML and one sentence you care about.

1. Pick the sentence on the page you most want an AI engine to quote, such as your one-line product definition or the direct answer under your main heading.
2. Fetch the page without JavaScript, the way a crawler does, using the command below.
3. Search the output for that sentence, your H1, and your JSON-LD block.
4. If any of the three is missing, that element is invisible to GPTBot, ClaudeBot, and PerplexityBot, whatever your browser shows.
5. Repeat for your highest-intent templates: homepage, product or service pages, pricing, and your best explanatory articles.

curl -s -A "GPTBot" https://example.com/pricing | grep -c "the sentence you want quoted"

# 0 means the sentence is not in the raw HTML.
# Also check the heading and structured data:
curl -s https://example.com/pricing | grep -o "<h1[^>]*>.*</h1>"
curl -s https://example.com/pricing | grep -c "application/ld+json"

One honest caveat about this test: some CDNs and firewalls treat a bot User-Agent differently from a browser, so the raw HTML a real crawler receives can differ from what your own curl returns. If a page passes your curl but you still suspect a problem, the cause is often a bot-specific block rather than rendering. We cover that failure in the AI crawler access check.

This failure is easy to ship, even for people who know better

While preparing the move to this site, we audited the previous version of our own marketing site and found a close cousin of this bug on its blog. Every article URL returned the correct title and meta tags in the head, but the body rendered the blog index instead of the article, both on a cold fetch and after the app hydrated. A crawler reading those URLs got a page of article cards, not the article. Nobody noticed in a browser review because the head was right and the index looked fine. The lesson we took from it is the one this guide is built on: verify the bytes a crawler receives, never the screen you see.

Once the content survives, make it quotable with semantic HTML

Getting content into the first response makes it readable. Semantic HTML makes it easy for an engine to find the part worth quoting and to know what that part is. The HTML Living Standard defines these elements precisely, and none of them change how your page looks.

• Wrap the primary content in main, and each self-contained piece, such as an article or a product description, in article. The standard defines article as a "self-contained composition" that is independently distributable, which is exactly how an answer engine treats a quoted passage.
• Keep one h1, then a real h2 and h3 hierarchy. Headings are how a retrieval system locates the passage that answers a sub-question, so a heading that states the question is worth more than a clever one.
• Put visible dates in a time element with a machine-readable datetime attribute, and make sure the date matches the dateModified in your Article structured data.
• Put the author byline inside the article, linked to an author page, rather than in a sidebar widget that may render separately.
• Use blockquote with a cite for quotations, real ul and ol lists for steps, and table with th headers for comparisons. A list styled from div elements reads as an undifferentiated block of text.

Most sites can ship all of this by editing one layout component and one article template. It is the cheapest structural improvement in AI visibility, and it compounds with the passage-level work that decides which paragraph gets lifted.

If you are on a client-rendered stack today

You rarely need a rewrite to fix this. In rough order of effort:

1. In the Next.js App Router, Server Components render on the server by default. Move content out of client boundaries and fetch it in the server component, so it lands in the HTML. Keep client components for the parts that are genuinely interactive.
2. Statically generate anything that does not change per request: marketing pages, docs, articles, glossary entries, and location pages.
3. On a client-only stack such as a Vite or Create React App single-page app, add server rendering or prerendering for the public routes first. Authenticated dashboards can stay client-rendered because they should not be indexed anyway.
4. Replace client-side data fetches for primary content with server fetches. Loading spinners for the main answer are a crawler-facing empty state.
5. Re-run the five-minute test after each change and keep a list of templates that pass.

How SEO for AI Agents measures this

Our audit fetches every page twice: once as a plain HTML request with no JavaScript, the way GPTBot and ClaudeBot do, and once in a real headless browser, the way Googlebot eventually does. The JS render-parity check compares the two and reports the render-parity diff: how much of the rendered page is missing from the raw HTML, and which headings are absent. The AI crawler readability check reports the share of the rendered content a non-JavaScript crawler can read, with a published threshold.

What you get are receipts, not a verdict to take on faith. For each page you see the raw-HTML fetch, the rendered fetch, and the exact headings that only exist after JavaScript runs, so you can reproduce the finding with the curl test above. Both checks link to methodology pages that name their primary sources. If you build sites for clients, the guide for AI specialists and agencies covers how render parity changes per stack.

The order of operations matters. Rendering is the gate: schema, passage structure, and entity work all depend on the crawler receiving the page in the first place. Fix readability first, verify it with the raw bytes, and every other AI visibility investment starts paying off.