Migración SEO: guía paso a paso con checklist y mapa

La mayoría de migraciones que se estropean no fallan por un detalle exótico. Fallan porque el mapa de redirecciones se hizo con una sola fuente de URLs, porque el noindex del entorno de pruebas viajó a producción o porque nadie definió qué haría falta ver para dar marcha atrás. Todo eso se decide antes del día del lanzamiento.

Esta guía recorre una migración de principio a fin, con el criterio con el que la plantearía como consultor: tipos, inventario, mapa, staging, despliegue, monitorización, errores y reversión. Lo ya desarrollado en otros artículos lo enlazo; aquí está el orden de trabajo. Si quieres ver cómo encaja en un proyecto completo, está la metodología de proyectos SEO que sigo.

Qué es una migración SEO y qué tipos hay

Google agrupa en su guía de traslado de sitios con cambios de URL tres casos: de HTTP a HTTPS, cambios de nombre de dominio (incluida la fusión de dominios o hosts) y cambios en la ruta de las URLs. Aparte, tiene una guía distinta para traslados sin cambio de URLs, como cambiar de hosting o poner un CDN. En la práctica yo manejo esta clasificación:

La última columna sale de la documentación de la herramienta, que explico más abajo. Para HTTPS y www, el artículo sobre versiones www y http detalla cómo elegir la versión y dejar una sola redirección; no lo repito. Si la migración implica además repensar la estructura de la web, eso es trabajo de arquitectura web y conviene hacerlo antes, no durante el lanzamiento.

Un principio de Google vale para todos: cambiar una sola cosa cada vez, una tras otra. En webs pequeñas o medianas recomienda mover todas las URLs a la vez; en las grandes puedes ir por secciones.

Antes de tocar nada: inventario de URLs y línea base

El inventario es la lista de todo lo que tiene URL y puede recibir tráfico, enlaces o rastreo. Google indica fuentes para obtenerla: sitemaps, logs del servidor, analítica, los datos de enlaces de Search Console y el propio CMS, e incluye imágenes, vídeos, JavaScript y CSS. Un rastreo solo ve lo que está enlazado hoy, y se queda corto: Search Console añade las URLs con impresiones, los logs las que Googlebot pide de verdad y los backlinks las que tienen enlaces externos.

Los logs son la fuente que más se omite; cómo sacarles partido está en análisis de logs SEO.

La línea base

Antes del lanzamiento guardo una fotografía para poder comparar: clics, impresiones y posición media por sección en Search Console; sesiones orgánicas y conversiones; número de URLs indexables según el rastreo; peticiones diarias de Googlebot y su reparto por código de respuesta; y una exportación de las posiciones de las keywords principales. Añade una copia de seguridad completa de la web antigua: hace posible la reversión. Sin esa fotografía, hablar de «cuánto hemos perdido» es opinión.

El mapa de redirecciones 1:1

Google pide mapear cada URL antigua con su equivalente nueva y guardar ese mapeo en una base de datos o en reglas de reescritura. Para dominios completos, una regla comodín en el servidor puede bastar; para cambios de estructura, no. Tipos de redirección, cadenas y qué se transmite en cada caso están en el artículo sobre tipos de redirecciones SEO; aquí lo que importa es el documento de trabajo.

La plantilla que uso tiene seis columnas:

Reglas que aplico al rellenarlo:

• Cada URL antigua con tráfico, enlaces o impresiones tiene destino equivalente. Si el destino no existe, la decisión es crearlo o devolver 404/410, no mandarla a la home.
• El destino siempre es la URL final: indexable, con 200 y con canonical a sí misma. Si el destino ya redirige, el mapa está mal.
• Las imágenes, los PDF y demás archivos entran en el mapa. Google los incluye expresamente en las URLs a considerar.
• Las URLs retiradas sin sustituto llevan 404 o 410, como indica Google para el contenido eliminado o fusionado. La diferencia entre ambos está en errores 404 y soft 404.

Staging: cómo evitar que el noindex llegue a producción

El entorno de pruebas debe estar fuera del índice. Google propone para ese caso un host temporal o restringido por IP y un noindex; la guía de traslados advierte además de preparar la versión de producción del robots.txt si bloqueaste el rastreo durante el desarrollo, y de listar las reglas noindex que habrá que quitar al lanzar. Es el fallo más repetido porque nadie ve el problema: la web carga bien.

Mi protocolo para que no se escape:

1. Poner el bloqueo de staging en un único lugar (una cabecera X-Robots-Tag de servidor o una variable de entorno), no repartido por plantillas.
2. Escribir en el plan de lanzamiento el paso explícito «quitar bloqueo de staging», con responsable.
3. Comprobar, tras el lanzamiento, que ninguna URL del mapa de destino devuelve noindex ni por cabecera ni por meta. Es un bucle de curl; lo dejo al final del artículo, probado.
4. Revisar que robots.txt de producción no es el de staging con su Disallow: /. Cómo interpreta Google ese archivo está en el artículo de robots.txt.

Dos detalles más de la guía de Google: un robots.txt inexistente debe devolver un 404 correcto, y el dominio nuevo no debe arrastrar acciones manuales ni eliminaciones de URL anteriores.

El día del despliegue: qué se activa y en qué orden

Google resume el arranque así: activar las redirecciones, confirmar que los canonical apuntan a las URLs nuevas y quitar los noindex propios de la migración, probar las redirecciones, hacer el Cambio de dirección si procede, y enviar el sitemap nuevo. Yo añado lo que hace falta para que eso salga bien:

1. Servidor preparado. Google rastrea más tras una migración, así que el servidor debe aguantar el aumento. Si responde lento, el rastreo se resiente; el efecto sobre el presupuesto de rastreo está desarrollado en su artículo.
2. Redirecciones 301 en el servidor, no en JavaScript ni con meta refresh. Dónde y cómo escribirlas: .htaccess, Nginx o la configuración de Apache, con un solo salto por URL.
3. Canonicals autorreferenciados en el sitio nuevo. Si el canonical sigue apuntando al dominio antiguo, contradice la redirección. El detalle está en canonicals.
4. hreflang actualizado con las URLs nuevas, en las dos direcciones. Si alguna anotación apunta a una URL que ahora redirige, deja de ser válida; hreflang explica las reglas de reciprocidad.
5. Sitemaps. Google recomienda enviar el sitemap nuevo y mantener también el antiguo durante el seguimiento para ver cómo uno cae y el otro sube; Search Console puede avisar de que las URLs del antiguo redirigen, y es esperable. Los criterios de contenido de un sitemap están en sitemaps XML.
6. Enlaces internos a las URLs finales, y cambio pedido a los enlaces externos de más valor y a las campañas de pago.

Google sugiere elegir un periodo de poca demanda si tu tráfico es estacional. Yo evito el viernes por la tarde: si algo falla, quiero al equipo disponible.

Cambio de dirección en Search Console: cuándo sí y cuándo no

La herramienta está pensada para pasar de un dominio o subdominio a otro, y solo después de haber trasladado y redirigido el sitio. No se usa para HTTP a HTTPS (Google lo detecta solo), ni para www frente a no-www (para eso, canonical y redirecciones), ni para cambios de ruta dentro del mismo sitio, ni cuando cambia el hosting sin cambiar las URLs.

La guía de traslados indica que, en migraciones de dominio, se envíe para todas las variantes verificadas del dominio antiguo. Una cobertura de prensa fecha en junio de 2026 la actualización que añadió expresamente las variantes con y sin www, aunque no las uses.

Lo que la herramienta no hace tiene el mismo peso: no elimina el sitio antiguo del índice, y sus URLs pueden seguir apareciendo si no tienen equivalente en el nuevo. Para unificar varias webs en una, Google sugiere moverlas de una en una. Mantén las redirecciones al menos 180 días, o más mientras Google siga enviando tráfico a las URLs antiguas, y el dominio antiguo registrado al menos un año.

Después: calendario de monitorización

Tras el lanzamiento, el trabajo cambia de preparar a comprobar. Este calendario es mío, no de Google, y coincide con el que publico en mi página de migraciones SEO: diario la primera semana, semanal el primer mes.

Google recomienda mirar el informe de cobertura o indexación (la guía usa los nombres Index Coverage e Index Status; yo miro el informe de indexación de páginas), las consultas de búsqueda, los logs y la analítica.

Qué esperar de la caída transitoria

Lo documentado es poco y conviene reproducirlo con exactitud. Google dice que debes esperar una fluctuación temporal del posicionamiento durante el traslado, que el tráfico bajará en el sitio antiguo y subirá en el nuevo, que en un sitio pequeño o mediano pueden hacer falta unas semanas para que la mayoría de páginas se muevan y que en uno grande tarda más. Añade que el traslado se produce URL a URL y que Googlebot debe visitar cada URL antigua y nueva al menos una vez.

