logo
GeekFormat

Comprobador de Cadenas de Redirección

Comprobación de cadena de redirecciones

Comprueba salto por salto 301/302/307/308, identifica bucles, redirecciones cross-domain y problemas de downgrade HTTPS.

Cuando introduces una dirección web en tu navegador, puede haber toda una serie de saltos invisibles ocurriendo tras bambalinas: HTTP→HTTPS, sin www→con www, dominio antiguo→dominio nuevo, enlace corto→enlace largo... Cada salto de redirección consume tiempo, afecta al ranking SEO e incluso puede degradar silenciosamente HTTPS a HTTP. El comprobador de cadenas de redirección rastrea la ruta de redirección completa de la URL salto a salto desde la perspectiva del servidor, mostrando el código de estado (301/302/303/307/308), la cabecera Location y la dirección de destino de cada salto, y detecta automáticamente problemas como saltos en bucle, saltos entre dominios, degradación HTTPS y truncamiento de cadena, ayudándote a descubrir riesgos ocultos de redirección en migraciones de dominio, implementación HTTPS y optimización SEO.

Relacionado

Casos de uso

  • Verificación de migración de dominio: después de cambiar el sitio de un dominio antiguo a uno nuevo, confirma salto a salto si las URLs antiguas se redirigen correctamente con 301 permanente a la nueva dirección, evitando pérdidas de tráfico por saltos en cadena y códigos de estado incorrectos
  • Comprobación de implementación HTTPS: confirma si la cadena de redirección HTTP→HTTPS es un solo salto 301, verifica si existen bucles de degradación HTTP→HTTPS→HTTP y valida si la configuración HSTS está activa
  • Detección de página de destino de enlaces cortos: rastrea la ruta de redirección completa de enlaces cortos (t.cn/bit.ly, etc.), enlaces de marketing UTM o enlaces compartidos en redes sociales, confirma si la página de destino final es la dirección esperada e investiga si los saltos intermedios insertan parámetros de seguimiento o redirecciones maliciosas
  • Normalización de www y sin www: comprueba si el dominio www y el dominio raíz se redirigen correctamente entre sí con 301 a la versión canónica, evitando problemas de contenido duplicado en SEO por funcionamiento en doble vía
  • Resolución de redirecciones en bucle: cuando el navegador muestra el error ERR_TOO_MANY_REDIRECTS, utiliza la herramienta para localizar con precisión los nodos donde ocurre el bucle, distinguiendo si se debe a errores de configuración de Nginx/Apache, conflictos de reglas CDN o plugins de WordPress
  • Depuración de CDN y proxy inverso: investiga conflictos de redirección en arquitecturas de múltiples capas como Cloudflare, CDN de Alibaba Cloud y proxy inverso Nginx, identificando problemas de redirección mutua entre reglas CDN y reglas de origen
  • Auditoría de salud SEO: comprueba periódicamente la longitud de la cadena de redirección de las páginas principales del sitio, evalúa el impacto de los saltos múltiples en la eficiencia de transferencia de PageRank y optimiza cadenas de redirección excesivamente largas
  • Evaluación de riesgos de redirección entre dominios: detecta escenarios que involucran redirección entre dominios como saltos de inicio de sesión, callbacks OAuth y saltos de pago, confirmando si las Cookies y Sesiones se transfieren correctamente durante el proceso entre dominios
  • Verificación de equilibrio de carga y multiactivo: comprueba la estrategia de redirección en escenarios de centros de datos multiactivo y equilibrio de carga global GSLB, confirmando que los usuarios de diferentes regiones son redirigidos correctamente al nodo disponible más cercano
  • Depuración de caché de redirección: valida la configuración de las cabeceras Cache-Control y Expires para redirecciones permanentes 301 y temporales 302, e investiga accesos anómalos causados por que el navegador almacene en caché reglas de redirección antiguas

