La condición técnica de GEO que debe resolverse antes de hablar de citas
Si un dato importante aparece solo después de ejecutar JavaScript, un agente de IA quizá no lo reciba nunca.
Esto incluye capacidades del producto, conclusiones de páginas comparativas, condiciones de precio, respuestas de documentación, información del autor y las pruebas que esperas que una IA cite. Que una persona vea la página completa en Chrome no prueba que un crawler, un extractor de artículos o un agente de navegador haya obtenido el mismo contenido.
Un profesional de SEO comparó el HTML sin procesar con la página renderizada en varias plantillas. En artículos, tutoriales, tiendas, cursos, landing pages y categorías, la mayor parte del contenido visible ya estaba en el HTML; solo una parte menor aparecía tras JavaScript. La lección no es el porcentaje exacto. La pregunta es: ¿la primera respuesta HTML ya contiene la respuesta que quieres que entienda un agente?
En GEO, esta es una comprobación de elegibilidad previa a la cita. El sistema debe recuperar los hechos centrales de la página antes de valorar las pruebas o elegirla como fuente.
Cada ruta de acceso tiene una capacidad distinta para JavaScript. La descarga sin procesar y los extractores de artículos suelen depender únicamente de la respuesta HTML.
Que Google renderice no es una promesa para todos los agentes
Es cierto que Google puede renderizar JavaScript. Pero convertir ese hecho en la suposición de que cada producto de búsqueda con IA y cada agente verá la página final del navegador es arriesgado.
Un mismo URL puede llegar por varios caminos:
| Ruta de acceso | Qué recibe | Dependencia de JavaScript |
|---|---|---|
| Fetch HTTP sin procesar | La respuesta HTML inicial | No ejecuta |
| Reader o extractor de artículo | Texto seleccionado del HTML | Normalmente no ejecuta |
| Automatización de navegador | DOM renderizado | Puede ejecutarlo, sujeto a tiempos y políticas |
| Pipeline de indexación | Fetch, cola y posible renderizado | Depende de la plataforma |
| Agente con herramientas | Salida de la herramienta de web fetch elegida | A menudo cercana al fetch sin procesar |
La capacidad de renderizado de Google no es una garantía trasladable. Otros motores de respuesta, sistemas internos de retrieval, agentes de navegación y herramientas de extracción web pueden obtener solo HTML o terminar antes de que carguen datos lentos del cliente. Basar la arquitectura del sitio en la capacidad de una plataforma es una apuesta innecesaria.
La regla segura es sencilla: los hechos públicos importantes para el descubrimiento y la cita deben poder leerse en la primera respuesta.
Audita dónde aparece el hecho, no el framework que usas
SSR frente a CSR no es una puntuación de GEO. Un sitio en React, Vue o Next.js puede ser apto para agentes; un sitio tradicional renderizado en el servidor también puede esconder hechos importantes detrás de una llamada de API del cliente.
Audita la capa en la que cada bloque importante pasa a estar disponible.
| Capa de contenido | Ejemplo habitual | Riesgo para GEO |
|---|---|---|
| HTML inicial | Título, texto, especificaciones, FAQ, autor y fecha | Bajo |
| HTML obtenido en el servidor | Precio actual o disponibilidad regional | Bajo a medio |
| Request de API en el cliente | Beneficios del producto, tabla comparativa, cuerpo de documentación | Alto |
| Tras interacción del usuario | Pestañas, acordeones, filtros, resultados de scroll infinito | Alto |
| Tras iniciar sesión | Dashboard o base de conocimiento privada | No esperes una cita pública |
Un hecho que esperas que la IA repita en una respuesta pública no debería depender de un clic, de que una request del cliente funcione o de una tarea larga de JavaScript. Conserva la interacción cuando aporte valor, pero adelanta la capa explicativa.
Los fallos habituales incluyen páginas de producto que devuelven solo una carcasa de carga, comparativas cuya tabla aparece tras hydration, documentación cuyo cuerpo se carga mediante routing del cliente, categorías que dependen únicamente de scroll infinito y módulos visuales cuya conclusión existe solo en una imagen o Canvas.
Una página renderizada puede verse muy bien y, aun así, revelar muy poco significado en su primera respuesta HTML.
Comprueba dos estados de la página en vez de adivinar
No preguntes si el sitio usa React. Guarda dos versiones del mismo URL:
- El HTML sin procesar obtenido sin ejecutar JavaScript.
- El texto de
maindespués de abrir la página en un navegador y esperar el contenido principal.
Puedes empezar con un fetch básico:
curl -sL "https://example.com/product" -o raw.html
Compara bloques semánticos, no el header, el banner de Cookie y el footer:
- H1 y respuesta breve
- Primer párrafo explicativo
- Hechos y limitaciones del producto
- Tablas comparativas
- Respuestas de FAQ
- Autor y fecha de actualización
- Enlaces internos y URL canonical
No uses networkidle como única condición de preparación del navegador. Scripts analíticos, widgets de chat y conexiones largas pueden mantener una página ocupada indefinidamente. Es mejor esperar al selector del contenido principal o a la finalización de la fuente específica que entrega los hechos clave.
Esta comparación puede convertirse en una métrica de release:
exposición de contenido central = bloques importantes presentes en HTML sin procesar / bloques importantes requeridos en la página
El objetivo no es meter cada píxel en HTML. Es hacer que las pruebas necesarias para entender la página no dependan de que el runtime del cliente se ejecute correctamente.
Corrige la entrega del contenido antes de reescribir el front end
La mayoría de los equipos no necesita reescribir todo el sitio. Mueve la información pública estable a la primera respuesta y mantén JavaScript para filtros, preferencias guardadas, mapas, animaciones y personalización.
| Situación | Patrón de entrega más adecuado |
|---|---|
| Artículos, tutoriales y glosarios estables | Generación estática o prerender durante el build |
| Precios, stock o detalles regionales que cambian | Renderizado en servidor con caché e invalidación explícita |
| Página interactiva con explicación estable | Renderiza explicación, hechos y FAQ en servidor; hidrata la interacción en cliente |
| Documentación pública en una aplicación grande | Haz prerender de rutas públicas y no dependas de login para la respuesta central |
| Dependencia de varias API internas | Agrupa datos críticos en servidor o en BFF compartido por HTML y aplicación |
JSON-LD ayuda, pero no sustituye contenido de página legible. Los datos estructurados deben describir hechos que visitantes y extractores también puedan encontrar en el documento.
Plan de dos semanas para un equipo de GEO
Días 1-2: enumera las plantillas que afectan al descubrimiento orgánico, las citas de IA, el enablement de ventas o el soporte. Artículos, páginas de producto, documentación, comparativas y categorías suelen bastar.
Días 3-5: toma URLs de muestra de cada plantilla. Guarda HTML sin procesar y contenido renderizado. Marca H1, explicaciones, hechos de producto, FAQ y enlaces internos que falten.
Días 6-9: arregla primero las páginas de mayor valor y contenido estable. Mueve definiciones, hechos, conclusiones de comparativas y FAQ al servidor o a la salida del build.
Días 10-14: repite las mismas pruebas y añade una puerta de release. Una plantilla no debe publicarse si el HTML inicial no contiene H1, respuesta principal, hechos críticos o enlaces canonical.
Esto no garantiza una cita de todos los productos de IA. Pero elimina un fallo evitable: publicar información pública que un agente potencial no puede leer de forma fiable.
La visión de Auspia
Las conversaciones sobre GEO suelen empezar por menciones de marca, calidad de fuente, claridad de entidad y estructura de respuesta. Todo eso presupone que el sistema obtuvo la página primero.
JavaScript no es el problema en sí. El problema es tratar la explicación pública como un efecto secundario del runtime del cliente. Deja que HTML asuma la responsabilidad del contenido y que JavaScript asuma la de la experiencia. Esta división también mejora las pruebas, el SEO técnico y la accesibilidad para agentes.
FAQ
Si Google renderiza JavaScript, ¿sigo necesitando una auditoría de HTML sin procesar?
Sí. La capacidad de Google no significa que otros crawlers, readers y agentes sigan la misma ruta. La comprobación del HTML sin procesar también revela retrasos de renderizado y fallos de requests del cliente.
¿SSR siempre es mejor que CSR para GEO?
No. La generación estática, el renderizado en servidor y el prerender pueden funcionar. Puedes mantener renderizado en cliente para elementos muy interactivos. El criterio es que los hechos esenciales de la página pública se puedan leer en la respuesta HTML inicial.
¿Hay que evitar JavaScript en toda la página?
No. Úsalo para filtros, animación, mapas, ajustes guardados, personalización y experiencias después de login. Prioriza el contenido que explica el tema de la página y aporta hechos citables.
¿llms.txt resuelve el contenido que aparece solo después de JavaScript?
No. Aunque un sistema lea llms.txt, no obtiene automáticamente el artículo completo ni los datos de API del cliente. La propia página pública todavía debe hacer accesible su contenido central.
Nota de fuente
Este artículo se inspira en un post de Adrian Skowron que compara contenido visible en SSR y CSR . El gráfico del post refleja las mediciones de las plantillas del autor, no un benchmark de toda la industria.
Autor: Julian Mercer, profesional de SEO técnico con 14 años de experiencia en Auspia. Julian escribe sobre crawling, renderizado, datos estructurados y la base técnica que permite a la búsqueda y a la IA entender el contenido.
