AI agents are making server-rendered HTML matter again
For a decade, where your pages were rendered was a question for engineers. AI agents that read raw HTML have made it a business decision again. Here's why, what "hydration" means in plain words, and what to ask your team.
How rendering left the server
A web page can be built in two places. Your server can send finished HTML, with the product name, price and description already in it. Or it can send a near-empty shell and a bundle of JavaScript that builds the page in the visitor's browser.
Over the last decade, many teams moved toward the browser. It made sites feel like apps, let front-end teams ship on their own, and the search cost seemed small: Google's crawler runs JavaScript. Google's own JavaScript SEO documentation describes processing JavaScript pages in three phases, crawling, rendering and indexing. So a page built in the browser could still rank, and the question of where it was built became an engineering preference.
The same documentation carries a line that's easy to skip: server-side or pre-rendering is still a great idea, it says, because it makes sites faster "and not all bots can run JavaScript". That line is now about your customers.
The new readers of your HTML
When someone asks ChatGPT, Claude or Perplexity about a product, the assistant often fetches your page and reads it in a few seconds. Many of these fetchers, and many AI search and training crawlers, read the HTML your server sends and don't run your scripts. Our guide to the AI agents that visit your website sorts out who does what, and what an AI agent sees shows the difference on a real page.
To an agent like that, a browser-built page is the shell: a logo, a loading spinner, maybe a menu. No price, no stock, no reason to recommend you.
<body>
<div id="app"><span class="spinner"></span></div>
<script src="/bundle.js"></script>
</body>The good news from our study of 255 online stores is that most pages are fine: only 17% of stores had pages, among those we checked, with less than 70% of their text in the HTML. Product pages are where it slips. 6% of stores only add their product data with JavaScript, and 15% don't have prices in the product page's HTML at all. Those are the pages and facts an agent needs most.
Why it's a business decision now
Rendering choices used to trade developer speed against page speed. Now there's a third factor: whether a growing kind of visitor can read your offer at all. That changes who should be in the room.
Built on the server
- Every reader gets the facts, scripts or not
- Prices and stock can be quoted by assistants
- More server work per page, which caching can offset
Built in the browser
- HTML readers get a shell
- Assistants may skip you or guess
- Less server work, and the cost moves to lost visibility
That doesn't mean every page needs a rebuild. It means a marketing or e-commerce leader should be able to answer one question about each important page type: is the information a customer asks about in the HTML? If nobody can answer, that's the first task.
Hydration, in plain words
Modern frameworks don't make you choose between a fast, readable page and an interactive one. They do both: build the HTML on the server, then make it interactive in the browser. That second step is called hydration. Google's web.dev guide to rendering defines it as "running client-side scripts to add application state and interactivity to server-rendered HTML".
For agents, hydration is good news, with one catch. The HTML from the server is what they read; hydration only matters to people and browser agents afterwards. So the question is never "do we use React?" but "which parts of the page are in the server's HTML, and which are left to load in the browser?"
Most frameworks now start from the server by default:
| Framework | What its documentation says it does by default |
|---|---|
| SvelteKit | Renders any component first on the server and sends it as HTML, then hydrates it in the browser. |
| Next.js (App Router) | Layouts and pages are Server Components; Client Components add interactivity where needed. |
| Astro | Renders every UI component to HTML and CSS, stripping out client-side JavaScript unless a component is marked as an interactive island. |
The catch is in how teams use them. A component marked to run only in the browser, data fetched after the page loads, or a price widget that appears once a script runs can all leave holes in otherwise server-rendered pages. React's documentation for hydrateRoot adds a developer-level warning: the browser's render is expected to match the server's, and mismatches should be treated as bugs. A page that shows one price in its HTML and another after hydration confuses people and agents alike.
The question isn't which framework you use. It's which facts are in the HTML your server sends.
What to render on the server first
You don't need everything in the HTML. Start with what customers ask an assistant about:
- Product name, price and currency
- Availability, sizes and key specifications
- Shipping, returns and plan pricing
- Product structured data, in the page template rather than a tag manager
- Personalized recommendations and recently viewed items (fine in the browser)
- Chat widgets and live inventory counters (fine in the browser)
If a full move to server rendering is a big project, Google describes its older workaround of serving bots a pre-rendered copy, dynamic rendering, as "a workaround and not a long-term solution". It also depends on recognizing every agent, which is getting harder. Treat it as a bridge, not a destination. Our guide to JavaScript-only content covers the options in more depth.
What to ask your team
- Open View Page Source on a product page and search for its price. If it isn't there, an HTML-only agent can't see it.
- Ask which page types are rendered where: home, category, product, pricing, policies. Get the answer in a table.
- Ask what's loaded after the page arrives, such as prices, stock and reviews, and whether it could be in the first response.
- Make it part of the brief. New templates should put key facts in the HTML. How to brief your agency and questions for your e-commerce platform have wording you can reuse.
AgentScore's Content loads without JavaScript check measures this for you: it passes when at least 70% of the rendered page's text is already in the HTML. Two other checks, Prices are in the page HTML and Product pages give price and stock in a form agents can read, look at the facts that matter most. If you think of your product page as something machines read, as we argue in your product page is now an API, server-rendered HTML is its most widely understood format.