Características

  • Seguimiento completo salto a salto: sigue cada redirección desde la perspectiva del servidor, mostrando secuencialmente la URL original, código de estado de cada salto, texto de estado, cabecera de respuesta Location y ruta de redirección completa, sin omitir ningún nodo intermedio
  • Soporte para todos los códigos de estado: cubre cinco códigos de estado de redirección estándar — 301 Moved Permanently, 302 Found, 303 See Other, 307 Temporary Redirect, 308 Permanent Redirect — y marca las diferencias semánticas de cada uno
  • Detección de bucles de redirección: identifica automáticamente patrones de salto en bucle como A→B→A, marca la posición exacta del nodo donde ocurre el bucle y su longitud, localizando con precisión la causa raíz del error ERR_TOO_MANY_REDIRECTS
  • Identificación de saltos entre dominios: detecta cambios de Host/Dominio en cada salto, marca los nodos de redirección entre dominios y advierte sobre el riesgo de pérdida de Cookie y problemas de preflight CORS
  • Alerta de degradación HTTPS: cuenta el número de nodos HTTP (no HTTPS) en la cadena de redirección, marca los saltos de degradación HTTPS→HTTP y advierte sobre riesgos de seguridad e impacto negativo en SEO
  • Protección contra truncamiento de cadena: establece un límite máximo de profundidad de salto (20 saltos), trunca automáticamente y marca cuando la cadena es demasiado larga, evitando tiempos de espera de solicitud por seguimiento infinito
  • Resumen estadístico de redirección: proporciona una vista rápida de métricas clave como número total de saltos, URL de destino final, si se detectó bucle, si es entre dominios, número de nodos HTTP y si la cadena fue truncada
  • Evaluación de impacto SEO: evalúa automáticamente el nivel de impacto en la transferencia de PageRank y en Core Web Vitals según el número de saltos, el tipo de código de estado y la cobertura HTTPS
  • URLs de prueba predefinidas: incluye direcciones de prueba comunes como geekformat.com, github.com, httpbin.org/redirect y servicios de enlaces cortos, con relleno con un clic para una experiencia rápida
  • Historial de consultas recientes: guarda automáticamente los últimos 8 registros de consulta (almacenados localmente en el navegador), admite detección repetida con un clic, facilitando la comparación de resultados antes y después de la reparación
  • Tarjetas de recomendaciones de diagnóstico: ofrece recomendaciones de reparación específicas y guías de mejores prácticas para problemas detectados como saltos en bucle, saltos entre dominios, degradación HTTP y cadenas demasiado largas
  • Vista dual de detalles y resumen: muestra la tarjeta de resumen de cadena por defecto; al expandir, puedes ver la URL de solicitud completa, el estado de respuesta, el destino Location y la marca HTTPS de cada salto

Cómo Usar

  1. Introduce la URL que deseas comprobar en el campo de entrada (debe incluir el prefijo de protocolo http:// o https://), o haz clic en los botones de URL predefinida (geekformat.com/github.com/httpbin.org/redirect, etc.) para rellenar rápidamente la dirección de prueba
  2. Haz clic en el botón «Rastrear cadena de redirección»; la herramienta enviará la solicitud desde el servidor y seguirá la cabecera de respuesta Location salto a salto para registrar información completa de cada salto
  3. Consulta la tarjeta de resumen de redirección en la parte superior: número total de saltos, URL de destino final, si se detectó bucle, si existen saltos entre dominios, número de nodos HTTP y si la cadena fue truncada por exceso de saltos
  4. Visualiza la información detallada de cada salto en el área de visualización de cadena: número de orden, URL de solicitud, código de estado de respuesta y texto descriptivo, URL de destino en la cabecera de respuesta Location, marca de seguridad HTTPS
  5. Presta atención a las tarjetas de advertencia de diagnóstico: si se detectan saltos en bucle (rojo), degradación HTTPS (naranja), saltos entre dominios (amarillo) o cadenas demasiado largas (amarillo), la herramienta los resaltará en las posiciones correspondientes y proporcionará una explicación del problema
  6. Utiliza el área de evaluación de impacto SEO para ver el nivel de impacto de la cadena de redirección actual en la eficiencia de transferencia de PageRank, la velocidad de carga de la página y Core Web Vitals, así como recomendaciones de optimización
  7. Después de completar la detección, puedes hacer clic en cualquier registro del historial de consultas recientes para repetir rápidamente la detección y comparar los cambios en la cadena de redirección antes y después de la reparación; también puedes capturar una pantalla o copiar el texto de los resultados para comunicación en equipo y registro de tickets

Preguntas Frecuentes

¿Cuántos saltos se consideran demasiados en una cadena de redirección? ¿Qué impacto tiene en el SEO?

Google recomienda oficialmente mantener las cadenas de redirección en un solo salto, como máximo 3 saltos. Según la documentación de Google Search Central, Googlebot normalmente sigue hasta 5 saltos de redirección antes de dejar de rastrear, pero esto no significa que 5 saltos sean seguros. Cada salto de redirección aumenta el retraso en la carga de la página (100-300ms/salto), desperdicia presupuesto de rastreo y puede provocar una disminución en la transferencia de PageRank. 1 salto casi no tiene impacto SEO; 2 saltos son aceptables pero se recomienda optimizar; más de 3 saltos empiezan a afectar a LCP y a la eficiencia de rastreo; más de 5 saltos existe el riesgo de que la página no se indexe. Utiliza esta herramienta para detectar la cadena de redirección de tus páginas principales, asegurándote de que las URLs clave (página principal, páginas de productos principales, páginas internas de alto tráfico) lleguen directamente en un solo salto.

¿Las redirecciones 301 dañan el SEO? ¿Se transfiere PageRank completamente?

Las redirecciones permanentes 301 utilizadas correctamente no dañan el SEO. Gary Illyes y John Mueller de Google han confirmado en múltiples ocasiones que, para las redirecciones 301 de migración de dominio HTTP a HTTPS y para migraciones permanentes de páginas dentro del mismo dominio, la transferencia de PageRank es del 100%, sin pérdidas. Pero ten en cuenta: 1) Las redirecciones temporales 302 no transfieren PageRank (o lo hacen con una eficiencia extremadamente baja); 2) Si aparecen noindex, bloqueo por robots.txt o errores 4xx/5xx en la cadena de redirección, la transferencia de autoridad se interrumpe; 3) Después de una migración 301 entre dominios, es necesario enviar una notificación de cambio de dominio en Google Search Console para acelerar la migración del índice; 4) Las redirecciones 301 se almacenan en caché a largo plazo por el navegador; durante la fase de prueba, se recomienda verificar primero con 302 antes de cambiar a 301.

