Cómo migrar de WordPress a Astro sin perder rankings de SEO

WordPress es una herramienta perfectamente válida — hasta que tu web crece a 200 posts, 30 plugins, dos custom post types y una factura de hosting que se ha doblado el último año. En algún momento el Lighthouse pasa a ser infixable, el editor a ser intolerable, y empiezas a pensar en reescribirlo.

Astro es un destino tentador: cero JavaScript por defecto, Lighthouse 95+ desde el día 1, contenido en Markdown que vive en Git, y un build pipeline que de verdad entiendes. Pero el miedo es real: ¿qué pasa con mi SEO si cambio de stack?

Respuesta corta: nada, si la migración la haces bien. He movido webs de WordPress a Astro con cero pérdida de ranking — y en la mayoría de casos ganancias pequeñas en 4–8 semanas tras el launch porque los Core Web Vitals mejoran tanto que Google premia la experiencia.

Esta es la checklist que sigo, en orden.

1. Inventaría la web WordPress ANTES de tocar nada

Antes de escribir una sola línea de Astro tienes que saber exactamente qué tienes. Saltarte esto significa descubrir URLs huérfanas tres meses después del launch, cuando ya han 404’eado y Google las ha tirado.

Yo exporto:

• La lista completa de URLs vía Screaming Frog o wp-cli (wp post list --post_type=any --format=csv). Quieres cada post, page, custom post type, categoría, tag y attachment.
• Las redirecciones ya existentes — normalmente de un plugin de redirects o en .htaccess. Muchas veces encierran años de cambios de URL que NO quieres perder.
• El rendimiento actual de Google Search Console — qué queries posicionan, qué URLs traen tráfico, qué palabras suben/bajan.
• El schema markup actual — si tienes Rank Math o Yoast, tienes schema. Audítalo con Schema.org Validator para saber qué replicar.

Todo a una hoja de cálculo. Va a ser la fuente de verdad de la migración.

2. Estrategia de slugs: mantenerlos o asumir el coste del redirect

Esta es la decisión SEO más importante de toda la migración.

Opción A — mantener slugs idénticos. Cada /2024/03/15/mi-slug-post/ pasa a /blog/mi-slug-post/ (o viceversa). Implementas 301 desde la estructura vieja a la nueva, y Google pasa el 90%+ del link equity a través del redirect en 4–8 semanas.

Opción B — reestructurar URLs. Tentador, pero cada URL reestructurada es una que Google tiene que redescubrir, reevaluar y decidir si la sigue posicionando. Si tus URLs ya son cortas y limpias, no las toques. Si son horribles (/?p=482), reestructúralas una vez, hazlo bien, y no las vuelvas a tocar.

Yo por defecto voy con Opción A excepto si la estructura URL está perjudicando activamente (ej. tiene fechas que envejecen artificialmente, o tiene query strings ?p=).

3. Exporta el contenido en un formato que Astro entienda

WordPress guarda los posts en la base de datos como HTML con shortcodes. Astro quiere ficheros Markdown con frontmatter YAML. La herramienta que yo uso es wp2md (un script Node pequeño que tengo en ~/bin) pero puedes hacerlo con:

• El wp export oficial en XML + el paquete npm wpxml2md, o
• Un script PHP custom que llame a wp_get_post_data() y serialice cada post a Markdown.

Lo importante es que el frontmatter acabe con:

---
title: "Título original del post"
description: "El meta description que Yoast/Rank Math emitía"
pubDate: 2023-08-15
updatedDate: 2025-02-01      # si WP tenía 'modified' date
slug: "slug-original-wp"
locale: "es"
tags: ["categoria-wp-1", "tag-wp-1"]
readingMinutes: 7
canonical: "/blog/slug-original-wp/"
---

Cada campo de ahí arriba es algo que Google o tus lectores ven. Si pierdes alguno, la migración filtra señales SEO.

4. Mapea el schema de WP a JSON-LD de Astro

Aquí es donde la mayoría de migraciones se rompen. Yoast emite alrededor de una docena de bloques application/ld+json por página: Article, Person, Organization, BreadcrumbList, FAQPage, WebSite con SearchAction, WebPage. Astro no emite nada de eso por defecto — tienes que hacerlo tú.

Mi Layout base incluye un prop jsonLd que recibe un array de objetos:

<Layout
  jsonLd={[articleLd, breadcrumbLd, faqLd]}
>

Cada schema se renderiza como un <script type="application/ld+json"> separado. Yo siempre emito:

• Article (o BlogPosting) con headline, image, author, publisher.logo, datePublished, dateModified, inLanguage, keywords y mainEntityOfPage.
• BreadcrumbList para cualquier página que no sea home.
• Person + Organization en home.
• FAQPage si el post o página tiene Q&A.

