Server-rendered HTML
Critical content must be present in the initial HTML response. Most AI crawlers don't execute JavaScript; client-rendered pages return blank to them.
On this page
- What is server-rendered HTML and how does it differ from client-side rendering?
- Why does server-rendered HTML matter for AI agent discoverability and citations?
- Is server-rendered HTML required for agent-ready sites?
- What the HTML Living Standard says about content structure
- What good server-rendered HTML looks like in production
- How do I add server-rendered HTML to my existing site?
- How can I test if my site serves server-rendered HTML?
- Frequently asked questions
- Does server-rendered HTML mean I can't use React or modern JavaScript frameworks?
- Will switching to server-rendered HTML hurt my site's interactivity or performance?
- How does server-rendered HTML apply to e-commerce product catalogs with thousands of SKUs?
- Can I use a CDN or prerendering service instead of rewriting my app for server-rendered HTML?
- Do SaaS documentation sites need server-rendered HTML or can they stay static?
- How is server-rendered HTML different from ensuring my site has a sitemap.xml or robots.txt?
- Can I verify server-rendered HTML is working on a Next.js site deployed to Vercel?
- Does WordPress automatically provide server-rendered HTML or do I need a plugin?
What is server-rendered HTML and how does it differ from client-side rendering?
Server-rendered HTML means that when an HTTP client requests your page, the response contains complete, readable content in the HTML itself—not empty <div> tags waiting for JavaScript to fill them in. The HTML Living Standard defines HTML as a markup language for structuring documents; nothing in the spec requires or even mentions JavaScript execution. A well-formed HTML document is self-contained: headings, paragraphs, links, and calls-to-action are present in the markup, visible to any user agent that can parse HTML.
Client-side rendering (CSR) frameworks like Create React App ship an almost-empty HTML shell and rely on JavaScript to inject the actual content. To a curl request or a web scraper, these pages appear blank. Server-side rendering (SSR) or static site generation (SSG) solves this by running your JavaScript framework on the server and returning fully populated HTML. The JavaScript hydrates the page after load for interactivity, but the content is already there.
Why does server-rendered HTML matter for AI agent discoverability and citations?
Most AI agents don't execute JavaScript. When ChatGPT's web browser plugin, Perplexity's crawler, or Claude's citations engine visits your site, they issue a plain HTTP request and parse the returned HTML. If your page is client-rendered, they receive an empty <div id="root"></div> and nothing else. Your carefully crafted content, your product descriptions, your calls to action—all invisible. The agent moves on or cites a competitor whose content was actually readable.
This directly impacts citation rate and discoverability. If you're building an agent-installable tool or selling through agentic commerce flows, an empty HTML response means your site doesn't exist in the agent's world. Even traditional search engines have shifted heavily toward SSR; Google officially deindexes or deprioritizes pure CSR sites because crawl budget is finite and JavaScript rendering is expensive. For agents with even tighter resource constraints, SSR isn't a nice-to-have—it's the minimum bar for participation.
Is server-rendered HTML required for agent-ready sites?
This check is required for nearly every public-facing site. If your business model involves being found, cited, or interacted with by automated agents—search engines, LLM-based assistants, social previews, accessibility tools—server-rendered content is non-negotiable.
The only exceptions are authenticated web apps with no public landing pages (internal dashboards, behind-the-login SaaS tools) or highly specialized interfaces where you control every client and can guarantee JavaScript execution. If you have a marketing site, a docs site, an e-commerce storefront, or anything you want an agent to read, this check is required.
What the HTML Living Standard says about content structure
The HTML Living Standard specifies semantic elements for structuring content. Key elements that should be present in the initial HTML response:
<h1>through<h6>for headings<p>,<article>,<section>for body content<a>for links and CTAs<img>withaltattributes for images<nav>,<main>,<header>,<footer>for landmark navigation
A minimal valid HTML document with server-rendered content:
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<title>Product Name – Company</title>
</head>
<body>
<header>
<h1>Product Name</h1>
</header>
<main>
<p>This is the primary value proposition, visible immediately in the HTML source.</p>
<a href="/signup">Get Started</a>
</main>
</body>
</html>
No spec mandates SSR, but the standard assumes content is present in the HTML. If it isn't, you're technically serving valid HTML—it's just empty.
What good server-rendered HTML looks like in production
Companies shipping production SSR include Stripe (Next.js), Shopify's storefronts (Hydrogen/Remix), and GitHub's marketing pages (Rails with Turbo). Without access to their exact source at this moment, the pattern is consistent: a curl of the homepage returns readable <h1> tags, body copy in <p> elements, and CTAs in <a> tags.
A simplified example from a Next.js app's server-rendered output:
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<title>Dashboard – Acme Corp</title>
</head>
<body>
<div id="__next">
<nav><a href="/">Home</a><a href="/pricing">Pricing</a></nav>
<main>
<h1>Welcome to Acme Dashboard</h1>
<p>Manage your infrastructure in real-time.</p>
<a href="/signup">Start Free Trial</a>
</main>
</div>
<script src="/_next/static/chunks/main.js"></script>
</body>
</html>
The content is in the HTML; the JavaScript enhances it.
How do I add server-rendered HTML to my existing site?
-
Audit your current setup. Run
curl -A "bot" https://yoursite.comand inspect the response. If you see<div id="root"></div>or<div id="app"></div>with no content inside, you're client-rendering. -
Switch to an SSR/SSG framework. If you're on Create React App, migrate to Next.js (React SSR/SSG), Remix (React SSR), or Astro (multi-framework SSG). For Vue, use Nuxt. For Svelte, SvelteKit. Each has built-in SSR or static export modes.
-
Enable SSR in your framework. In Next.js, pages in
app/orpages/are server-rendered by default. For static generation, export withnext build && next export. In Nuxt 3:// nuxt.config.ts export default defineNuxtConfig({ ssr: true, }) -
Pre-render as a stopgap. If a full migration is off the table, use a prerendering service like Prerender.io or Rendertron to intercept bot traffic and serve rendered snapshots. Configure your CDN (Cloudflare, Fastly) to route bot user-agents to the prerender service.
-
Verify with curl. After deploying, confirm that headings and body text appear in the raw HTML.
How can I test if my site serves server-rendered HTML?
curl -A "Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; Googlebot/2.1)" \
https://yoursite.com | grep -i "<h1"
If you get no output, your content isn't in the HTML. Or just run a free scan and we'll check this for you alongside 30+ other agent-readiness signals.
Frequently asked questions
Does server-rendered HTML mean I can't use React or modern JavaScript frameworks?
No. Server-rendered HTML works perfectly with React, Vue, and Svelte through SSR frameworks like Next.js, Nuxt, and SvelteKit. These frameworks run your components on the server, send complete HTML to the client, then hydrate with JavaScript for interactivity. You keep your development experience while ensuring agents see real content in the initial response.
Will switching to server-rendered HTML hurt my site's interactivity or performance?
No. SSR frameworks deliver faster initial page loads because browsers can render content immediately without waiting for JavaScript. After the HTML loads, JavaScript hydrates the page to add interactivity. Users see content sooner, and agents can parse it. Modern SSR is faster than pure client-side rendering for both humans and bots.
How does server-rendered HTML apply to e-commerce product catalogs with thousands of SKUs?
E-commerce sites benefit enormously from server-rendered HTML. Platforms like Shopify Hydrogen use SSR to ensure every product page ships with price, description, and images in the HTML. This makes products discoverable to shopping agents and search engines. Use incremental static regeneration (ISR) in Next.js to pre-render popular products and render others on-demand.
Can I use a CDN or prerendering service instead of rewriting my app for server-rendered HTML?
Yes, as a stopgap. Services like Prerender.io or Rendertron intercept bot traffic and serve rendered snapshots. Configure your CDN (Cloudflare, Vercel) to route user-agents matching bot|crawler|agent to the prerender service. This buys time but adds latency and cost. Native SSR is the long-term solution for performance and maintainability.
Do SaaS documentation sites need server-rendered HTML or can they stay static?
Documentation sites absolutely need server-rendered HTML—or static HTML, which satisfies the same requirement. Tools like Docusaurus, VitePress, and Astro generate static HTML at build time. Every doc page ships as complete HTML, making guides instantly readable to LLM citation engines, search crawlers, and accessibility tools. Static generation is SSR done once at build time.
How is server-rendered HTML different from ensuring my site has a sitemap.xml or robots.txt?
robots.txt and sitemap.xml tell agents which pages exist and which to crawl. Server-rendered HTML determines whether agents can actually read your content once they visit. A perfect sitemap.xml is useless if your pages return empty <div id="root"></div>. They're complementary: sitemaps guide discovery, SSR ensures legibility.
Can I verify server-rendered HTML is working on a Next.js site deployed to Vercel?
Yes. Run curl -A "Googlebot" https://yoursite.vercel.app and inspect the response. You should see your <h1>, <p>, and <a> tags with real content inside the <div id="__next"> container. Vercel's Next.js deployments server-render by default unless you've explicitly disabled SSR or are using client-only components incorrectly.
Does WordPress automatically provide server-rendered HTML or do I need a plugin?
WordPress has always served server-rendered HTML—it's a PHP application that generates complete HTML on every request. You don't need a plugin for basic SSR. Issues arise if you've added a React-based headless frontend (e.g., Frontity) without SSR. In that case, switch to a framework like Next.js with getServerSideProps or keep WordPress's native theme engine.