Cuando una tienda online decide cambiar de dominio, el equipo suele centrarse en el diseño y olvida lo aburrido. Ese fue el caso de un pequeño negocio de cerámica artesanal que migró de un dominio antiguo a uno más corto. La intención era clara: evitar caídas de tráfico al migrar. Sin embargo, el desarrollador configuró las redirecciones 301 apuntando todas las URLs antiguas a la página de inicio nueva, en lugar de a su equivalente exacto. Durante tres semanas, Google dejó de mostrar las fichas de producto y el tráfico orgánico se desplomó. No fue un problema de algoritmo: fue un fallo de ejecución.
Ese error es más común de lo que parece. La lección no está en la teoría de las redirecciones, sino en cómo se detecta y se corrige a tiempo. Aquí va el relato de qué salió mal y qué se podría haber hecho distinto.
El día que el tráfico orgánico desapareció del panel
La migración se hizo un viernes por la tarde. El lunes, el dueño abrió Search Console y vio una línea roja descendente. Las impresiones habían caído más de la mitad en cuestión de días. Lo primero que pensó fue en una penalización, pero no había habido cambios de contenido ni enlaces sospechosos. El problema estaba en el mapa de redirecciones: se habían creado reglas genéricas del tipo «cualquier URL antigua → home» para ahorrar tiempo.
Para evitar caídas de tráfico al migrar, la regla básica es que cada URL antigua debe tener una URL nueva equivalente, no un destino comodín. Cuando se redirige todo a la portada, Google interpreta que las páginas de producto ya no existen y las elimina del índice. El tráfico de cola larga, que suele ser el más valioso en ecommerce, se pierde primero.
El negocio tardó en reaccionar porque no tenía monitorización de códigos de estado. No había alertas configuradas para detectar picos de 404 o de redirecciones mal implementadas. Simplemente esperaron a que «se estabilizara», y no lo hizo.
Qué se hizo mal en la configuración técnica
El primer fallo fue no inventariar las URLs antes de mover nada. Sin un listado de las páginas con más tráfico y enlaces internos, es imposible saber qué redirigir y a dónde. El segundo fue usar redirecciones 302 en lugar de 301 en algunas secciones, lo que enviaba señales contradictorias sobre la permanencia del cambio.
También se olvidaron de actualizar los enlaces internos del menú y del pie de página. Aunque las redirecciones funcionaran, cada clic interno pasaba por una redirección innecesaria, lo que ralentizaba la carga y diluía la autoridad. Para evitar caídas de tráfico al migrar, los enlaces internos deben apuntar directamente a las nuevas URLs, sin saltos.
El tercer error fue no revisar el archivo robots.txt. Durante la migración, alguien añadió una línea Disallow: / para «proteger» el sitio mientras se probaba. Se olvidaron de quitarla al publicar. Google dejó de rastrear durante días. Ese detalle, que parece de principiante, ocurre en proyectos profesionales con equipos grandes.
La corrección: priorizar lo que ya funcionaba
Cuando por fin identificaron el problema, el equipo reconstruyó el mapa de redirecciones página por página. Empezaron por las URLs con más clics en Search Console y en el informe de rendimiento. No intentaron redirigir todo de golpe: hicieron tandas y verificaron con curl que cada código de estado fuera el esperado.
Para evitar caídas de tráfico al migrar en el futuro, establecieron una comprobación previa: comparar el número de URLs antiguas con el de nuevas y revisar que ninguna quedara huérfana. También añadieron monitorización semanal de errores 404 en las páginas de producto.
El tráfico no volvió de inmediato. Tardó semanas en recuperarse, y algunas fichas de producto nunca regresaron a su posición anterior. Esa es la parte que no se suele contar: una migración mal hecha puede dejar secuelas durante meses, incluso después de corregir las redirecciones.
Limitaciones y lo que este enfoque no resuelve
Este caso es de un negocio pequeño con pocas URLs. En proyectos con miles de páginas, la revisión manual no escala y hace falta un rastreo completo con herramientas de log o un crawler. Tampoco funciona igual en sitios con JavaScript renderizado en cliente: las redirecciones del lado del servidor pueden no capturar rutas generadas dinámicamente.
Otro matiz: si el cambio de dominio incluye una reestructuración de categorías, la equivalencia uno a uno no siempre es posible. Ahí toca decidir qué páginas se consolidan y aceptar que parte del tráfico se pierda de forma controlada. No hay fórmula mágica para evitar caídas de tráfico al migrar cuando la arquitectura cambia de raíz.
La conclusión práctica: documentar, inventariar y verificar. Y no dar por hecho que el equipo de desarrollo entiende el impacto SEO de una redirección comodín. La comunicación entre quien migra y quien mide el tráfico es lo que separa una transición limpia de un susto de tres semanas.
Perfiles verificables: Sitio web
Publicado el 31 de October de 2026. Última revisión: 31 de October de 2026.