Migrar WordPress a Astro sin perder SEO: guía para agencias

Recibes el acceso al WordPress de un cliente nuevo y lo primero que ves son cuarenta y dos plugins activos. Tres hacen caché. Dos son constructores visuales, uno de ellos caducado. El theme lo tocó alguien en 2019 editando el functions.php desde el propio panel. La web carga en cinco segundos y el cliente pregunta por qué no sube en Google.

Es el momento en el que alguien del equipo dice: “¿y si lo pasamos a Astro?”. Buena idea, a veces. Pero migrar WordPress a Astro solo sale bien si antes respondes dos preguntas que no son técnicas: qué hace realmente esa web y quién va a publicar en ella después. El resto —exportar, maquetar, desplegar— es trabajo conocido y acotado.

Esta guía va de lo segundo: cómo hacerlo sin que el cliente vea caer su tráfico, que es la única forma en que una migración se considera exitosa desde fuera del equipo técnico.

Cuándo migrar WordPress a Astro y cuándo no tocarlo

WordPress no es el problema. Lo que suele estar roto es lo que se le ha ido colgando encima durante años.

No migres si la web depende de funcionalidad de servidor que en Astro tendrías que reconstruir entera: una tienda WooCommerce con catálogo grande y stock en vivo, un área privada con usuarios registrados, membresías, reservas con disponibilidad. Ahí WordPress hace un trabajo real y sustituirlo cuesta más de lo que devuelve. Tampoco migres una web que funciona, carga rápido y a la que nadie le toca nada. Si no duele, no operes.

Migra cuando se junten varias de estas:

• La web es contenido: corporativa, blog, catálogo sin carrito, landings.
• Los Core Web Vitals están en rojo y ya has probado el camino de la caché y los plugins sin resultado suficiente. Si no lo has probado aún, empieza por ahí: lo cuento en cómo pasar Core Web Vitals en WordPress.
• El mantenimiento se come el margen: actualizaciones que rompen, incompatibilidades, un plugin de pago que ya nadie renueva.
• Hay deuda de seguridad. Cada plugin es superficie de ataque y el cliente no lo sabe hasta que pasa algo.
• Vais a rediseñar de todas formas.

Esa última es la que inclina la balanza casi siempre. Si el diseño se rehace, maquetar en Astro en vez de pelearse con un theme heredado no añade coste: lo quita.

Antes de nada: decide dónde publicará el cliente

Este es el punto que hunde migraciones enteras, y no es código. Es una conversación.

El cliente lleva años entrando a /wp-admin, escribiendo un post y dándole a publicar. Si le entregas un sitio precioso en el que para cambiar un teléfono hay que abrir un pull request, has empeorado su vida por mucho que el PageSpeed marque cien. Tienes tres opciones, y conviene elegirla antes de exportar nada:

WordPress headless. Dejas la instalación viva, pero oculta: el cliente sigue publicando en el panel de siempre y Astro consume el contenido por la REST API en el build. Es la vía con menos fricción humana. A cambio, sigues manteniendo un WordPress —actualizaciones incluidas—, aunque ya no reciba tráfico público y puedas cerrarlo tras un firewall.

CMS headless de verdad. Mueves el contenido a un gestor moderno con panel propio. El cliente gana una interfaz limpia y tú te quitas PHP de encima del todo. Es la opción más cara en horas de migración y la que exige formar al cliente.

Markdown en Git. El contenido vive en el repositorio, en ficheros de texto, y lo gestionan las colecciones de contenido de Astro. Rápido, versionado, gratis. Solo funciona si quien publica es tu equipo, no el cliente.

No hay una respuesta correcta. Hay una que encaja con quién toca el contenido cada semana. Elígela con el cliente delante y déjala por escrito en el presupuesto.

Cómo migrar WordPress a Astro sin perder SEO, paso a paso

1. Congela el inventario de URLs antes de tocar nada

