De WordPress a Astro: por qué en 2026 migrar a un sitio headless

El sitio que estás leyendo era WordPress hasta hace poco. Hoy es un sitio estático construido con Astro, publicado en el mismo hosting cPanel donde vivía el WordPress original: mismo servidor, mismo dominio, cero mudanzas de infraestructura. Solo cambió la forma de fabricar y servir las páginas.

La migración no fue un experimento — es el mismo cambio que vengo recomendando en proyectos de clientes. Acá va el porqué, con la comparativa completa.

El problema de fondo: páginas que se fabrican en cada visita

WordPress es dinámico por diseño: cada visita ejecuta PHP, consulta la base de datos MySQL, arma el HTML y lo entrega — con ayuda de caché, si la configuraste y si el hosting la soporta. Ese modelo le da su gran ventaja (panel de administración, plugins para todo) y también su gran debilidad: en cada request hay código ejecutándose, una base de datos viva y decenas de plugins de terceros que se actualizan por su cuenta.

Astro y los generadores de sitios estáticos invierten el modelo: el sitio se fabrica una sola vez, en el build. Lo que se publica es HTML, CSS y JS ya terminados. El servidor de producción solo entrega archivos. No ejecuta nada.

Seguridad: la superficie de ataque más chica posible

La mayoría de las vulnerabilidades reportadas en WordPress no vienen del núcleo, sino de plugins desactualizados o abandonados. Súmale un panel de login expuesto a internet, PHP vivo y una base de datos conectada, y tenés una superficie de ataque permanente que exige actualizaciones continuas, WAF y vigilancia.

Un sitio estático con Astro directamente no tiene nada que ejecutar en producción: no hay PHP, no hay base de datos, no hay login, no hay plugins. Lo peor que le puede pasar a un servidor de archivos estáticos es que alguien descargue… archivos públicos.

Despliegue: 71 archivos contra un ecosistema

Mi flujo de publicación hoy es literalmente un comando: npm run build y la subida de 71 archivos estáticos al mismo cPanel donde estaba el WordPress. Sin actualizar núcleo, plugins y tema; sin verificar compatibilidades; sin backup obligatorio de base de datos antes de cada actualización. Publicar una mejora = compilar y subir.

En WordPress, el despliegue y el mantenimiento son lo mismo: actualizaciones que no podés postergar mucho (por seguridad) y que a veces rompen algo (por compatibilidad). Y si el sitio crece, el hosting PHP compartido se queda chico.

Bonus: un sitio estático también se puede publicar gratis en Netlify, Vercel o Cloudflare Pages, con HTTPS y CDN globales incluidos.

Optimización: rendimiento de fábrica, sin tunelear

• HTML pre-renderizado: cero consultas a base de datos y cero ejecución en runtime → TTFB bajísimo.
• Cero JavaScript por defecto: Astro solo hidrata los componentes interactivos (“islands”). El resto es HTML puro.
• Assets con hash y caché agresiva: los recursos estáticos se cachean un año sin tocar nada.
• Resultado: Core Web Vitals verdes sin plugins de caché, sin configurar CDNs a mano, sin pelear con el hosting. (Sobre por qué esto importa para el negocio, escribí aquí.)

Y el punto 2026: los buscadores tradicionales y las nuevas experiencias de búsqueda con IA (ChatGPT, Perplexity, Gemini) favorecen contenido rápido, limpio y bien estructurado. Un HTML estático y semántico es el mejor punto de partida para SEO y para AI Search.

Comparativa directa

Dimensión	WordPress	Astro (headless)
Seguridad	Superficie grande: PHP + MySQL + login + plugins	HTML estático: nada ejecutable en producción
Despliegue	Actualizar núcleo, plugins y tema + backup de DB	npm run build → subir archivos estáticos
Optimización	Depende de caché, hosting y plugins	Pre-renderizado, cero JS por defecto
SEO	Maduro (Yoast, RankMath)	Excelente: HTML limpio, control total
Contenido	Panel visual, usuarios y roles	Markdown + git, o un CMS headless aparte
Costo de hosting	PHP + MySQL, crece con el tráfico	Cualquier hosting estático, incluso gratis
Mantenimiento	Continuo e ineludible	Casi nulo tras publicar

Ventajas y desventajas, sin filtros

WordPress:

Ventajas	Desventajas
Panel de administración para cualquier perfil	Superficie de ataque permanente
Plugins para absolutamente todo	Rendimiento atado a la caché y al hosting
Editores visuales, multiusuario, roles	Actualizaciones continuas y compatibilidades frágiles
Comunidad gigante, todo documentado	Cada visita ejecuta PHP y consulta la DB (sin caché)

Astro / headless:

Ventajas	Desventajas
Seguridad por diseño: nada ejecutable	Crear y editar requiere perfil técnico
Velocidad de fábrica, CWV sin esfuerzo	El “editor” es código (o integrar un CMS aparte)
Deploy simple y barato, hasta gratis	Formularios y comentarios: servicios externos
Markdown + git: contenido versionado	La migración inicial tiene costo real

¿Cuándo seguir con WordPress?

Siendo honesto: si el equipo que administra el contenido no es técnico y publica todos los días, WordPress sigue siendo una respuesta válida. Y existe un camino intermedio — WordPress como CMS headless, administrando contenido por su panel y sirviéndolo vía API REST a un frontend estático (escribí sobre esa API acá). Conservás el panel que el equipo conoce, y ganás el frontend rápido.

Cómo fue mi migración, en la práctica

1. El contenido pasó a archivos Markdown en colecciones de Astro, conservando slugs donde se pudo.
2. Los URLs que cambiaron recibieron redirecciones 301 en el .htaccess — cero enlaces roto hacia atrás.
3. Mantuve el nombre del sitemap (sitemap_index.xml, el clásico de Yoast) para no perder el historial en Search Console.
4. El WordPress viejo quedó en una subcarpeta del mismo hosting mientras confirmaba que nada faltara; después salió.
5. El sitio completo: 71 archivos estáticos, sin base de datos, sin PHP.

La decisión no es “WordPress malo”. Es que en 2026, para sitios de contenido, la pregunta correcta es cuánto código querés ejecutando en producción en cada visita. Yo elegí: ninguno.