Astro vs WordPress en 2026: Un Desglose Honesto de Costes y Operaciones

Esta es la pregunta que realmente lo decide, y no es «cuál es más rápido». Es: después del lanzamiento, ¿quién actualiza el sitio y con qué frecuencia?

Si la respuesta es «yo, en un editor de texto, unas cuantas veces al mes», Astro gana en casi todos los ejes que le importan a un operador: coste, superficie de ataque y cuántas piezas móviles pueden despertarte. Si la respuesta es «un colega no técnico que espera un panel, una biblioteca de medios y un botón de Publicar», gana WordPress, y fingir lo contrario significa enseñar Git a alguien contra su voluntad.

Aquí hay tres opciones, no dos:

1. Astro como sitio estático - el build produce archivos planos, nada se ejecuta en el servidor.
2. WordPress clásico - PHP más MySQL, wp-admin, ecosistema de plugins, la rutina interminable de actualizaciones.
3. WordPress headless más Astro - los editores conservan wp-admin, los visitantes reciben páginas estáticas generadas en el despliegue.

La mayoría de las comparaciones ignoran la tercera, que suele ser la respuesta honesta cuando necesitas a la vez una GUI para el editor y un hosting barato y rápido.

Dos cifras anclan todo lo que sigue. WordPress todavía impulsa el 40.7% de todos los sitios web y el 58.9% de los sitios con un CMS conocido (W3Techs, septiembre de 2026), así que esto no es un artículo de «WordPress ha muerto». Pero su cuota lleva seis meses consecutivos cayendo desde su pico de principios de 2025 (Search Engine Journal, 27 de mayo de 2026), el primer declive sostenido registrado. Mientras tanto, Astro 7.3.2 se publicó el 8 de septiembre de 2026, y el proyecto del framework ahora vive dentro de Cloudflare (adquisición anunciada el 16 de enero de 2026) manteniendo la licencia MIT y la gobernanza abierta.

Lo que este artículo no es: un tutorial de migración. Ya publiqué la guía de migración de WordPress a Astro que cubre la exportación, la conversión a Markdown y las redirecciones. Esto es la capa de decisión por encima de ella. Cada cifra de abajo lleva una fuente y una fecha, para que puedas comprobar si sigue vigente cuando lo leas.

El panorama en 2026: qué ha cambiado de verdad

Tres cambios importan, y cada uno tiene fecha.

1. La cuota de mercado de WordPress cambió de dirección. Primero contexto histórico, porque muchos números de «2025» siguen circulando como si fueran actuales: WordPress tocó techo en torno al 43.6% de todos los sitios web a principios de 2025. En diciembre de 2025 estaba en el 43.20%, y el 27 de mayo de 2026 en el 41.90% — seis caídas mensuales consecutivas (Search Engine Journal, 27 de mayo de 2026; The Register, 3 de junio de 2026). En septiembre de 2026, W3Techs lo sitúa en el 40.7% de todos los sitios web, todavía más de siete veces el siguiente CMS (Shopify con 5.3%). La distribución de versiones también dice algo sobre la base instalada: aproximadamente el 68% de los sitios están en la línea 7.x, ~25% en 6.x y cerca del 1.7% todavía en 4.x o anterior.

2. Cloudflare compró The Astro Technology Company. Anunciado el 16 de enero de 2026. El detalle que importa para tu decisión es lo que no cambió: Astro sigue siendo open source bajo licencia MIT con gobernanza abierta, y el código se sigue desplegando en cualquier parte, desde Cloudflare Pages hasta un VPS de 4 €/mes o un repo de GitHub Pages. Cloudflare también adquirió VoidZero (la gente de Vite y Rolldown) el 4 de junio de 2026, una pista clara de hacia dónde va la tooling de build.

3. Astro 7 llegó con un compilador en Rust. Astro 7.0 aterrizó en junio de 2026 con un compilador basado en Rust, Vite 8, Advanced Routing y caché de rutas. Los benchmarks publicados en un MacBook Pro M4 Pro merecen citarse porque explican la presión por actualizar: docs.astro.build (6,313 páginas) pasó de 114.54s a 73.53s, astro.build (308 páginas) de 62.70s a 24.24s, y developers.cloudflare.com (8,431 páginas) de 386.89s a 261.94s. Eso es una aceleración de build del 15-61% según el número de páginas. Si quieres saber por qué importa operacionalmente, el análisis de builds más rápidos en Astro 7 profundiza en ello.

En el lado de WordPress, la línea estable actual es WordPress 7.1 “Mary Lou” (19 de agosto de 2026), tras 7.0 “Armstrong” (20 de mayo de 2026) y 6.9 (2 de diciembre de 2025). Se espera WordPress 7.2 alrededor de diciembre de 2026. Requisitos según wordpress.org: PHP 8.3+ recomendado (7.4 es el mínimo, no lo hagas), MySQL 8.0+ o MariaDB 10.11+.

Cronología de hitos de WordPress y Astro desde principios de 2025 hasta septiembre de 2026

Qué cambia (y qué no) la adquisición de Cloudflare

La objeción obvia merece una respuesta directa: ¿Astro ahora está atado a Cloudflare?

