WordPress vs Astro (2026): ¿cuál fits mejor tu sitio?

En pocas palabras: Depende de quién va a editar el sitio: WordPress trae dashboard, usuarios y media library de fábrica, ideal si alguien sin código necesita publicar. Astro genera HTML en el build y requiere sumar un CMS aparte; Astro supera a WordPress 71% a 48% en Core Web Vitals (agosto 2026), según datos de Astro.

¿WordPress o Astro para tu próximo proyecto? La respuesta no depende de qué framework es más moderno, sino de una pregunta más aburrida y más importante: ¿quién va a tocar el sitio después de que el desarrollador se vaya?

Astro es un framework open source para sitios basados en contenido que genera páginas HTML durante el build y puede renderizar rutas a pedido con adaptadores para Node.js, Netlify, Vercel o Cloudflare. WordPress es un sistema de gestión de contenido con dashboard de edición, cuentas de usuario y biblioteca de medios, pensado para que alguien sin tocar código publique y actualice un sitio por su cuenta.

¿Qué tipo de sitio necesita WordPress y cuál necesita Astro?

WordPress sirve mejor cuando el cliente va a entrar al dashboard después del lanzamiento; Astro sirve mejor cuando el equipo de desarrollo mantiene el contenido a través de código y despliegues. Esa es la distinción real, no «cuál es más nuevo» o «cuál usan los influencers de turno».

En WordPress, los editores crean posts, suben medios y publican desde el dashboard sin pasar por un desarrollador cada vez. Para estructuras más custom, WordPress tiene las APIs core para registrar custom post types y metadata. Un plugin de campos personalizados agrega una interfaz más cómoda para definir esos campos: Advanced Custom Fields PRO cobra USD 49 al año por un sitio, USD 149 por diez sitios y USD 249 por sitios ilimitados (precios vigentes a octubre 2026). Secure Custom Fields, un fork gratuito de ACF, ofrece lo mismo sin costo.

Astro, en cambio, no trae dashboard editorial, media library ni sistema de usuarios. El contenido vive en Markdown, MDX o archivos de datos, o viene de un CMS externo. Sin esa integración, mantener contenido significa abrir archivos del proyecto en un entorno de desarrollo (algo que un cliente de WooCommerce jamás va a querer hacer, y con razón). Ya lo cubrimos antes en cómo funciona la comunidad detrás de wp-community.

¿Quién va a editar el sitio después del lanzamiento?

En WordPress, publicar o actualizar contenido no requiere reconstruir el front end; el cambio queda disponible de inmediato, sujeto a caché. En Astro, un cambio de contenido en un sitio generado estáticamente normalmente dispara un build y un deploy, y el visitante recién ve la actualización cuando ese proceso termina.

Ponele que tenés un cliente con una página de servicios que cambia de precio cada trimestre. En WordPress, el cliente entra, edita el campo y listo. En Astro sin CMS, alguien con acceso al repo tiene que tocar el archivo de contenido, comitear y esperar el deploy. ¿Puede automatizarse? Sí, con un webhook que dispare el build. ¿Resuelve el problema de fondo? No del todo, porque sigue dependiendo de que el cliente tenga (o no tenga) acceso a ese flujo.

El tiempo de build depende del contenido, las integraciones y el hosting. Astro introdujo builds estáticos incrementales experimentales en la versión 7.2 para reutilizar páginas cuyo código y contenido no cambiaron, lo que acorta ese tiempo en sitios grandes. Una ruta que lee contenido del CMS en el momento de la request puede mostrar cambios sin rebuild, pero su frescura sigue dependiendo de la caché.

¿Cómo se agrega un editor de contenido a un sitio Astro?

Hay tres caminos: edición basada en Git, una plataforma de contenido alojada, o WordPress headless. Ninguno viene incluido en Astro por default, así que elegir e integrar uno pasa a ser parte del presupuesto del proyecto, no un detalle menor.

• Edición basada en Git: herramientas como Keystatic, TinaCMS o CloudCannon gestionan contenido guardado en un repositorio. Keystatic usa un «singleton» para representar un registro de contenido compartido, parecido a una options page de WordPress.
• Plataforma de contenido alojada: un servicio como Sanity guarda el contenido por separado y lo expone vía API.
• WordPress headless: WordPress funciona como entorno de edición, y Astro consulta ese contenido para generar las páginas públicas.

Un detalle que se pasa por alto: un esquema de validación (Zod, en el caso de Astro) valida los datos que llegan, pero no crea una pantalla de edición. Esas dos cosas van separadas. Si usás Keystatic con WordPress headless simultáneamente, las definiciones de campos existen tanto en el schema de validación como en la configuración del CMS, y hay que mantenerlas alineadas a mano (o con validación compartida, que tampoco es gratis en tiempo de desarrollo). Tema relacionado: armar una landing page en WordPress.

