Migración web y SEO: checklist para no perder tráfico

Ya lo mencioné al hablar de auditoría técnica: la mayoría de las caídas de tráfico orgánico más graves que he visto no vienen de una penalización, sino de una migración mal ejecutada. Cambio de dominio, cambio de estructura de URLs, cambio de plataforma — cualquiera de estos movimientos, hecho sin un proceso cuidadoso, puede borrar de un plumazo años de posicionamiento acumulado. Este es el checklist que sigo, paso a paso, antes, durante y después de cualquier migración.

Antes de tocar nada: inventario completo del sitio actual

El primer paso, antes de diseñar nada nuevo, es tener un listado completo de todas las URLs indexadas del sitio actual, no solo las que aparecen en el menú de navegación. Cruzo el listado del sitemap actual con un rastreo completo (Screaming Frog) y con el informe de páginas indexadas de Search Console, porque cada fuente puede revelar URLs que las otras no capturan — páginas antiguas sin enlace interno visible pero que siguen indexadas y recibiendo tráfico, por ejemplo. Sin este inventario completo, es imposible planificar redirecciones para todo lo que existe.

Mapeo de redirecciones: uno a uno, no genérico al home

Este es el punto donde más veces he visto fallar migraciones ajenas: redirigir todas las URLs antiguas al home del sitio nuevo, en vez de a su equivalente específico. Google interpreta una redirección genérica al home de forma muy distinta a una redirección 301 específica de la URL antigua a su contenido equivalente en el sitio nuevo — en el primer caso, la señal de relevancia y autoridad acumulada para esa URL concreta prácticamente se pierde. El mapeo correcto es una tabla completa: cada URL antigua apuntando de forma específica a su URL nueva equivalente, y solo cuando no existe un equivalente razonable, se decide conscientemente si redirigir a una categoría relacionada o dejar que devuelva un 410 (contenido eliminado deliberadamente).

Contenido que desaparece: redirigir a lo más parecido, no a cualquier cosa

Cuando una página no tiene equivalente directo en el sitio nuevo (un producto descatalogado, un artículo que se ha fusionado con otro), la tentación es redirigirla a la home o a la categoría general «porque algo hay que poner». Es mejor evitarlo: una redirección a contenido que no tiene relación real con el original puede interpretarse como una redirección de baja calidad, y además ofrece al usuario que llega desde un enlace externo o de resultados de búsqueda antiguos una experiencia confusa. Si no hay un destino razonable, es preferible dejar que la URL devuelva un código 410 (eliminado permanentemente) antes que forzar una redirección que no tiene sentido para nadie.

robots.txt: el error más tonto y más caro

Es sorprendentemente habitual que, tras migrar de un entorno de pruebas a producción, el robots.txt de staging (que bloquea todo el rastreo, como debe ser en un entorno de pruebas) se quede activo por error en el sitio ya publicado. El resultado es que Google deja de poder rastrear el sitio completo, sin ningún otro síntoma visible salvo la caída progresiva de tráfico en los días siguientes. Comprobar el robots.txt inmediatamente después de publicar la migración —no al día siguiente, en el mismo momento— es de los primeros pasos de cualquier checklist de migración que me tomo en serio.

Sitemap.xml actualizado y reenviado

El sitemap nuevo, reflejando la estructura de URLs definitiva, debe generarse y enviarse a Search Console en cuanto el sitio nuevo esté publicado, no varios días después. Si además cambias de dominio, Search Console tiene una herramienta específica de cambio de dirección que ayuda a comunicar a Google la relación entre el dominio antiguo y el nuevo, y conviene usarla explícitamente en vez de confiar solo en que las redirecciones 301 se lo comuniquen de forma indirecta.

Verificar que todo el contenido indexado tiene equivalente accesible

