01 / Decisión
Cuándo Astro puede encajar mejor
La web es sobre todo editorial
Blogs, guías, landings y directorios con cambios de contenido controlados pueden aprovechar una salida estática o híbrida sin mantener un CMS PHP completo para servir cada visita.
El frontend depende demasiado del tema y plugins
Si cada ajuste de diseño exige atravesar capas de tema, constructor y plugins, una arquitectura basada en componentes puede reducir dependencias y hacer más previsible el mantenimiento.
Necesitas control del código y del despliegue
Astro encaja cuando el proyecto ya trabaja con Git, build, QA y despliegues verificables, y el equipo acepta que una parte mayor del sistema vive en el repositorio.
Las funciones dinámicas están acotadas
Formularios, búsqueda, calculadoras o integraciones concretas se pueden resolver como servicios separados o interacciones locales. Si toda la operación depende del panel de WordPress, hay que valorarlo con mucha más cautela.
02 / Inventario
Antes de tocar el diseño: inventaría el WordPress real
Una migración segura empieza con una lista de todo lo que existe y de todo lo que recibe tráfico. No basta con copiar el menú. Hay que inventariar URLs públicas, contenidos, medios, formularios, taxonomías, redirecciones, canonicals, datos estructurados, usuarios y cualquier función que dependa de plugins.
- Separa páginas editoriales, fichas comerciales, categorías, archivos, adjuntos y endpoints; no asumas que todo necesita una página equivalente.
- Marca qué URLs tienen enlaces externos, impresiones o tráfico antes de decidir si se mantienen, redirigen o deben devolver 404.
- Identifica funciones dinámicas reales: cuentas, comentarios, formularios, pagos, búsqueda, membresías, automatizaciones e integraciones.
- Conserva un mapa origen → destino y pruébalo sobre el build candidato antes de cambiar el dominio.
- No copies automáticamente scripts, schemas comerciales, shortcodes o datos de plugins si la función que representaban ya no existe.
03 / URLs y SEO
El SEO se protege con URLs y equivalencia, no con el framework
Cambiar WordPress por Astro no obliga a cambiar las URLs. Si una URL conserva el mismo contenido e intención, mantenerla evita una migración SEO innecesaria. Cuando una URL sí cambia, Google recomienda preparar un mapa y usar redirecciones permanentes de servidor hacia el destino final, evitando cadenas. Canonical, sitemap, enlazado interno y respuestas 404 también deben validarse sobre el sitio nuevo.
Qué debe incluir el mapa de migración
- URL antigua, URL nueva o decisión explícita de retirarla.
- Código HTTP esperado: 200, 301/308 o 404 real.
- Title, description, canonical e indexación prevista.
- Imágenes y otros assets que forman parte del contenido indexable.
- Enlaces internos que todavía apuntan a una ruta antigua.
04 / Caso real
Caso real: Mi Casa Autosuficiente
En Mi Casa Autosuficiente la migración se trató como un cambio de arquitectura y de alcance, no como una copia mecánica del WordPress. Se inventarió la superficie pública, se separaron los contenidos editoriales de funciones comerciales que ya no debían presentarse como activas y el cambio en el dominio principal solo se dio por cerrado después de validar el build y el HTTPS real de Hostinger.
- El dominio principal sirve ahora Astro y mantiene una arquitectura editorial centrada en energía, huerto urbano y agua.
- Las herramientas prácticas que no necesitan servidor funcionan directamente en el navegador.
- La migración distinguió entre conservar una URL útil, redirigirla y retirarla; no se asumió que todo el legado merecía ser republicado.
- La publicación se valida con build, comprobaciones de navegación/SEO y smoke sobre el HTTPS real, no solo con una compilación local.
- La ficha pública del proyecto muestra el resultado actual; la trastienda de migración queda reservada a documentación técnica como esta guía.
05 / Checklist
Checklist antes del cambio
- 01
Inventaría todas las URLs y funciones públicas antes de construir la sustitución.
- 02
Decide qué se conserva, qué se redirige y qué se retira con una razón explícita.
- 03
Compara titles, canonicals, metadatos, sitemap, robots y enlazado interno del candidato.
- 04
Prueba móvil, formularios, herramientas, 404 y assets sobre un host real de staging.
- 05
Cambia producción solo cuando puedas verificar la revisión exacta desplegada y monitoriza Search Console después del corte.
06 / Cuándo no migrar
Cuándo no migraría a Astro
No migraría solo porque Astro sea más nuevo o porque una puntuación de rendimiento resulte atractiva. Si el equipo necesita editarlo todo desde un backoffice WordPress, depende mucho de WooCommerce o plugins difíciles de sustituir, tiene flujos de miembros complejos o no dispone de un proceso de build y mantenimiento del código, WordPress puede seguir siendo la opción más eficiente. También existe la opción intermedia de conservar WordPress como CMS headless.