# Migrar de WordPress a Astro: por qué lo estoy haciendo (y cuándo NO deberías)

> Acabo de migrar un sitio corporativo de WordPress a Astro: de 40 plugins y un hosting mensual a un sitio estático sin nada que hackear ni mantener. Los números reales de la migración, qué gana tu organización — y los casos donde quedarte en WordPress es la decisión correcta.

Publicado: 2026-08-27 · Autor: Felipe Tause (https://tause.pro) · Poderosamente Simple (https://www.poderosamentesimple.com)

La semana pasada migré un sitio corporativo real — el del estudio del que hago parte — de WordPress a Astro. No fue un capricho de tecnólogo: fue la conclusión de un mes viendo de cerca lo que le pasa a los WordPress institucionales cuando nadie los cuida.

Estos son los números de esa migración, lo que significa cada uno para una organización como la tuya, y — porque este blog no vende humo — la lista honesta de casos en los que **migrar sería un error**.

## Los números de una migración real

El sitio venía de WordPress con tema comercial de página builder, WooCommerce instalado (con **cero productos** — solo por si acaso, desde 2021), y componentes duplicados: dos plugins de formularios, tres herramientas de analytics, un plugin de seguridad premium.

| | Antes (WordPress) | Después (Astro) |
|---|---|---|
| Plugins que actualizar | ~40 | **0** |
| Base de datos que respaldar | 1 (con años de tablas huérfanas) | **0** |
| Superficie atacable (PHP ejecutándose) | Todo el sitio | **Ninguna** — archivos estáticos |
| Hosting | Plan mensual administrado | **$0** (hosting estático) |
| Tiempo de carga | 2–4 segundos | **Menos de 1** |
| ¿Quién actualiza el contenido? | "El de sistemas" | Panel propio, cualquiera del equipo |

La última fila es importante y la explico más abajo, porque es la objeción #1 a los sitios estáticos — y ya tiene solución buena.

## Qué significa "estático" (sin jerga)

WordPress arma cada página **en el momento en que alguien la visita**: consulta la base de datos, ejecuta PHP, pasa por 40 plugins, y entrega el resultado. Eso implica que en cada visita hay código ejecutándose que puede fallar, ser lento, o ser atacado.

Un sitio estático se arma **una sola vez** — cuando publicas un cambio — y lo que se entrega a cada visitante es el resultado final: archivos ya construidos. Como la diferencia entre cocinar el plato frente al cliente cada vez (con la cocina abierta a extraños) y entregar el plato ya emplatado.

Las consecuencias prácticas:

**1. Seguridad por diseño, no por plugin.** El caso del [activador pirata de Wordfence](/blog/plugins-nulled-el-candado-pirata/) que conté hace unos días es imposible en un sitio estático — no porque haya un mejor candado, sino porque **no hay puerta**: no hay PHP que ejecutar, no hay base de datos que inyectar, no hay panel wp-admin que forzar.

**2. Nada que mantener.** Sin plugins no hay actualizaciones pendientes, ni incompatibilidades entre versiones, ni el ciclo de miedo de "si actualizo se daña, si no actualizo me hackean" que describí en el [checklist de las 12 señales](/blog/12-senales-wordpress-institucional-va-a-colapsar/).

**3. Velocidad que Google premia.** Los archivos estáticos se sirven desde CDN — el sitio carga desde un servidor cercano al visitante, en milisegundos. Y desde que la búsqueda incluye IAs que citan fuentes, los sitios rápidos, limpios y bien estructurados tienen ventaja medible.

**4. Costo de operación cercano a cero.** El hosting estático moderno es gratuito o casi para sitios institucionales típicos. El plan mensual de hosting administrado de WordPress — $30 a $100 USD/mes — desaparece.

## "¿Y cómo edito el contenido sin WordPress?"

Esta es la objeción legítima. La respuesta corta: **un panel de contenido separado del sitio**.

En la migración que hice, el equipo edita textos, proyectos y personas desde un panel web — igual de fácil que WordPress — y al darle "publicar" el sitio se regenera en un minuto. La diferencia arquitectónica es crucial: **el panel y el sitio viven separados**. Si el panel fallara, el sitio sigue en pie, intacto, porque no depende de él para existir. En WordPress, el editor y el sitio son la misma cosa: si uno cae, caen los dos.

## Cuándo NO migrar (léelo antes de escribirme)

Migrar no es la respuesta universal. Quedarte en WordPress es la decisión correcta si:

1. **Tu operación ES WordPress.** Tienda WooCommerce activa con cientos de pedidos, membresías con pagos recurrentes, LMS con cursos en marcha. Ahí WordPress no es el sitio: es el sistema de negocio. Migrar eso es otro proyecto, con otro presupuesto, y a veces no vale la pena.

2. **Publicas mucho y muy seguido con un equipo grande.** Si tienes 15 editores publicando a diario con flujos de revisión, el editor de WordPress sigue siendo difícil de superar. (Para un blog como este, o noticias institucionales mensuales, el panel separado sobra y alcanza.)

3. **Tu sitio actual funciona, está mantenido y no te cuesta dolores.** Si tienes quien lo cuide, respaldos probados y plugins al día — no arregles lo que no está roto. Guarda este artículo para cuando eso cambie.

4. **El presupuesto solo alcanza para "moverlo".** Una migración mal hecha — sin redirecciones, sin migrar el SEO, sin resolver la edición de contenido — es peor que no migrar. Hecho a medias, pierdes lo mejor de ambos mundos.

## Cuándo SÍ es urgente

Al revés, la migración sube al primer lugar de la lista cuando:

- El sitio es **informativo/corporativo** (quiénes somos, servicios, proyectos, contacto, blog) y vive en WordPress solo por inercia
- Ya nadie actualiza los plugins, o **el "webmaster" ya no está** — cada mes que pasa el riesgo crece en silencio
- Encontraste **componentes pirata o abandonados** (si no lo has revisado: [guía de auditoría aquí](/blog/plugins-nulled-el-candado-pirata/))
- Pagas hosting administrado por un sitio que cambia **unas pocas veces al año**
- Tu sitio se cayó en un momento crítico y el diagnóstico dio como el de [este postmortem](/blog/anatomia-de-un-error-500/): memoria agotada, plugins de hace 5 años, deuda acumulada

Si marcaste dos o más, el costo de migrar ya es menor que el costo de quedarte — solo que uno se paga una vez y el otro se paga en riesgo, cada mes.

## Cómo se ve una migración bien hecha

Para que tengas la referencia al cotizar (mía o de quien sea):

1. **Inventario primero**: qué contenido existe de verdad, qué se migra, qué se archiva. En mi caso: 16 páginas resultaron ser 8 reales, un WooCommerce vacío se eliminó, y unas FAQs de relleno ("lorem ipsum" en producción desde 2022) se descartaron
2. **El diseño se conserva o se mejora — nunca se pierde**: colores, logos, identidad. La migración no debe verse como "otro sitio"
3. **Redirecciones de todas las URLs viejas**: el SEO acumulado durante años se transfiere, no se abandona
4. **Panel de contenido** para que el equipo edite sin tocar código
5. **El WordPress viejo queda congelado** unos días como respaldo — revertir debe ser posible en minutos
6. Solo cuando el nuevo lleva días estable: se cancela el hosting anterior

Tiempo real de mi última migración con todo lo anterior: **tres días de trabajo**. No los tres meses que te van a cotizar los que cobran por hora de reunión.

---

*¿Tu sitio institucional está en la lista de "urgente"? Escríbeme — reviso tu caso concreto y te digo con franqueza si te conviene migrar o quedarte. A veces la respuesta correcta es la que no me deja factura.*