No, no en ningún sentido de licencia ni de gobernanza. Tanto el anuncio de Astro como el de Cloudflare dicen que la portabilidad se preserva, el proyecto mantiene su modelo de gobernanza abierta, y aún puedes desplegar en Netlify, Vercel, Bunny, GitHub Pages o un contenedor nginx autoalojado. Una salvedad: la API de GitHub reporta el campo de licencia como NOASSERTION en lugar de MIT, porque el archivo de licencia no está en el formato exacto que GitHub detecta automáticamente. El texto del anuncio dice MIT. Lee el archivo LICENSE tú mismo si la redacción importa para tu revisión de cumplimiento.

Lo que la adquisición sí cambia es el impulso y la ergonomía. Es menos probable que la financiación sea un problema. La integración con Cloudflare Pages y Workers será el camino más cómodo, y el framework probablemente irá creciendo con funciones que asumen la semántica de Workers. Es la misma forma de lock-in blando que ves con Next.js inclinándose hacia Vercel. Es conveniente, no una trampa, siempre que mantengas tu output portable.

El seguro barato: si mantienes un sitio de contenido, quédate con output: 'static' y agnóstico de adapters. Un build estático no tiene API de runtime de la que depender, así que cambiar de host es un cambio de DNS y una resubida, no una reescritura. Para proyectos paralelos, yo lo plantearía así: alquilaría encantado una caja de Hetzner (ver mi review de Hetzner Cloud) y no pensaría jamás en funciones específicas de plataforma, porque para un blog ninguna me compra nada que no pueda hacer en un contenedor.

Qué es realmente cada uno

Esto es una elección de arquitectura, no una checklist de funciones. Las tres opciones pueden servir el mismo blog con las mismas URLs y el mismo contenido. Lo que difiere es dónde ocurre el renderizado, qué se ejecuta cuando un visitante llega a la página y quién es responsable de mantener esa maquinaria parcheada.

La forma más rápida de verlo: poner las tres lado a lado.

Diagrama comparando tres arquitecturas: Astro estático, WordPress clásico con PHP y MySQL, y WordPress headless alimentando un frontend Astro estático

WordPress: CMS dinámico, GUI de administración, 71.000 plugins

WordPress en 2026 es una aplicación PHP con backend MySQL o MariaDB, una GUI de administración que aproximadamente el 68% de su base instalada ejecuta en la versión mayor actual, y un ecosistema de más de 71.000 plugins gratuitos en el directorio de wordpress.org (algunas capturas cuentan más cerca de 30.000 mantenidos activamente; añadiendo CodeCanyon el total práctico supera los 76.000), más unos 15.000 temas gratuitos y alrededor de 12.900 de pago.

El ecosistema es el producto. Solo WooCommerce funciona en el 29.7% de las tiendas online (unos 4.08 millones de tiendas activas, el 8.1% de todos los sitios web). Elementor, Yoast y Contact Form 7 superan cada uno los 10 millones de instalaciones. Si tu requisito es «probablemente haya un plugin para eso», WordPress es la única respuesta seria en esta comparación.

El trato es que estás operando una aplicación con estado. PHP 8.3+ y MySQL 8.0+/MariaDB 10.11+ son los requisitos a cumplir, y cumplirlos es lo fácil. Si quieres la versión rápida de un sitio WordPress, el stack que realmente la entrega es una capa de caché más una CDN, que es lo que recorre acelerar WordPress con Cloudflare, Varnish y Redis. Fíjate en lo que acabas de leer: tres piezas móviles adicionales para conseguir el rendimiento que el hosting estático tiene por defecto.

Astro: static-first, islas, cero JS por defecto

Astro es un framework static-first. Las páginas son componentes .astro o Markdown/MDX en colecciones de contenido. Las partes interactivas son «islas» que se hidratan individualmente, así que un post con un solo cuadro de búsqueda no tiene que enviar el JavaScript de una app completa. El renderizado en servidor está disponible a través de adapters (@astrojs/node, Cloudflare, Netlify) cuando necesitas rutas dinámicas, pero el output por defecto son archivos.

Los prerrequisitos son refrescantemente pequeños: Node.js v22.12.0 o más reciente, y específicamente no una versión impar. v23 no está soportado. No necesitas base de datos, ni PHP, ni sistema de login.

# scaffold a blog from the official template
npm create astro@latest -- --template blog

# build to dist/ and preview the result locally
npm run build
npm run preview

Los límites honestos, porque son el coste real del trato: no hay comentarios, formularios ni búsqueda del sitio integrados. No hay GUI de biblioteca de medios. Los tiempos de build crecen con el número de páginas, y los builds incrementales seguían siendo experimentales en Astro 7.2. Toda la lógica es tuya, y el framework no va a tapar una decisión que no tomaste. La ventaja es que el destino de despliegue es una carpeta. Despliega un blog Astro gratis cubre el camino de coste cero de principio a fin.

Rendimiento: los números honestos

Todo el mundo dice «Astro rápido, WordPress lento». Ese eslogan es perezoso, y los datos reales son más interesantes, sobre todo porque incluyen evidencia que complica la historia. Aquí están los números de campo, y después el contraejemplo que los hace útiles.

Qué dicen realmente los datos

El HTTP Archive Core Web Vitals Technology Report (dataset de abril de 2026, vía Search Engine Journal, 27 de mayo de 2026) es datos de campo de CrUX más HTTP Archive sobre los 10 millones de sitios principales. Esa metodología importa: son mediciones de usuarios reales en sitios reales, no una prueba de laboratorio sobre una instalación demo limpia.

