Corregir el SEO tras una migración de WordPress a Astro: cadenas de redirecciones, sitemaps y limpieza de GSC

Después de migrar de WordPress a Astro, su sitio compila más rápido, carga más rápido y cuesta menos alojarlo. Pero si las URL del blog cambiaron durante la migración —por ejemplo, de /post-slug/ a /insights/post-slug— es probable que tenga problemas de SEO que solo afloran semanas después, cuando Google termina de rastrear el sitio de nuevo.

Google Search Console empezará a enviarle correos sobre «Duplicado: Google ha elegido una versión canónica diferente a la del usuario» y «Validación fallida: No encontrado (404)». Sus páginas con mejor rendimiento pueden estar pasando por saltos de redirección innecesarios. Y puede que esté manteniendo dos sitemaps con contenido superpuesto sin saberlo.

Esta guía explica cómo encontrar y corregir estos problemas. Nos los encontramos todos durante nuestra propia limpieza de SEO tras la migración de WordPress a Astro, y aquí documentamos las soluciones.

Lo que necesitará

Acceso SSH a su servidor (configuración de nginx)
Acceso a Google Search Console para su propiedad
curl instalado en local
Herramienta de analítica (nosotros usamos Plausible autoalojado)

Qué soluciona esta guía

Cadenas de redirecciones con varios saltos (2 o más) reducidas a 301 de un solo salto
Sitemaps duplicados consolidados en una única fuente generada automáticamente
Páginas con noindex eliminadas del sitemap
Propiedades obsoletas de GSC y sitemaps heredados de WordPress eliminados
Confusión sobre la URL canónica entre la estructura de URL antigua y la nueva

Paso 1: diagnosticar las cadenas de redirecciones

Compruebe cuántas redirecciones atraviesan sus URL principales. Si las URL de WordPress llevaban barra final y las de Astro no, es probable que tenga una cadena de dos saltos: una redirección elimina la barra y otra añade el nuevo prefijo de ruta.

curl -sL -w "Hops: %{num_redirects}, Final: %{http_code}, URL: %{url_effective}\n" \
  -o /dev/null "https://yourdomain.com/old-post-slug/"

Si la salida muestra Hops: 2, tiene una cadena de redirecciones. Ejecute esto para sus cinco páginas con más tráfico —son en las que más importan los saltos adicionales.

Cruce los datos con su herramienta de analítica. Si ve el mismo artículo apareciendo bajo varias variantes de URL (con barra, sin barra, con el nuevo prefijo), sus redirecciones no están consolidando el tráfico. Nosotros vimos nuestro artículo más visitado repartido en tres variantes de URL en Plausible, lo que nos llevó a realizar la comprobación de redirecciones descrita arriba.

Paso 2: configurar nginx para redirecciones de un solo salto

La regla estándar de nginx para eliminar la barra final tiene este aspecto:

location ~ ^(.+)/$ { return 301 $1; }

Esta regla elimina la barra final pero no tiene en cuenta el cambio de ruta del blog. La solicitud acaba llegando a una segunda regla que redirige /slug a /insights/slug. Dos saltos.

Sustitúyala por una regla que tiene en cuenta la estructura del blog: comprueba si el slug coincide con una entrada y redirige directamente a la URL final:

# Blog slugs with trailing slash — single-hop to /insights/
location ~ ^/([^/]+)/$ {
    set $slug $1;
    if (-f /usr/share/nginx/html/insights/$slug/index.html) {
        return 301 https://www.yourdomain.com/insights/$slug;
    }
    return 301 https://www.yourdomain.com/$slug;
}
# Multi-segment paths — just strip the slash
location ~ ^(.+)/$ { return 301 https://www.yourdomain.com$1; }

La primera regla gestiona los slugs en la raíz (sus antiguas URL de WordPress). Comprueba si existe una página coincidente bajo /insights/ y redirige allí directamente. Las demás rutas en la raíz reciben una única redirección que elimina la barra desde esa misma regla; las rutas con varios segmentos coinciden con la segunda regla, la genérica. Tras el despliegue, verifique:

curl -sL -w "Hops: %{num_redirects}\n" -o /dev/null \
  "https://yourdomain.com/your-top-post-slug/"
# Expected: Hops: 1

Paso 3: consolidar los sitemaps

Compruebe si tiene más de un sitemap. Un patrón habitual tras la migración: un sitemap.xml estático creado manualmente durante el traslado, más un sitemap-index.xml generado automáticamente por la integración @astrojs/sitemap de Astro.

# Check both
curl -sI "https://yourdomain.com/sitemap.xml" | head -1
curl -sI "https://yourdomain.com/sitemap-index.xml" | head -1

Si ambos devuelven 200, está manteniendo dos sitemaps que pueden desincronizarse. Compruebe cuál referencia el robots.txt:

curl -s "https://yourdomain.com/robots.txt" | grep -i sitemap

La solución: elimine el sitemap.xml estático del directorio public/, actualice el robots.txt para que apunte al sitemap-index.xml, y deje que la integración de Astro se encargue de todo. Las nuevas entradas aparecerán automáticamente en cada compilación.

Revise también el sitemap estático en busca de páginas con noindex. Si su sitemap.xml lista páginas como /legal o /privacy-policy que tienen <meta name="robots" content="noindex">, está enviando señales contradictorias a Google. El sitemap generado automáticamente por @astrojs/sitemap se puede configurar con reglas de filtrado para excluir estas páginas correctamente.

Paso 4: limpiar Google Search Console

Abra GSC y compruebe dos cosas: propiedades y sitemaps.

Propiedades: Si tiene tanto una propiedad de dominio (sc-domain:yourdomain.com) como una propiedad de prefijo de URL (https://www.yourdomain.com/), recibirá alertas duplicadas por los mismos problemas. Puede conservar ambas, pero si los correos duplicados le resultan molestos, elija una. Si sus subdominios son proyectos separados, la propiedad de prefijo de URL es más limpia: solo informa sobre las URL bajo ese prefijo exacto, como las de su host www de producción.

Sitemaps: Vaya a Indexación → Sitemaps. Elimine cualquier sitemap antiguo de WordPress que siga registrado ahí (post-sitemap.xml, page-sitemap.xml, sitemap-post-type-product.xml, etc.). Envíe su nuevo sitemap-index.xml como único sitemap.

Validación de 404: Vaya a Indexación → Páginas → «No encontrado (404)» y revise qué URL aparecen. Si son rutas antiguas de WordPress que ya no existen ni deben existir (páginas de productos de WooCommerce, páginas de autor, URL de feeds), se desindexarán con el tiempo. Si son entradas del blog que deberían redirigir, necesita actualizar las reglas de nginx. Tras corregir las redirecciones, haga clic en «Validar corrección» para activar un nuevo rastreo.

Paso 5: verificar todo

Ejecute estas comprobaciones después de desplegar los cambios:

# 1. Redirect chains resolved
curl -sL -w "Hops: %{num_redirects}, URL: %{url_effective}\n" \
  -o /dev/null "https://yourdomain.com/your-top-post/"
# Expected: Hops: 1, URL ends in /insights/your-top-post

# 2. robots.txt points to generated sitemap
curl -s "https://yourdomain.com/robots.txt" | grep sitemap
# Expected: sitemap-index.xml

# 3. Old static sitemap returns 404
curl -sI "https://yourdomain.com/sitemap.xml" | head -1
# Expected: 404

# 4. Generated sitemap returns 200
curl -sI "https://yourdomain.com/sitemap-index.xml" | head -1
# Expected: 200

# 5. Non-www redirects to www
curl -sI -o /dev/null -w "%{http_code} %{redirect_url}\n" \
  "https://yourdomain.com/insights"
# Expected: 301 https://www.yourdomain.com/insights

Cuánto tarda Google en ponerse al día

Las redirecciones de un solo salto surten efecto inmediatamente en los nuevos rastreos. Los cambios en el sitemap se detectan en pocos días. La confusión sobre la URL canónica —en la que Google prefiere la URL antigua sobre la nueva— tarda más en resolverse. Google trata la etiqueta <link rel="canonical"> como una sugerencia, no como una directiva. Si la URL antigua acumula más enlaces entrantes e historial de clics, Google puede seguir eligiéndola como URL canónica durante varias semanas.

La combinación de redirecciones limpias y un único sitemap de referencia ofrece a Google la señal más clara posible; una propiedad de GSC consolidada facilita el seguimiento de los informes restantes. En nuestro caso, vimos que las advertencias de «versión canónica duplicada» empezaron a disminuir dos semanas después de desplegar estas correcciones.

Gestionamos este tipo de migraciones de forma habitual como parte de nuestro trabajo de rendimiento y migración de WordPress. Si tiene problemas de SEO tras una migración, contáctenos.