La migración web que borró el pasado · Serpion 005

Cuando una inmobiliaria local me contactó para revisar su web, lo primero que me dijeron fue que llevaban semanas sin recibir consultas por el buscador. No pocas. Ninguna. El sitio acababa de pasar por un proceso de renovación completa: nueva estructura, nuevas URLs, nuevo diseño. Todo limpio, todo actualizado. Sobre el papel, una mejora. En la práctica, el tráfico orgánico había caído a cero y no había vuelto.

El síntoma era claro, pero la causa no. Una migración web de esa envergadura mueve muchas piezas a la vez, y cualquiera de ellas puede ser el punto de fallo. Lo primero que hice fue separar lo que sabía de lo que asumía. Sabía que el sitio tenía visibilidad antes del cambio: había histórico, había posiciones, había páginas que Google había visitado durante meses. Lo que no sabía era si ese historial seguía siendo accesible para el rastreador, o si el cambio lo había dejado sin ancla.

Los primeros datos en Search Console eran extraños. No había un pico de errores brutal. No había un aviso llamativo. Solo silencio. Y el silencio, en SEO, casi siempre significa que algo no está llegando a donde tiene que llegar. Esto no me cuadraba. El sitio existía, respondía, se veía bien. Pero para Google, parecía que el pasado había desaparecido.

Rastrear una migración web cuando el punto de partida ya no existe

Empecé por donde siempre: Google Search Console. El informe de cobertura mostraba algo que, a primera vista, podía interpretarse de varias formas. Las URLs antiguas seguían apareciendo, la mayoría con estado «Error 404». Eso era esperable: si las URLs cambian de estructura, las antiguas dejan de existir. Normal en cualquier cambio de este tipo. Pero lo que me llamó la atención fue que las nuevas URLs no aparecían con errores ni con exclusiones. Simplemente no aparecían. Casi ninguna tenía impresiones. Como si Google aún no las hubiera encontrado, o como si las hubiera encontrado y hubiera decidido no hacer nada con ellas.

La primera hipótesis que evalué fue la del sitemap. Pensé que quizás el sitemap enviado seguía apuntando a la estructura antigua, o que el nuevo no estaba bien formado. Era una explicación limpia y bastante habitual tras un cambio de URLs. Lo revisé con detalle: el sitemap estaba actualizado, incluía las nuevas rutas, tenía formato válido y estaba correctamente declarado en Search Console. Demasiado limpio para ser el problema. Si el sitemap era correcto y las nuevas URLs existían con respuesta 200, el rastreador debería haberlas procesado ya.

Descartado eso, pasé a revisar el comportamiento del rastreador con Screaming Frog. Rastreé el sitio nuevo completo y, en paralelo, rastreé una muestra de las URLs antiguas que habían tenido posiciones. Lo que obtuve fue el primer dato que realmente abrió el caso.

Qué señales dejaba la migración web antes de que Google lo procesara todo

Al pasar las URLs antiguas por el rastreador, empecé a ver respuestas inconsistentes. Algunas devolvían 404, como esperaba. Pero otras devolvían 200 directamente, sin ninguna redirección. Y otras, las más interesantes, devolvían códigos de respuesta distintos dependiendo del contexto. Aquí había ruido, pero no era ruido aleatorio.

Para afinar más, analicé las cabeceras HTTP de una muestra representativa de URLs antiguas: las fichas de inmuebles, las páginas de zona y la home. Quería saber exactamente qué estaba devolviendo el servidor cuando alguien, o el rastreador, accedía a esas rutas.

GET /venta/piso-centro-valencia-4hab/ HTTP/1.1
Host: www.inmobiliaria-ejemplo.es

HTTP/1.1 200 OK
Content-Type: text/html; charset=UTF-8

Una URL que debería haber desaparecido con la migración estaba respondiendo 200. Eso significaba que el servidor la trataba como una página válida, aunque su contenido ya no era el correcto, o simplemente no existía en la nueva estructura. Google podía entrar, rastrear algo que no aportaba nada útil y seguir adelante sin procesar las nuevas URLs.

En ese punto manejé una segunda hipótesis: quizás el problema era de contenido duplicado. Si las URLs antiguas respondían 200 y cargaban algo parecido a las nuevas, Google podría estar viendo versiones redundantes y decidir no indexar ninguna de forma prioritaria. Revisé el contenido que devolvían esas URLs: algunas cargaban la home por defecto, otras mostraban una página de error personalizada con código 200 —lo que se conoce como soft 404—. Eso podía generar señales confusas para el rastreador, pero no explicaba por sí solo que las páginas nuevas tuvieran cero impresiones. Una canibalización entre URLs viejas y nuevas podría haber reducido visibilidad, pero no borrarla por completo.

El problema no era que Google no entrara. Era que entraba, pero no encontraba el camino hacia donde ahora vivía el contenido.

El punto donde el pasado y el presente dejaron de estar conectados

Con todos esos datos sobre la mesa, el diagnóstico se fue cerrando solo. La causa real no estaba en el sitemap, ni en el contenido duplicado, ni en los soft 404s, aunque todos esos factores contribuían al ruido. El problema central era que la migración web se había ejecutado sin implementar correctamente las redirecciones entre las URLs antiguas y las nuevas.

