Migración SEO: cambiar de dominio sin perder tráfico

Todo eso viaja por un solo canal: las redirecciones. Si el mapa está bien hecho, se pierde poco; si no, se pierde casi todo.

Qué se mueve y qué se queda

Conviene ser preciso con qué cuenta como migración, porque el riesgo cambia mucho.

Cambiar de dominio, cambiar la estructura de las URLs o pasar de http a https son migraciones: cambia la dirección de las páginas, y hay que decirle a Google a dónde fueron.

Cambiar el diseño sin tocar las direcciones no lo es. Cambiar de servidor tampoco. Son riesgosos por otros motivos, pero no obligan a rehacer el mapa.

La distinción práctica: si después del cambio una URL vieja deja de devolver la página que devolvía, es una migración.

Los 5 pasos, en orden

El orden no es una sugerencia. El paso 2 —mapear— hay que hacerlo con el sitio viejo todavía en pie, porque es la única forma de saber qué existía.

1. Inventariar todo lo que existe hoy

No alcanza con el sitemap: el sitemap tiene lo que vos creés que existe.

Hacen falta tres fuentes cruzadas:

1. El sitemap, que da la lista declarada.
2. Search Console, informe de páginas: ahí están las que Google conoce, incluidas las que vos olvidaste.
3. Los registros del servidor, que muestran las que reciben visitas de verdad, incluidas las que ningún enlace interno alcanza. Cómo leerlos está en análisis de logs para SEO.

La tercera fuente es la que aparece siempre con sorpresas: URLs viejas de campañas, PDFs enlazados desde otro sitio, páginas huérfanas que igual reciben gente.

2. Mapear URL por URL

Es el paso aburrido y el que decide el resultado.

Una planilla con dos columnas: la dirección vieja y la nueva. Una fila por URL. La plantilla está hecha, con las columnas de comprobación incluidas. Sin reglas generales del tipo “todo lo de /blog/ va a /articulos/”, porque las excepciones son justo las páginas que importan.

✓Un mapa que conserva el tráfico

• Cada URL vieja apunta a su equivalente más cercana
• Si no hay equivalente, va a la categoría de ese tema
• Las que no tienen destino razonable devuelven 410
• El mapa se revisa a mano antes de aplicarlo

✕Uno que lo tira

• Todo lo que no coincide va a la portada
• Una regla general con expresiones regulares y nada más
• Las que sobran quedan en 404 sin decidirlo
• Se aplica y se revisa después, si hay tiempo

Ese primer punto de la derecha merece insistencia, porque se hace todo el tiempo. Una redirección a la portada le dice a Google que la página vieja no tiene equivalente: la trata como borrada y no traslada nada.

3. Redirigir con 301, y sin cadenas

La 301 es la que dice «esto se mudó para siempre» y es la que traslada las señales. La diferencia con la 302 y cuándo corresponde cada una está en redirecciones 301.

Lo que casi siempre sale mal es la cadena: la URL vieja apunta a una intermedia que apunta al destino. Pasa cuando el sitio ya tenía redirecciones de una mudanza anterior.

La regla: cada URL vieja apunta directo al destino final. Si ya había redirecciones, hay que reescribirlas para que salten el intermedio.

4. Comprobar antes de que lo descubra Google

Con el sitio nuevo arriba, recorrer la columna vieja de la planilla y comprobar que cada una llegue a donde debía, con un solo salto.

while read url; do
  printf '%s → %s\n' "$url" "$(curl -sI -o /dev/null -w '%{http_code} %{redirect_url}' "$url")"
done < urls-viejas.txt

Lo que hay que buscar: cualquier 404, cualquier 302 que debía ser 301, y cualquier destino que no sea el de la planilla.

A partir de cierto tamaño esto no se hace a mano: cuándo se justifica una herramienta de rastreo está en herramientas de rastreo.

5. Esperar sin tocar nada

Es el paso que más cuesta y el más importante.

Google necesita volver a rastrear todo, seguir cada redirección y trasladar las señales. Eso lleva semanas, y durante ese tiempo los números bajan.

Cuánto es normal caer

La curva típica de una migración bien hecha

10-20 %Semanas 1 a 3Caída normal mientras Google reprocesa

RecuperaciónSemanas 4 a 8Vuelve, a veces por encima

Sigue abajoMes 3Ahí hay un problema real, no paciencia

La distinción importa porque define cuándo actuar. En la semana dos, mirar los datos y no tocar nada es lo correcto. En el mes tres, esperar más es perder el tiempo.

Si a los tres meses no volvió, lo primero que hay que revisar no es el contenido: es la planilla del paso 2, buscando URLs que se quedaron sin destino.

Los 4 errores que explican casi todas las migraciones fallidas

1. Cambiar varias cosas a la vez. Dominio, diseño, estructura de URLs y contenido en el mismo lanzamiento. Si cae el tráfico, no hay forma de saber cuál fue. Conviene separarlas por semanas.

2. No inventariar antes. Una vez que el sitio viejo bajó, reconstruir qué URLs existían es arqueología: quedan Search Console y lo que haya en el archivo de la web.

3. Dejar el sitio viejo apagado sin redirecciones. Un dominio que deja de responder no transmite nada. Las redirecciones tienen que vivir en el servidor viejo, y ese servidor tiene que seguir encendido al menos un año.

4. Bloquear el sitio nuevo sin querer. El robots.txt del entorno de pruebas, con su Disallow: /, sale a producción. Es el clásico, y se detecta en dos minutos: qué se puede y qué no con el robots.txt.

Qué hacer el día del cambio

Una lista corta para el momento en que se levanta el sitio nuevo:

1. Comprobar que el robots.txt nuevo no bloquee nada que no quieras.
2. Comprobar que no haya quedado un noindex de las pruebas: el diagnóstico de indexación.
3. Enviar el sitemap nuevo en Search Console, y dejar el viejo hasta que se procese.
4. Si cambió el dominio, usar la herramienta de cambio de dirección de Search Console. No reemplaza a las redirecciones: las acompaña.
5. Anotar la fecha. Sin ese dato, dentro de dos meses nadie va a poder relacionar una caída con la mudanza.

La documentación oficial de Google sobre migraciones, con la distinción entre las que cambian URLs y las que no, está en su guía de migraciones.