Una migración puede minimizar el riesgo, pero nadie puede garantizar que conservará exactamente el mismo tráfico. Google advierte que los cambios importantes pueden producir fluctuaciones mientras vuelve a rastrear e indexar las URLs. Por eso esta página ya no presenta un resultado de cliente ni afirma una pérdida de cero.
El objetivo es mostrar qué registros permiten evaluar una migración con honestidad. La referencia principal es la guía oficial de Google para cambios de URL.
Antes de fijar una fecha
La migración necesita un inventario que combine varias fuentes. Sitemap, CMS, analítica, Search Console, backlinks y logs aportan URLs diferentes. Cada fila debe registrar al menos:
| Campo | Motivo |
|---|---|
| URL antigua y destino propuesto | Hace auditable el mapa uno a uno |
| Estado, canonical y robots actuales | Detecta problemas que no deben trasladarse |
| Tráfico y consultas del periodo base | Prioriza páginas con demanda observada |
| Enlaces internos y externos | Identifica rutas que no pueden quedar huérfanas |
| Tipo de decisión | Conservar, consolidar o retirar con 404/410 |
| Responsable y prueba | Evita que una regla quede sin propietario |
Una URL retirada no debe enviarse a la homepage por conveniencia. Google recomienda responder con 404 o 410 cuando el contenido desaparece y no existe un reemplazo relevante.
Pruebas en el entorno previo
El mapa se valida antes del lanzamiento. Cada URL antigua debe llegar en un salto a un destino que responda 200 y represente la misma intención. También se comprueban canonicals, hreflang, enlaces internos, sitemap, robots, assets y códigos de estado.
La muestra manual no sustituye el test completo. Un archivo automatizado puede recorrer todas las filas y fallar si encuentra cadenas, loops, destinos no indexables o redirecciones hacia páginas irrelevantes.
Un 301 correcto no demuestra que la migración esté completa. Solo confirma una relación técnica. Todavía hay que revisar contenido, navegación, medición y comportamiento de Googlebot.
Ventana de lanzamiento
El registro de cambio debe incluir hora, versión desplegada, persona responsable y forma de rollback. Durante las primeras horas se vigilan errores 5xx, 404 inesperados, carga del servidor y eventos de analítica. No conviene cambiar al mismo tiempo dominio, CMS, diseño, arquitectura y copy si esos movimientos pueden separarse.
Google también recomienda verificar las propiedades antiguas y nuevas en Search Console, enviar el sitemap nuevo y mantener los redirects. El rastreo ocurre URL por URL y no tiene una frecuencia fija.
Cómo medir el resultado
La comparación usa grupos equivalentes, no solo el total del sitio:
- URLs prioritarias con destino uno a uno
- páginas consolidadas
- secciones retiradas
- imágenes y otros recursos que recibían tráfico
- países o idiomas afectados.
Por grupo se revisan clics, impresiones, consultas, páginas indexadas, respuestas del servidor y sesiones. El periodo anterior debe ser comparable por día de la semana y estacionalidad. Campañas, cambios de demanda y problemas de tracking se anotan como factores de confusión.
Una conclusión defendible puede ser: “el grupo de URLs prioritarias recuperó su rango habitual dentro del periodo observado”. No puede ser “se preservó el 100%” si faltan exportaciones, fechas, criterios y registros de lanzamiento.
Expediente mínimo para llamar a esto un caso
Un caso publicable necesita el mapa anonimizado, el alcance, fechas, captura o exportación de Search Console, registros de despliegue, pruebas de redirects y autorización del cliente. Sin ese expediente, corresponde presentar el método, como se hace aquí.