Esa documentación no da cifra de pérdida «normal» ni plazo de recuperación, y no las voy a inventar. Separo tres situaciones: una oscilación general que encaja con lo documentado; una caída concentrada en una sección o plantilla, que suele ser un fallo localizable; y una pérdida que no remite, que pide una auditoría completa.

Errores clásicos y cómo se detectan

Qué devuelve el servidor en cada situación y cómo lo trata Google está en códigos de respuesta del servidor.

Criterios de reversión (rollback)

Revertir es mover de vuelta la configuración: retirar las redirecciones, restaurar el servidor o el DNS antiguos y volver a publicar el sitio previo. Cuanto antes se decida, más barato es. Por eso el criterio se fija por escrito antes de lanzar. Estos son los que uso; son míos, no de Google.

• Revertir: el robots.txt de producción bloquea el rastreo y no se corrige en horas; noindex en una parte relevante del sitio sin arreglo inmediato; un porcentaje alto de URLs del mapa con 404, 5xx o bucle; errores 5xx sostenidos que no se resuelven con capacidad; formularios o checkout rotos que afectan al negocio.
• Corregir sin revertir: un grupo de URLs mal mapeadas, canonicals o hreflang erróneos en una plantilla, sitemaps desactualizados, cadenas de redirecciones puntuales.
• Esperar y medir: descenso de tráfico o variación de posiciones en los primeros días, sin fallos técnicos detrás. Es lo que Google describe como fluctuación temporal.

Un límite: Google no documenta qué pasa si retiras unas redirecciones que ya ha visto. No afirmo que revertir deje todo como estaba, solo que ante un fallo grave es mejor hacerlo pronto.

Migración sin cambio de URLs

Cambiar de hosting, poner un CDN o mover el servidor sin tocar las URLs tiene su propia guía en Google, actualizada el 10 de diciembre de 2025 en la versión que consulté. No hay redirecciones ni Cambio de dirección, pero el riesgo existe. Lo documentado:

• Probar la copia con un host temporal o IP restringida y noindex; verificar que ningún firewall bloquea a Googlebot; mantener la verificación de Search Console en la copia.
• Bajar el TTL del DNS a unas horas, al menos una semana antes, para que las cachés se actualicen antes.
• Al lanzar, retirar los bloqueos y cambiar el DNS; después, vigilar los logs de ambos servidores y el informe de indexación.
• Esperar una caída temporal del ritmo de rastreo, seguida de un aumento gradual a lo largo de varios días, siempre que Googlebot no encuentre problemas serios.
• Apagar el hosting antiguo solo cuando su tráfico llegue a cero.

Añado el chequeo del noindex residual, que aquí también aplica, y comparar el tiempo de respuesta antes y después.

Cómo lo tengo en mi web

Este sitio es PHP con .htaccess, sin CMS. Lo que sigue sale del código de cristofercruz.net. No consta en él ninguna migración de dominio ni un mapa de redirecciones por URL, y no voy a presentar un historial que no tengo: aquí describo el estado actual.

• Versión única. SITE_URL está fijada en includes/config.php como https://cristofercruz.net. El canonical se construye con esa constante y la ruta, así que no depende del host de la petición.
• Redirecciones de host y protocolo. El .htaccess contiene una regla de www a sin www y otra de HTTP a HTTPS, las dos con 301 hacia https://cristofercruz.net en un salto. La de HTTP respeta X-Forwarded-Proto para no crear bucles detrás de un proxy. Con una copia del .htaccess en un Apache 2.4.58, www y HTTP sin www devolvieron 301 a https://cristofercruz.net/blog/cache-seo/?a=1 (ruta y query intactas), y con X-Forwarded-Proto: https no hubo redirección.
• Contenido retirado. /blog/google-io-2025/ responde 410 con X-Robots-Tag: noindex, desde su propio index.php, no desde una regla del servidor. Esa URL no está en sitemap.xml ni en sitemap-blog.xml.
• Páginas inexistentes. La página de error envía 404, Cache-Control: no-store y X-Robots-Tag: noindex, nofollow. Lo comprobé pidiendo /404.php en local; no he verificado qué devuelve producción para una ruta cualquiera.
• Sitemaps y robots.txt. robots.txt no bloquea CSS, JS ni imágenes, y declara los dos sitemaps con la URL absoluta del dominio. El sitemap del blog se genera con SITE_URL; el principal tiene las URLs escritas en el archivo.

Si cambiara de dominio, tendría que tocar SITE_URL, las dos líneas Sitemap: de robots.txt, las URLs fijas de sitemap.xml y las reglas del .htaccess, y empezaría por un mapa 1:1 con todo el contenido del sitio, hecho como se describe arriba.

