Operando ahora · respuesta en < 30 min por WhatsApp
Monitoreo 24/7 · atención L–V 8:00–20:00
Cuéntanos qué pasa
Operando ahora · respuesta < 30 min Monitoreo 24/7 · atención L–V 8:00–20:00

SEO TÉCNICO · MIGRACIONES

Recuperar el tráfico perdido tras una migración

La web nueva quedó mejor. Más rápida, más bonita, más fácil de administrar. Y lleva seis semanas facturando la mitad.

Esto pasa casi siempre por lo mismo, y casi nunca es el diseño. Google tenía dos mil páginas tuyas en su índice, cada una con su historial y su autoridad acumulada. Ahora pide esas dos mil direcciones y le contestan 404, o una redirección masiva a la portada que lo abandona a mitad de camino.

La buena noticia: si la migración fue hace poco, casi todo es recuperable. La mala: la ventana no es infinita, y cada semana que pasa con las direcciones rotas es autoridad que se escurre.

server_access.log

Qué pasó exactamente

Dos o tres de estos fallos a la vez es lo habitual. Una migración mal cerrada casi nunca falla en un solo punto. Mira cuál describe tu caso:

Todo lleva a la portada

Redirección masiva a la raíz. Google puede tratarla como soft 404 y entonces no transfiere nada de autoridad.

Cómo confirmar: Inspecciona 10 URLs viejas en Search Console. Si Google declara la portada como canónica, lo estás perdiendo todo.

Miles de 404 nuevos

No se construyó el mapa de redirecciones, o se construyó de manera muy parcial olvidando categorías.

Cómo confirmar: Search Console → Cobertura → No encontrada (404), ordenado por la fecha de detección.

Hay redirecciones, pero igual bajó

Cadenas de saltos excesivas, códigos 302 temporales donde debía haber 301, o redirección a una URL que a su vez redirige.

Cómo confirmar: Comprobar los encabezados de respuesta (Headers): cuántos saltos y con qué código llega cada uno.

Solo bajó una sección (Ej: /blog/)

Se migró una parte y de otra se cambió la estructura (slugs) sin mapearla individualmente.

Cómo confirmar: Comparar el sitemap viejo contra el nuevo, aislando por carpeta o Custom Post Type.

El sitio nuevo NO se indexa

Se migró arrastrando el robots.txt bloqueado o la etiqueta noindex del entorno de pruebas por error.

Cómo confirmar: Inspección de URL dirá "excluida por etiqueta noindex" o "bloqueada por robots.txt".

Google indexa el dominio viejo

Falta la redirección del lado del servidor, o la etiqueta canónica quedó apuntando al viejo, o no se usó la herramienta de cambio.

Cómo confirmar: site:dominioviejo.com y revisar qué canónica está leyendo Google realmente.

Mándame por WhatsApp el dominio nuevo, el viejo si cambió, y la fecha de la migración. Con eso compruebo cinco URLs y te digo cuál de estos casos es el tuyo.

Lo que dice Google y casi nadie aplica

Esto no es opinión de agencia. Es la documentación técnica oficial de Google sobre movimientos de sitio, y contradice frontalmente lo que se hace en la mayoría de las migraciones improvisadas que nos llegan a rescate.

1

Las redirecciones se mantienen al menos un año

Google lo especifica así: "generalmente al menos un año", para que el bot tenga tiempo de transferir las señales a las URLs nuevas. Desde el punto de vista del visitante, mantenerlas indefinidamente es válido. La práctica de quitarlas a los tres meses "porque ya está migrado" es tirar el trabajo justo antes de que termine de surtir efecto.

2

Las cadenas de redirección penalizan

Googlebot sigue hasta diez saltos, pero recomienda redirigir directamente al destino final. Si no es posible, máximo tres saltos. Cada salto añade latencia. En WordPress las cadenas aparecen solas por acumulación: una redirección de 2019 + el cambio a HTTPS + la migración de hoy = un muro infranqueable.

3

Redirigir en masa a la portada es un error grave

Google avisa que redirigir muchas URLs a un destino irrelevante (como la Home) confunde al visitante y se trata como Soft 404. La excepción razonable: si consolidaste varias páginas viejas en una nueva, redirigir a esa nueva es correcto. Usar la portada como vertedero de errores no funciona.

4

La herramienta de "Cambio de Dirección" es limitada

Solo sirve para cambios reales de dominio o subdominio (ejemplo.com a ejemplo.net). No sirve para pasar de HTTP a HTTPS, ni para cambiar entre www y sin www, y no sirve para mover rutas dentro del mismo dominio. Y cuando sí aplica, hay que enviarla para todas las variantes verificadas.

5

El plazo es de semanas, no de días

Para sitios pequeños/medianos puede llevar unas semanas que la mayoría de las páginas se muevan en el índice. La visibilidad fluctúa durante el proceso. Una caída en la primera semana no es una emergencia definitiva; una caída sostenida a las ocho semanas, sí.

Qué es recuperable y qué no

Te lo decimos de frente antes de cobrarte nada, porque en una crisis esta es la pregunta que de verdad importa.

