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, tu sitio compila más rápido, carga más rápido y cuesta menos alojarlo. Pero si las URLs del blog cambiaron durante la migración —por ejemplo, de /post-slug/ a /insights/post-slug— es probable que tengas problemas de SEO que solo afloran semanas después, cuando Google termina de rastrear el sitio de nuevo.

Google Search Console empezará a enviarte correos sobre «Duplicado: Google eligió un canonical diferente al indicado por el usuario» y «Validación fallida: No encontrado (404)». Tus páginas con mejor rendimiento pueden estar perdiendo autoridad de enlace a través de saltos de redirección innecesarios. Y puede que tengas dos sitemaps compitiendo entre sí 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ás

Acceso SSH a tu servidor (configuración de nginx)
Acceso a Google Search Console para tu propiedad
curl instalado en local
Herramienta de analíticas (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 en conflicto consolidados en una única fuente generada automáticamente
Páginas con noindex eliminadas del sitemap
Propiedades obsoletas de GSC y sitemaps heredados de WordPress limpiados
Confusión de canonical entre la estructura de URLs antigua y la nueva

Paso 1: Diagnosticar las cadenas de redirecciones

Comprueba cuántas redirecciones atraviesan tus URLs principales. Si las URLs de WordPress llevaban barra final y las de Astro no, es probable que tengas 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, tienes una cadena de redirecciones. Ejecuta esto para tus cinco páginas con más tráfico —son en las que más importa no perder autoridad de enlace.

Cruza los datos con tus analíticas. Si ves el mismo artículo apareciendo bajo varias variantes de URL (con barra, sin barra, con el nuevo prefijo), tus 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 confirmó el problema con la cadena.

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 impactando en una segunda regla que redirige /slug a /insights/slug. Dos saltos.

Sustitúyela por una regla que conoce 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://yourdomain.com/insights/$slug;
    }
    return 301 https://yourdomain.com/$slug;
}
# Multi-segment paths — just strip the slash
location ~ ^(.+)/$ { return 301 $1; }

La primera regla gestiona los slugs en la raíz (tus antiguas URLs de WordPress). Comprueba si existe una página coincidente bajo /insights/ y redirige allí directamente. Las rutas que no son del blog pasan a la eliminación genérica de la barra. Tras el despliegue, verifica:

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

Comprueba si tienes 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, tienes sitemaps en conflicto. Comprueba cuál referencia el robots.txt:

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

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

Revisa también el sitemap estático en busca de páginas con noindex. Si tu sitemap.xml lista páginas como /legal o /privacy-policy que tienen <meta name="robots" content="noindex">, estás 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

Abre GSC y comprueba dos cosas: propiedades y sitemaps.

Propiedades: Si tienes tanto una propiedad de dominio (sc-domain:yourdomain.com) como una propiedad de prefijo de URL (https://www.yourdomain.com/), recibirás alertas duplicadas por los mismos problemas. Quédate con una. Si tus subdominios son proyectos separados, la propiedad de prefijo de URL es más limpia: solo informa del tráfico en producción.

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

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

Paso 5: Verificar todo

Ejecuta 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 de canonical —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 backlinks e historial de clics, Google puede seguir eligiéndola como canonical durante varias semanas.

La combinación de redirecciones limpias, un único sitemap autoritativo y una propiedad de GSC consolidada ofrece a Google la señal más clara posible. En nuestro caso, vimos que las advertencias de «canonical duplicado» 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 tienes problemas de SEO tras una migración, contáctanos.