• Peso mediano de página: Astro 1.65 MB (el más ligero del grupo), Duda 1.87 MB, Drupal 2.39 MB, Joomla 2.65 MB, Wix 2.67 MB, WordPress 2.76 MB, Shopify 3.77 MB.
• Puntuación mediana de auditoría Lighthouse: Astro 68 (la más alta), Wix 62, Duda 54, Drupal 48, Shopify 47, WordPress 44, Joomla 43.
• Porcentaje de sitios que pasan Core Web Vitals: Duda ~85%, Wix ~80%, Shopify ~79%, Astro ~67%, Drupal ~64%, Joomla ~58%, WordPress ~49%.

Dos gráficos: peso de página en MB y porcentaje de sitios que pasan Core Web Vitals

Dos cosas para tener en la cabeza a la vez. Los sitios WordPress son los más pesados y los menos propensos a pasar CWV entre las plataformas principales. Los sitios Astro son los más ligeros y con la mejor mediana de Lighthouse, pero solo pasan CWV en aproximadamente dos tercios de los sitios. Las medias describen poblaciones de sitios, no tu sitio.

Por qué la brecha es menor de lo que crees

La mejor evidencia contra el eslogan es un write-up de migración de mfyz.com (3 de junio de 2025) que comparó una reconstrucción en Astro contra un WordPress fuertemente optimizado con WP Rocket y caché de edge de Cloudflare por delante:

• Puntuación de rendimiento: 99.1 a 99.5 (+0.4)
• Puntuación SEO: 86 a 100 (+14)
• LCP: 0.81s a 0.44s, TTFB: 83.1ms a 68.3ms
• Tamaño de recursos: HTML -72%, JS -60.4%, CSS -90.2%

Lee las puntuaciones, luego lee la salvedad que el propio autor declara: un WordPress bien optimizado puede casi igualar a un sitio estático. La brecha medida sobre un WordPress ya afinado es pequeña. El contraejemplo de Shopify en los datos de HTTP Archive apunta lo mismo desde el otro lado: los sitios Shopify cargan las páginas más pesadas de cualquier plataforma en ese informe y aun así pasan CWV en torno al 79% de los sitios. El peso de página por sí solo no predice Core Web Vitals.

Así que el encuadre útil no es «estático es más rápido». Es: el delta es pequeño cuando WordPress está afinado, y el afinado es lo que tienes que seguir pagando. Cada actualización de plugin, cada cambio de tema, cada edición con page builder invalida la caché y puede volver a mover los números. El rendimiento de un build estático es el mismo después de una edición que antes, porque el output o compiló o no compiló.

Esa diferencia también aparece en la columna de costes. A alguien en una comunidad de WordPress que sigo le presupuestaron $2,000 por arreglar los Core Web Vitals de su sitio, y las puntuaciones volvieron a romperse tras la siguiente edición de contenido. Tómalo como una anécdota, no una estadística, pero describe la forma del problema con precisión: no estás comprando un arreglo, estás comprando un intervalo de servicio.

Si quieres mantener ligero un build de Astro autoalojado, optimización de builds Astro SSG es el compañero práctico de esta sección.

Seguridad: comparando radio de impacto, no eslóganes

«Astro no tiene nada que hackear» es marketing, no un hecho. La pregunta útil es: tras un bug en cada stack, ¿a qué llega un atacante?

Para un sitio Astro estático, la respuesta es archivos estáticos, más lo que la pipeline de build pueda ser engañada para enviar. Para WordPress, es una base de datos, un sistema de autenticación, una API de administración y un ecosistema de plugins donde vive la mayoría de las vulnerabilidades conocidas. Esa es toda la diferencia en una frase.

Diagrama comparando la superficie de ataque: Astro solo expone archivos estáticos mientras WordPress expone base de datos, login de administración, plugins y temas

WordPress: el 91% de las vulnerabilidades están en plugins, 5 horas hasta la explotación

Los números, de los datos de Patchstack de 2025 reportados a lo largo de 2026: el 91% de las vulnerabilidades de WordPress estaban en plugins, el 46% de ellas no tenía parche disponible en el momento de la divulgación, y los plugins premium fueron más explotados que los gratuitos, no menos. Lo que hayas pagado por una licencia no te compró una auditoría de seguridad.

El timing es la parte que debería cambiar tu proceso. El tiempo mediano desde la divulgación pública hasta la explotación masiva ronda las 5 horas (swif.ai, 4 de agosto de 2026). Las actualizaciones semanales de plugins son estructuralmente demasiado lentas para esa ventana. No importa lo disciplinado que seas con tu ritual de parches del domingo.

Las defensas de la capa de hosting son más finas de lo que se asume. Los pentests de Patchstack encontraron que las configuraciones comunes de WAF y CDN bloqueaban solo el 26% de los intentos de explotación en general, y el 12% de los ataques específicos de WordPress. Una CDN delante de un plugin vulnerable no es un control, es un badén.

El RCE del núcleo que cambió la conversación

El consuelo estándar es «el núcleo está bien, solo los plugins son arriesgados». Eso ya era una simplificación excesiva, y en julio de 2026 dejó de ser cierto.

