--- title: "Astro vs WordPress en 2026: Un Desglose Honesto de Costes y Operaciones" description: "Astro vs WordPress para operadores en solitario en 2026: datos reales de Core Web Vitals, tablas de costes totales, radio de impacto en seguridad y la vía pragmática de WordPress headless." date: 2026-09-10 categories: ["web-development"] tags: ["astro","wordpress","self-hosting"] --- import Button from "@components/widgets/Button.astro"; import Notice from "@components/widgets/Notice.astro"; import ListCheck from "@components/widgets/ListCheck.astro"; import Accordion from "@components/widgets/Accordion.astro"; import Tabs from "@components/widgets/Tabs.astro"; import Tab from "@components/widgets/Tab.astro"; 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](/es/migracion-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](/astro-7-faster-builds/) 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+**. WordPress sigue siendo el CMS más grande con mucha diferencia, pero su cuota lleva declinando desde principios de 2025. Astro es la alternativa content-first en ascenso, ahora financiado por Cloudflare y aún portable. La brecha que realmente decide tu migración no es la puntuación de Lighthouse. Es operacional: una pipeline de build que produce archivos estáticos frente a un runtime PHP más una rutina interminable de actualizaciones de plugins. ![Cronología de hitos de WordPress y Astro desde principios de 2025 hasta septiembre de 2026](@assets/images/26/09/diagram-1-timeline.svg) ### 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](/es/hetzner-cloud-resena/)) 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. Las funciones Cloudflare-first son convenientes, pero son la única parte de Astro que no es portable. Mantén el build estático y el output estándar, para que el hosting siga siendo una decisión intercambiable y no una reescritura. ## 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. `npm run build` produce una carpeta `dist/` con HTML, CSS y JS. La subes a una CDN, la sirves con nginx o la empujas a Cloudflare Pages. No hay base de datos, no hay página de login, no hay intérprete PHP y ningún proceso runtime que mantener vivo. - **Coste:** $0 en un tier gratis, o ~4-6 €/mes en un VPS que controlas - **Falla cuando:** el build falla, o publicas un enlace roto - **Tú controlas:** comentarios, formularios, búsqueda, imágenes y cada pieza de lógica PHP más MySQL detrás de wp-admin. Los editores entran, escriben, publican. La página se ensambla en cada petición (y con suerte se cachea). Los plugins y temas la extienden, que es a la vez toda la propuesta de valor y toda la superficie de riesgo. - **Coste:** $20-50/mes gestionado, o $4-20/mes autoalojado en un VPS más tu tiempo - **Falla cuando:** una actualización de plugin rompe el sitio, o comprometen la instancia - **Tú controlas:** actualizaciones, copias de seguridad, postura de seguridad, stack de caché WordPress sigue siendo el CMS, pero los visitantes nunca lo tocan. Astro obtiene los posts de la API REST o GraphQL de WordPress en tiempo de build y envía output estático a una CDN. Los editores tienen wp-admin; los visitantes, archivos. - **Coste:** hosting de WordPress más un host estático, aproximadamente $4-50/mes según cómo ejecutes el CMS - **Falla cuando:** la API de WordPress no es alcanzable durante un build - **Tú controlas:** dos sistemas, una pipeline de build y el contrato de API entre ellos Las opciones de CMS headless más allá de WordPress se cubren en [mejores headless CMS para Astro](/best-headless-cms-for-astro/) si prefieres no ejecutar WordPress en absoluto. ![Diagrama comparando tres arquitecturas: Astro estático, WordPress clásico con PHP y MySQL, y WordPress headless alimentando un frontend Astro estático](@assets/images/26/09/diagram-2-architectures.svg) ### 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](/speed-up-wordpress-with-cloudflare-varnish-and-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. ```bash # 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](/es/crear-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](@assets/images/26/09/diagram-3-page-weight-vs-cwv.svg) 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. 68 contra 44 es una comparación de dos poblaciones de sitios. Un WordPress afinado gana a un Astro sin afinar siempre. Lo que realmente eliges es cuánto esfuerzo continuo cuesta mantenerse afinado, y quién hace ese trabajo. Si quieres mantener ligero un build de Astro autoalojado, [optimización de builds Astro SSG](/astro-ssg-build-optimization/) 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](@assets/images/26/09/diagram-4-blast-radius.svg) ### 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. Si estás en 6.9.0-6.9.4 o 7.0.0-7.0.1, actualiza a 6.9.5 o 7.0.2 o posterior (corregido el 17 de julio de 2026). Si aún no puedes actualizar, bloquea el acceso anónimo a `/batch/v1` en la capa del proxy y trata el sitio como expuesto. ### 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. Son estimaciones de vendors y agencias más precios de lista de hosting actuales, no facturas auditadas de la contabilidad de nadie. Trátalas como rangos para decisiones de orden de magnitud, y vuelve a comprobar el precio actual antes de comprometer presupuesto. ### 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](https://go.bitdoze.com/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. | Concepto | WordPress (gestionado) | WordPress (VPS autoalojado) | Astro (estático, tier gratis) | Astro (SSR en VPS) | |---|---|---|---|---| | Hosting | $20-50/mes | $4-20/mes VPS | $0 | ~$4-6/mes VPS | | BD / runtime | incluido | MySQL + PHP que gestionas | ninguno | Node que gestionas | | Superficie de seguridad | grande | grande | casi cero (sin BD, sin login, sin PHP) | pequeña (sin BD) | | Mantenimiento | 2-5 h/mes | 2-5 h/mes más servidor | ~0 | parches de servidor + Node | | Plugins y temas al año | $300-800 | $300-800 | $0 | $0 | | Objetivos de ataque | plugins, admin, `/batch/v1` | igual | solo archivos estáticos | tu código de app | | Total típico al año | $1,500-4,000 | $1,000-3,000 | solo dominio (~$10-15) | ~$50-100 | Para las filas de VPS, los hosts que realmente mantengo en mi lista corta: [Hetzner Cloud desde unos 4 €/mes](https://go.bitdoze.com/hetzner) como referencia de caja EU barata, o [Hostinger KVM VPS](https://go.bitdoze.com/hostinger-vps) si quieres NVMe en un plan económico. Si necesitas presencia en una región concreta, [Vultr](https://go.bitdoze.com/vultr) y [DigitalOcean Droplets](https://go.bitdoze.com/do) son los otros dos que consideraría. Si comparas planes en lugar de proveedores, [planes cost-optimizados de Hetzner](/hetzner-cloud-cost-optimized-plans/) y [DigitalOcean vs Vultr vs Hetzner](/digitalocean-vs-vultr-vs-hetzner/) entran en detalle, y [opciones de cloud hosting PHP](/php-cloud-hosting/) 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](/es/subidas-precios-vps/)._ ![Gráfico de barras del coste anual total de WordPress gestionado, WordPress autoalojado, Astro estático y Astro SSR](@assets/images/26/09/diagram-5-annual-cost.svg) ### 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](https://go.bitdoze.com/bunny) 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](/tugtainer-docker-autoupdate/) 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: ```astro Hello World Hello{' '} World ``` 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. - **Semanal:** comprobaciones de actualizaciones de plugins y núcleo, lectura de avisos - **Mensual:** actualizaciones de núcleo más plugins con copia de seguridad previa - **Trimestral:** auditoría de plugins, prueba de restauración, revisión de CWV - **Anual:** actualización de versión mayor, espera una reconstrucción de algo - **Mensual:** `npm audit` más subidas de dependencias (Renovate o Dependabot pueden hacerlo por ti) - **Trimestral:** comprobación de Node LTS - quédate en versiones LTS pares - **Anual:** actualización mayor del framework, normalmente una tarde ### 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](/add-contact-form-static-websites/) cubre las opciones, con una versión específica de Astro en [añadir un formulario de contacto en Astro](/es/anadir-formulario-contacto-astro/). Si mantienes el lado de WordPress autoalojado, [instalar WordPress con Docker](/install-wordpress-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`. ```ts // 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(); ``` Dos parámetros de consulta hacen el trabajo pesado: `_embed` trae los medios destacados dentro de la respuesta para evitar un segundo viaje por post, y `_fields` recorta el payload a lo que renderizas. Una respuesta por defecto de `/wp/v2/posts` es mucho más grande de lo que necesita una página de listado, y ese peso cae en tu build. ```ts // rendering the featured image from the embedded payload const img = post._embedded?.["wp:featuredmedia"]?.[0]?.media_details?.sizes?.medium?.source_url; ``` Fíjate en el encadenamiento opcional. Un post sin imagen destacada lanzará un error durante el build de otro modo, y un solo post malo puede tumbar todo el despliegue. ```graphql query LatestPosts($first: Int!) { posts(first: $first, where: { status: PUBLISH }) { nodes { slug title date excerpt featuredImage { node { sourceUrl altText } } } } } ``` ```ts 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)); ``` GraphQL devuelve `200 OK` con un array `errors` para muchos fallos, así que comprueba ese array explícitamente. Confiar solo en el código de estado es una forma común de enviar un sitio vacío. 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. Un CMS headless caído en tiempo de build es un despliegue fallido. Cachea la última respuesta buena, monitoriza la API y trata su uptime como parte de tu superficie de producción. ## 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. ```bash 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: ```dockerfile 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. ```bash npx astro add node ``` ```dockerfile 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:** ```bash 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](/es/desplegar-astro-en-vps/), [desplegar Astro en Cloudflare Pages](/deploy-astrojs-cloudflare/) o [desplegar Astro en Bunny.net](/deploy-astro-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. ```yaml 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](/traefik-proxy-docker/) en lugar de inventar uno. Si prefieres no montar nginx ni Traefik a mano, [Coolify](/es/instalar-coolify-alternativa-heroku/) y [Dokploy](/dokploy-install/) gestionan ambos esta capa por ti. **Verificación:** ```bash 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:** ```bash 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. `docker compose down -v` borra los volúmenes nombrados, lo que incluye todo tu directorio de datos de MySQL. Prueba la restauración de tus copias de seguridad antes de necesitar este comando, no después. Guarda también el output del build antiguo. Un VPS de unos **4-6 €/mes** es la caja de referencia para ambos caminos. Es lo que uso para trabajo autoalojado ([Hetzner Cloud](https://go.bitdoze.com/hetzner)), 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](/install-wordpress-on-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](/es/migracion-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: ```bash 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](/export-wordpress-post-urls-titles/) 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.