GEO técnico · Comparativa de CMS
Qué CMS elegir si quieres que la IA lea tu web
WordPress sigue moviendo casi el 60% de la web con gestor de contenido, pero es de los que peor aprueba Core Web Vitals. Next.js está en el extremo contrario. Repasamos qué es un CMS, cómo se comparan las principales familias y qué dice la evidencia sobre cuál rinde mejor cuando quien te "lee" ya no es solo una persona, sino un rastreador de IA que no ejecuta JavaScript.
Por el equipo de ArribaIA · Actualizado el
Resumen citable
No existe una marca de CMS que sea, por sí sola, "la mejor para GEO". Lo que determina si ChatGPT, Gemini o Perplexity pueden leer tu web es si el contenido llega ya construido en el HTML inicial, con datos estructurados coherentes y fechas claras, porque GPTBot y ClaudeBot descargan JavaScript pero no lo ejecutan casi nunca. Un CMS tradicional como WordPress renderiza en el servidor por defecto, pero arrastra el peor porcentaje de aprobado en Core Web Vitals (45% en móvil, frente al 68% de las webs en Next.js). Un CMS headless no resuelve nada por sí solo: solo aporta si el frontend que lo consume usa renderizado en servidor o estático, como el que construimos con Next.js.
Este resumen condensa la guía en menos de 130 palabras a propósito: es el tipo de fragmento que una IA puede citar sin necesidad de leer el resto de la página.
¿Qué es un CMS?
Un CMS es donde vive el contenido, no cómo se ve
Un CMS (Content Management System, sistema de gestión de contenido) es el software que permite crear, editar, organizar y publicar el contenido de una web sin escribir cada página a mano. Almacena textos, imágenes, metadatos y estructura, y decide (o delega) cómo se convierte todo eso en el HTML que llega a un navegador o a un rastreador.
Esa última parte es la que ha cambiado de peso en los últimos años. Durante mucho tiempo, elegir CMS era sobre todo una decisión de comodidad editorial. Hoy es también una decisión de visibilidad: quien construye el HTML final determina qué puede leer un rastreador que, a diferencia de una persona, no siempre ejecuta JavaScript ni espera a que la página termine de cargar.
Por eso conviene separar dos preguntas que suelen mezclarse: dónde se gestiona el contenido y cómo se entrega. Las cuatro familias siguientes responden a esa pregunta de forma distinta, y esa diferencia es la que explica buena parte de lo que viene después en esta guía, incluida su relación con la autoridad de negocio local y con el AEO.
Gestiona y muestra el contenido en el mismo sistema
WordPress, Joomla o Drupal en su modo clásico. El propio CMS genera el HTML en el servidor (normalmente con PHP) a partir de una base de datos y unas plantillas. Es la familia con más cuota de mercado con diferencia.
Todo en uno, pensado para no tocar código
Wix, Squarespace, GoDaddy Website Builder o Webflow en su uso más habitual. Editor visual, hosting y gestión de contenido en un mismo paquete cerrado, con poco margen para tocar cómo se genera el HTML.
Gestiona el contenido, no lo muestra
Contentful, Sanity, Strapi, Storyblok o Contentstack. Almacenan y organizan el contenido y lo entregan por API (REST o GraphQL), sin una plantilla visual propia. El frontend se construye aparte, con la tecnología que se elija.
El frontend decide cómo y cuándo se renderiza
Next.js, Astro, Nuxt o Remix conectados a un CMS headless (o a un WordPress usado solo como fuente de datos vía su API). El equipo de desarrollo controla si cada página se genera en el momento de la petición (SSR), de antemano (SSG) o de forma incremental (ISR).
El mercado, en cifras
Quién usa qué, hoy
Antes de comparar arquitecturas, conviene ver el punto de partida real: dónde vive hoy la mayoría del contenido de la web y cómo rinde.
| Dato | Cifra | Contexto |
|---|---|---|
| Webs que usan algún CMS | 69,6% | Sobre el total de sitios monitorizados por W3Techs en agosto de 2026. El resto usa desarrollo a medida o no declara un CMS identificable. |
| Cuota de WordPress sobre el total de la web | 41,2% | Equivale a un 59,1% del mercado de CMS conocido: más de la mitad de todas las webs con gestor de contenido usan WordPress. |
| Webs de WordPress que aprueban Core Web Vitals en móvil | 45% | Frente al 85% de Duda o el 74% de Wix, según el capítulo dedicado a CMS del Web Almanac 2025 de HTTP Archive. |
| Webs en Next.js que aprueban Core Web Vitals en móvil | 68% | Frente al 44% de una SPA en React sin renderizado en servidor, según el panel de benchmarks de webvitals.tools (abril de 2026). |
Comparativa
Cuatro familias, cuatro formas de entregar tu contenido
Ninguna familia es objetivamente superior en todos los aspectos. Esto es lo que cambia entre una y otra, con lo que de verdad hay que decidir antes de elegir.
| Aspecto | CMS tradicional | Website builder | CMS headless | Framework + headless |
|---|---|---|---|---|
| Ejemplos | WordPress, Joomla, Drupal | Wix, Squarespace, Webflow | Contentful, Sanity, Strapi, Storyblok | Next.js, Astro, Nuxt + CMS headless |
| ¿El HTML inicial ya trae el contenido? | Sí, se genera en el servidor con PHP en cada visita | Depende: los builders antiguos dependían del navegador, los actuales ya usan renderizado en servidor | No por sí solo: es una API, depende por completo del frontend que la consuma | Sí, si el equipo elige renderizado en servidor o estático en vez de solo en el cliente |
| Quién controla el rendimiento | El hosting, el tema elegido y los plugins instalados | La propia plataforma, con poco margen de ajuste manual | No aplica directamente: el rendimiento lo decide el frontend, no el CMS | El equipo que construye el frontend, con control casi total |
| Curva de aprendizaje | Baja para uso básico, media o alta si hay muchos plugins | Muy baja: pensado para no escribir código | Media o alta: necesita un desarrollador para construir el frontend | Alta: requiere un equipo de desarrollo con experiencia en el framework |
| Coste típico | Licencia baja o nula, coste variable en hosting y plugins | Cuota mensual fija, con todo incluido | Cuota del CMS más el desarrollo y mantenimiento del frontend | Coste de desarrollo más hosting o cuota del CMS headless |
| Mejor para | Blogs, medios y negocios con un equipo de contenido amplio | Negocios pequeños que necesitan una web ya, sin equipo técnico | Marcas que publican el mismo contenido en varios canales (web, app, tienda) | Negocios que priorizan velocidad, control técnico y visibilidad en IA |
Rendimiento
Por qué el renderizado en servidor pesa tanto ahora
El renderizado en servidor (SSR) y el estático (SSG) generan el HTML antes de que el navegador o el rastreador lo pidan. El renderizado en cliente (CSR), típico de una SPA construida con JavaScript sin más, obliga a ejecutar código para poder ver el contenido.
Esto era, hasta hace poco, sobre todo una cuestión de velocidad percibida por las personas. Ha dejado de serlo. Un análisis de tráfico de rastreadores de IA realizado por Vercel y MERJ encontró que ninguno de los grandes rastreadores de IA ejecuta JavaScript de forma habitual: GPTBot descarga archivos JavaScript en el 11,5% de sus peticiones y ClaudeBot en el 23,84%, pero en ningún caso los ejecuta. Si el contenido principal de una página solo aparece después de ejecutar JavaScript en el navegador, ese rastreador simplemente no lo ve.
Google es la excepción parcial: Google-Extended hereda el renderizado completo de Googlebot, así que sí puede ejecutar JavaScript, aunque con más coste y demora que leer HTML ya construido. Ningún otro rastreador de IA relevante ofrece hoy esa misma garantía.
Los datos de Core Web Vitals van en la misma dirección, aunque midan otra cosa (la experiencia real de carga, no la legibilidad para un rastreador). Las arquitecturas que generan HTML estático o renderizado en servidor aprueban con más frecuencia que las que dependen del navegador para construir la página entera.
| Tecnología | CWV aprobado | Fuente |
|---|---|---|
| Astro (estático) | 84% en móvil | webvitals.tools, abril de 2026 |
| Eleventy (estático) | 81% en móvil | webvitals.tools, abril de 2026 |
| SvelteKit (servidor) | 75% en móvil | webvitals.tools, abril de 2026 |
| Next.js (servidor o estático) | 68% en móvil | webvitals.tools, abril de 2026 |
| Nuxt (servidor o estático) | 60% en móvil | webvitals.tools, abril de 2026 |
| React sin renderizado en servidor | 44% en móvil | webvitals.tools, abril de 2026 |
| WordPress | 45% en móvil / 50% en escritorio | Web Almanac 2025 (móvil) y webvitals.tools, noviembre de 2025 (escritorio) |
| Wix | 74% en móvil / 82% en escritorio | Web Almanac 2025 (móvil) y webvitals.tools, noviembre de 2025 (escritorio) |
Esto no demuestra que cambiar de CMS garantice mejores cifras por sí solo: el hosting, el tema, los plugins instalados y la disciplina del equipo pesan tanto como la tecnología base. Un WordPress bien cuidado puede superar a un proyecto en Next.js mal construido. Lo que sí es un patrón consistente en los datos es que las arquitecturas pensadas para generar HTML de antemano parten con ventaja.
La pregunta del millón
¿Cuál es el mejor CMS para GEO?
No hay un ganador universal. Lo que sí hay son cuatro rasgos que, según coinciden la documentación técnica y varios análisis del sector, determinan si un CMS ayuda o estorba: si el HTML inicial ya trae el contenido, si permite datos estructurados coherentes, si expone fechas y autoría de forma clara, y si facilita organizar el contenido en fragmentos que respondan a una pregunta concreta.
CMS tradicional (WordPress bien configurado)
Al renderizar en el servidor por defecto, el contenido suele estar en el HTML inicial sin depender de JavaScript. El riesgo no es que el rastreador no vea el texto, es la acumulación de plugins, temas pesados y datos estructurados mal implementados por complementos que no siempre coinciden con lo que ve una persona.
Website builder (Wix, Squarespace, Webflow)
Los builders modernos ya usan renderizado en servidor para la carga inicial (Wix lo hace desde 2020), así que el problema histórico de contenido invisible para los rastreadores está en gran parte resuelto. Lo que sigue limitado es el control sobre el marcado, los tipos de datos estructurados disponibles y la profundidad de la personalización técnica.
CMS headless en solitario
Un CMS headless no genera HTML: solo entrega datos por API. Su idoneidad para GEO depende por completo del frontend que lo consuma. Un headless conectado a una aplicación que solo renderiza en el cliente puede acabar siendo menos legible para un rastreador de IA que un WordPress estándar.
Framework + headless con SSR o SSG (Next.js + Sanity, Contentful u otro)
Combina modelado de contenido estructurado, entrega por API y control total sobre cuándo y cómo se renderiza cada página. Es, según los datos de rendimiento anteriores, la combinación con más probabilidades de servir HTML completo, rápido y con datos estructurados coherentes. También es la que exige más inversión técnica para hacerlo bien.
Tener el techo técnico más alto no significa automáticamente más visibilidad: una web headless mal implementada puede rendir peor que un WordPress bien cuidado. La arquitectura pone el límite de lo posible; el contenido, la autoridad y la consistencia son los que deciden si una marca llega a ese límite, como explicamos con más detalle en qué es el GEO.
Pros y contras
Lo bueno y lo malo de cada familia, sin adornos
CMS tradicional
- Ecosistema enorme de temas, plugins e integraciones
- Curva de entrada baja para publicar contenido cada día
- Renderiza en servidor por defecto
- Comunidad y documentación muy amplias
- El rendimiento depende mucho del hosting, el tema y los plugins
- Es el objetivo más frecuente de ataques por su cuota de mercado
- Fácil acumular plugins redundantes o mal mantenidos
- Los datos estructurados generados por plugins no siempre coinciden con el contenido visible
Website builder
- Se puede tener una web publicada en horas, sin equipo técnico
- Todo incluido: hosting, certificado, editor visual
- Los builders principales ya usan renderizado en servidor
- Mantenimiento mínimo para el propietario del negocio
- Poco control sobre el marcado HTML y los datos estructurados
- Migrar a otra plataforma más adelante suele ser costoso
- Rendimiento limitado por decisiones de la propia plataforma
- Personalización técnica limitada frente a un desarrollo a medida
CMS headless
- El mismo contenido alimenta web, app y otros canales a la vez
- Modelado de contenido estructurado, pensado como datos y no como páginas
- Libertad total para elegir la tecnología del frontend
- Suele facilitar flujos editoriales avanzados (roles, revisiones, versiones)
- No sirve de nada sin un frontend bien construido detrás
- Coste doble: la plataforma headless más el desarrollo del frontend
- Requiere un equipo técnico permanente, no solo al lanzar la web
- Mayor complejidad de mantenimiento que un CMS todo en uno
Framework + headless (Next.js y similares)
- Mejor rendimiento medio según los datos de Core Web Vitals disponibles
- Control total sobre qué llega en el HTML inicial
- Encaja de forma natural con datos estructurados y contenido en fragmentos
- Escala bien de una landing sencilla a una plataforma compleja
- El coste de desarrollo inicial es mayor que con un CMS tradicional
- Publicar contenido nuevo puede requerir apoyo técnico según cómo esté montado
- Un mal uso del renderizado en cliente anula buena parte de la ventaja
- Menos plugins prefabricados: casi todo se construye a medida
Antes de decidir
Cómo elegir CMS pensando también en IA
- 01Comprobar si el contenido principal aparece en el HTML inicial, sin ejecutar JavaScript (se puede ver desactivándolo en el navegador).
- 02Revisar si el tema o el frontend actual generan datos estructurados coherentes con lo que ve una persona.
- 03Medir Core Web Vitals reales, no solo una captura puntual de PageSpeed.
- 04Confirmar que fechas de publicación y de actualización son visibles y están marcadas correctamente.
- 05Contar cuántos plugins o dependencias de terceros carga cada página, y para qué sirve cada uno.
- 06Valorar quién va a publicar contenido en el día a día, no solo quién lo construye una vez.
- 07Si se plantea migrar, calcular el coste de desarrollo y mantenimiento frente a la ganancia esperada en rendimiento.
- 08No migrar de CMS solo por GEO si la base de SEO técnico todavía tiene errores más urgentes.
- 09Apoyarse en una auditoría de visibilidad en IA antes de decidir, para saber si el problema es la plataforma o el contenido.
- 10Si se construye desde cero, valorar Next.js con renderizado en servidor como punto de partida.
Preguntas frecuentes
Lo que más se pregunta
¿Tengo que migrar de WordPress a Next.js para que ChatGPT me lea?
No necesariamente. WordPress renderiza en el servidor por defecto, así que el contenido suele estar en el HTML inicial. El problema habitual no es la plataforma en sí, es la acumulación de plugins, temas pesados y datos estructurados mal implementados que arrastra muchas instalaciones con años de uso.
Antes de plantear una migración completa, tiene más sentido auditar qué está fallando de verdad: rastreo, velocidad, datos estructurados o simplemente contenido poco útil. Es justo el punto de partida de una auditoría de visibilidad en IA.
¿Un CMS headless mejora el SEO o el GEO de forma automática?
No. Un CMS headless no genera HTML por sí solo, solo entrega contenido por API. Su efecto en SEO o GEO depende por completo de cómo se construya el frontend que lo consume: si ese frontend renderiza en el cliente sin más, puede acabar siendo menos legible para un rastreador de IA que un WordPress estándar.
El beneficio real de un CMS headless aparece cuando se combina con un frontend que use renderizado en servidor o estático, no por el simple hecho de ser headless.
¿Wix o Squarespace son malos para la visibilidad en IA?
Ya no arrastran el problema histórico de depender por completo del navegador: desde 2020, Wix usa renderizado en servidor para la carga inicial, y Squarespace ha seguido una evolución parecida. El contenido principal suele estar accesible para un rastreador que no ejecuta JavaScript.
La limitación real está en el control: estas plataformas dejan poco margen para ajustar datos estructurados avanzados, la arquitectura de la información o el rendimiento más allá de lo que permite el propio editor.
¿Y las tiendas online en Shopify?
Shopify se comporta de forma parecida a un website builder orientado a comercio: buen rendimiento medio (78% de aprobado en Core Web Vitals en escritorio, según webvitals.tools) y renderizado en servidor por defecto en sus temas estándar, pero con margen limitado si se personaliza mucho con apps de terceros, que suelen añadir JavaScript adicional.
¿Compensa migrar de CMS solo por motivos de GEO?
Rara vez, si es el único motivo. Migrar de plataforma tiene un coste real (desarrollo, contenido, redirecciones, curva de aprendizaje del equipo) que solo se justifica si el CMS actual es, de verdad, el cuello de botella. En la mayoría de los casos, el margen de mejora está antes: en el SEO técnico, en los datos estructurados o en cómo está escrito el contenido.
Tiene más sentido migrar cuando se está construyendo una web nueva desde cero, o cuando la plataforma actual impone límites técnicos que ya no se pueden resolver con ajustes.
¿Cómo compruebo si mi web actual es legible para los rastreadores de IA?
Una forma simple y gratuita: desactivar JavaScript en el navegador y recargar la página. Si el contenido principal desaparece o queda en blanco, es muy probable que GPTBot, ClaudeBot o PerplexityBot tampoco lo vean, porque ninguno de los tres ejecuta JavaScript de forma habitual.
Para una revisión más completa (datos estructurados, rastreo, arquitectura), lo hacemos como parte de nuestra auditoría de visibilidad en IA.
¿Los datos estructurados dependen del CMS que use?
En parte. Un CMS headless o un framework como Next.js permiten definir exactamente qué JSON-LD se genera para cada tipo de contenido. En un CMS tradicional o un website builder, los datos estructurados suelen depender de un plugin o de una función integrada, con menos margen para adaptarlos a casos concretos.
En cualquier caso, la regla no cambia según la plataforma: los datos estructurados deben coincidir siempre con el contenido visible en la página. Es el trabajo que hacemos en optimización de contenido para LLMs.
Fuentes
En qué nos apoyamos
Distinguimos siempre entre documentación oficial, informes de datos a gran escala y análisis del sector. Un panel de benchmarks construido por una empresa no es lo mismo que la documentación oficial de una plataforma, y lo señalamos en cada caso.
- Análisis profesional
Usage statistics of content management systems
W3Techs
Panel de estadísticas de uso de tecnologías web actualizado de forma continua, con la cuota de mercado de cada CMS sobre el total de sitios monitorizados y sobre el conjunto de sitios con CMS conocido.
w3techs.com/technologies/overview/content_management - Análisis profesional
CMS | Web Almanac 2025
HTTP Archive
Capítulo dedicado a gestores de contenido del informe anual de HTTP Archive, con datos reales de Core Web Vitals, peso de página y uso de JavaScript por plataforma, agregados a partir de millones de sitios.
almanac.httparchive.org/en/2025/cms - Análisis profesional
Performance Benchmarks Dashboard
webvitals.tools
Panel que cruza datos de Chrome UX Report (CrUX) con detección de tecnología (Wappalyzer) para mostrar el porcentaje de aprobado en Core Web Vitals por framework y por CMS, actualizado mensualmente.
webvitals.tools/benchmarks/ - Análisis profesional
The rise of the AI crawler
Vercel & MERJ
Análisis de tráfico real de rastreadores de IA (GPTBot, ClaudeBot, PerplexityBot y otros) sobre la red de Vercel, incluido el porcentaje de peticiones que descargan JavaScript sin llegar a ejecutarlo.
vercel.com/blog/the-rise-of-the-ai-crawler - Documentación oficial
AI features and your website
Google Search Central
Documentación oficial de Google sobre cómo funcionan AI Overviews y AI Mode, y sobre los requisitos técnicos reales para que una página pueda usarse como fuente.
developers.google.com/search/docs/appearance/ai-features - Documentación oficial
Integrating Next.js and Contentful for your Headless CMS
Vercel
Guía oficial de Vercel (creadora de Next.js) sobre cómo conectar Next.js a un CMS headless, y por qué Next.js no sustituye a un CMS sino que se combina con uno.
vercel.com/kb/guide/integrating-next-js-and-contentful-for-your-headless-cms - Documentación oficial
Headless CMS explained in one minute
Contentful
Explicación de referencia sobre qué es un CMS headless y en qué se diferencia de un CMS tradicional o de uno decoupled.
www.contentful.com/headless-cms/ - Análisis profesional
Tested: Is Wix Good For SEO?
Seobility
Análisis independiente sobre la evolución técnica de Wix, incluido el paso a renderizado en servidor para la carga inicial desde 2020.
www.seobility.net/en/blog/wix-seo/ - Análisis profesional
How to choose the best CMS for LLM SEO
Brightspot
Marco de seis criterios técnicos (modelado estructurado, soporte de Schema.org, entrega por API, modularidad, señales de frescura y gobernanza editorial) para evaluar un CMS de cara a la visibilidad en sistemas de IA. Es contenido publicado por un proveedor de CMS, así que sus rankings de producto se han tratado con la prudencia correspondiente.
www.brightspot.com/cms-resources/cms-selection-guide/best-cms-for-llm-seo
¿Tu CMS actual frena tu visibilidad en IA?
Revisamos si el contenido de tu web llega ya construido al HTML, si tus datos estructurados son coherentes y qué migraría o no según tu caso concreto, sin recomendar un cambio de plataforma porque sí.