Saca la lista completa de URLs que existen hoy y que Google conoce. El sitemap.xml que genera Yoast o Rank Math, más el informe de páginas indexadas de Search Console, más las URLs con tráfico en Analytics. Cruza las tres fuentes.

De ahí sale el documento que gobierna toda la migración: cada URL viva, su tráfico, y qué va a ser de ella. Se queda igual, cambia de ruta o desaparece. Sin este inventario estás migrando a ciegas y lo descubrirás dos meses después, cuando el cliente pregunte por qué una página que le traía clientes devuelve un 404.

2. Exporta el contenido por la REST API

WordPress expone casi todo en /wp-json/wp/v2/: entradas, páginas, categorías, etiquetas y biblioteca de medios, en JSON. Es mucho más limpio que el XML del exportador clásico y te evita entrar a la base de datos.

Un script recorre esos endpoints, convierte el HTML del cuerpo a Markdown y escribe un fichero por entrada con su frontmatter. Si el cliente usa Advanced Custom Fields, revisa si los campos salen en la respuesta: algunos requieren exponerlos explícitamente y es fácil no darse cuenta hasta que faltan la mitad de los datos de una ficha.

Reserva tiempo para esto. Es el paso menos lucido y el que más se alarga.

3. Replica los permalinks tal cual

Aquí está la mejor noticia de esta migración, y por eso es más benévola que otras: puedes conservar las URLs exactas. Astro te deja definir la ruta de cada página, así que si el cliente tiene /blog/como-elegir-proveedor/, en Astro puede seguir siendo /blog/como-elegir-proveedor/.

Una URL que no cambia no necesita redirect, no reparte autoridad y no da margen a que Google interprete nada raro. La regla es simple: cambia solo las rutas que tengas una razón de negocio para cambiar. La tentación de “aprovechar y reordenar la estructura” durante una migración es real y es la forma más habitual de convertir un proyecto de dos semanas en tres meses de recuperación de posiciones.

Para las que sí cambien —y siempre cambia alguna—, monta redirects 301 uno a uno, no reglas comodín que apunten todo a la home. Un 301 a la home es un 404 con mejores modales.

4. Rescata los metadatos SEO

El title y la meta description de cada página no están en el contenido: están en la tabla de metadatos, puestos por Yoast o Rank Math. Si exportas solo el cuerpo, los pierdes todos y el sitio nuevo sale con títulos autogenerados.

Migra, entrada por entrada: título SEO, meta description, canónica si hay alguna personalizada, y la marca de noindex en las páginas que la tuvieran. Esa última importa más de lo que parece: si el cliente tenía desindexadas las páginas de etiquetas o de resultados internos, y al migrar las abres todas, le has metido cientos de URLs de baja calidad en el índice.

Los datos estructurados también se van con el plugin. Astro no los pone solo: reconstruye el Schema.org que tuviera —Article, BreadcrumbList, Organization— desde el frontmatter. Es la parte del trabajo que solapa con una auditoría de SEO técnico y conviene hacerla antes del cambio de DNS, no después.

5. La biblioteca de medios, con sus alt

Descarga los originales de /wp-content/uploads/ y pásalos por el componente de imagen de Astro para que genere formatos modernos y tamaños responsive. Es una de las mejoras de rendimiento más grandes y sale casi gratis.

El detalle que se pierde siempre: el texto alt. Vive en la base de datos como metadato del adjunto, no en el HTML del post. Si no lo arrastras explícitamente, tu sitio nuevo sale sin alt en ninguna imagen. Accesibilidad fuera, SEO de imágenes fuera.

6. Lo que WordPress hacía por ti sin que lo notaras

Haz la lista completa antes de apagar nada, porque son cosas que solo se echan de menos cuando ya no están:

