Alternativas a WordPress para la era de la IA

No salí a buscar una alternativa a WordPress. Salí a buscar la forma de dejar de pagar por copiar y pegar.

Publicar una página de campaña en tres idiomas, en un WordPress normal, es más o menos esto: duplicar la página, pegar el texto, traducirlo a mano o pasarlo por un plugin, rehacer los campos SEO de cada idioma, comprobar que el selector apunta al hermano correcto, actualizar lo que pida actualizarse y confiar en que nada se haya movido. Luego alguien cambia una frase en el original y vuelta a empezar.

Así que haces lo que haría cualquier equipo sensato en 2026: apuntas una IA al problema. Y ahí es donde deja de tener gracia.

No puedes automatizar un sistema que esconde tu contenido dentro del markup

Pídele a una IA que actualice doscientas fichas de producto en un WordPress con maquetador y mira con qué se encuentra: divs anidados con nombres de clase generados, shortcodes cuyo significado vive dentro de un plugin y la mitad del contenido serializada en campos de base de datos como arrays. No hay estructura sobre la que razonar. Hay decoración envolviendo texto.

Así que el modelo hace lo único que puede. Busca patrones, edita a ciegas y produce algo que parece plausible en un diff. Te enteras en la página cinco de que la maquetación ha desaparecido, o en la cuarenta de que un shortcode se renderiza como texto literal en una página que convertía perfectamente.

Lo que me sorprende es la constancia con la que esto se diagnostica como un problema de la IA. No lo es. La misma petición sobre contenido con esquema de verdad —título, cuerpo, meta, idioma, cada uno con su tipo— es de lo más aburrida. El modelo rellena campos. Lo que esté mal formado falla la validación antes de llegar a un visitante. La diferencia no es la calidad del modelo: es si tu CMS guarda contenido o guarda markup.

WordPress en 2026 es más o menos el mismo software que era en 2022. Lo que ha cambiado es lo que queremos hacer con nuestras webs, y lo poco de eso que sobrevive a un maquetador.

El mercado lo ha notado. WordPress pasó de en torno al 43,2% de todas las webs a finales de 2025 al 41,2% aproximado de mediados de 2026 según el seguimiento de W3Techs — poca cosa en porcentaje, pero es el primer descenso sostenido tras quince años subiendo. Nadie está abandonando WordPress. Hay gente que simplemente ha dejado de elegirlo.

Tu tráfico de IA no puede ver una página que le hace esperar

Esta es la parte que me cambió el cálculo.

La investigación de Vercel sobre crawlers, basada en tráfico real de bots de IA, concluyó que ninguno de los grandes crawlers de IA renderiza JavaScript. GPTBot descargó ficheros JavaScript en torno al 11,5% de las peticiones y no los ejecutó nunca. ClaudeBot los descargó en torno al 24% y tampoco los ejecutó. A mediados de 2026 esto sigue siendo cierto para GPTBot, OAI-SearchBot, ClaudeBot, PerplexityBot y Bytespider. La excepción relevante es Gemini de Google, porque se apoya en la infraestructura de renderizado de Googlebot.

Vuelve a leerlo pensando en tu web. Cada tabla de precios, bloque comparativo, acordeón de FAQ o ficha técnica que solo existe después de que se ejecute un script es invisible para los sistemas a los que tus compradores piden hoy recomendaciones. No es que posiciones mal en las respuestas de IA. Es que no estás.

WordPress no es automáticamente culpable: un theme sencillo renderiza HTML en servidor perfectamente. Pero la web WordPress de empresa típica no es sencilla. Es un maquetador escupiendo divs anidados, seis plugins inyectando sus propios scripts, una herramienta de consentimiento, un widget de chat y un hero que se monta después de cargar. Esa página es legible para un navegador y medio legible para un crawler con presupuesto de tiempo.

Si quieres la mecánica completa para que tu contenido sea legible por máquinas, lo contamos aparte en llms.txt: revolucione su SEO en la era de la IA.

Qué cambió de verdad en 2025-2026

Cloudflare compró Astro (enero de 2026)

El 16 de enero de 2026, Cloudflare anunció la adquisición de The Astro Technology Company, con todo el equipo incorporándose y el framework manteniéndose open source. Astro es el framework detrás de webs de Unilever, Visa o NBC News.

Estratégicamente es de una limpieza poco habitual: el framework que produce HTML estático y la red que lo sirve desde más de 300 ciudades pasan a ser la misma organización. Si esperabas una señal de que esta forma de construir webs de contenido es una apuesta duradera y no una moda de desarrolladores, era esa.

