Migración web: Cómo hacer una sin perder todo tu posicionamiento

El patrón que se repite

Hay un patrón que se repite en casi todas las migraciones web que salen mal. No es un error técnico complejo ni un problema de presupuesto. Es que alguien asumió que otro estaba revisando algo, y nadie lo revisó.

El resultado siempre se ve igual: rankings que caen en las primeras semanas, páginas que desaparecen del índice, tracking que dejó de funcionar sin que nadie se diera cuenta hasta que los reportes del mes siguiente llegaron vacíos.

La buena noticia es que la mayoría de esos problemas son completamente prevenibles. Y casi todos se evitan con el mismo principio: no asumir, verificar.

Lo que tienes que resolver antes de tocar el sitio en vivo

Todo lo que no encuentras en staging lo vas a encontrar en producción. Y encontrarlo en producción es más caro, más lento y más estresante.

El staging tiene que ser invisible para Google

Parece obvio pero ocurre constantemente: el sitio de staging queda indexable. Google lo rastrea, indexa páginas a medio terminar, y cuando el sitio real sale al aire ya hay contenido duplicado dando vueltas en el índice.

La solución es simple: bloquea los crawlers desde el primer día que existe el staging, ya sea con un robots.txt restrictivo o con protección por contraseña. El staging no es un sitio, es un laboratorio. Tiene que comportarse como tal.

Toma un benchmark antes de tocar nada

Una de las cosas que más complica la recuperación post-migración es no saber cuál era el punto de partida. Sin un baseline claro, cualquier caída de tráfico parece una catástrofe y cualquier recuperación parcial parece un éxito.

Antes de empezar, registra las sesiones orgánicas, las posiciones de tus páginas principales, cuántas páginas están indexadas y cuáles son tus URLs de mayor tráfico. Esos números son los que vas a usar para distinguir movimiento normal de un problema real.

Identifica tus páginas críticas y dales trato especial

No todas las páginas pesan igual. Hay un grupo pequeño que concentra la mayor parte del tráfico, los backlinks y las conversiones. Esas páginas necesitan una revisión más exhaustiva en redirects, contenido y links internos que el resto del sitio.

Si tienes que priorizar en algún momento del proceso, prioriza ahí.

Los redirects son el área de mayor riesgo

Un redirect mal hecho no siempre es visible de inmediato. Puede parecer que todo funciona y tres semanas después notar que páginas enteras perdieron posiciones porque los redirects formaban cadenas, apuntaban al home en vez de a la página equivalente, o simplemente no existían.

Mapea todos los redirects antes del lanzamiento. Revisa los que ya existen en el CMS, en el CDN y en Search Console. Cada URL que cambia necesita un destino claro y directo, sin escalas.

Los cambios de URL innecesarios son un riesgo que no vale la pena tomar

Cada vez que cambia una URL, hay trabajo que hacer para preservar las señales que esa URL había acumulado. A veces ese trabajo vale la pena. Muchas veces el cambio no era necesario en primer lugar.

Agregar o quitar trailing slashes sin una regla consistente, cambiar estructuras de carpetas por razones estéticas, mezclar mayúsculas y minúsculas en las URLs: son decisiones que parecen menores y que pueden generar URLs duplicadas, confusión en el rastreo y pérdida de señales innecesaria.

La regla práctica es simple: no cambies lo que no necesitas cambiar.

Revisa las plantillas antes de asumir que todo migró bien

Las plantillas controlan los títulos, los meta tags, los canonical, el structured data y los links internos de cientos de páginas al mismo tiempo. Si una plantilla tiene un error, ese error se multiplica por todas las páginas que la usan.

Antes del lanzamiento revisa que los títulos y headings estén presentes, que los canonical apunten a URLs completas del sitio en vivo y no al staging, que el structured data se haya transferido correctamente y que el contenido e imágenes estén intactos.

El día del lanzamiento: verificar, no asumir

Lo que funcionaba en staging tiene que funcionar en el sitio en vivo. Eso no es automático. El día del lanzamiento es de verificación sistemática, no de celebración anticipada.

Rastrear el sitio apenas sale al aire

El primer paso después de lanzar es correr un crawl completo del sitio en vivo y compararlo con el crawl del staging. Cualquier diferencia es una señal de alerta. Links rotos, páginas que devuelven errores, redirects que no existen: todo eso aparece ahí.

Testear los redirects a escala

Revisar los cinco principales no es suficiente. Cada URL mapeada tiene que redirigir de forma limpia, sin cadenas, sin loops, sin ir al home cuando debería ir a una página específica.

En migraciones donde los redirects se revisan a medias, la recuperación tarda meses más de lo necesario. No porque el problema sea complejo, sino porque tardó semanas en detectarse.

Confirmar que el tracking está funcionando

Si el tracking no estaba configurado antes del lanzamiento, los primeros días en vivo van a generar datos sucios que van a complicar cualquier análisis posterior.

GA4, píxeles de pauta y cualquier otro tag tienen que estar verificados antes de que el sitio salga al aire, no después. Y si el dominio no cambia, mantén la misma propiedad de GA4. Crear una nueva propiedad durante una migración rompe la continuidad de los datos históricos justo cuando más los necesitas para comparar.

Revisar robots.txt y las señales de indexación

Que el staging estuviera bloqueado no significa que el sitio en vivo está correctamente abierto. Revisa que el robots.txt del sitio en vivo no tenga restricciones que quedaron de cuando era staging, y que las páginas que deben indexarse estén efectivamente accesibles.

Después del lanzamiento: monitorear con calma y sin reaccionar de más

Incluso en migraciones bien ejecutadas hay movimiento en las primeras semanas. Rankings que fluctúan, tráfico que baja antes de estabilizarse. Eso es normal. Lo que no es normal es una caída sostenida que no muestra señales de recuperación.

La diferencia entre los dos escenarios está en los datos que tienes para distinguirlos.

Search Console es tu primera línea de alerta

En las primeras semanas post-migración, Search Console tiene que ser revisado con frecuencia. Errores de rastreo, páginas que aparecen excluidas del índice, caídas en páginas específicas: esos patrones son los que señalan si hay un problema estructural o si es movimiento temporal.

Lo importante es mirar patrones, no URLs aisladas.

Compara contra el benchmark, no contra la semana anterior

El punto de comparación para evaluar cómo va la migración son los números que registraste antes de empezar, no los de la semana pasada. Una caída del 15% que se está recuperando gradualmente es una situación completamente distinta a una caída del 15% que lleva tres semanas estable hacia abajo.

Los redirects de URLs antiguas siguen importando semanas después

Las URLs que cambiaron siguen atrayendo tráfico y crawlers durante meses. Confirma periódicamente que esos redirects siguen resolviendo correctamente. No es un trabajo de una sola vez.

Cuánto tiempo tarda una migración en estabilizarse

Si los redirects están limpios, el contenido migró íntegro y el rastreo está sin restricciones, la recuperación en la mayoría de los casos ocurre en semanas, no en meses.

Cuando la recuperación tarda más de lo esperado, casi siempre hay un problema estructural detrás: redirects que apuntan al lugar equivocado, contenido que no migró correctamente, señales de indexación contradictorias. Esos problemas tienen solución, pero requieren diagnóstico, no paciencia.

La migración que sale bien no es necesariamente la más simple ni la más pequeña. Es la que tuvo a alguien revisando cada etapa con criterio, sin asumir que porque funcionaba en staging iba a funcionar en producción, y sin esperar a que los reportes del mes siguiente confirmaran lo que se podía haber detectado el día uno.