Se recupera casi siempre

Lo que falló estrictamente por una redirección ausente, incompleta o encadenada, cuando el contenido equivalente sigue existiendo intacto en el sitio nuevo. Aquí el trabajo de rescate es mecánico y el resultado es predecible.

Se recupera parcialmente

Cuando se consolidó contenido masivamente (ej. diez páginas viejas convertidas en tres nuevas). La autoridad se reparte, no se multiplica mágicamente. Recuperaremos la mayor parte del tráfico agregado, pero no esperes que cada URL nueva herede el 100% de lo que tenían todas juntas.

NO se recupera

El contenido que se borró por completo en la migración y no existe en ninguna parte. Si se perdieron 200 artículos porque nadie los exportó, no hay redirección que arregle la nada: hay que restaurarlos de un backup antiguo, del archivo web, o aceptar la pérdida. Te lo diremos con nombres de URL en el diagnóstico.

El factor tiempo importa

Seis semanas es una situación de rescate muy distinta a dos años. No hay fecha de caducidad oficial, pero Google consolida el estado nuevo con el tiempo. Si los enlaces externos llevan dos años apuntando a un 404, lo que se recupera hoy es menos. Sigue valiendo la pena, pero las expectativas cambian.

El procedimiento de rescate

Fase 1

Reconstrucción del inventario viejo

Qué se hace

Recuperar la lista real de URLs del sitio anterior usando: sitemap archivado, Search Console histórico, logs del servidor, Archive.org y exportaciones de la base de datos vieja si existen.

Qué recibes

El inventario de las URLs que existían, con su tráfico histórico asignado, ordenadas matemáticamente por lo que más valor aportaba.

* Esta es la fase que decide si el proyecto sale bien, la que nadie cotiza en la industria y la que más horas forenses lleva.

Fase 2

Mapeo uno a uno

Qué se hace

Emparejar cada URL vieja con su equivalente exacto en la web nueva. Las que no tienen equivalente se deciden a mano contigo: consolidar a categoría, recrear, o dejar morir limpiamente con un código 410.

Qué recibes

El mapa de redirecciones completo en una hoja de cálculo que puedas auditar línea por línea.

Fase 3

Implementación Técnica

Qué se hace

Inyección de redirecciones 301 directas al destino final, eliminando cadenas. Limpieza total de las cadenas tóxicas heredadas de migraciones de años anteriores.

Qué recibes

Confirmación de código de respuesta y número de saltos, URL por URL.

Fase 4

Saneamiento SEO

Qué se hace

Ajuste de canónicas, hreflang (si aplica por idioma/país), robots.txt, etiquetas de indexación, generación de sitemap real y uso de la herramienta de cambio de dirección de Google cuando corresponda.

Qué recibes

Lista forense de lo corregido con la foto del antes y el después.

Fase 5

Reindexación Priorizada

Qué se hace

Forzar solicitudes de indexación a Google empezando metódicamente por las URLs con mayor volumen de tráfico histórico, no por simple orden alfabético.

Qué recibes

Calendario de reindexación con prioridades de negocio.

Fase 6

Vigilancia (3 meses)

Qué se hace

Seguimiento semanal de cobertura en Search Console, posiciones de las URLs clave y detección de errores nuevos, con corrección en caliente sobre la marcha.

Qué recibes

Informe mensual demostrando la curva visual de recuperación.

Cómo trabajamos (Lo que necesitamos)

1. Acceso a Search Console con histórico

Es la única fuente que dice qué URLs tenían tráfico real antes. Si la propiedad se creó después de migrar, el histórico se esfumó y hay que reconstruirlo por vías más lentas. Si conservas la propiedad del dominio viejo verificada: no la borres por nada del mundo, vale oro.

2. Logs del servidor

Nos dicen exactamente qué URLs antiguas sigue pidiendo Google hoy y qué le estás respondiendo el servidor. Sin ellos se puede trabajar, pero vamos a ciegas adivinando el comportamiento del bot.

3. No reescribimos tu web

Esto es un servicio de recuperación de direcciones y autoridad. Si además detectamos que el sitio nuevo tiene problemas estructurales de rendimiento, te lo diremos, pero lo trataremos como un proyecto de optimización aparte.

4. No culpamos a quien migró

Nos lo piden mucho y no nos parece útil profesionalmente. Decimos objetivamente qué falta y qué cuesta arreglarlo. Si necesitas un informe formal para reclamar a tu proveedor anterior, lo hacemos, pero por separado y sabiendo el objetivo.

¿Todavía no has migrado? Esta página no es para ti. Hacerlo bien desde el principio cuesta una fracción de este rescate.
→ Ver servicio de Migraciones de WordPress preventivas. Y si lo que viene es un rediseño completo, hazlo sin perder posicionamiento.

Lo que viene en 2027

1. Comparar tráfico será confuso (AI Mode)