¿Por qué mi sitio web redirige automáticamente a HTTP en lugar de HTTPS? ¿Cómo repararlo?

Los saltos de degradación HTTPS→HTTP suelen deberse a las siguientes causas: 1) El proxy inverso/CDN vuelve al origen por HTTP, y cuando Nginx/Apache del servidor de origen utiliza la variable $scheme para obtener el protocolo, obtiene http en lugar de https; 2) El código de la capa de aplicación tiene codificada de forma rígida URLs con prefijo http://; 3) La URL Home o Site URL de CMS como WordPress está configurada como http; 4) Existen restos de reglas HTTP antiguas en .htaccess; 5) La configuración SSL/TLS de servicios de terceros (CDN/WAF) está en modo «flexible» en lugar de modo «estricto». Pasos de reparación: primero utiliza esta herramienta para determinar en qué salto ocurre la degradación; configura el SSL de la CDN en modo «Full (strict)»; en Nginx, maneja correctamente la cabecera X-Forwarded-Proto; en WordPress, añade $_SERVER['HTTPS']='on'; en wp-config.php; implementa la cabecera de respuesta HSTS para evitar la degradación a nivel de navegador; comprueba que todas las reglas de redirección tengan como destino https://.

¿Cómo reparar los bucles de redirección en Nginx (ERR_TOO_MANY_REDIRECTS)?

Más del 90% de los bucles de redirección en Nginx se deben a un manejo incorrecto de la cabecera X-Forwarded-Proto en escenarios de proxy inverso/CDN. Métodos de reparación: 1) Asegúrate de que la CDN/equilibrio de carga envíe la cabecera X-Forwarded-Proto al backend: proxy_set_header X-Forwarded-Proto $scheme; 2) En Nginx, utiliza X-Forwarded-Proto en lugar de $scheme para determinar si se debe saltar a HTTPS. Se recomienda utilizar un bloque map: map $http_x_forwarded_proto $is_https { default 0; "https" 1; } server { listen 80; if ($is_https = 0) { return 301 https://$host$request_uri; } } 3) Evita escribir reglas rewrite en el bloque server que coincidan infinitamente consigo mismas; 4) Las redirecciones entre www y sin www configuran saltos unidireccionales solo en un bloque server, no configures de forma bidireccional.

¿Cómo reparar los bucles de redirección en .htaccess de Apache?

Los bucles en .htaccess de Apache suelen deberse a conflictos entre las reglas RewriteRule. Pasos de reparación: 1) Asegúrate de que RewriteEngine On aparezca solo una vez; 2) Coloca la regla de salto HTTP→HTTPS al principio de todas las reglas, utilizando: RewriteCond %{HTTPS} off RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]; 3) Las reglas www/sin www se colocan después del salto HTTPS y solo realizan saltos unidireccionales (sin www→www o viceversa); 4) Ten en cuenta que el flag [L] significa «last» pero si la regla modifica la URL, la coincidencia volverá a empezar desde la primera regla, lo que puede provocar bucles; para reglas complejas, considera utilizar el flag [END] (Apache 2.3.9+); 5) Comprueba si hay múltiples archivos .htaccess (los .htaccess en subdirectorios también surten efecto); 6) Cambia temporalmente R=301 a R=302 para probar, evitando interferencias por caché del navegador.

¿Cómo reparar los bucles de redirección causados por Cloudflare?

La causa más común de los bucles de Cloudflare es una configuración incorrecta del modo de cifrado SSL/TLS o conflictos en reglas de página: 1) Cambia el modo SSL/TLS de Cloudflare de «Flexible» a «Full» o «Full (strict)» — en modo Flexible, Cloudflare utiliza HTTP para llegar al origen, y si el origen tiene configurado el salto forzado a HTTPS, se produce un bucle; 2) Comprueba si «Always Use HTTPS» en «Edge Certificates» de Cloudflare está activado; no configures repeticiones de salto HTTPS tanto en el origen como en Cloudflare; 3) Comprueba si hay reglas de reenvío conflictivas en Page Rules; 4) Si utilizas el plugin Cloudflare WordPress, no configures redirecciones HTTPS tanto en el plugin como en Cloudflare simultáneamente; 5) Comprueba si las reglas de Forwarding URL apuntan a direcciones que a su vez son redirigidas por Cloudflare.

¿Cuál es la diferencia entre las redirecciones 301, 302, 307 y 308? ¿Cuál debería elegir?