Cómo verificar el mapa con curl

Verificar a mano ciento cincuenta URLs es lo que hace que no se haga. Este script lee el mapa en CSV (url_antigua,url_nueva,codigo) y comprueba por cada fila el código del primer salto, la cabecera Location, el número de saltos y que el destino final responda 200.

#!/usr/bin/env bash
# Uso: ./verificar-mapa.sh mapa.csv http://host-antiguo [http://host-nuevo]
MAPA=$1; ORIGEN=${2%/}; DESTINO=${3:-$ORIGEN}; DESTINO=${DESTINO%/}
tail -n +2 "$MAPA" | while IFS=, read -r vieja nueva codigo; do
  if [ "$codigo" = "410" ] || [ "$codigo" = "404" ]; then
    got=$(curl -s -o /dev/null -w '%{http_code}' "$ORIGEN$vieja")
    [ "$got" = "$codigo" ] && echo "OK    $vieja -> $got" || echo "FALLA $vieja: esperaba $codigo y devuelve $got"
    continue
  fi
  read -r c1 loc < <(curl -s -o /dev/null -w '%{http_code} %{redirect_url}\n' "$ORIGEN$vieja")
  read -r saltos final cf < <(curl -sL -o /dev/null -w '%{num_redirects} %{url_effective} %{http_code}\n' "$ORIGEN$vieja")
  esperado="$DESTINO$nueva"; errores=""
  [ "$c1" = "$codigo" ]   || errores="$errores primer_salto=$c1(esperado $codigo)"
  [ "$loc" = "$esperado" ] || errores="$errores location=$loc"
  [ "$saltos" = "1" ]     || errores="$errores saltos=$saltos"
  [ "$cf" = "200" ]       || errores="$errores final=$cf"
  [ "$final" = "$esperado" ] || errores="$errores acaba_en=$final"
  [ -z "$errores" ] && echo "OK    $vieja -> $nueva" || echo "FALLA $vieja:$errores"
done

Lo probé contra un Apache 2.4.58 local con un mapa de ocho filas, cuatro correctas y cuatro con fallos introducidos a propósito: una cadena de dos saltos, una redirección a la home, un 302 en lugar de 301 y una URL retirada con 410. Esto devolvió:

OK    /servicios/seo-local.html -> /nuevo/servicios/seo-local/
OK    /blog/post-1 -> /nuevo/blog/guia-unificada/
OK    /blog/post-2 -> /nuevo/blog/guia-unificada/
OK    /contacto.php -> /nuevo/contacto/
FALLA /cadena-a: location=http://127.0.0.1:8421/cadena-mid/ saltos=2
FALLA /promo-2022: location=http://127.0.0.1:8421/ acaba_en=http://127.0.0.1:8421/
FALLA /tmp: primer_salto=302(esperado 301)
OK    /promo-2021 -> 410

Limitaciones: las rutas del CSV no pueden llevar comas y el script comprueba códigos, no contenido. Para el noindex residual, otro bucle (una URL por línea):

#!/usr/bin/env bash
# Uso: ./noindex-residual.sh urls.txt
while read -r u; do
  h=$(curl -sIL "$u" | grep -i '^x-robots-tag:' | grep -i 'noindex')
  m=$(curl -sL "$u" | grep -io '<meta[^>]*name=["'"'"']robots["'"'"'][^>]*noindex[^>]*>')
  [ -n "$h$m" ] && echo "NOINDEX $u  ${h}${m}" || echo "limpia  $u"
done < "$1"

Con tres URLs de prueba, una con <meta name="robots" content="noindex"> y otra con la cabecera X-Robots-Tag: noindex, marcó las dos y dio por limpia la tercera. Después, rastrea el sitio nuevo con la lista del mapa y compáralo con la línea base. Esta revisión forma parte de lo que hago en una auditoría previa al traslado.

Preguntas frecuentes

Referencias y fuentes

1. Site moves with URL changes Google Search Central (actualizada el 20 de agosto de 2026)
2. Site moves without URL changes Google Search Central (actualizada el 10 de diciembre de 2025)
3. Change of Address tool Search Console Help
4. Google’s site move guide now covers www and non-www domain variants PPC Land, 17 de junio de 2026
5. La checklist de migración web definitiva Semrush
6. La guía de migración web que necesitas leer Ahrefs
7. Checklist: cómo hacer una migración SEO IEBS