wp2shell, CVE-2026-63030, fue un fallo de ejecución remota de código pre-autenticación en el núcleo de WordPress, que combinaba una confusión de rutas batch de REST con inyección SQL. Afectó a 6.9.0 hasta 6.9.4 y 7.0.0 hasta 7.0.1, y se parcheó en 6.9.5 y 7.0.2 el 17 de julio de 2026, distribuido mediante auto-actualizaciones forzadas (reportado por Wiz, 22 de julio de 2026; Wordfence, 29 de julio de 2026; SOCRadar, 20 de julio de 2026).

Crédito donde corresponde: el arreglo llegó rápido, y el mecanismo de auto-actualización forzada hizo lo correcto. La lección no es «WordPress está roto». La lección es que «el núcleo es seguro» es un argumento de venta, no una garantía, y que deberías verificar tu versión en lugar de asumir.

La superficie menor de Astro, y sus riesgos reales

El hosting estático no tiene base de datos que exfiltrar, ni login que atacar por fuerza bruta, ni PHP en el que inyectar. Eso reduce genuinamente el radio de impacto, y es el argumento de seguridad más fuerte a favor de lo estático.

Pero la superficie se desplaza en lugar de desaparecer, y vale la pena nombrar los tres lugares a los que se mueve. Primero, la cadena de suministro npm: una dependencia de build comprometida se envía directamente a tu output de producción, y nunca verás un log de runtime de ello. Segundo, las credenciales de CI y despliegue: tu token de GitHub o tu clave de API de Cloudflare tiene acceso de escritura al sitio en producción. Tercero, tu propio código de aplicación, si vas a SSR y empiezas a manejar sesiones, cookies o entrada de usuario.

Un sitio estático no es seguro por arquitectura. Es seguro porque hay menos código, y el código que queda es código que escribiste o revisaste. Mantén las actualizaciones de dependencias automáticas, los tokens con alcance limitado y el camino de despliegue auditable.

Coste total de propiedad para un operador en solitario

Esto suele ser por lo que la gente lee estos artículos. La mayoría de las comparaciones se detienen en la línea de hosting, que es la parte más pequeña del número. El total real incluye plugins, herramientas de seguridad, incidentes de limpieza y las horas que pasas manteniendo la cosa.

La realidad mensual

El hosting de WordPress, según lo lista la industria: compartido $5-15/mes, gestionado $20-50/mes, gestionado premium $50-200+/mes (1123interactive, 22 de enero de 2026). El WordPress gestionado en una plataforma como Cloudways se sitúa en esa banda media y elimina parte del trabajo de servidor, que es exactamente por lo que pagas el premium.

El hosting estático de Astro es $0 en Cloudflare Pages, Netlify, Vercel o GitHub Pages. Un VPS donde controlas todo cuesta unos 4 €/mes en hardware clase Hetzner, o $4-20/mes si autoalojas WordPress en su lugar (y entonces también te pertenecen los backups de MySQL, las actualizaciones de PHP y el firewall).

Aquí está la comparación completa, incluidas las líneas que nadie pone en una página de precios.

Para las filas de VPS, los hosts que realmente mantengo en mi lista corta: Hetzner Cloud desde unos 4 €/mes como referencia de caja EU barata, o Hostinger KVM VPS si quieres NVMe en un plan económico. Si necesitas presencia en una región concreta, Vultr y DigitalOcean Droplets son los otros dos que consideraría. Si comparas planes en lugar de proveedores, planes cost-optimizados de Hetzner y DigitalOcean vs Vultr vs Hetzner entran en detalle, y opciones de cloud hosting PHP cubre el lado de WordPress específicamente.

Los precios de VPS saltaron en 2026 — si estás reconsiderando una caja alquilada, mira qué cambió y cuándo gana un mini PC.

Gráfico de barras del coste anual total de WordPress gestionado, WordPress autoalojado, Astro estático y Astro SSR

Los costes ocultos que nadie presupuesta

La factura de hosting no es el número interesante. Estos sí:

• Plugins y temas: $300-800/año. Las licencias premium de plugins se renuevan anualmente y se apilan rápido cuando añades un plugin de formularios, uno de SEO, uno de caché y un page builder.
• Plugins de seguridad: $100-300/año. Estás pagando una suscripción para detectar una clase de problema que el hosting estático no tiene.
• Limpieza de malware: $200-500 por incidente. Por incidente. Si el sitio se limpia y se reinfecta a través del mismo plugin abandonado, pagas dos veces.
• Mantenimiento: 2-5 h/mes, o $100-300/mes si lo externalizas. Es el coste honesto de la rutina, y la línea que la mayoría de las comparaciones omite por completo.
• Todo incluido para un propietario típico: $1,500-4,000/año.

Compáralo con un sitio Astro estático: el dominio cuesta unos $10-15/año, más almacenamiento CDN y ancho de banda opcionales. La parte cara nunca fue la licencia. Fue el mantenimiento.

Sobre la capa de caché: un build de Astro estático ya es cache-friendly, pero si pones por delante mucho tráfico de imágenes o assets, Bunny.net es ancho de banda de edge barato y funciona para cualquiera de los dos caminos, incluido delante de un WordPress optimizado.

La salvedad del «tier gratis es gratis»

El hosting estático gratuito es genuinamente de nivel de producción. No voy a fingir lo contrario. Pero los tiers «gratis» se miden en dos ejes que deberías comprobar antes de comprometerte: minutos de build y ancho de banda.