La diferencia fundamental radica en dos dimensiones: «si es permanente» y «si se preserva el método de solicitud». Guía de selección rápida: para solicitudes GET de páginas web normales (usuarios accediendo a páginas) — usa 301 para migraciones permanentes (migración de dominio, cambio a HTTPS, cambio permanente de URL) y 302 para saltos temporales (pruebas A/B, mantenimiento temporal, redirección de inicio de sesión); para solicitudes POST/PUT/DELETE (llamadas API, envío de formularios) — usa 308 para migraciones permanentes y 307 para saltos temporales, asegurando que el método y el cuerpo de la solicitud no se pierdan; 303 se utiliza específicamente para saltar a la página de resultados después del envío de un formulario POST (forzando GET, evitando envío repetido). Recordatorio sencillo: 301=permanente seguro para GET, 302=temporal seguro para GET, 307=temporal para todos los métodos, 308=permanente para todos los métodos, 303=salto a página de resultados después de POST.

¿El navegador almacena en caché permanentemente las redirecciones 301? ¿Cómo borrar la caché 301?

Las redirecciones permanentes 301 se almacenan en caché por defecto en el navegador, pero el tiempo de caché depende de la configuración de Cache-Control y Expires en las cabeceras de respuesta. Si no se especifican explícitamente cabeceras de caché, el comportamiento de caché predeterminado varía según el navegador: Chrome normalmente almacena en caché las redirecciones 301 durante semanas o meses (incluso puede seguir almacenándolas después de reiniciar el navegador); Firefox almacena en caché 301 por defecto pero puede volver a validarlo después de reiniciar el navegador; la estrategia de caché de Safari es relativamente conservadora. Métodos para borrar la caché 301: 1) Chrome: Configuración→Privacidad y seguridad→Borrar datos de navegación→Rango de tiempo selecciona «Todos los periodos»→marca «Imágenes y archivos en caché»→Borrar datos; 2) Cuando las herramientas de desarrollo (F12) están abiertas, marca «Disable cache» en el panel Network; 3) Añade un parámetro de consulta sin sentido al final de la URL (?nocache=1) para evitar la caché; 4) Los desarrolladores Chrome pueden Flush sockets en chrome://net-internals/#sockets, o Clear host cache en chrome://net-internals/#dns; 5) Durante la fase de prueba, utiliza redirección temporal 302 en lugar de 301, y cambia a 301 después de confirmar que todo es correcto.

¿Cuál es la diferencia entre Meta Refresh y la redirección HTTP? ¿Cuál es mejor?

Meta Refresh es una redirección implementada mediante la etiqueta <meta> en el documento HTML (como <meta http-equiv="refresh" content="0;url=https://example.com/new">), que realiza el salto después de que el navegador analice el HTML, mientras que la redirección HTTP se indica directamente por el servidor a nivel de protocolo HTTP mediante códigos de estado 3xx. Comparación de diferencias: 1) Velocidad: la redirección HTTP empieza a saltar al recibir la cabecera de respuesta, mientras que Meta Refresh necesita esperar a que se descargue y analice el HTML para saltar, por lo que es más lenta; 2) SEO: Google normalmente puede reconocer Meta Refresh y transferir autoridad (si delay=0), pero oficialmente se recomienda utilizar redirecciones HTTP 301/302, porque Meta Refresh es un salto de cliente y su señal no es tan clara como la redirección de servidor; 3) Retraso: Meta Refresh puede configurar el tiempo de retraso (como content="5;url=..." significa saltar después de 5 segundos), pero la redirección HTTP no tiene esta función; 4) Accesibilidad: W3C no recomienda utilizar Meta Refresh, porque las tecnologías de asistencia como lectores de pantalla no la manejan bien y puede confundir a los usuarios; 5) Botón de retroceso: Meta Refresh puede romper el comportamiento del botón de retroceso en algunos navegadores. Conclusión: prioriza siempre el uso de redirecciones HTTP 301/302/307/308 y evita Meta Refresh, a menos que no puedas controlar la configuración del servidor (como alojarse en plataformas de páginas estáticas sin poder configurar reglas de servidor).

¿Las redirecciones afectan a LCP en Core Web Vitals?

Sí, y el impacto es muy grande. La redirección ocurre antes de que el navegador obtenga el documento HTML, lo que significa que cada salto de redirección retrasa el inicio de la descarga del documento HTML. El punto de cálculo de LCP (Largest Contentful Paint) es el tiempo de inicio de navegación, y el navegador debe obtener el HTML final para poder empezar a analizar el DOM, cargar CSS y renderizar el elemento LCP. Suponiendo que cada salto de redirección añade 150ms de retardo de red (DNS+TCP+TLS+solicitud-respuesta), 3 saltos de redirección harían que LCP aumentara al menos 450ms, lo suficiente para llevar a LCP de «bueno» (≤2,5s) al intervalo de «necesita mejora» (2,5-4s). La documentación de Core Web Vitals de Google menciona explícitamente «evitar múltiples redirecciones» como una de las recomendaciones clave para optimizar LCP. Mejores prácticas: asegúrate de que las páginas principales tengan cero redirecciones (enlaces directos a la URL final), y las redirecciones necesarias como HTTP→HTTPS y normalización www se mantengan en un solo salto.

