Una migración web rara vez falla porque alguien olvidó cambiar la página de inicio. Los problemas caros aparecen en las URLs profundas: una ficha de producto que pasa por dos dominios antiguos, una ruta de soporte que conserva un 302 durante meses, un nombre que primero resuelve al servidor antiguo y después devuelve una cadena de redirecciones. El usuario puede llegar al final, pero con más latencia y más posibilidades de error. Los buscadores pueden interpretar señales contradictorias y los equipos pierden la capacidad de saber qué dirección es realmente canónica. Revisar la cadena completa convierte una migración arriesgada en un conjunto de pruebas observables.
Una redirección es una instrucción HTTP que indica que el recurso solicitado se encuentra en otra URL. El código elegido importa: 301 y 308 expresan un cambio permanente, mientras 302 y 307 describen un movimiento temporal. Google explica que las redirecciones permanentes son una señal para que el destino pueda convertirse en la URL canónica, pero también recomienda evitar secuencias largas. El objetivo operativo no es conseguir un número concreto de saltos, sino hacer que cada URL antigua llegue directamente al destino que un cliente, un rastreador y un equipo de soporte deben usar.
Qué es una cadena y por qué cuesta dinero
Existe una cadena cuando la URL A responde con una redirección a B, B redirige a C y C termina en D. A veces se produce durante un cambio de dominio, después de forzar HTTPS, al añadir o quitar www, o cuando una página antigua conserva una regla general. Cada salto consume tiempo, puede perder cabeceras, cambia la observación de los agentes y añade otra configuración que puede quedar obsoleta. En móvil, una latencia adicional puede afectar la conversión. En una integración, un cliente puede limitar el número de redirecciones o rechazar un cambio de método.
- URL antigua y URL final, incluyendo esquema, host, puerto y ruta.
- Código de cada respuesta y ubicación exacta indicada por Location.
- Número de saltos, tiempo de cada respuesta y si existe un bucle.
- Cambios de host, de HTTP a HTTPS, de www o de ruta durante el recorrido.
- Destino final, código, contenido esperado y certificado presentado.
- Propietario de la regla y fecha en la que debe revisarse o retirarse.
Elige el código que describe la intención
Usa 301 o 308 cuando la URL ha cambiado de forma permanente y quieres que clientes y buscadores conozcan ese hecho. La diferencia técnica entre ambos afecta al manejo del método y del cuerpo de la petición, por lo que una API o un formulario merece una prueba explícita. Usa 302 o 307 cuando el cambio es temporal, por ejemplo durante una campaña o una prueba controlada. No mantengas un 302 por costumbre si el movimiento ya es definitivo. La respuesta debe coincidir con la intención del negocio y con el comportamiento que necesita el cliente.
Evita mezclar redirecciones de servidor, meta refresh y JavaScript como solución por defecto. Google documenta que las redirecciones del servidor son la opción más clara cuando se puede configurar, y que las alternativas del lado del cliente deben reservarse para casos en los que no hay otra posibilidad. Un enlace con JavaScript puede funcionar en un navegador moderno y fallar en una herramienta, un cliente de correo o una comprobación de disponibilidad. Diseña una ruta directa y deja el comportamiento alternativo como excepción documentada, no como capa permanente.
Plan de pruebas antes de cambiar el dominio
Construye un inventario de URLs a partir del sitemap, los enlaces internos, los registros de acceso y las páginas que reciben tráfico. Selecciona rutas de cada plantilla, no solo la portada: producto, categoría, blog, ayuda, inicio de sesión y endpoint público. Para cada URL define el destino final y el código previsto. Comprueba además qué ocurrirá con parámetros, mayúsculas, barra final y rutas antiguas que ya no tienen equivalente. Si solo rediriges las páginas más visitadas, las URL profundas pueden terminar en errores o en una página genérica que no conserva la intención del usuario.
- Congela el mapa URL antigua a destino final y consigue un propietario por grupo.
- Reduce las reglas duplicadas y calcula la ruta directa antes del cambio.
- Verifica DNS, certificados y hosts antiguos y nuevos en un entorno controlado.
- Prueba 301, 308, 302 y 307 solo donde la intención lo requiere.
- Comprueba métodos GET y POST en las rutas que aceptan formularios o API.
- Guarda respuestas, tiempos y destinos para comparar después del lanzamiento.
Comprueba DNS y TLS antes de seguir la cadena
Una prueba HTTP puede ocultar un problema de resolución. Comprueba A, AAAA y CNAME de cada host antiguo y nuevo, y confirma que el nombre llega al sistema que contiene la regla prevista. Si una dirección IPv6 apunta todavía al servicio anterior, algunos usuarios verán una cadena distinta. Revisa también el certificado del nombre antiguo: el navegador debe poder establecer HTTPS antes de recibir la redirección. La presencia de un certificado válido en el destino no corrige un certificado caducado en la URL que el usuario solicita primero.
DomScan permite combinar el Comprobador de redirecciones con el Comprobador DNS y el Comprobador SSL. Registra la URL solicitada, el host, el código, el destino y la hora. Si la respuesta es 403, 429, un error de conexión o una espera agotada, clasifícala como no verificada, no como ausencia de redirección. La herramienta ayuda a observar el resultado público, pero no sustituye la revisión de tus reglas de servidor ni una prueba autorizada desde los entornos que realmente usan tus clientes.
Migración de dominio con señales de búsqueda
En un traslado, las redirecciones solo son una parte del mapa. Google recomienda comprobar las propiedades antigua y nueva en Search Console, enviar el sitemap nuevo y aceptar que el rastreo y la indexación pueden tardar. Mantén la redirección el tiempo suficiente para que usuarios, rastreadores y enlaces externos encuentren la nueva ubicación. Actualiza enlaces internos, canonical, hreflang y referencias en campañas. No uses una redirección global de todas las rutas a la portada si existe un destino equivalente: puede frustrar al usuario y perder la intención de la página original.
Evita dos extremos. Mantener todas las reglas antiguas para siempre crea una configuración opaca, pero eliminarlas inmediatamente corta enlaces que todavía reciben visitas. Mide tráfico, errores y solicitudes en los dos dominios y define un criterio de retirada. Cuando una URL no tiene equivalente, devuelve una respuesta honesta o redirige a una página realmente relacionada. Una página de inicio no es una respuesta universal. En tiendas españolas o latinoamericanas, revisa además rutas de idioma, moneda y catálogo para que una redirección no cambie el país o el contexto del comprador.
Detecta bucles y destinos inesperados
Un bucle aparece cuando una regla devuelve al mismo host o alterna entre dos variantes. Suele ocurrir cuando una capa fuerza HTTPS y otra cree que la petición todavía es HTTP, o cuando una regla de www contradice la del dominio raíz. Prueba cada combinación de esquema y host, y conserva la cabecera que permita explicar lo que ocurrió. Un destino inesperado también merece revisión: la URL puede llegar a un login, una página de error o un idioma incorrecto aunque el código final sea 200. Comprueba contenido, título y canonical, no solo el estado.
Si gestionas muchos dominios, automatiza el inventario mediante la API de cadenas de redirección, con límites de velocidad, reintentos acotados y almacenamiento de la evidencia mínima. Guarda estado presente, no verificado y error de infraestructura por separado. No conviertas un 429 o un fallo temporal en un destino ausente, porque podrías eliminar una regla correcta. Programa una segunda prueba desde otro momento o punto de observación y vincula el resultado a la solicitud de cambio. La automatización sirve para descubrir diferencias, no para ocultar la incertidumbre.
Prueba parámetros, métodos y contenido
Una tabla de redirecciones suele quedarse corta cuando solo contiene la URL visible. Conserva también parámetros de campaña, identificadores de producto, fragmentos que el servidor no recibe y diferencias de mayúsculas o barra final. Decide qué parámetros se mantienen, cuáles se eliminan y cuáles deben producir un destino distinto. Prueba una muestra de peticiones GET y POST en las rutas que aceptan formularios o API, porque un cambio de código puede modificar el método o perder el cuerpo. La ruta correcta para una página informativa no demuestra que un webhook o un pago sigan funcionando.
Después de seguir cada cadena, compara el contenido con el objetivo de negocio. Un 200 final puede ser una página de inicio, un inicio de sesión o un mensaje de error que no coincide con la intención de la URL original. Comprueba título, canonical, idioma, enlaces y respuesta para un agente sin JavaScript. Guarda el destino final y una pequeña evidencia que permita revisar la regla sin almacenar datos de usuarios. Si la URL no tiene equivalente, devuelve una respuesta honesta o una página relacionada, y anota quién decidió esa excepción y cuándo debe volver a revisarse.
Después del lanzamiento, compara una muestra de URLs antiguas, nuevas y rutas de servicio. Revisa que no aumenten los errores, que el certificado cubra todos los hosts y que las sesiones, formularios y webhooks conserven su comportamiento. Monitoriza las cadenas nuevas y cierra reglas de prueba que ya no tienen propietario. Documenta la fecha de migración, el mapa final y el criterio de retirada. Una migración bien cerrada deja menos reglas, destinos claros y una explicación que el equipo podrá reutilizar cuando cambie el siguiente dominio.
El destino final debe ser una decisión de producto y de infraestructura, no el accidente de la última regla añadida.
Principio de una migración web verificable
Una cadena de redirecciones bien gestionada conserva el camino del usuario, ayuda a los buscadores a interpretar el cambio y reduce el trabajo de soporte. Empieza con un mapa URL, elige códigos que expresen intención, comprueba DNS y TLS, elimina saltos innecesarios y mide después del lanzamiento. Utiliza el Comprobador de redirecciones para una URL concreta o la documentación de la API para integrar la revisión en una migración repetible.