¿Qué funciones de WordPress hay que reconstruir a mano en Astro?

Formularios, e-commerce, cuentas de usuario y edición visual son los cuatro puntos donde WordPress empaqueta el trabajo en un plugin y Astro te deja armar la integración. No es que Astro no pueda hacerlo: es que vos (o tu equipo) tenés que elegir y conectar cada pieza.

Formularios: ¿Astro sirve para formularios de contacto?

Sí, pero con trabajo adicional: Astro Actions y endpoints bajo demanda procesan envíos, aunque hay que conectar storage, email, protección antispam y gestión de envíos por tu cuenta. En WordPress, plugins como Gravity Forms o Contact Form 7 empaquetan buena parte de ese flujo en un dashboard, y un builder como Divi suma integraciones de estilo para esos mismos plugins.

E-commerce: ¿Astro sirve para tiendas online?

Astro puede soportar links de checkout, pagos embebidos y storefronts conectados a APIs de comercio, pero no trae un dashboard de productos y pedidos propio. Su guía de e-commerce muestra ejemplos con Lemon Squeezy, Paddle y Snipcart, aunque esos no son los únicos servicios que se pueden integrar. WordPress con WooCommerce resuelve producto, carrito, checkout y pedidos dentro del mismo entorno, y Divi suma módulos visuales para esas páginas.

Cuentas de usuario: ¿Astro tiene roles como WordPress?

No de fábrica. WordPress incluye usuarios y roles, y plugins extienden eso a membresías y portales de cliente. Astro integra herramientas de autenticación como Better Auth o Clerk, pero las reglas de acceso y las funciones de membresía las implementa el desarrollador. Tener sesiones disponibles no es lo mismo que tener un sistema de membresías completo. Te puede servir nuestra cobertura de probar cambios usando un entorno de staging.

Edición visual: ¿Astro tiene un editor como el de WordPress?

No. WordPress tiene el editor de bloques, y el Visual Builder de Divi agrega edición visual arriba de eso. Astro no trae un editor equivalente en el framework; servicios como CloudCannon pueden sumar edición visual, pero las capacidades dependen de la integración elegida (no es «instalás y ya», como el plugin de un clic al que WordPress nos acostumbró mal a todos).

Aspecto	WordPress	Astro
Edición de contenido	Dashboard incluido	Archivos del proyecto o CMS agregado
Publicar un cambio	Disponible sin rebuild (sujeto a caché)	Normalmente dispara build y deploy
Formularios	Plugin (Gravity Forms, CF7)	Astro Actions + servicios conectados a mano
E-commerce	WooCommerce integrado	Checkout externo (Lemon Squeezy, Paddle, Snipcart)
Cuentas y roles	Nativo, extensible con plugins	Better Auth o Clerk, lógica custom
Edición visual	Editor de bloques, Divi Visual Builder	Depende de la integración (CloudCannon, etc.)

WordPress vs Astro: ¿qué dice la comparación de Core Web Vitals?

Según el propio sitio de Astro, la comparación de agosto 2026 da 71% de Core Web Vitals aprobados para sitios Astro contra 48% para sitios WordPress. El dato suena contundente, pero compara poblaciones enteras de sitios, no el mismo proyecto construido dos veces por el mismo equipo.

WordPress cubre una franja enorme de la web, con instalaciones viejas, presupuestos dispares y prácticas de mantenimiento que van de excelentes a inexistentes. Un sitio Astro también puede cargar bastante JavaScript si suma componentes interactivos, analytics y scripts de terceros sin cuidado: el tamaño chico del framework no garantiza una página final liviana. En WordPress, el theme, el comportamiento de los plugins, el hosting, la caché y el manejo de imágenes definen el resultado final mucho más que el nombre de la plataforma.

Si vas a medir performance en serio, probá páginas representativas del sitio terminado y no te quedes con el promedio de la categoría. Para WordPress, eso incluye revisar si tu hosting soporta caché a nivel servidor: el hosting WordPress de Donweb viene con LiteSpeed preinstalado, sin tener que migrar de plataforma.

¿Qué significa que Astro se uniera a Cloudflare en 2026?

La empresa detrás de Astro se unió a Cloudflare en enero de 2026, según el anuncio citado en la comparación de Elegant Themes. El framework sigue siendo open source bajo licencia MIT y se puede desplegar en cualquier runtime compatible, no solo en Cloudflare.