¿Cómo comprobar a dónde redirige finalmente un enlace corto?

Los enlaces cortos (t.cn, bit.ly, dwz.cn, url.cn, etc.) normalmente llegan a la URL final mediante 1-3 saltos de redirección, y en el medio pueden incluir parámetros de seguimiento UTM, saltos por detección de dispositivo, saltos por región, etc. Con esta herramienta puedes: 1) Introducir la URL del enlace corto (incluyendo http:// o https://); 2) Hacer clic en rastrear para ver la ruta completa de cada salto; 3) Ver la URL de destino final, el número de saltos y el tipo de código de estado; 4) Comprobar si hay degradación HTTP o redirección entre dominios anómala en los saltos intermedios. Nota: algunos enlaces cortos devuelven diferentes destinos finales según el User-Agent o la región de la IP; esta herramienta utiliza una IP de servidor para realizar las solicitudes, por lo que los resultados pueden diferir ligeramente de los que ves en tu navegador (especialmente para servicios de enlaces cortos en el extranjero). Para los enlaces cortos url.cn de WeChat/QQ, es posible que se necesite estar dentro del entorno de WeChat para redirigir correctamente a la página de destino.

¿Para el salto forzado HTTPS se usa 301 o 302? ¿Es necesario añadir HSTS?

El salto forzado HTTPS debe utilizar redirección permanente 301, porque el cambio de HTTP a HTTPS es un cambio permanente, no un salto temporal. Después de configurar 301, también se debe implementar la cabecera de respuesta HSTS. El esquema completo de HTTPS forzado se divide en tres fases: 1) Primera fase (periodo de prueba): configura primero la redirección 301 HTTP→HTTPS, no habilites HSTS, observa 1-2 semanas para confirmar que todos los recursos y subdominios funcionan correctamente; 2) Segunda fase (periodo estable): añade la cabecera de respuesta Strict-Transport-Security, establece inicialmente max-age en un tiempo corto (como max-age=300, es decir, 5 minutos), aumentando gradualmente hasta max-age=31536000 (1 año); 3) Tercera fase (Preload): después de confirmar que todos los subdominios admiten HTTPS, añade includeSubDomains y la directiva preload, luego envía a la HSTS Preload List (hstspreload.org), haciendo que el navegador tenga incorporada la estrategia HSTS de tu dominio, eliminando la ventana HTTP en el primer acceso. Ten en cuenta que una vez que HSTS se almacena en caché en el navegador, no puede revocarse desde el lado del servidor antes de que caduque max-age, así que asegúrate de probar exhaustivamente.

¿Cuál es la diferencia entre el salto window.location de JavaScript y la redirección HTTP?

El salto JS (como window.location.href='https://example.com') tiene una diferencia fundamental con las redirecciones HTTP 3xx: 1) Nivel de ejecución: la redirección HTTP devuelve un código de estado por el servidor a nivel de protocolo, y el navegador salta inmediatamente al recibir la cabecera de respuesta; el salto JS necesita que se descargue el HTML y se ejecute el análisis JS para saltar, por lo que es más lento; 2) SEO: los robots de motores de búsqueda pueden reconocer y seguir correctamente las redirecciones HTTP 301/302 para transferir autoridad, pero el efecto SEO de los saltos JS depende de si el robot ejecuta JS y del momento de ejecución, siendo la señal débil e inestable; 3) Etapa intermedia: antes del salto JS, la página ya ha empezado a cargarse (puede aparecer una pantalla en blanco o parpadeo de contenido parcial), mientras que con la redirección HTTP el usuario llega directamente a la página de destino, con una experiencia más fluida; 4) Fiabilidad: JS puede ser bloqueado por el navegador, extensiones o Content Security Policy, mientras que la redirección HTTP es manejada por el núcleo del navegador, con máxima fiabilidad. Conclusión: cuando necesites redirigir URLs de forma permanente/temporal, utiliza siempre redirecciones HTTP 301/302 de servidor; los saltos JS solo se utilizan para la navegación de páginas en la lógica interactiva (como saltos después de la validación de formularios, saltos por clic en botones, etc.).

¿Las cadenas de redirección pueden hacer que los resultados de las pruebas A/B sean inexactos?