Las vulnerabilidades de plugins crecieron un 42% en un año

El informe State of WordPress Security in 2026 de Patchstack contabilizó 11.334 vulnerabilidades nuevas divulgadas en el ecosistema WordPress durante 2025, un 42% más que el año anterior. El 91% estaban en plugins y el 9% en themes. El core no es el problema, y en realidad nunca lo fue.

La matemática incómoda: cada plugin es una suscripción permanente a la disciplina de seguridad de otra persona.

Las respuestas de IA se convirtieron en canal de captación

Durante 2025 y lo que va de 2026, “¿cómo se compara esto con X?” dejó de ser una búsqueda en Google y pasó a ser una conversación. Eso movió el requisito técnico de posicionar en una página a ser interpretable, citable y lo bastante rápido como para entrar en una respuesta generada en menos de dos segundos.

Las cuatro opciones honestas

No todo el mundo debería migrar. Esta es la comparativa que me habría gustado que alguien me diera.

Opción	Ideal para	Coste real	Ojo con
Astro + Cloudflare Pages	Webs de contenido, documentación, marketing multiidioma	Tiempo de ingeniería al principio; casi cero después	Tus editores pierden wp-admin salvo que añadas un CMS
Next.js + Vercel	Webs que en realidad son apps: paneles, personalización, login	Más complejidad y coste de runtime	Es fácil acabar enviando mucho más JavaScript del necesario
WordPress headless	Equipos que deben conservar wp-admin por motivos editoriales	Sigues manteniendo y parcheando WordPress	Conservas el mantenimiento y encima añades un pipeline de build
Quedarte en WordPress, endurecido	Webs pequeñas, ingresos por WooCommerce, equipos de una persona	Gasto continuo en plugins y hosting	Lo manual sigue siendo manual; automatizar sigue siendo arriesgado

Esa última fila es una recomendación de verdad. Si WooCommerce es tu checkout, o tu web son treinta páginas y una persona editando, migrar es una respuesta cara a una pregunta que no tienes. La economía cambia cuando hay cientos de páginas, más de un idioma y un equipo que publica cada semana.

Para una web de contenido gana Astro sobre Cloudflare Pages, y no por poco

Entré en esta comparativa esperando un empate entre Astro y Next.js. No lo hay, y por dos motivos que no tienen nada que ver con el gusto.

Astro no envía nada de JavaScript por defecto. No “menos”: nada, salvo que un componente necesite de verdad ser interactivo, y entonces solo se envía ese. Una página de Next.js parte de una base de React de unos 70-100 kB antes de que escribas una línea de código propio. En una web de contenido —artículos, landings, documentación— estás pagando ese peaje en cada página por una interactividad que no usas. Astro además trae la optimización de imágenes incorporada y escribe el ancho y el alto en cada imagen al construir, que es la causa número uno de que una página baile mientras carga.

Cloudflare Pages no te pone contador. Aquí es donde la comparación se pone incómoda para las alternativas. Vercel y Netlify limitan su plan gratuito a 100 GB de tráfico y cobran —a veces con dureza— a partir de ahí. Cloudflare Pages no factura el tráfico de los archivos estáticos, que en una web de mil y pico artículos no es un detalle. Con las redirecciones pasa lo mismo: Vercel admite unas 1.024 reglas en su configuración, Netlify ronda las 2.000 y Cloudflare Pages 2.100 en un fichero equivalente — y si te pasas, Cloudflare Bulk Redirects acepta hasta 100.000 a nivel de red sin tocar tu web. Si migras mil URLs, quieres ese techo lejos y no rondándolo.

Súmale la compra de enero de 2026 y el argumento se cierra: la empresa que ahora tiene en plantilla a quienes construyen Astro es la misma que reparte tus páginas, con su cortafuegos y su protección contra ataques ya puestos delante.

Por lo que valga: esta web —cada landing, cada post, cinco idiomas— es Astro sobre Cloudflare Pages. No elegimos el stack para trabajos de cliente y dejamos nuestra propia web en un sitio más indulgente. Esa es toda la prueba que ofrezco. Coge el argumento por lo que vale, no por nuestras cifras.

Las dos decisiones que todo el mundo aplaza, y las dos salen caras

Las migraciones se venden con velocidad y posiciones. Las dos cosas que de verdad determinan si la web nueva será mejor dentro de tres años casi no aparecen en la conversación comercial.

