Por qué tu blog debería renderizar en el servidor si quieres que la IA lo encuentre

Hay una decisión arquitectónica que parece menor pero que define si tu contenido existe o no para los agentes de IA: dónde se renderiza tu web.

La mayoría de desarrolladores eligen client-side rendering (CSR) por inercia. Es más fácil, React lo hace por defecto, y para dashboards y apps interactivas tiene todo el sentido. Pero para un blog — especialmente uno que quiere ser visible en la web agéntica — es la peor decisión que puedes tomar.

Qué ven los agentes de IA cuando visitan tu web

Cuando ChatGPT, Gemini, Perplexity o cualquier agente de IA visita una URL, esto es lo que recibe:

Blog con SSR (Server-Side Rendering):

<article>
  <h1>WebMCP: el protocolo que está cambiando las reglas</h1>
  <p>Un protocolo abierto de Google y Microsoft que permite a los agentes de IA interactuar con cualquier web...</p>
  <script type="application/ld+json">
    {"@type": "BlogPosting", "headline": "WebMCP...", "author": {"@type": "Person"...}}
  </script>
</article>

Blog con CSR (Client-Side Rendering):

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

El agente de IA ve un div vacío. No ejecuta JavaScript. No espera a que React hidrate. No hace el fetch a tu API. Simplemente pasa de largo. Tu artículo no existe para él.

"Pero Googlebot sí ejecuta JavaScript"

Es verdad, parcialmente. Googlebot tiene un renderizado basado en Chromium que ejecuta JS, pero con un delay significativo — puede tardar días o semanas en renderizar tu página. Y cuando lo hace, consume un "presupuesto de renderizado" limitado. Si tu sitio tiene muchas páginas CSR, Google simplemente no las renderiza todas.

Pero el argumento de Googlebot ya no es suficiente. El SEO clásico (Google) está siendo complementado por GEO (Generative Engine Optimization) — la optimización para que tu contenido aparezca en respuestas de agentes de IA. Y los agentes de IA no ejecutan JavaScript. Punto.

La economía del rendering

Hay un argumento que parece razonable a favor de CSR: "si renderizo en el servidor, cada visita tiene un coste computacional. Con CSR, el servidor solo sirve archivos estáticos".

Analicemos los números reales:

Concepto SSR en el edge CSR Coste por request ~0€ (Cloudflare Workers free tier: 100K req/día) ~0€ (archivos estáticos) Query a base de datos 1 por request (servidor) 1 por request (cliente) Bundle enviado al usuario HTML (~20KB) JS bundle (~150-300KB) + HTML vacío Time to First Contentful Paint ~100ms ~800ms-2s (descarga JS + fetch + render) Visible para agentes de IA Sí No

El coste de la query a la base de datos es idéntico — alguien tiene que hacer el fetch. La diferencia es quién: el servidor (que está a 2ms de Supabase) o el navegador del usuario (que está a 200ms y tiene que descargar 150KB de JavaScript primero).

Con Cloudflare Workers, el SSR es prácticamente gratis. El edge más cercano al usuario renderiza la página y la sirve. No hay servidor centralizado que escalar. No hay cold starts relevantes. El coste es menor que servir el bundle de JavaScript que necesitaría la versión CSR.

El stack que funciona

En Agentikas construimos el blog con este stack:

• Next.js con Server Components en el edge
• Cloudflare Workers como runtime (via @cloudflare/next-on-pages)
• Supabase como base de datos (PostgreSQL, queries directas via REST)
• Schema.org embebido en el HTML (BlogPosting, Organization, etc.)
• WebMCP como protocolo de descubrimiento para agentes

Cada página se renderiza en el edge en ~100ms. El HTML incluye todo: contenido, metadatos, structured data, Open Graph. Cuando un agente de IA visita la URL, recibe todo lo que necesita para entender, citar y recomendar el contenido.

No hay bundle de JavaScript para el contenido. No hay loading spinners. No hay "cargando...". El usuario (humano o IA) recibe el contenido inmediatamente.

Cuándo sí tiene sentido CSR

No estamos diciendo que CSR sea malo. Para aplicaciones interactivas — dashboards, editores, herramientas de trabajo — CSR es la elección correcta. Nuestro propio CMS (write.agentikas.ai) usa componentes client-side para la edición en tiempo real, el selector de imágenes, y la generación con IA.

La regla es simple: si el contenido necesita ser descubierto, SSR. Si el contenido necesita ser manipulado, CSR.

Un blog necesita ser descubierto. Un editor necesita ser manipulado. No mezcles los dos.

La web agéntica no espera

Estamos en un momento de transición. Los agentes de IA están empezando a navegar la web de forma autónoma — buscando información, comparando opciones, recomendando soluciones. Si tu contenido no está en el HTML que reciben, no existes en su mundo.

Renderizar en el servidor no es una decisión técnica menor. Es la diferencia entre participar en la web agéntica o quedarse fuera de ella.

Y con las herramientas que existen hoy — Cloudflare Workers, Vercel Edge Functions, Deno Deploy — el coste de hacerlo bien es literalmente cero.

No hay excusa para servir un div vacío.

---

En Agentikas construimos infraestructura para la web agéntica. Nuestro blog es open source y puedes ver exactamente cómo implementamos SSR en el edge en github.com/agentikas/agentikas-blog.