Sí, las cadenas de redirección afectan a las pruebas A/B en múltiples aspectos: 1) Si la prueba A/B se implementa mediante redirección (50% de usuarios con 302 a la versión A, 50% a la versión B), el retraso por redirección hará que la velocidad de carga de la página sea diferente en las dos versiones, y la velocidad en sí misma puede afectar a la tasa de conversión (la versión más rápida tiene naturalmente una tasa de conversión más alta), provocando desviaciones en la prueba; 2) Durante el proceso de redirección pueden perderse parámetros UTM o marcas de origen, provocando datos de atribución inexactos; 3) Si una redirección 302 dura demasiado tiempo, Google puede determinar por sí misma que es una redirección 301 y transferir autoridad, afectando al SEO de las páginas de prueba; 4) Si en una cadena de redirección de múltiples saltos algún salto configura una Cookie, puede afectar a la lógica de agrupación de usuarios. Se recomienda que las pruebas A/B utilicen la distribución por renderizado de servidor o la distribución JS de cliente (como Google Optimize, Optimizely), evitando la distribución por redirección. Si es necesario utilizar redirección (como probar rutas URL completamente diferentes), utiliza 302 (no 301) y asegúrate de que llegue directamente en un solo salto, eliminando la redirección puntualmente después de finalizar la prueba.

¿Cómo comprobar masivamente las cadenas de redirección de todo un sitio web?

La comprobación masiva de cadenas de redirección de un sitio web requiere combinar herramientas de rastreo: 1) Utiliza herramientas de rastreo como Screaming Frog SEO Spider para rastrear todo el sitio web y visualizar todas las URLs de redirección y la longitud de la cadena en el informe Redirect Chains; 2) Utiliza las funciones de auditoría de sitio de herramientas SEO como Ahrefs, Semrush o Sitebulb, que detectan automáticamente cadenas y bucles de redirección; 3) Para listas de páginas principales, puedes escribir scripts que llamen a la API backend de esta herramienta para detectar masivamente; 4) Consulta las indicaciones de «errores de redirección» y «cadena de redirección demasiado larga» en el informe de «índice de páginas» de Google Search Console; 5) Utiliza la auditoría Lighthouse de Chrome DevTools; en la sección Performance se marcarán los problemas de redirección. Se recomienda priorizar la comprobación de: página principal, páginas de navegación principales, páginas de destino de alto tráfico, páginas recientemente migradas/rediseñadas, todas las URLs HTTP después del cambio a HTTPS, todas las URLs bajo dominios antiguos.

术语表