Eso importa para un patrón concreto. Un sitio de contenido con un CMS headless que dispara un rebuild con cada post publicado puede quemar minutos de build rápido, y un sitio con imágenes o vídeo pesados puede quemar ancho de banda. Cuando alcanzas cualquiera de los dos techos, la actualización suele ser un plan de pago o un VPS pequeño.

La heurística que yo usaría: un blog personal con una cadencia de publicación estable cabe cómodamente en un tier gratis. Un sitio de marketing de alto tráfico con rebuilds frecuentes, o un equipo publicando docenas de posts a la semana, se sirve mejor con un VPS de 4-6 €/mes ejecutando nginx, donde los límites son tuyos en lugar de alquilados.

Mide tu volumen de build antes de comprometerte. Comprueba los topes actuales de minutos de build y ancho de banda en la plataforma que elijas, porque esos números se mueven.

Carga operativa: ¿quién mantiene esto a las 2 AM?

Esta es la sección que decide la mayoría de los casos reales. Dos trabajos muy diferentes: una rutina de actualizaciones donde el sitio sigue arriba pero la superficie no deja de cambiar, frente a una pipeline de build donde el sitio es estático pero el toolchain se mueve.

La rutina de actualizaciones de WordPress

Una cadencia realista para un sitio WordPress autoalojado:

• Semanal: comprobar actualizaciones de plugins y núcleo, leer avisos, parchear cualquier cosa con un exploit activo.
• Mensual: aplicar actualizaciones de núcleo y plugins con una copia de seguridad previa, luego verificar que el sitio renderiza.
• Trimestral: auditar la lista de plugins, eliminar lo que no se use, confirmar que una copia de seguridad restaura de verdad.
• Anual: una actualización de versión mayor que romperá algo, normalmente un page builder o un plugin que no se ha mantenido al día.

Además hay riesgo estacional. Monarx observó que las subidas maliciosas a sitios WordPress casi se triplicaron entre noviembre y diciembre de 2025, lo que encaja con el patrón de temporada de fiestas que todo el mundo en hosting ve. El cuarto trimestre no es el mes para saltarse ciclos de parches.

El problema que se acumula es el lock-in del page builder. Elementor y Divi guardan el layout como markup propio dentro del contenido del post, así que «simplemente cambia el tema» se convierte en una reconstrucción completa, y caché más un page builder significa que los Core Web Vitals pueden retroceder en cada edición de contenido. No estás manteniendo un sitio web. Estás manteniendo un sitio web más un motor de layout más un stack de caché, y cada uno puede invalidar a los otros.

Pon ese calendario frente al de Astro y la asimetría es obvia. Si autoalojas WordPress en Docker y quieres parte de esto automatizado, Tugtainer para auto-actualizaciones de Docker gestiona las actualizaciones de imágenes de contenedor, que cubre la capa base pero no la capa de plugins dentro del volumen.

La pipeline de build de Astro

Lo que realmente mantienes con Astro estático: la versión de Node, el árbol de dependencias, el build en CI y el destino de despliegue. Eso es todo. En la práctica esto son casi cero horas en un mes normal.

El trabajo recurrente son las actualizaciones, y hay una trampa que conviene conocer antes de pisarla. El compilador Rust de Astro 7 es estricto. Ya no corrige silenciosamente HTML mal formado, así que las etiquetas sin cerrar ahora producen un error de build donde las versiones antiguas adivinaban tu intención. Es un buen cambio, y significa que una migración desde un proyecto Astro antiguo o una plantilla copiada puede fallar ruidosamente en markup que antes renderizaba bien.

El segundo cambio es más sutil. Los elementos inline consecutivos ya no reciben espacio en blanco implícito:

<!-- renders "HelloWorld" in Astro 7 -->
<span>Hello</span>
<span>World</span>

<!-- explicit space, renders "Hello World" -->
<span>Hello</span>{' '}
<span>World</span>

Ambas son fricción de migración, no fragilidad. Tu build te dice qué se rompió, en tiempo de build, que es exactamente la propiedad que quieres.

Lo que pierdes al salir de WordPress

En claro: pierdes comentarios (Giscus o Hyvor, ambos JavaScript de terceros), formularios (un servicio de formularios externo o una función serverless), búsqueda del sitio (Pagefind o un índice externo) y la GUI de biblioteca de medios. También pierdes «hay un plugin para eso». Cada función se convierte en una decisión, una implementación y una cosa más que mantener.

Para la pieza que más falta hace, añadir un formulario de contacto a sitios estáticos cubre las opciones, con una versión específica de Astro en añadir un formulario de contacto en Astro. Si mantienes el lado de WordPress autoalojado, instalar WordPress con Docker es el punto de partida.

Si la respuesta a «quién publica después del lanzamiento» es un no-desarrollador, esa lista es la factura real. No el coste de hosting: la formación y la tooling.

El híbrido: WordPress headless más Astro

Aquí está el medio pragmático, y es la configuración que más a menudo recomiendo cuando alguien genuinamente necesita a la vez una GUI de editor y páginas estáticas rápidas. Los editores conservan wp-admin tal cual. Astro obtiene el contenido de WordPress en tiempo de build y envía archivos estáticos. Los visitantes nunca tocan PHP.