Pasa cada URL por Schema.org Validator tras el launch. Si ves menos schemas que los que tenía WP, vas a perder visibilidad de rich results.

5. Construye el mapa de redirects 301 ANTES de ir live

No negociable. Cada URL que existía en WordPress tiene que:

1. Resolver en el mismo path en la nueva web (200 OK), o
2. Hacer 301 al nuevo path con contenido equivalente.

Escribo el mapa como un fichero _redirects plano (sintaxis Netlify / Cloudflare Pages):

/2024/03/15/mi-post   /blog/mi-post   301
/category/noticias    /blog/tag/noticias   301
/feed                 /rss.xml         301
/sitemap.xml          /sitemap-index.xml 301

Testea cada línea con curl -I antes del launch. Un redirect que devuelve 200 en lugar de 301 es una herida SEO autoinfligida.

6. Ejecuta la pasada QA de dos entornos

Antes de tocar DNS, hostea el build de Astro en una URL preview y crawléala con Screaming Frog. Compara con el crawl de WordPress. Estás buscando:

• Mismo número de URLs indexables (con un margen de 2% — desvíos pequeños son normales, 10% es que algo se ha roto).
• Todos los canonical apuntando a URLs absolutas de producción.
• Todos los hreflang correctos para webs multi-idioma.
• Todos los meta descriptions presentes y únicos.
• Todos los H1 presentes y únicos por página.

Si alguno falla, fíxalo antes del launch. Después es demasiado tarde — Google va a recrawlear tus errores nuevos.

7. Envía sitemaps frescos el día del launch

La hora que tocas DNS:

1. Reenvía el nuevo sitemap-index.xml en Google Search Console.
2. Reenvía en Bing Webmaster Tools.
3. Usa “URL Inspection” en GSC para pedir indexación en tus 10 páginas top de tráfico.
4. Vigila el reporte “Coverage” de GSC los siguientes 7 días — quieres ver URLs de WordPress pasar de Indexed a Page with redirect, y las nuevas URLs Astro pasar a Indexed.

Si ves un spike de errores Not found (404), te has saltado un redirect. Encuéntralo en el export de GSC y añade el 301.

8. Los primeros 90 días: no entres en pánico

Los rankings van a oscilar. Es normal. Google necesita recrawlear, reevaluar las URLs nuevas, y decidir si merecen los mismos rankings. Timeline esperado:

• Semana 1–2: GSC muestra señales mixtas. URLs de WP y de Astro apareciendo a la vez.
• Semana 3–4: La mayoría de URLs WP pasan a “Page with redirect” y desaparecen de búsqueda. Las Astro las reemplazan.
• Semana 5–8: Rankings se estabilizan. Páginas pueden moverse 2–5 posiciones temporalmente para sus keywords objetivo.
• Semana 9–12: Nuevo estado estable. Si tus Core Web Vitals ahora están verdes donde WP los tenía rojos, normalmente verás GANANCIAS pequeñas de ranking porque Google premia la mejor page experience.

No hagas cambios durante esta ventana. Sin tweaks de URL, sin cambios de schema, sin experimentos de internal linking. Deja que se asiente el polvo, luego optimiza.

Errores comunes de migración (que he visto y arreglado)

• Olvidar el feed RSS. WordPress emite uno en /feed/. Los suscriptores (y Feedly, y Google News) necesitan 301 a tu nuevo /rss.xml.
• Perder el path del sitemap XML. WordPress emite /sitemap_index.xml; Astro emite /sitemap-index.xml por defecto. 301 del viejo al nuevo.
• Saltarse las páginas de archivo de autor. Si rankeabas para /author/tuname/, redirígelo a /about (no 404).
• Olvidar deshabilitar la API wp-json de WP. Va a seguir respondiendo desde el origen WP si no la apagas, y los bots la seguirán crawleando.
• Dejar que WordPress redirija al login al acceder URLs viejas. Si mantienes el install WP como fallback, configura cada URL para 301 al nuevo sitio — no para redirigir a /wp-login.php.

Cuándo NO migrar

WordPress es la respuesta correcta si:

• Tu equipo editorial es grande y está comprometido con el editor Gutenberg (Astro requiere Markdown o un CMS headless).
• Dependes de plugins para forms, e-commerce, membership o LMS, y reemplazarlos es más trabajo del que merece la pena.
• Tu tráfico es de pago (ads), y el SEO no importa — no hay upside en migrar.

Si ninguna de esas describe tu caso, y el Lighthouse está consistentemente bajo 80, la migración se paga sola en 6–12 meses con el lift de conversión y el momentum de SEO.

---

Si estás pensando en migrar desde WordPress y quieres un presupuesto cerrado del paquete entero (export, redirects, schema, reescritura de contenido, deploy, 30 días de soporte post-launch), envíame un brief — los hago end-to-end, normalmente en 3–5 semanas para una web de 50–200 posts.