La primera es la indexación. Pregúntale a tu equipo qué URLs de la web actual puede indexar Google. En la mayoría de WordPress nadie sabe responder, porque la respuesta está repartida entre un plugin SEO, el robots.txt, los ajustes de archivos y lo que decidiera el theme sobre las páginas de etiqueta y autor. Así que las webs publican en silencio miles de URLs paginadas, filtradas y casi duplicadas, y el crawl budget se va a páginas que nadie quería posicionar. Una migración es el único momento en que puedes dejar eso explícito: una decisión por plantilla, escrita en el código, donde cambiarla es un cambio revisado y no un interruptor que alguien mueve a las seis de la tarde. Hazlo durante el movimiento o heredarás la misma niebla sobre un stack más rápido.

La segunda es el idioma. Multiidioma en WordPress significa un plugin que convierte cada página en un duplicado que alguien tiene que mantener sincronizado, que es justo por lo que las agencias lo cobran como recargo y tratan un tercer idioma como una complicación. Bien modelado, cada idioma es una ruta con su propio fichero de contenido, el hreflang se genera del propio contenido y una traducción que falta aparece cuando la web se construye, no cuando la encuentra un cliente. Esa inversión —de “las traducciones se separan en silencio” a “las traducciones fallan en voz alta”— vale más en tres años que cualquier puntuación de Lighthouse.

Y lo tercero, que es lo que la gente sí recuerda pero demasiado tarde: conserva las URLs. Todas. El mapa de redirecciones no es papeleo de la migración, es la migración. Constrúyelo la primera semana con tu inventario real de Search Console, no con una suposición sobre lo que contiene el sitemap.

Tres cosas que se rompen cuando desaparece la base de datos

Nadie te vende una migración enumerando lo que deja de funcionar, así que aquí está la lista. Las tres tienen solución, y las tres salen más baratas resueltas a propósito que a la carrera la semana después de lanzar.

El buscador. La búsqueda de WordPress es una consulta a la base de datos. Quita la base de datos y no hay a qué preguntar. La solución es un índice de búsqueda estático — Pagefind es la herramienta en la que acaba la mayoría de webs Astro: lee tu web ya construida después de cada compilación, escribe un índice compacto al lado y el navegador se descarga solo los fragmentos que coinciden con lo que alguien ha escrito. Va lo bastante rápido como para que los resultados aparezcan mientras escribes, y no cuesta nada mantenerlo porque no hay servidor de por medio.

Los formularios. Sin PHP no hay función de envío de correo, así que tu formulario de contacto necesita a dónde ir. En Cloudflare eso es una función pequeña en su red: recibe el formulario, filtra el spam con Turnstile —que, a diferencia de un CAPTCHA, normalmente no le pide nada al visitante— y entrega el mensaje a un servicio de correo como Resend o SendGrid. O te saltas todo eso y apuntas el formulario a HubSpot, que es lo que la mayoría de equipos de marketing ya tiene.

Los soft 404 y los bucles de redirección. Esta es la que cuesta tráfico en silencio. Si alguien pide una página que no existe, la web tiene que responder con un 404 de verdad y no redirigir educadamente a la portada con un código de éxito — Google interpreta ese segundo comportamiento como un “soft 404” y degrada cómo rastrea todo el dominio. En las webs multiidioma es peor: fuerza HTTPS, añade la barra final, añade el prefijo de idioma y ya has encadenado tres redirecciones para una sola visita. Todo eso debe resolverse en un único salto, decidido una vez. Es aburrido de hacer bien y caro de hacer mal.

Hacia dónde va esto

Lo interesante no es que WordPress pierda dos puntos porcentuales. Es que los requisitos de una web de empresa cambiaron por debajo de todos a la vez: legible por máquinas por defecto, rápida como para entrar en una respuesta generada, y lo bastante barata de cambiar como para que tu equipo deje de tratar la web como un proyecto trimestral.

Algunos equipos llegarán ahí con WordPress, con disciplina y una lista de plugins muy corta. Más equipos decidirán que la forma más simple de no tener nada que parchear es no tener nada ejecutándose.

Preguntas frecuentes

¿Está muriendo WordPress en 2026?

No. Sigue moviendo cerca del 41% de todas las webs y en torno al 59% de los sitios con un CMS conocido. Lo que ha cambiado es la dirección: tras quince años creciendo, lleva perdiendo uno o dos puntos al año. Para la mayor parte del mundo WordPress sigue siendo la opción por defecto. Los equipos que se van suelen ser los que publican en volumen, en varios idiomas y con soporte de ingeniería disponible.