El trato es honesto y conviene decirlo desde el principio: ahora ejecutas dos sistemas, y uno de ellos es una dependencia en tiempo de build. No has eliminado WordPress de tu vida. Lo has eliminado del camino de peticiones del visitante, lo que reduce el radio de impacto pero no lo elimina. Si comprometen WordPress, el atacante se lleva tu base de datos de contenido.

¿REST o WPGraphQL?

Dos formas de traer el contenido.

La API REST de WordPress viene integrada. Sin plugins extra, endpoints en /wp-json/wp/v2/, y vale para un blog: obtener posts, renderizarlos, listo.

WPGraphQL (o Gato GraphQL) te da una consulta tipada que devuelve exactamente los campos que necesitas, lo que importa cuando las plantillas empiezan a componer múltiples tipos de contenido y estás cansado de adivinar las formas de _embedded.

// src/pages/blog/index.astro
const API = "https://cms.example.com/wp-json/wp/v2/posts";

const res = await fetch(
  `${API}?_embed&_fields=id,slug,title,excerpt,date,_embedded`
);
if (!res.ok) throw new Error(`WordPress API returned ${res.status}`);

const posts = await res.json();

// rendering the featured image from the embedded payload
const img = post._embedded?.["wp:featuredmedia"]?.[0]?.media_details?.sizes?.medium?.source_url;

query LatestPosts($first: Int!) {
  posts(first: $first, where: { status: PUBLISH }) {
    nodes {
      slug
      title
      date
      excerpt
      featuredImage {
        node {
          sourceUrl
          altText
        }
      }
    }
  }
}

const res = await fetch("https://cms.example.com/graphql", {
  method: "POST",
  headers: { "Content-Type": "application/json" },
  body: JSON.stringify({ query, variables: { first: 10 } }),
});
const { data, errors } = await res.json();
if (errors) throw new Error(JSON.stringify(errors));

La regla general: REST para un blog sencillo, GraphQL cuando compones páginas complejas o varios tipos de post en una plantilla. Ambas requieren que el sitio WordPress sea alcanzable en tiempo de build, lo que nos lleva a la trampa.

La trampa de la dependencia en tiempo de build

Esta es la trampa más grande del setup híbrido. Si la API de WordPress no es alcanzable cuando corre tu build, tu despliegue o falla o envía contenido obsoleto. Tu CMS se ha convertido en una dependencia de build con las mismas expectativas de disponibilidad que un servicio de producción.

Cuatro mitigaciones que funcionan de verdad:

1. Trata el uptime de la API como crítico para producción. Si cae durante tu ventana de build nocturno, no hay despliegue.
2. Cachea la última respuesta buena. Escribe la respuesta de la API a disco o a object storage durante el build, y úsala como fallback cuando la llamada falle. El build tiene éxito con contenido ligeramente obsoleto en lugar de no tener éxito en absoluto.
3. Añade un fallback para los medios destacados. Los datos _embedded que falten deberían degradar a un placeholder, no lanzar error.
4. Prefiere rebuilds programados a builds de un solo post bajo demanda. Un rebuild nocturno es un dominio de fallo. Un webhook por publicación convierte cada nuevo post en un despliegue que puede fallar.

Una cosa más a tener en cuenta: WordPress sigue siendo un objetivo vivo aunque los visitantes nunca lo toquen. Has reducido el radio de impacto, no lo has eliminado, así que las secciones de seguridad y mantenimiento de arriba se siguen aplicando a esa instancia en su totalidad.

Autoalojando ambos caminos: setup, verificación, rollback

Este es el camino de operador viable más corto para cada opción, no un tutorial completo. Solo se cubre aquí la capa de despliegue; las instalaciones a nivel de raíz, el aprovisionamiento TLS y las reglas de firewall están en las guías enlazadas. Cada paso tiene un comando de verificación, porque «arrancó» y «funciona» son afirmaciones distintas.

Qué necesitas antes de empezar

Astro: estático en un VPS o en Cloudflare Pages

Dos variantes, y puedes elegir cualquiera sin cambiar de framework.

Variante A - build estático, servido en cualquier parte. Es la opción por defecto y con la que yo empezaría.

npm create astro@latest -- --template blog
cd my-blog
npm install
npm run build

# confirm the build actually produced output before you deploy anything
ls -la dist/index.html

Luego, o subes dist/ a Cloudflare Pages (npx wrangler pages deploy dist), lo empujas a Bunny o GitHub Pages, o lo sirves con nginx en tu propia caja. Dockerfile multi-etapa para la ruta nginx:

FROM node:lts AS build
WORKDIR /app
COPY package*.json ./
RUN npm install
COPY . .
RUN npm run build

FROM nginx:alpine AS runtime
COPY ./nginx/nginx.conf /etc/nginx/nginx.conf
COPY --from=build /app/dist /usr/share/nginx/html
EXPOSE 8080

Variante B - SSR con el adapter Node. Úsala solo si necesitas rutas dinámicas.

npx astro add node

FROM node:lts AS runtime
WORKDIR /app
COPY . .
RUN npm install
RUN npm run build
ENV HOST=0.0.0.0
ENV PORT=4321
EXPOSE 4321
CMD ["node", "./dist/server/entry.mjs"]

Verificación:

docker compose ps                          # container state should be Up, not Restarting
curl -I http://127.0.0.1:4321              # 200, content-type: text/html
curl -I https://yourdomain                 # 200 through the proxy, same content-type
docker compose logs --tail 50 astro        # no unhandled build or runtime errors

Cómo se ve lo roto: npm run build sale limpio pero falta dist/index.html significa que tu directorio de output se configuró en otro sitio. Un 200 en el puerto interno pero un 502 a través del proxy significa que el reverse proxy no alcanza el contenedor, normalmente un HOST o PORT mal puesto. Una página obsoleta tras un build exitoso suele significar que nginx sirve un montaje dist/ antiguo, no el output recién construido.

Fallos comunes: versión de Node incorrecta (las versiones impares como v23 no están soportadas y los mensajes de error no siempre son obvios); puerto 4321 ya en uso - comprueba con lsof -i :4321 o ss -ltnp | grep 4321; nginx.conf referenciado en el Dockerfile pero no copiado al contexto de build.

Para el recorrido completo en cualquiera de los dos destinos: desplegar Astro en un VPS, desplegar Astro en Cloudflare Pages o desplegar Astro en Bunny.net.

WordPress: Docker Compose en un VPS

2 GB de RAM mínimo. Una instancia de 1 GB se quedará sin memoria con un conjunto de plugins realista una vez que MySQL y PHP estén residentes.

services:
  db:
    image: mysql:8.0
    restart: unless-stopped
    environment:
      MYSQL_DATABASE: wordpress
      MYSQL_USER: wordpress
      MYSQL_PASSWORD: ${MYSQL_PASSWORD:?set MYSQL_PASSWORD in .env}
      MYSQL_ROOT_PASSWORD: ${MYSQL_ROOT_PASSWORD:?set MYSQL_ROOT_PASSWORD in .env}
    volumes:
      - db_data:/var/lib/mysql
    healthcheck:
      test: ["CMD", "mysqladmin", "ping", "-h", "127.0.0.1", "-p${MYSQL_ROOT_PASSWORD}"]
      interval: 10s
      timeout: 5s
      retries: 10

  wordpress:
    image: wordpress:php8.3-apache
    restart: unless-stopped
    depends_on:
      db:
        condition: service_healthy
    environment:
      WORDPRESS_DB_HOST: db:3306
      WORDPRESS_DB_USER: wordpress
      WORDPRESS_DB_PASSWORD: ${MYSQL_PASSWORD}
      WORDPRESS_DB_NAME: wordpress
    volumes:
      - wp_data:/var/www/html
    ports:
      - "127.0.0.1:8080:80"

volumes:
  db_data:
  wp_data:

Dos decisiones deliberadas ahí. Ambos servicios van detrás de un reverse proxy en lugar de exponerse en la interfaz pública (127.0.0.1:8080:80), y el healthcheck más depends_on: condition: service_healthy evita que WordPress arranque contra un MySQL a medio inicializar, que es el origen de un «Error establishing a database connection» muy confuso en el primer arranque. Para la capa de proxy, usa el setup existente de Traefik reverse proxy con Docker en lugar de inventar uno. Si prefieres no montar nginx ni Traefik a mano, Coolify y Dokploy gestionan ambos esta capa por ti.

Verificación:

docker compose ps                                  # every service Up
curl -I https://yourdomain/wp-login.php             # 200
curl -s https://yourdomain/wp-json/ | head -c 200   # valid JSON, not an HTML error page
docker compose logs -f wordpress                    # watch for DB connection errors during boot

Luego abre wp-admin y confirma que Settings > General muestra tu dominio real tanto en WordPress Address como en Site Address. Las URLs desajustadas causan bucles de redirección que parecen un problema de proxy pero no lo son.

Fallos comunes: conexión a la base de datos rechazada (host equivocado, o MySQL aún inicializándose - el healthcheck de arriba lo previene); volúmenes obsoletos tras cambiar credenciales de BD (el volumen retiene la contraseña antigua y WordPress fallará para siempre hasta que borres y reinicialices); un nombre de proyecto de Docker Compose distinto del que creó los contenedores, así que docker compose down no elimina nada; permalinks 404 tras un cambio de proxy (vuelve a guardar los ajustes de enlaces permanentes); OOM en una instancia de 1 GB; fallos de renovación TLS desde la capa de proxy y no desde la app.

Rollback y deshacer:

docker compose down       # stop and remove containers, keep volumes and data
docker compose down -v    # destroy containers AND volumes - data is gone

Para Astro, rollback significa redesplegar el commit anterior. Guarda el último output de build bueno conocido o una imagen etiquetada para que revertir sea un comando, no un rebuild bajo presión.

Un VPS de unos 4-6 €/mes es la caja de referencia para ambos caminos. Es lo que uso para trabajo autoalojado (Hetzner Cloud), y sirve cómodamente un sitio Astro estático; el camino de WordPress pide 2 GB o más. Para hardware ARM, instalar WordPress en Ubuntu ARM cubre la variante.

Si migras, la versión corta

El proceso completo vive en la guía de migración de WordPress a Astro, así que esto es el esquema y no las instrucciones.

1. Exporta el contenido de WordPress como XML, luego conviértelo a Markdown con las imágenes descargadas en local:

   npx wordpress-export-to-markdown

