Para la mayoría de webs de empresa, Astro 7 sobre Cloudflare sale más barato, más rápido y más fácil de asegurar que WordPress 7.0. Pero esa ventaja tiene un precio del que la versión anterior de esta comparativa no dijo nada: el framework tiene su propio ritmo de publicación y alguien lo paga en horas de desarrollo.
Escribí la primera versión de esta comparativa en abril, contra Astro 6 y un WordPress 7.0 todavía en release candidate. Los dos han salido desde entonces, y hemos movido este sitio de Astro 6 a Astro 7. Así que ahora tengo algo que entonces no tenía: una factura desglosada de una migración mayor de framework, ejecutada sobre nuestro propio corpus de bastante más de diez mil páginas.
La recomendación de plataforma no ha cambiado. Lo que ha cambiado es cuánto sé sobre los costes ocultos del lado de Astro.
WordPress 7.0, tres meses después del lanzamiento
WordPress 7.0 salió el 20 de mayo de 2026. Conviene separar lo anunciado de lo que realmente venía en el paquete.
AI Client y Abilities API
AI Client es infraestructura, no un redactor con IA terminado. WordPress 7.0 aporta una API unificada para hablar con modelos, pero pide una clave externa y configuración antes de hacer nada. Abilities API permite que los agentes descubran e invoquen funciones de WordPress de forma programática, algo que importa a quien desarrolla plugins y que es prácticamente invisible para un redactor.
Es un cimiento importante. No es una función que un cliente vaya a notar en el panel el primer día.
La colaboración en tiempo real no llegó
La edición simultánea fue la promesa más ruidosa de esta versión y se retiró tras problemas técnicos. Tres meses después sigue ausente de la línea 7.0. Quien vendió WordPress 7.0 a un cliente prometiendo varios redactores sobre el mismo documento tiene una conversación incómoda por delante.
La arquitectura de debajo no se ha movido
El panel renovado y los bloques nuevos son un avance visual. Debajo siguen PHP, MySQL y un servidor convencional que hay que parchear, cachear y vigilar. Ninguna novedad de la 7.0 cambia que cada plugin amplía la superficie de ataque, ni que el rendimiento solo aparece tras una capa de caché y CDN.
WordPress 7.0, el intercambio
Lo que te da:
- El mejor editor de contenido para gente no técnica, sin competencia real en esa categoría
- Un ecosistema de plugins que se cuenta por decenas de miles
- WooCommerce como plataforma de comercio completa
- Abilities API como base para integraciones con agentes
Lo que te cuesta:
- Peso del núcleo y sobrecarga que no puedes desactivar
- Una superficie de ataque que crece con cada plugin
- Presupuesto de alojamiento, copias, monitorización y plugins de seguridad
- Rendimiento que solo llega tras caché y CDN
- Versiones de seguridad cada pocas semanas
Astro 7 y qué cambió de verdad respecto a la versión 6
Astro 7.0.0 salió el 22 de junio de 2026, 104 días después de Astro 6.0.0. Tres cambios tienen consecuencias que no se ven en el changelog hasta que lanzas tu propia compilación.
El compilador Rust dejó de ser un experimento
En Astro 6 el compilador escrito en Rust era un experimento opcional. Astro 7 cambia la dependencia @astrojs/compiler por @astrojs/compiler-rs y la convierte en el comportamiento por defecto. Las compilaciones ganan velocidad. El analizador se vuelve, a la vez, más estricto.
A nosotros nos rompió en exactamente una línea. Un comentario HTML escrito dentro de una expresión JSX, algo como {import.meta.env.DEV && ( <!-- ... --> )}, pasaba el compilador viejo y el nuevo lo rechaza. El arreglo es un comentario JavaScript. Un minuto de trabajo, siempre que sepas qué buscar, porque el mensaje de error apunta a una posición del resultado compilado y no de tu fuente.
Vite 8 por debajo
Astro 6 se apoyaba en Vite 7. Astro 7 pasa a Vite 8, la línea basada en Rolldown. Para la mayoría de proyectos es invisible, pero con corpus grandes conviene vigilar la memoria durante la compilación, porque el perfil de reserva es distinto al de antes.
El CSP hashea los estilos en línea, y ahí duele
Este es el cambio que nos costó un día entero.
Astro 7 calcula hashes de los bloques <style> incrustados en la página y los añade a la directiva style-src. Según la especificación de Content Security Policy, la presencia de cualquier hash en una directiva anula 'unsafe-inline'. El resultado: todos los atributos style="" dinámicos dejan de funcionar. A nosotros nos tumbó los colores de token de Shiki en los bloques de código, junto con variables de tema, velocidades de animación e imágenes de fondo. Solo la página de inicio dio 26 infracciones de CSP, y quedó afectada cada página con resaltado de sintaxis.
No hay interruptor para desactivar el hasheo. 'unsafe-hashes' por sí solo tampoco lo resuelve, porque cubre los atributos de estilo pero no el contenido de los elementos <style>.
La solución resultó más sencilla de lo que parecía, porque el conjunto de estilos en línea es finito. Sobre unas 260.000 apariciones en todo el corpus había 143 valores únicos. Recogerlos una vez, escribir los hashes en la configuración, añadir 'unsafe-hashes' para el caso de los atributos, y las infracciones caen a cero en todos los tipos de plantilla.
Queda una obligación permanente. Cualquier componente nuevo que introduzca un valor de estilo en línea nuevo entra en la lista o se bloquea en silencio en producción. Esto necesita una comprobación en CI, o te enterarás por el aviso de un usuario.
Una nueva cadena de markdown por defecto
Astro 7 cambia el procesamiento de markdown por defecto. Si mantienes tu propia cadena de remark y rehype, tienes que incluir @astrojs/markdown-remark de forma explícita para conservar el comportamiento anterior. Es una línea en las dependencias, pero si falta produce una diferencia silenciosa de renderizado en lugar de un error de compilación, y por eso es fácil publicarla sin darte cuenta.
Lo que nos costó de verdad la migración de Astro 6 a 7
Cifras de nuestro propio despliegue, no de la documentación.
| Concepto | Resultado |
|---|---|
| Ficheros modificados | 5 |
| Líneas de código de plantilla modificadas | 1 |
| Cambios rupturistas principales que nos afectaban | 1 de 4 |
| Infracciones de CSP antes del arreglo, solo la portada | 26 |
| Valores únicos de estilo en línea a hashear | 143 |
| Páginas en la compilación de vista previa tras migrar | 15.850, código de salida 0 |
| Pruebas unitarias | 103 de 103 |
| Errores de typecheck | 0 |
Tres de los cuatro cambios rupturistas principales no nos afectaban, y ahí está el fondo del asunto. No tenemos Astro DB, no hay adaptador de servidor que mover y compilamos de forma estática, así que la reorganización del punto de entrada del servidor nos pasó de largo. Un proyecto con SSR, adaptador y base de datos de Astro recibe una factura completamente distinta por la misma migración.
La lección práctica: el coste de una versión mayor de Astro no escala con el tamaño del sitio. Escala con cuántos puntos de contacto tienes con el entorno de ejecución. Nuestras más de catorce mil páginas costaron menos de lo que habría costado una sola aplicación con Astro DB y adaptador propio.
Comparativa directa 2026
| Rasgo | WordPress 7.0 | Astro 7 + Cloudflare | Ganador |
|---|---|---|---|
| Tiempo de carga | 1,5 a 4 s | por debajo de 500 ms, normalmente 200 a 300 ms | Astro |
| Coste de alojamiento anual | varios cientos de euros | de cero a decenas | Astro |
| Seguridad | superficie de ataque amplia | HTML estático más islas | Astro |
| Edición de contenido | editor de bloques, sin rival real | buena, Content Collections más CMS | WordPress |
| Core Web Vitals | buenos tras optimizar | 100/100 casi siempre | Astro |
| Escalabilidad | media, necesita caché | muy alta, servido desde el borde | Astro |
| Ecosistema de plugins | decenas de miles | integraciones npm y Cloudflare | WordPress |
| Comercio electrónico | WooCommerce | sin equivalente nativo | WordPress |
| Curva de aprendizaje | fácil para contenido, dura para código | media | Empate |
| Mantenimiento de infraestructura | alto | mínimo | Astro |
| Seguir el ritmo del framework | bajo, versiones mayores raras | real, versiones mayores cada pocos meses | WordPress |
Resultado: Astro 7, WordPress 3, un empate.
WordPress ha recuperado un punto en esta edición, y no por una función nueva. Lo ha recuperado por el ritmo de publicación. Una web WordPress de hace tres años sigue compilando, porque no hay compilación. Una web Astro de hace tres años va dos versiones mayores por detrás y alguien tiene que llevarla adelante.
Cuándo migrar en 2026, mi lista de verificación de 8 puntos
Migrar tiene sentido cuando cumples al menos cinco de ocho:
- Sitio de contenido, blog o página de aterrizaje, es decir, exactamente aquello para lo que se creó Astro
- PageSpeed por debajo de 80 pese a optimizar WordPress, lo que indica un problema de arquitectura y no de configuración
- Costes de alojamiento por encima de unos doscientos euros al mes
- Incidentes de seguridad recurrentes, parcheo de plugins, intentos de fuerza bruta
- Un equipo de desarrollo que domina JavaScript y TypeScript y que seguirá ahí para ejecutar la siguiente actualización mayor
- Sin necesidad de WooCommerce ni de una zona de usuario registrado pesada
- El SEO es prioritario y los Core Web Vitals mueven posiciones
- El sitio atiende a varios países y el TTFB global importa
El punto cinco es más amplio que en la versión de abril de esta lista, y lo es a propósito. El requisito no es saber JavaScript el día del lanzamiento. El requisito es saber quién ejecuta npm update nueve meses después.
Tres o menos: quédate en WordPress. Cuatro: valora el híbrido. Cinco o más: la migración compensa.
Caso de estudio, antes y después
Web corporativa, cliente de Varsovia
Antes: WordPress con Elementor, PageSpeed en rojo en móvil, tiempo de carga medido en segundos, una partida mensual fija de alojamiento.
Después: Astro sobre Cloudflare Pages, PageSpeed en verde, tiempo de carga muy por debajo del segundo, alojamiento estático en el plan gratuito.
Efecto neto: la partida de alojamiento desapareció y los Core Web Vitals pasaron de rojo a verde en las plantillas principales. Esa misma web pasó después por la migración de Astro 6 a 7 dentro de nuestro mantenimiento y el cliente no notó nada más allá de un despliegue.
wppoland.com, este sitio
Más de catorce mil páginas prerrenderizadas en seis idiomas, de las cuales unas tres mil aparecen en los sitemaps como contenido destinado a indexarse. El resto es un despliegue de ciudad por servicio con noindex. Alojamiento en el plan gratuito de Cloudflare. Este mismo sitio funcionaba antes sobre WordPress con alojamiento mensual de pago.
Migrar ese corpus de la 6 a la 7 fueron cinco ficheros y un día de trabajo, casi todo él de Content Security Policy.
El factor idiomático: castellano y lenguas cooficiales
La comparativa anterior se rompe en cuanto el cliente opera en una comunidad con lengua cooficial. Un fabricante en Cataluña, una clínica en Galicia o una empresa de servicios en el País Vasco no publican un sitio, publican dos versiones desde el primer día, y a menudo una tercera en inglés para exportación. Eso deja de ser una funcionalidad y pasa a ser la restricción principal del proyecto.
El problema real no es técnico, es de mantenimiento. Quien actualiza el sitio suele ser una sola persona de marketing. La versión en castellano se actualiza el mismo día, la versión en catalán o en gallego llega semanas después, y al año el sitio tiene dos verdades distintas. Cualquier decisión de plataforma que ignore esto acaba mal, por muy bueno que sea el PageSpeed.
| Necesidad | WordPress 7.0 con WPML o Polylang | Astro 7 |
|---|---|---|
| Alta de un idioma nuevo | inmediata desde el panel | requiere tocar el proyecto |
| Traducción de cadenas de plugins | depende de cada plugin | no aplica, no hay plugins |
| Detectar contenido sin traducir | listados dentro del panel | falta el archivo y se ve en el build |
| Publicar sin desarrollador | sí | solo con un CMS conectado |
| hreflang correcto | plugin de SEO más configuración | se genera del árbol de archivos |
Astro tiene aquí una ventaja poco comentada: si falta la traducción, falta el archivo, y eso aparece en el build en lugar de publicarse una página a medias. WordPress te deja publicar igualmente, que es cómodo y es exactamente el mecanismo por el que se acumula la deuda de contenido.
El ritmo de publicación del apartado anterior añade aquí un matiz que conviene decir en la propuesta. Un sitio con tres idiomas en Astro es un solo repositorio, así que una versión mayor se ejecuta una vez y sirve para los tres. En WordPress con WPML son tres árboles de contenido dentro de una misma instalación, pero el riesgo se traslada al plugin de multiidioma, que tiene su propio calendario y sus propias incompatibilidades con cada versión del núcleo. No es que uno de los dos evite el problema, es que lo colocan en sitios distintos.
Un segundo detalle muy español: la mayoría de pymes tienen el alojamiento, el dominio y el correo contratados con el mismo proveedor nacional y con soporte telefónico en castellano. Mover el frontal a Cloudflare parte esa relación en dos, porque el correo se queda donde estaba y el DNS pasa a gestionarse en otro sitio. Conviene decidirlo antes de la migración y dejarlo por escrito, no descubrirlo el día en que alguien pregunta por qué no llegan los correos del formulario.
Cómo es la migración de WordPress a Astro en la práctica
Paso 1, auditoría del sitio WordPress
Cuenta los custom post types, lista los plugins con lo que hace cada uno de verdad, mapea las plantillas. Esto determina la complejidad de todo lo demás.
Paso 2, exportar el contenido
WP CLI o la API REST para sacar entradas, páginas y medios a markdown o JSON. La mayor parte se automatiza.
Paso 3, construir las plantillas Astro
Rehacer layouts y componentes en sintaxis .astro. Tailwind CSS se comporta igual. La mayoría de plantillas de WordPress tienen equivalentes directos.
Paso 4, Content Collections
Define tipos de contenido con validación Zod. El equivalente a los custom post types, salvo que el tipado detecta el error en la compilación y no en producción.
Paso 5, alojamiento y DNS
Cloudflare Pages conectado al repositorio Git, dominio configurado. Las compilaciones se disparan en cada push.
Paso 6, redirecciones uno a uno
Mapea cada URL antigua a su ruta nueva. Este es el paso donde mueren los posicionamientos cuando se hace de cualquier manera.
Paso 7, pruebas y envío a GSC
Rastreo completo, ejecuciones de Lighthouse en cada tipo de plantilla, sitemap nuevo en Google Search Console.
Paso 8, treinta días de seguimiento
Vigila posiciones, indexación y Core Web Vitals durante el primer mes.
Hoy añadiría un noveno paso: anota qué versión de Astro desplegaste y qué hay que revisar en la siguiente mayor. Un runbook escrito el día de la migración cuesta una hora. Reconstruir ese conocimiento seis meses después cuesta un día.
Solución híbrida, WordPress más Astro
No hace falta elegir uno de los dos. El híbrido se ve así:
- WordPress como CMS headless, el panel de edición de contenido
- Astro como frontal, generando páginas estáticas a partir de los datos de WordPress
- WPGraphQL o la API REST como puente
- Cloudflare Pages alojando el frontal
La redacción conserva la interfaz que conoce, las visitas reciben una página estática y el equipo técnico trabaja con un stack moderno. El modelo de costes completo está en la guía de TCO headless frente a monolito.
El coste oculto del que no escribí en abril
Astro 6.0.0 salió el 10 de marzo de 2026. Astro 7.0.0 salió el 22 de junio. A finales de agosto la línea 7.x iba por la 7.2.8. Ese ritmo WordPress no lo ha tenido nunca.
Para nosotros es asumible, porque mantenemos nuestro propio stack y tenemos comprobaciones en CI que detectan la desviación antes de que llegue a producción. Para un cliente que recibió una web y desapareció dos años, la cosa cambia. La web sigue funcionando, porque el HTML estático no deja de funcionar. Pero añadir cualquier cosa al cabo de dos años significa saltar dos versiones mayores de golpe, y eso es bastante más duro que dos migraciones seguidas.
Así que la versión honesta de la recomendación es esta. Astro gana en rendimiento, coste de infraestructura y seguridad. WordPress gana en que se puede dejar solo durante más tiempo. Si el presupuesto de mantenimiento no tiene una partida para revisiones técnicas, esa segunda propiedad vale más de lo que sugiere la tabla.
Huella energética e información de sostenibilidad
Entre los clientes sujetos a información de sostenibilidad, la huella energética del sitio ha empezado a aparecer en los pliegos. Conviene separar desde el principio lo que se puede acreditar de lo que solo suena bien en una propuesta.
El mecanismo es real y fácil de explicar a un auditor. Cada visita a una página dinámica en WordPress arranca un proceso PHP-FPM y una serie de consultas a MySQL, así que la visita consume ciclos de CPU en un centro de datos. Una página estática sale de la caché en el borde de la red y, en un acierto de caché normal, no ocupa ningún proceso de aplicación. La dirección de la diferencia no se discute.
Lo que sí se discute es la cifra. No entregamos a los clientes un porcentaje de reducción de consumo energético, porque no lo hemos medido, y los valores que circulan en material comercial no tienen metodología publicada detrás. Si tiene que entrar un número concreto en un informe, ha de venir de los datos del proveedor de alojamiento para ese periodo, no de una comparación de arquitecturas.
Consejo práctico: coge lo que tu proveedor publica de verdad sobre su infraestructura y su mix energético, y cítalo como declaración suya, no como medición tuya. Pasar a una arquitectura estática es un argumento sobre consumo de recursos, no un certificado ambiental.
Mi previsión para 2026 y 2027
WordPress sigue dominando en tiendas WooCommerce, sitios con equipos editoriales no técnicos, proyectos construidos sobre plugins ya hechos y empresas que necesitan salir rápido y barato.
Astro con Cloudflare se lleva los sitios de contenido y los blogs orientados a rendimiento, las webs corporativas y páginas de aterrizaje, la documentación técnica y los sitios multiidioma con alcance global.
Mi estimación de abril situaba a los frameworks estáticos en el 30 a 40 por ciento de los sitios de contenido que hoy corren sobre WordPress, para finales de 2027. La mantengo, con la salvedad del apartado anterior: esa migración solo compensa donde el frontal está presupuestado como software.
Conclusión
WordPress 7.0 es una versión sólida que no toca los cimientos de la plataforma. Astro 7 es más trabajo bajo el capó que funciones nuevas para el usuario: compilador Rust por defecto, Vite 8 y un CSP más estricto.
Si montas una tienda online: WordPress. Si montas una web corporativa, un blog o una página de aterrizaje donde importan el rendimiento y el SEO: Astro 7 con Cloudflare. Si montas las dos cosas: valora el híbrido.
Si no lo tienes claro, escríbeme. Si Astro es la elección correcta para tu proyecto, hay más en la página de desarrollador Astro.
Mariusz Szatkowski, desarrollador WordPress y Astro. Organizador de WordCamp Gdynia, contribuidor de WordPress Core. Trabaja con ambas plataformas para clientes de Polonia y Europa.