¿Qué es exactamente una web “ai-native”?

Una web cuyo contenido es legible por máquinas sin necesidad de navegador. En la práctica: HTML renderizado en servidor con semántica limpia, contenido que no depende de JavaScript para aparecer, un fichero llms.txt que describe tu sitio a los modelos de lenguaje y, a menudo, una versión en Markdown de cada artículo. Más que una categoría de producto es un conjunto de propiedades — y una web estática consigue casi todas de serie.

¿Podemos dejar que una IA escriba directamente en la web?

Con seguridad, sí — pero solo cuando el contenido tiene esquema. Si cada tipo de contenido declara sus campos y sus tipos, un agente puede generar o actualizar entradas y lo que esté mal formado falla la validación antes de llegar a un visitante, con el cambio llegando como un diff que alguien aprueba. Ejecutar esa misma automatización contra un WordPress con maquetador implica editar markup generado y campos serializados en base de datos, que es como los equipos acaban restaurando copias de seguridad en vez de ahorrando tiempo.

¿Cómo se mantiene el control de lo que se indexa?

Decidiéndolo por plantilla, en el código, antes de que la web salga. Archivos de etiqueta, archivos de autor, series paginadas y vistas filtradas reciben cada uno una respuesta explícita —indexar, redirigir o retirar— y sitemaps, canonicals y reglas de robots se generan en el build en vez de editarse a mano. La prueba práctica es si alguien de tu equipo puede decir hoy qué patrones de URL son indexables sin abrir la pantalla de ajustes de un plugin.

¿Puedo conservar WooCommerce si me paso a Astro?

Dentro de Astro no, y es el descarte más claro de toda la decisión. Una tienda transaccional pertenece a Shopify o a un backend de comercio headless, con Astro como front si lo quieres. Si WooCommerce es donde aterrizan tus ingresos, migra la web de contenido de alrededor y deja el checkout en paz.

¿Cómo publicará nuestro equipo de marketing sin wp-admin?

Dos caminos viables. Ficheros Markdown en git con un editor visual encima, que encaja con equipos algo técnicos y no cuesta nada. O un CMS headless — Sanity, Contentful, Decap, Keystatic — que da a los editores una interfaz familiar y se conecta al mismo build. Publicar dispara una reconstrucción; en nuestra web eso tarda menos de un minuto para el sitio entero.

¿Qué pasa con nuestros plugins?

Cada uno se mapea a su sustituto antes de empezar, o se señala. Los formularios pasan a HubSpot o a un endpoint serverless. Los metadatos SEO se convierten en frontmatter tipado que rompe el build cuando está mal. La caché y el CDN son la propia plataforma de hosting. Los plugins de seguridad dejan de hacer falta porque no hay runtime que atacar. Lo que no tenga equivalente debe salir en la auditoría, no en la semana tres.

¿Astro sirve para una web de miles de páginas?

Es justo donde se gana el sueldo — esta web corre encima, en cinco idiomas y con varios miles de páginas. Las content collections te dan contenido tipado y validado, así que una fecha mal escrita o un alt que falta rompe el build en vez de publicar una página rota en producción. Cuanto más grande el catálogo, más importa: nadie revisa a mano la página 1.800.

Ya hemos invertido mucho en un maquetador. ¿Cambia eso las cuentas?

Encarece la migración, porque la salida del maquetador hay que reconstruirla como componentes, no exportarla. También encarece quedarse, porque ese markup suele ser lo más pesado de la página y lo menos legible para los crawlers. El coste hundido no es argumento en ninguna dirección: compara los próximos tres años de ambas opciones, no los tres anteriores.

¿A partir de qué tamaño compensa?

A grandes rasgos: más de unos cientos de páginas, o más de un idioma, o un equipo que publica semanalmente y va frenado por el stack actual. Por debajo de eso, endurecer tu WordPress actual suele ser mejor inversión. Lo decimos en auditorías más a menudo de lo que la gente espera.

¿Cuánto dura una migración?

Una web de contenido de unos cientos de páginas suele llevar cuatro semanas de kickoff a cutover. Miles de páginas, varios idiomas o un CMS headless encima lo llevan a seis u ocho. La auditoría de URLs de la primera semana es lo que convierte la estimación en realista en vez de optimista.