Desde 2026, el tráfico generado por AI Mode está mezclado dentro del informe general de Search Console bajo el tipo "Web", sin un filtro propio limpio. Y los resúmenes de IA generativa (lanzados en junio de 2026) reportan impresiones pero rara vez clics. Si migraste y comparas el antes y el después, estás mezclando dos composiciones de tráfico distintas. Para un diagnóstico certero, hay que aislar la causa real de la caída en lugar de culpar ciegamente a la migración.

2. Los enlaces externos pesan más

Lo que no se recupera con simples redirecciones es la fracción de autoridad que venía de enlaces en otros blogs que llevan meses apuntando a tu 404. Conforme más contenido se consume dentro de respuestas generadas por IA sin salir al navegador, cada enlace tradicional conseguido en los años buenos vale relativamente más, y perderlo por una redirección que nadie mapeó es mucho más caro que antes.

3. Cuidado con los constructores visuales

Una tendencia sin fecha pero con dirección clara: cada migración que se haga hacia temas con constructores pesados va a llegar con deuda de rendimiento. Con INP midiendo la peor latencia de interacción de toda la visita, un sitio nuevo "más bonito" puede ser mediblemente peor para Google que el viejo. Conviene medir a fondo antes de celebrar el rediseño.

Preguntas frecuentes

Migré hace tres semanas y el tráfico bajó un 50%. ¿Es normal?

Una caída temporal de impresiones durante el movimiento sí es normal: Google tarda semanas en procesar y mover la mayoría de las páginas, y la visibilidad fluctúa. Un 50% sostenido de caída de clics NO es normal. La clave está en los 404: si tu reporte de cobertura se llenó de errores justo el día de la migración, no estás "esperando a que asiente", estás perdiendo dinero a diario.

Redirigí todo masivamente a la portada para no tener 404s. ¿Está mal?

Sí, y es el error técnico más caro. Google documenta oficialmente que redirigir muchas URLs a un destino irrelevante se trata algorítmicamente como Soft 404, lo que significa que no te transfiere ninguna autoridad. Es literalmente peor que dejar el 404 honesto, porque además confunde y frustra al visitante que buscaba un artículo concreto.

¿Cuánto tiempo tengo que mantener las redirecciones activas en el servidor?

Google dice "al menos un año", y mantenerlas indefinidamente en tu archivo `.htaccess` o servidor Nginx es la opción técnica válida. Quitarlas a los tres meses creyendo que "Google ya lo aprendió" es la forma más habitual de perder dos veces el mismo tráfico.

Cambié solo de proveedor de hosting, sin tocar los enlaces. ¿Esto me aplica?

No debería. Un cambio de servidor sin cambio de estructura de URLs no mueve nada en el índice de Google. Si bajó el tráfico drásticamente, la causa suele ser otra: olvidaron el `robots.txt` del nuevo servidor bloqueando, dejaron un `noindex` que viajó desde el entorno de pruebas, falló el certificado SSL, o el servidor nuevo es terriblemente más lento. Eso se diagnostica igual, pero el rescate es más corto.

Usé la herramienta de Cambio de Dirección de Google y no pasó nada.

Comprueba que tu caso técnico sea de los que cubre la herramienta: solo soporta cambios de dominio raíz o subdominio. No sirve para pasar de HTTP a HTTPS, ni para cambiar entre www y sin www en el mismo dominio, y desde luego no sirve para mover rutas o categorías internas. Y si sí aplicaba tu caso, debes enviarla para todas las variantes verificadas del dominio viejo.

Perdimos artículos enteros en la migración y no hay copia local. ¿Hay arreglo?

A veces sí. El Archive.org (Wayback Machine) o la caché de Google conservan copias de muchas páginas de texto, y Search Console nos dice qué URLs antiguas tenían tráfico. Se puede extraer ese contenido de las páginas que valían la pena y volver a publicarlas en la misma URL o redirigirlas bien. No es barato operativamente y no siempre están todas guardadas, pero para un blog corporativo con años, puede ser la diferencia entre recuperarse o quebrar ese canal.

¿Me conviene restaurar el backup y volver al sitio viejo?

Casi nunca. Volver atrás es, a ojos de Google, una segunda migración forzada, con su propia pérdida de autoridad, y rara vez arregla la causa raíz. La única excepción a esta regla es si el sitio nuevo está tan incompleto y roto que literalmente no hay contenido al que redirigir. Si tu caso es ese nivel de emergencia, te lo diremos claro en el diagnóstico para que abortes.

Tres formas de empezar

Migraste hace poco y el tráfico no llegó

Mándame por WhatsApp el dominio nuevo, el viejo (si cambió) y la fecha. Compruebo 5 URLs gratis y te digo qué pasa.

Escribir por WhatsApp

Quieres saber cuánto es recuperable

El diagnóstico técnico te entrega el inventario de URLs perdidas y el porcentaje real de tráfico que se salvará. Es tuyo.

Pedir el diagnóstico

Quieres presupuesto de rescate

Dime cuántas URLs tenía el sitio viejo, la fecha, y si conservas Search Console. Te armo la propuesta con las 6 fases.

Solicitar propuesta

Última revisión técnica: octubre de 2026.
Volver a SEO técnico en WordPress

```eof