Redirección (Redirect)
Mecanismo por el cual el servidor indica al cliente que acceda automáticamente a otra URL devolviendo un código de estado 3xx y una cabecera de respuesta Location. La redirección suele ser transparente para el usuario, y el navegador sigue automáticamente el salto.
301 Moved Permanently
Código de estado de redirección permanente. Indica que el recurso se ha movido permanentemente a una nueva ubicación; los motores de búsqueda transfieren el PageRank de la URL antigua a la nueva URL, y los navegadores almacenan en caché esta redirección a largo plazo. Recomendado para migraciones de dominio, cambio a HTTPS y otros cambios permanentes en escenarios de solicitudes GET.
302 Found
Código de estado de redirección temporal (anteriormente llamado Moved Temporarily). Indica que el recurso se encuentra temporalmente en otra ubicación; los motores de búsqueda no transfieren autoridad y los navegadores no almacenan en caché a largo plazo. Nota: después de que una solicitud POST recibe un 302, la mayoría de los navegadores convierten la solicitud a GET para redirigir, pudiendo perder el cuerpo de la solicitud.
303 See Other
Código de estado de ver otra ubicación. Normalmente utilizado para saltos a páginas de resultados después del envío de formularios POST, requiriendo explícitamente que el cliente solicite la nueva URL con el método GET para evitar el envío repetido de formularios. Las respuestas 303 no deberían almacenarse en caché.
307 Temporary Redirect
Código de estado de redirección temporal (introducido en HTTP/1.1). Tiene el mismo significado que 302, pero exige estrictamente preservar el método y el cuerpo de la solicitud — una solicitud POST que recibe un 307 debe seguir solicitando la nueva URL mediante POST, sin perder los datos del formulario. Aplicable a saltos temporales en escenarios de API y formularios.
308 Permanent Redirect
Código de estado de redirección permanente (definido en RFC 7538). Tiene el mismo significado que 301, pero exige estrictamente preservar el método y el cuerpo de la solicitud — una solicitud POST que recibe un 308 sigue redirigiendo mediante POST. Es la versión «segura en método» de 301, ya completamente compatible en navegadores modernos.
Cabecera Location
Campo de cabecera de respuesta HTTP, utilizado para especificar la URL de destino en respuestas de redirección 3xx. Puede ser una URL absoluta (recomendado) o una URL relativa; tras recibirla, el cliente envía automáticamente una nueva solicitud a esa URL. Los caracteres no ASCII en la cabecera Location deben codificarse en URL.
Cadena de redirección (Redirect Chain)
Serie de redirecciones consecutivas que transcurren desde la URL inicial hasta la URL de destino final. Por ejemplo, A→B→C→D forma una cadena de redirección de 3 saltos. Las cadenas de redirección excesivamente largas ralentizan la velocidad de carga y reducen la autoridad SEO; se recomienda mantenerlas en un solo salto, como máximo 3 saltos.
Bucle de redirección (Redirect Loop)
Una URL en la cadena de redirección aparece repetidamente, formando un bucle infinito de saltos (como A→B→A). Cuando el navegador alcanza el número máximo de saltos (normalmente 20 veces), muestra el error ERR_TOO_MANY_REDIRECTS. Las causas comunes incluyen saltos mutuos HTTP↔HTTPS, saltos mutuos www↔sin www y pérdida de protocolo en proxy inverso.
Migración de dominio (Domain Migration)
Proceso por el cual un sitio web cambia permanentemente de un dominio a otro, como el cambio de dominio por marca o fusión/adquisición de empresas. Durante la migración, es necesario redirigir todas las URLs del dominio antiguo a las páginas correspondientes del nuevo dominio mediante redirección permanente 301, y enviar una notificación de cambio de dominio en Google Search Console.
Normalización de URL (URL Canonicalización)
Proceso de unificar múltiples variantes de URL para un mismo contenido (www/sin www, con/sin barra final, HTTP/HTTPS, diferencias de mayúsculas/minúsculas) en una URL canónica única, normalmente implementado mediante redirección 301. La normalización evita problemas de contenido duplicado y concentra la autoridad SEO.
Redirección forzada HTTPS
Configuración que redirige todas las solicitudes HTTP (puerto 80) a HTTPS (puerto 443) mediante 301; es un paso necesario después de implementar certificados SSL/TLS. Normalmente se utiliza junto con la cabecera de respuesta HSTS para eliminar la ventana de texto plano HTTP en el primer acceso.
HSTS
HTTP Strict Transport Security; mediante la cabecera de respuesta Strict-Transport-Security, le dice al navegador que solo puede acceder al dominio por HTTPS durante el tiempo especificado. El navegador actualiza automáticamente HTTP a HTTPS internamente, sin necesidad de redirección por parte del servidor. Defiende eficazmente contra ataques de despojo SSL.
Enlace corto (Short URL)
Servicio que convierte URLs largas en URLs cortas (como bit.ly, t.cn); al acceder, redirige a la URL original mediante redirección 301/302. Detrás de los enlaces cortos suelen ocultarse cadenas de redirección de múltiples saltos, que pueden incluir parámetros de seguimiento o redirigir a diferentes destinos en condiciones específicas.
PageRank
Algoritmo de ranking de páginas web inventado por los fundadores de Google, Larry Page y Sergey Brin, que evalúa la autoridad de la página a través de relaciones de enlaces. Las redirecciones permanentes 301 transfieren el PageRank de la URL antigua a la nueva URL, mientras que las redirecciones temporales 302 normalmente no transfieren o transfieren muy poco.
Core Web Vitals
Métricas de experiencia web principales definidas por Google, que incluyen LCP (Largest Contentful Paint, mide el rendimiento de carga, estándar bueno ≤2,5s), FID/INP (capacidad de respuesta interactiva, estándar bueno ≤100ms/200ms) y CLS (estabilidad visual, estándar bueno ≤0,1). Las cadenas de redirección retrasan la descarga HTML y deterioran directamente la métrica LCP.
Redirección entre dominios (Cross-origin Redirect)
El dominio de la URL de destino de la redirección es diferente al de la URL original (incluyendo dominios completamente diferentes o diferentes subdominios). Las redirecciones entre dominios están limitadas por la política de mismo origen, lo que puede provocar que no se envíen Cookies, se bloqueen Cookies de terceros, fallen preflight CORS y otros problemas.
Truncamiento de cadena (Chain Truncation)
Cuando el número de saltos de la cadena de redirección supera el límite máximo de profundidad establecido por la herramienta o el navegador (esta herramienta: 20 saltos, Chrome: 20 saltos), el rastreador deja de seguir las redirecciones posteriores y marca la cadena como truncada. El truncamiento de cadena normalmente sugiere la existencia de un bucle infinito o una configuración de redirección anómalamente compleja.

Tabla de comparación completa de códigos de estado de redirección HTTP

301Moved PermanentlySí (permanente)Puede cambiar (POST→GET)Migración de dominio, cambio a HTTPS, normalización www/sin www, cambio permanente de URL
302FoundNo (temporal)Puede cambiar (POST→GET)Páginas de mantenimiento temporal, redirección de inicio de sesión, pruebas A/B, páginas de campaña a corto plazo
303See OtherNo (temporal)Sí (GET forzado)Salto a página de resultados después del envío de formulario POST, evitando envío repetido
307Temporary RedirectNo (temporal)No (preserva estrictamente el método original)Redirección temporal de API, saltos temporales que necesitan preservar datos POST
308Permanent RedirectSí (permanente)No (preserva estrictamente el método original)Migración permanente de API RESTful, redirecciones permanentes que necesitan preservar métodos PUT/DELETE

Tabla de comparación del impacto de las cadenas de redirección en el SEO