Para el desarrollador de a pie, esto cambia poco en lo inmediato: Astro sigue siendo el mismo framework, con los mismos adaptadores para Node.js, Netlify y Vercel. Lo que sí vale la pena seguir de cerca es si la hoja de ruta empieza a priorizar integraciones con la infraestructura de Cloudflare por sobre el resto. Todavía no hay evidencia de eso. Para más detalles técnicos, mirá detectar y arreglar enlaces rotos.

¿Existe un punto medio entre WordPress y Astro?

Sí: WordPress headless. WordPress funciona como entorno de edición (el dashboard de siempre, con roles y revisiones) y Astro consulta ese contenido vía API para generar el front end público. El cliente edita donde siempre editó, y el front termina siendo un sitio Astro con el rendimiento que eso implica. Lo complementamos en una falla reciente en instalaciones multisitio.

El costo de este enfoque está en la coordinación: cada campo custom tiene que existir tanto en WordPress como en la capa que lo consume en Astro, y cualquier cambio de estructura implica tocar los dos lados. Para un sitio con backend WordPress corriendo aparte, un hosting confiable sigue siendo parte de la ecuación: ahí entra de nuevo donweb.com como opción para alojar ese WordPress headless sin que se vuelva el cuello de botella del proyecto.

Errores comunes al elegir entre WordPress y Astro

• Confundir el tamaño del build con el peso de la página. El HTML generado por la demo de la comparación pesó 2.734 bytes, pero eso es un solo archivo, no la página completa con imágenes, estilos y scripts. Comparar ese número con el peso total de un sitio WordPress es comparar cosas distintas.
• Elegir Astro sin definir quién publica contenido después del lanzamiento. Si el cliente necesita entrar y cambiar un precio sin pedirle nada a nadie, armar Astro sin CMS termina generando un ticket de soporte por cada actualización.
• Asumir que «estático» significa cero JavaScript. La arquitectura de islas de Astro agrega interactividad donde se necesita, y eso puede sumar peso si no se controla. Un sitio chico no garantiza una página chica.
• No alinear el schema de validación con la configuración del CMS. Si usás Keystatic o TinaCMS sobre Astro, el esquema Zod y la configuración del CMS definen los mismos campos por separado. Si se desalinean, el build falla o guarda datos que el front no sabe mostrar.

Preguntas Frecuentes

¿Astro reemplaza a WordPress?

No necesariamente. Astro reemplaza la parte de generación del front end, pero no incluye dashboard, usuarios ni media library, así que un sitio que necesita que alguien no técnico publique contenido sigue necesitando WordPress (headless o tradicional) o un CMS agregado. Cobertura relacionada: una vulnerabilidad que escala permisos de usuario.

¿Astro tiene un editor como WordPress?

No. Astro no trae un editor de bloques ni panel de administración propio. Para lograr algo similar hay que sumar un CMS como Keystatic, TinaCMS o Sanity, o usar WordPress headless como capa de edición.

¿Qué es más rápido, WordPress o Astro?

Según la comparación de Core Web Vitals de agosto 2026 publicada por Astro, 71% de los sitios Astro aprueban contra 48% de los sitios WordPress. El dato compara poblaciones distintas de sitios, no el mismo proyecto construido en ambas plataformas, así que la performance real depende del theme, los plugins, el hosting y cuánto JavaScript se agregue en cada caso.

¿Se puede usar WordPress como backend de Astro?

Sí, es el enfoque de WordPress headless: WordPress gestiona la edición de contenido y Astro consulta esa información vía API para generar las páginas públicas. Esto combina el dashboard conocido de WordPress con el rendimiento del front end de Astro, a costa de mantener dos capas coordinadas.

¿Astro sirve para tiendas online o formularios?

Astro puede manejar formularios con Astro Actions y conectarse a servicios de pago como Lemon Squeezy, Paddle o Snipcart para e-commerce, pero no trae un dashboard de pedidos ni gestión de envíos incluida. WordPress con WooCommerce resuelve eso dentro de un solo entorno, sin integraciones externas obligatorias.

Conclusión

La decisión entre WordPress y Astro se resuelve mirando quién va a tocar el sitio el mes que viene, no comparando benchmarks de rendimiento aislados. Si el cliente necesita publicar, actualizar precios o manejar pedidos sin depender de un desarrollador, WordPress (con o sin WooCommerce) sigue siendo el camino con menos fricción. Si el equipo mantiene el sitio por código y el contenido cambia poco, Astro ofrece una base liviana, aunque hay que presupuestar la integración de CMS, formularios y cuentas que WordPress trae de fábrica. Antes de elegir, probá las páginas reales del proyecto terminado (no el promedio de categoría) y definí por escrito quién edita qué y en cuánto tiempo se ve el cambio publicado.

Fuentes

• Elegant Themes – WordPress vs Astro
• Astro – sitio oficial del framework
• WordPress.org – sitio oficial del CMS