No había un mapa de redireccionamiento activo. Las páginas que Google tenía en su índice, las que tenían historial de rastreo, posiciones y señales acumuladas durante meses, simplemente habían dejado de existir sin dejarle al rastreador ninguna instrucción sobre dónde encontrar el contenido equivalente. Desde el punto de vista de Google, era como si la web hubiera desaparecido y en su lugar hubiera aparecido un sitio completamente nuevo, sin historial, sin señales, sin contexto.

# Estado real tras la migración (muestra de URLs clave)

/venta/piso-centro-valencia-4hab/     → 200 (soft 404, carga home)
/alquiler/local-comercial-ruzafa/     → 404
/zona/valencia-centro/                → 200 (soft 404, carga home)
/contacto/                            → 301 → /contactanos/ ✓ (única correcta)

# URLs nuevas equivalentes (sin redirección desde las antiguas)
/comprar/pisos/centro-valencia/       → 200 ✓
/arrendar/locales/ruzafa/             → 200 ✓
/zonas/centro-valencia/               → 200 ✓

El patrón era claro: de todas las páginas con historial, solo una tenía redirección configurada. El resto habían quedado desconectadas. Las nuevas URLs existían y respondían bien, pero Google las veía como páginas de estreno, sin ninguna señal heredada. Todo el peso que el dominio había acumulado en posiciones, en rastreo frecuente, en páginas conocidas, había quedado atrapado en rutas que ya no llevaban a ningún sitio.

Una redirección 301 no es solo una instrucción técnica. Es la forma en que le dices a Google que lo que había ahí ahora vive en otro sitio, y que las señales que tenía registradas deben aplicarse al nuevo destino. Sin esa instrucción, el rastreador no asume nada. Simplemente registra que la página antigua ya no responde de forma válida, y trata la nueva como si acabara de nacer.

Ahí quedó claro el patrón: las señales seguían existiendo, pero ya no apuntaban al proyecto correcto.

Reconstruir el mapa que el cambio no dejó hecho

La corrección tenía una dirección evidente: había que reconstruir el mapa completo de redirecciones 301 entre todas las URLs antiguas con historial y sus equivalentes en la nueva estructura. Pero antes de tocar nada, había que decidir cómo hacerlo sin introducir nuevos problemas.

La tentación inicial era ir URL por URL y añadir las reglas de forma masiva en el panel de configuración del servidor. Rápido, directo. Pero hacerlo así, sin verificar primero el estado de cada URL antigua y su equivalente nueva, podía generar cadenas de redirección —una URL antigua redirigiendo a otra intermedia que a su vez redirigía a la final— y eso, además de ralentizar el rastreo, hace que Google pierda parte de la señal que se intenta transferir.

Qué reconstruir primero sin romper lo que el servidor ya reconocía

La otra vía era más ordenada: construir primero el mapa completo, validar que cada URL de destino respondía correctamente con 200, y solo entonces activar las reglas de forma agrupada. El riesgo de no hacerlo así era lanzar redirecciones apuntando a URLs nuevas que todavía no estaban del todo consolidadas, o que tenían pequeños errores de ruta que no habían sido detectados. Una migración web mal cerrada puede corregirse; una migración web corregida con otro error encima cuesta mucho más de estabilizar.

Generé el mapa de URLs a partir del histórico de rastreo y del informe de cobertura de Search Console, cruzando las rutas antiguas con las nuevas según la lógica de la estructura. Para las fichas de inmuebles, la equivalencia era directa. Para las páginas de zona y las categorías, hubo que revisar caso por caso, porque algunos slugs habían cambiado de nombre y no podían inferirse automáticamente.

Con el mapa validado, se activaron las redirecciones permanentes en bloque. Tras la implementación, se forzó el rastreo de las URLs más importantes desde Search Console y se comprobaron las cabeceras en tiempo real para verificar que cada redirección devolvía 301 de forma limpia, sin cadenas ni bucles.

# Resultado tras implementar el mapa 301 (muestra validada)

/venta/piso-centro-valencia-4hab/     → 301 → /comprar/pisos/centro-valencia/  ✓
/alquiler/local-comercial-ruzafa/     → 301 → /arrendar/locales/ruzafa/         ✓
/zona/valencia-centro/                → 301 → /zonas/centro-valencia/            ✓
/contacto/                            → 301 → /contactanos/                      ✓ (ya existía)

La recuperación del tráfico orgánico no fue inmediata. Google necesitó varios ciclos de rastreo para procesar las redirecciones, actualizar el índice y volver a evaluar las nuevas URLs con las señales heredadas. En las dos primeras semanas después de la corrección, las impresiones empezaron a subir de forma progresiva. Al final del primer mes, el tráfico orgánico había recuperado aproximadamente el 65% del nivel previo al cambio. El resto fue llegando en las semanas siguientes, a medida que Google fue consolidando las nuevas rutas.

Una redirección mal ejecutada no solo pierde tráfico. Pierde tiempo. Y en una inmobiliaria local que depende del buscador para recibir consultas, cada semana sin visibilidad tiene un coste real.