Con el mapeo de redirecciones ya implementado, hago una comprobación sistemática: reviso una muestra representativa (o, si el volumen lo permite, la totalidad) de las URLs antiguas, verificando que cada una redirige correctamente con un código 301 (no 302, que es temporal y transmite una señal más débil) a su destino correcto, sin cadenas de redirección innecesarias por el camino.

Monitorización post-migración: qué reviso y con qué frecuencia

Los primeros días después de una migración, reviso a diario el informe de cobertura de índice en Search Console, buscando específicamente un aumento repentino de errores 404 o de páginas «rastreadas, no indexadas» que antes no existían. También comparo el tráfico orgánico diario con el periodo anterior a la migración, sabiendo que cierta fluctuación en los primeros días es normal mientras Google reprocesa el sitio, y que no hay que sacar conclusiones definitivas todavía con solo unos días de datos.

Un calendario realista de recuperación

Aquí es donde hay que ser honesto y no prometer plazos que no se pueden garantizar. Google suele empezar a rastrear las redirecciones nuevas en cuestión de días, pero reprocesar y reevaluar completamente un sitio migrado —sobre todo si es grande— puede llevar semanas. Para sitios con mucha autoridad acumulada y una migración técnicamente bien ejecutada, es razonable esperar que el tráfico se estabilice cerca de los niveles previos en unas pocas semanas. Para sitios con errores en el proceso, o en sectores muy competidos donde cualquier señal de inestabilidad puede aprovecharse por la competencia, la recuperación completa puede extenderse varios meses. Cualquiera que prometa una recuperación instantánea y sin fluctuación tras una migración no está siendo realista sobre cómo procesa Google este tipo de cambios.

Un caso particular: cambio de plataforma sin cambio de dominio

No todas las migraciones implican cambio de dominio. Pasar de una plataforma a otra (por ejemplo, de una plantilla antigua a un CMS distinto) manteniendo el mismo dominio y, en teoría, las mismas URLs, puede parecer más seguro, pero esconde su propio riesgo: es fácil asumir que como el dominio no cambia, no hace falta un plan de redirecciones tan cuidadoso, cuando en la práctica muchas migraciones de plataforma sí alteran la estructura de URLs (por ejemplo, cambia cómo se generan las rutas de categoría o de producto), aunque el dominio raíz siga siendo el mismo. El checklist completo aplica igual, cambie o no el dominio — lo que importa es si cambian las URLs individuales, no el dominio en sí.

Comunicación interna: que nadie más toque nada durante el proceso

Un fallo que no es técnico sino de coordinación: alguien del equipo (marketing, un desarrollador externo, el propio cliente) hace un cambio en el sitio nuevo durante la ventana de migración sin coordinarlo, alterando algo del mapeo de redirecciones ya verificado. Antes de una migración, dejo claro quién tiene permiso para tocar qué durante el proceso, y establezco una ventana de congelación de cambios no relacionados con la propia migración hasta que esté verificada y estable — parece obvio, pero es un fallo de proceso que he visto complicar migraciones que, técnicamente, estaban bien planteadas.

Checklist resumen

1. Inventario completo de URLs indexadas del sitio actual (sitemap + rastreo + Search Console).
2. Tabla de redirecciones 301 uno a uno, sin redirecciones genéricas al home.
3. Decisión consciente (redirección a contenido similar o 410) para páginas sin equivalente.
4. Comprobación inmediata del robots.txt tras publicar el sitio nuevo.
5. Sitemap.xml nuevo generado y enviado a Search Console el mismo día.
6. Herramienta de cambio de dirección de Search Console, si hay cambio de dominio.
7. Verificación de que las redirecciones funcionan correctamente, sin cadenas ni errores.
8. Monitorización diaria de cobertura de índice y tráfico durante las primeras semanas.

Si quieres ver el resto de la auditoría técnica que hago independientemente de si hay una migración de por medio, tengo el artículo completo sobre SEO técnico: la auditoría que hago antes de tocar una keyword. Y si tienes una migración planeada y quieres que la supervise, puedes escribirme desde contacto.