0 saltos (llegada directa)Sin impacto, estado óptimoSin retraso adicionalMantén el estado actual; los enlaces internos apuntan directamente a la URL final
1 saltoTransferencia normal de PageRank, impacto SEO despreciableAñade aproximadamente 100-300ms de retraso (un viaje de ida y vuelta)Aceptable; número común de saltos para HTTP→HTTPS y normalización de dominio
2 saltosLa transferencia de autoridad puede tener una ligera disminución; los robots pueden rastrear normalmenteAñade aproximadamente 200-600ms de retrasoSe recomienda optimizar a un solo salto; comprueba si los enlaces internos apuntan a URLs de redirección intermedias
3 saltosDisminuye la eficiencia de transferencia de autoridad; algunos robots pueden abandonar el seguimientoAñade aproximadamente 300-900ms de retraso; LCP puede verse afectadoDebe optimizarse; fusiona las reglas de redirección directamente a la URL final
4-5 saltosDisminución evidente de PageRank; la indexación puede verse afectada; desperdicio de presupuesto de rastreoAñade 500ms-1,5s de retraso; es muy probable que LCP supere el umbralReparación urgente; comprueba la superposición de redirecciones en múltiples capas CDN/origen/aplicación
Más de 6 saltosRiesgo grave; los motores de búsqueda pueden dejar de rastrear y la página se sale del índiceRetraso superior a 1 segundo; experiencia de usuario extremadamente deficienteInvestiga inmediatamente si hay bucles o errores de configuración; reestructura las reglas de redirección
Bucle (ERR_TOO_MANY_REDIRECTS)La página es completamente inaccesible; los motores de búsqueda la eliminan del índiceLa página no carga; el navegador muestra un errorReparación de máxima prioridad; utiliza esta herramienta para localizar los nodos del bucle

Errores comunes de configuración de redirección y soluciones

Error de bucle ERR_TOO_MANY_REDIRECTS, saltos repetidos HTTP↔HTTPSCDN/equilibrio de carga vuelve al origen por HTTP, y el servidor de origen no maneja correctamente la cabecera X-Forwarded-Proto, redirigiendo siempre a HTTPSAñade en la configuración Nginx: set $forwarded_scheme $http_x_forwarded_proto; if ($forwarded_scheme != "https") { return 301 https://$host$request_uri; } o utiliza la variable $scheme junto con la configuración proxy_set_header X-Forwarded-Proto
www y sin www saltan entre sí formando un bucleLa capa CDN configura el salto www→sin www, y el Nginx de origen configura el salto sin www→www, conflicto de reglasElige una versión canónica (recomendado sin www o www, mantén la coherencia), configura la redirección solo en una capa (CDN o origen) y elimina las reglas correspondientes en las otras capas
La cadena de redirección pasa por 4-5 saltos antes de llegar a la página finalSalto HTTP→HTTPS → salto sin www→www → salto de adición de barra final → salto de ruta antigua a ruta nueva, superposición de reglas de múltiples capasFusiona las reglas de redirección, saltando directamente desde la URL inicial a la URL final en un solo paso. En Nginx, utiliza la directiva return para saltar directamente a la dirección final completa
Aparecen nodos HTTP (degradación) en la cadena de redirección de un sitio HTTPSLa configuración del servidor tiene codificada de forma rígida una destino de redirección con prefijo http://, o la aplicación genera la URL de redirección sin reconocer que se está accediendo por HTTPSConfigura la aplicación para confiar en el proxy inverso y leer correctamente X-Forwarded-Proto; en Nginx, utiliza URLs absolutas https:// o la variable $scheme (siempre que el proxy haya configurado correctamente el scheme); implementa HSTS
Después de modificar una redirección 301, el navegador sigue saltando a la dirección antiguaEl navegador almacena en caché a largo plazo las reglas de redirección permanente 301; la actualización F5 no tiene efectoDurante la fase de prueba, utiliza redirección temporal 302 para confirmar que todo es correcto antes de cambiar a 301; borra la caché del navegador (Chrome: Configuración→Privacidad→Borrar datos de navegación→Imágenes y archivos en caché); utiliza la opción Disable cache en DevTools
Pérdida de datos de formulario después de redireccionar una solicitud POSTSe ha utilizado redirección 301 o 302, y el navegador convierte automáticamente POST en GET, descartando el cuerpo de la solicitudPara solicitudes que no son GET como POST/PUT/DELETE, cambia a redirección 307 (temporal) o 308 (permanente), preservando estrictamente el método y el cuerpo de la solicitud
Aparecen caracteres de doble codificación como %2520 en la URL después de la redirecciónLos parámetros URL ya han sido codificados una vez, y el servidor los codifica por segunda vez al redirigirComprueba la lógica de redirección, asegurando que la URL se codifique solo una vez; en Nginx, utiliza $request_uri (URI original, sin decodificar) en lugar de $uri (decodificado)
Error CORS después de redirección entre dominios en solicitudes AJAX/fetchEl servidor de destino de la redirección entre dominios no tiene configuradas las cabeceras de respuesta CORS (Access-Control-Allow-Origin, etc.)Asegúrate de que los servidores de cada salto en la cadena de redirección tengan configuradas correctamente las cabeceras CORS; o evita utilizar redirección entre dominios en solicitudes AJAX, cambiando a que el frontend obtenga la URL de destino y solicite directamente

Troubleshooting