Migración SEO: cómo se mueve un sitio sin perder tráfico
Migración SEO es el conjunto de planificación, ejecución y QA cuando un sitio cambia de plataforma, dominio, estructura de URLs o todo a la vez. Hecha bien, es transparente para Google. Hecha mal, baja entre 30% y 70% del tráfico orgánico — y recuperarlo después puede tomar 6-12 meses si es que se recupera.
Por qué tantas migraciones rompen SEO
Hay un patrón que se repite. La decisión de migrar viene de un equipo no-SEO — diseño, IT, dirección general — con foco en mejorar UX, performance o reducir technical debt. SEO entra al final, cuando ya hay decisiones tomadas que son difíciles de revertir. La estructura nueva no preserva la URL canónica de las páginas que más tráfico generan, los redirects se planifican apurados o no se planifican, y se lanza un viernes a la tarde.
El resultado típico: caída de 30-50% de tráfico orgánico en las primeras 4 semanas post-launch, semanas de debugging para entender por qué, parches de redirect y meta tags, y recuperación parcial 3-6 meses después. Las pérdidas que no se recuperan son las páginas long tail que rankeaban hace años — Google las pierde y no vuelve a indexarlas.
Las cuatro etapas que importan
Discovery + audit
Inventario completo de URLs actuales con tráfico, posiciones, conversiones. Identificar qué se preserva, qué se consolida, qué se deprecia.
Redirect map
Cada URL legacy mapeada 1:1 a su URL nueva. Sin patrones genéricos. Cada redirect documentado con destino y razón.
Pre-launch QA
Staging environment con todo el redirect map cargado. Crawl completo en staging. Validación de schema, sitemap, robots, canonicals.
Post-launch monitoring
Monitoreo intensivo primeras 4 semanas. GSC index coverage diario, comparación de queries y posiciones, parches de redirects que rompieron.
Redirect map: donde se gana o se pierde la migración
El redirect map es el documento que mapea cada URL legacy con tráfico/autoridad a su URL equivalente nueva. No es opcional. No es “lo armamos después”. Es el activo más importante de la migración y debe estar firmado y validado antes de planificar el launch.
Reglas que aplico siempre: redirects 301 (permanentes), nunca 302 — los 302 no transfieren autoridad. Mapeo 1:1 con destino específico — nunca redirigir todo a la home como fallback (Google interpreta como soft 404). Los redirects no deben encadenarse — A → B → C es mucho peor que A → C directo. Profundidad máxima un hop.
Caso típico que pierde tráfico: redirect chains heredadas de migraciones anteriores. Un sitio que ya migró tres veces puede tener URLs legacy con 4-5 hops antes de llegar al destino actual. Cada hop diluye autoridad y aumenta tiempo de respuesta. Auditar y aplanar estas cadenas antes de la migración nueva es trabajo invisible pero enorme retorno.
Content audit: qué preservar, qué deprecar
El content audit pre-migración cataloga cada URL del sitio actual con métricas: tráfico orgánico (últimos 12 meses), posiciones promedio en queries top, conversiones atribuibles, backlinks de calidad, fecha de última actualización. Con esa data se decide en cuál de tres categorías va cada URL.
Preservar: URLs con tráfico significativo, autoridad, backlinks. Estas migran 1:1 con su redirect mapeado. Consolidar: URLs con tráfico bajo pero relacionadas a un tema fuerte se consolidan en una URL nueva más comprensiva (canonical múltiple). Deprecar: URLs con cero tráfico, contenido obsoleto, sin backlinks. Estas se eliminan, redirigidas a la categoría madre o un hub relacionado.
El error frecuente es preservar todo “por las dudas”. Migrar 50.000 URLs cuando 5.000 tienen tráfico real diluye crawl budget y mantiene contenido thin que Google ya estaba penalizando. Una migración es la oportunidad de limpiar.
Post-migration QA: las primeras 4 semanas
Las primeras 4 semanas post-launch son críticas. Lo que se hace ahí determina si la migración es transparente o si se convierte en proyecto de recuperación. El stack de QA que sostengo: dashboard diario en Looker Studio con queries top, posiciones, índice de URLs nuevas, errores de cobertura en GSC; crawl semanal completo del sitio nuevo + lista de URLs legacy para verificar redirects; comparación día por día con baseline pre-migración.
Las cosas que hay que mirar específicamente: páginas que cayeron del top 10 al top 50 (señal de pérdida de autoridad por redirect roto), URLs nuevas con “Crawled – currently not indexed” en GSC (Google no las quiere indexar — calidad o duplicación), spike de 404s en logs (redirects que faltaron), cambios drásticos en CTR (titles/metas que cambiaron sin querer).
Cómo se aplica en la práctica
El stack típico de una migración enterprise: discovery 4-6 semanas antes, redirect map firmado 2 semanas antes, staging QA la semana del launch, post-launch monitoring intensivo 4 semanas. Cada migración tiene su perfil de riesgo distinto — un cambio de plataforma con misma URL es bajo riesgo, un cambio de dominio + estructura de URLs es alto. La metodología completa de migración con casos reales está en /servicios/migracion-seo/ y casos en /casos/.