Why your blog should render on the server if you want AI to find it

There's an architectural decision that looks minor but defines whether your content exists or not for AI agents: where your site is rendered.

Most developers pick client-side rendering (CSR) out of inertia. It's easier, React does it by default, and for dashboards and interactive apps it makes perfect sense. But for a blog — especially one that wants to be visible in the agentic web — it's the worst decision you can make.

What AI agents see when they visit your site

When ChatGPT, Gemini, Perplexity or any AI agent hits a URL, this is what they get:

Blog with SSR (Server-Side Rendering):

<article>
  <h1>WebMCP: The Protocol That's Changing the Game</h1>
  <p>An open protocol from Google and Microsoft that lets AI agents interact with any site...</p>
  <script type="application/ld+json">
    {"@type": "BlogPosting", "headline": "WebMCP...", "author": {"@type": "Person"...}}
  </script>
</article>

Blog with CSR (Client-Side Rendering):

<div id="root"></div>
<script src="/bundle.js"></script>

The AI agent sees an empty div. It doesn't execute JavaScript. It doesn't wait for React to hydrate. It doesn't hit your API. It simply moves on. Your article doesn't exist for it.

"But Googlebot does run JavaScript"

Partly true. Googlebot has a Chromium-based renderer that runs JS, but with a significant delay — it can take days or weeks to render your page. And when it does, it spends a limited "render budget." If your site has many CSR pages, Google simply won't render them all.

But the Googlebot argument isn't enough anymore. Classic SEO (Google) is being complemented by GEO (Generative Engine Optimization) — optimizing so your content appears in AI agents' answers. And AI agents don't run JavaScript. Period.

The economics of rendering

There's a seemingly reasonable argument for CSR: "if I render on the server, every visit has a computational cost. With CSR, the server only serves static files."

Let's look at the real numbers:

ConceptEdge SSRCSR Cost per request~€0 (Cloudflare Workers free tier: 100K req/day)~€0 (static files) Database query1 per request (server)1 per request (client) Bundle sent to userHTML (~20KB)JS bundle (~150–300KB) + empty HTML Time to First Contentful Paint~100ms~800ms–2s (JS download + fetch + render) Visible to AI agentsYesNo

The database query cost is identical — someone has to do the fetch. The difference is who: the server (2ms from Supabase) or the user's browser (200ms away and needing to download 150KB of JavaScript first).

With Cloudflare Workers, SSR is essentially free. The closest edge to the user renders and serves the page. No central server to scale. No meaningful cold starts. The cost is less than serving the JavaScript bundle the CSR version would need.

The stack that works

At Agentikas we built the blog on this stack:

• Next.js with Server Components at the edge
• Cloudflare Workers as the runtime (via @opennextjs/cloudflare)
• Supabase as the database (PostgreSQL, REST queries)
• Schema.org embedded in the HTML (BlogPosting, Organization, etc.)
• WebMCP as the discovery protocol for agents

Each page renders at the edge in ~100ms. The HTML includes everything: content, metadata, structured data, Open Graph. When an AI agent visits the URL, it gets everything it needs to understand, cite and recommend the content.

No JavaScript bundle for the content. No loading spinners. No "loading…". The user (human or AI) gets the content instantly.

When CSR does make sense

We're not saying CSR is bad. For interactive applications — dashboards, editors, work tools — CSR is the right choice. Our own CMS (write.agentikas.ai) uses client-side components for live editing, image pickers, and AI generation.

The rule is simple: if the content needs to be discovered, SSR. If the content needs to be manipulated, CSR.

A blog needs to be discovered. An editor needs to be manipulated. Don't mix them.

The agentic web doesn't wait

We're in a transition moment. AI agents are starting to navigate the web autonomously — searching for information, comparing options, recommending solutions. If your content isn't in the HTML they receive, you don't exist in their world.

Rendering on the server isn't a minor technical call. It's the difference between participating in the agentic web or being locked out of it.

And with the tools available today — Cloudflare Workers, Vercel Edge Functions, Deno Deploy — the cost of doing it well is literally zero.

There's no excuse for serving an empty div.

---

At Agentikas we build infrastructure for the agentic web. Our blog is open source and you can see exactly how we implement edge SSR in github.com/agentikas/agentikas-blog.