2. Reconcilia el frontmatter. Tus posts antiguos no tienen description, ni tags, y títulos inconsistentes. Esta es la parte tediosa, y donde los agentes de código realmente se ganan el pan.

3. Construye el mapa de redirecciones. Cada URL que cambie necesita un 301. Exportar URLs y títulos de posts de WordPress es cómo generas esa lista antes de tocar nada.

4. Mantén el sitio antiguo vivo hasta que el nuevo esté verificado. Ambos, simultáneamente. No borres la instalación de WordPress el día que cambies el DNS.

5. Rastrea y compara. Compara las URLs antiguas con las nuevas y comprueba que los enlaces internos sobrevivieron. Luego vigila Search Console un par de semanas.

Dos advertencias que importan más que la mecánica. Primero, espera una caída de unas dos semanas en el ranking aunque hagas todo bien; es reevaluación normal, no un fallo. Segundo, el riesgo real es la paridad de enlaces internos, no la puntuación de Lighthouse. Perder enlaces internos baja silenciosamente el valor que se pasa entre tus páginas, y aparece como un misterioso deslizamiento de ranking semanas después, mucho después de que hayas dejado de mirar la migración.

Cuándo WordPress sigue siendo la respuesta correcta

Cuatro casos donde WordPress no es un compromiso. Argumentar solo un lado de esto haría inútil todo el artículo.

1. WooCommerce a escala. WooCommerce impulsa el 29.7% de las tiendas online, y la experiencia de administración para pedidos, reembolsos, stock, envíos e impuestos es genuinamente madura. Astro puede hacer comercio, pero solo comercio headless más trabajo de integración: estarías construyendo el storefront y pegándolo a un backend de comercio. A menos que la experiencia del storefront sea tu diferenciador, eso es esfuerzo gastado en fontanería indiferenciada. El recorrido por el dashboard de administración de WooCommerce muestra lo que estarías reconstruyendo.

2. Membresías y cuentas de usuario. WordPress hace usuarios autenticados de forma nativa. Astro no, en absoluto. Si necesitas cuentas, contenido restringido o suscripciones, o ejecutas WordPress o levantas un backend real con un proveedor de auth. Los archivos estáticos no pueden iniciar sesión a nadie.

3. Publicadores diarios no técnicos. Si la persona que publica no puede ni quiere ejecutar git commit, entonces wp-admin no es una rebaja, es el requisito. Enseñar una pipeline de build a un colega de marketing es un coste recurrente que nunca desaparece del todo, y falla la primera vez que estás de vacaciones. Este es el caso donde WordPress gana de forma decisiva y el argumento de rendimiento deja de importar.

4. Dependencias duras de plugins. Si un plugin de reservas, un LMS o un plugin de directorio es la razón de existir del sitio, eso es una razón para quedarse, no un fallo de juicio. El plugin está haciendo meses de trabajo que de otro modo serían tuyos. Ejecuta bien la sección de seguridad de arriba y sigue adelante.

Para el camino del page builder específicamente, Breakdance es a lo que apuntaría a un editor no técnico, y la review del builder Breakdance cubre los tradeoffs con honestidad, incluido el lock-in de markup que viene con cualquier builder.

¿Cuál deberías ejecutar? Un árbol de decisión de 60 segundos

Cuatro arquetipos, cada uno con un veredicto y un orden de magnitud de coste mensual.

Diagrama de flujo eligiendo Astro, WordPress o WordPress headless más Astro según quién publica contenido tras el lanzamiento y si se necesita una tienda o cuentas de usuario

Ejecútalo en orden: quién publica tras el lanzamiento, luego si necesitas una tienda o cuentas, luego si un no-desarrollador necesita una GUI de editor. Esas tres respuestas cubren casi todos los casos reales. Si aterrizas en «se necesita GUI de editor pero el rendimiento también importa», ese es el híbrido, y mejores headless CMS para Astro merece leerse antes de comprometerte con WordPress como la mitad CMS.

FAQ

Veredicto

No hay un ganador universal aquí, y quien te diga lo contrario te está vendiendo algo. La decisión pertenece a quien actualice el sitio tras el lanzamiento.

Para un desarrollador en solitario que ejecuta un blog, un sitio de marketing o un sitio de docs, yo ejecutaría Astro estático. Menos piezas móviles, unos $0-6/mes, superficie de ataque casi nula y un workflow en el que los agentes de código son genuinamente buenos, porque todo el proyecto son archivos en un repo. Los modos de fallo son errores de build, que ves antes de desplegar, en lugar de un plugin explotado que descubres un viernes.

Elige WordPress cuando una persona no técnica deba publicar a diario, cuando necesites WooCommerce o membresías, o cuando un plugin concreto sea la razón de existir del sitio. Elige WordPress headless más Astro cuando necesites a la vez una GUI de editor y páginas estáticas rápidas, y acepta que ejecutas dos sistemas con uno de ellos como dependencia de build.

El encuadre de costes que mantiene unida toda la comparación: la parte cara nunca fue la licencia, ni tampoco la factura de hosting. Fue la rutina. Las horas de mantenimiento, las renovaciones de plugins, los incidentes de limpieza y el esfuerzo recurrente de mantener el rendimiento afinado suman $1,500-4,000 al año. Un build estático reemplaza todo eso con una pipeline que o tiene éxito o te dice por qué falló.