• Formularios. Contact Form 7, Gravity Forms o el que sea, corren en PHP. En un sitio estático necesitas un servicio externo o un endpoint serverless. Móntalo, pruébalo en producción y comprueba que el correo llega de verdad antes de migrar.
• Buscador interno. WordPress busca contra su base de datos. En Astro se resuelve con un índice generado en el build y búsqueda en cliente.
• Comentarios. Si el blog los tiene y se usan, hacen falta un servicio externo o la decisión consciente de cerrarlos.
• Feed RSS. Puede estar alimentando newsletters o agregadores. Genéralo en la misma ruta de siempre.
• Redirects previos. Muchos WordPress arrastran redirecciones antiguas en un plugin. Esa cadena también hay que migrarla, o revives 404 que llevaban años resueltos.

Las trampas que se llevan el SEO por delante

Tres que veo repetirse:

Apagar WordPress demasiado pronto. Mantén el solape. Astro en producción, redirects respondiendo, Search Console limpia y el rastreo estabilizado. Entonces apagas. Nunca antes.

Rediseñar y migrar el contenido a la vez sin control. Cambiar de stack es una variable. Reescribir todos los textos es otra. Si mueves las dos y el tráfico baja, no sabrás cuál fue. Al menos deja el contenido de las páginas con más tráfico intacto en el primer despliegue.

Dar por hecho que estático es rápido. Astro sale rápido de fábrica, pero una migración descuidada te devuelve al punto de partida: fuentes sin optimizar, imágenes sin tamaños, scripts de terceros sin control. Mide con PageSpeed Insights antes y después, y guarda ambas capturas. Es la prueba que le enseñas al cliente.

En resumen

Migrar WordPress a Astro no es una operación arriesgada si haces los deberes en el orden correcto: decides antes quién publica, congelas el inventario de URLs, conservas los permalinks que puedas y arrastras los metadatos que viven fuera del contenido. La parte difícil no es Astro. Es no dejarte nada de lo que WordPress venía haciendo en segundo plano.

Y si el caso es el contrario —un cliente atrapado en un WordPress que no controla, con un proveedor que le cobra por cada cambio—, eso es otra conversación que también tiene solución: la cuento en migración de WordPress. Para migraciones desde otros gestores, el planteamiento es parecido pero cambian los detalles; escribí sobre ello en migrar de October CMS a Astro.

¿Tienes un WordPress heredado sobre la mesa y dudas entre optimizarlo o migrarlo? Cuéntame el caso y te digo qué haría yo y cuántas horas supondría. Trabajo como socio técnico white-label con agencias que necesitan estas manos sin montar equipo propio, y este tipo de proyecto en Astro y Next es el pan de cada día.

Preguntas frecuentes

¿Se puede migrar WordPress a Astro sin perder posiciones en Google?

Sí, y es más fácil que en otras migraciones porque puedes replicar la estructura de permalinks de WordPress tal cual en Astro. Si cada URL antigua responde en la misma ruta, no hay redirects que montar ni autoridad que repartir. Cuando sí cambias rutas, un mapa de 301 uno a uno conserva el posicionamiento.

¿El cliente pierde su panel de WordPress al migrar a Astro?

Solo si tú lo decides. Tienes tres caminos: dejar WordPress vivo como CMS headless y que Astro consuma su API, mover el contenido a un headless con panel propio, o pasar a Markdown en Git si quien publica es tu equipo. Esta decisión va antes de escribir una línea de código.

¿Qué webs de WordPress no conviene migrar a Astro?

Las que dependen de funcionalidad de servidor difícil de reemplazar: WooCommerce con muchos productos y stock en vivo, áreas privadas con usuarios registrados, membresías o reservas. Ahí WordPress hace un trabajo que replicar sale caro. Para webs corporativas, blogs y landings, Astro gana con holgura.

¿Cómo se exporta el contenido de WordPress a Astro?

Por la REST API de WordPress, en /wp-json/wp/v2/. Devuelve entradas, páginas, categorías y medios en JSON, incluidos los campos de Yoast o Rank Math si el plugin los expone. Con un script conviertes ese JSON a los ficheros Markdown que consumen las colecciones de contenido de Astro.