Redirecciones HTTP: detectar bucles, cadenas y enlaces sospechosos

⚡TL;DR

• Los bucles de redirección (ERR_TOO_MANY_REDIRECTS) se producen por configuraciones circulares entre servidores, CDN o CMS.
• Las cadenas de redirección excesivas (más de 3 saltos) diluyen el SEO y añaden de 100 a 500 ms de latencia por salto.
• Los enlaces acortados (bit.ly, t.co) ocultan el destino real y pueden conducir a sitios de phishing.
• El Redirect Checker de CaptainDNS detecta automáticamente estos tres problemas en un solo análisis.
• Google sigue un máximo de 10 redirecciones. Más allá, la página no se indexa.

Haces clic en un enlace y tu navegador muestra ERR_TOO_MANY_REDIRECTS. O la página termina cargando, pero tras un retraso sospechoso de varios segundos. O un compañero te envía un enlace acortado de bit.ly y dudas antes de hacer clic. Estas tres situaciones tienen algo en común: implican redirecciones HTTP que nadie ve, pero que pueden ocultar problemas graves.

Las redirecciones son un mecanismo fundamental de la web. Permiten mover páginas, forzar HTTPS, gestionar vanity URLs. Pero cuando están mal configuradas, generan tres categorías de problemas distintos. Los bucles impiden por completo el acceso a la página. Las cadenas excesivas degradan el SEO y el rendimiento sin que el visitante lo note. Los enlaces acortados ocultan el destino real y sirven como vector de phishing en 1 de cada 10 casos según las investigaciones de Palo Alto Networks sobre dominios recientemente registrados (NRD).

Esta guía cubre el diagnóstico y la corrección de estos tres problemas. Cada sección explica el mecanismo técnico, los síntomas observables y los pasos concretos para resolver la situación. El objetivo es que seas autónomo para identificar y corregir cualquier problema de redirección, ya seas administrador de sistemas, desarrollador o responsable de SEO.

¿Qué es un bucle de redirección?

Un bucle de redirección se produce cuando una URL A redirige a una URL B, que a su vez redirige a la URL A. El navegador sigue las redirecciones en círculo, sin alcanzar nunca una página de contenido. Tras un cierto número de intentos, se rinde y muestra un mensaje de error.

El caso más simple es el ciclo de dos elementos: A redirige a B, B redirige a A. Pero los bucles pueden implicar tres, cuatro o cinco URLs intermedias antes de volver al punto de partida.

¿Cómo reacciona el navegador ante un bucle?

Cada navegador impone un límite al número de redirecciones que sigue antes de rendirse. Cuando se alcanza ese límite, el navegador muestra un mensaje de error específico.

Navegador	Límite de redirecciones	Mensaje de error
Chrome	20	ERR_TOO_MANY_REDIRECTS
Firefox	20	"La página no está redirigiendo adecuadamente"
Safari	16	"Safari no puede abrir la página"
Edge	20	ERR_TOO_MANY_REDIRECTS

El navegador no distingue entre un bucle (ciclo) y una cadena muy larga (secuencia lineal). En ambos casos, si se alcanza el límite, la visualización se bloquea. La diferencia es que una cadena larga terminará por llegar a destino si se aumenta el límite, mientras que un bucle no terminará nunca.

Desde el punto de vista de Googlebot, un bucle es fatal para la indexación. Google detecta el ciclo, marca la página como inaccesible y los backlinks que apuntan a ella pierden todo valor SEO.

Anatomía de un bucle: el ciclo HTTP en detalle

Aquí tienes el detalle de un bucle de tres elementos a nivel de red.

1. GET https://captaindns.com/page-a
   → 301, Location: https://captaindns.com/page-b

2. GET https://captaindns.com/page-b
   → 302, Location: https://captaindns.com/page-c

3. GET https://captaindns.com/page-c
   → 301, Location: https://captaindns.com/page-a

4. GET https://captaindns.com/page-a   (vuelta al punto de partida)
   → 301, Location: https://captaindns.com/page-b

... (el ciclo se repite)

Cada iteración consume una petición de red. Chrome y Firefox cortan después de 20 peticiones, es decir, entre 6 y 7 vueltas completas en un bucle de 3 elementos. La cabecera Location es el hilo conductor: siguiéndola es como las herramientas de diagnóstico reconstruyen la cadena y detectan el punto de retorno.

Las 7 causas más frecuentes de ERR_TOO_MANY_REDIRECTS

Los bucles de redirección casi nunca son intencionales. Son el resultado de conflictos entre varios componentes que intentan forzar una redirección cada uno por su lado. Estas son las 7 causas más comunes, ordenadas por frecuencia de aparición.

1. Conflicto HTTP/HTTPS entre CMS y servidor

Síntoma: el sitio muestra ERR_TOO_MANY_REDIRECTS desde la página de inicio.

Mecanismo: el CMS (WordPress, Joomla) está configurado para forzar HTTPS en sus ajustes internos. Al mismo tiempo, el archivo .htaccess o la configuración de Nginx contiene una regla que redirige HTTP a HTTPS. Cuando el CMS redirige a HTTPS y el servidor redirige esa petición a HTTP (o viceversa por un proxy intermedio), se crea un bucle.

Diagnóstico: verifica la URL del sitio en los ajustes del CMS (siteurl y home en WordPress). Compara con las reglas de redirección del servidor web. Si ambos fuerzan el protocolo en direcciones opuestas, has encontrado la fuente.

Corrección: elige un único punto de control para la redirección HTTP a HTTPS. La buena práctica es gestionar esta redirección a nivel del servidor web (Nginx, Apache) o del reverse proxy, y configurar el CMS para usar HTTPS en su URL sin forzar la redirección por su cuenta.

2. Redirección www/sin-www circular

Síntoma: ERR_TOO_MANY_REDIRECTS solo en la variante www o sin-www del dominio.

Mecanismo: el DNS apunta www.captaindns.com al servidor A y captaindns.com al servidor B. El servidor A redirige a la versión sin-www, el servidor B redirige a la versión www. El navegador rebota indefinidamente entre los dos.

Diagnóstico: prueba ambas variantes por separado con curl -I http://www.captaindns.com y curl -I http://captaindns.com. Si cada una redirige a la otra, el bucle está confirmado.

Corrección: alinea la configuración de ambos servidores con una sola versión canónica. Si eliges captaindns.com como versión canónica, configura www.captaindns.com para redirigir con 301 a captaindns.com, y asegúrate de que captaindns.com no redirija a www.

3. Plugin de caché o de seguridad en WordPress

Síntoma: ERR_TOO_MANY_REDIRECTS tras instalar o actualizar un plugin.

Mecanismo: ciertos plugins de seguridad (Really Simple SSL, Wordfence) o de caché (W3 Total Cache, WP Super Cache) añaden sus propias reglas de redirección en el .htaccess o a través de filtros PHP. Estas reglas pueden entrar en conflicto con las redirecciones existentes del tema, del CMS o del servidor.

Diagnóstico: desactiva los plugins uno a uno vía FTP (renombra la carpeta del plugin en wp-content/plugins/). Cuando el sitio vuelva a ser accesible, el último plugin desactivado es el culpable.

Corrección: reactiva el plugin y ajusta sus parámetros para evitar el conflicto. Si el plugin fuerza HTTPS y tu servidor ya lo hace, desactiva la funcionalidad en el plugin. Si el plugin añade reglas .htaccess, verifica que no dupliquen las reglas existentes.

4. Cloudflare Flexible SSL combinado con HTTPS forzado en el servidor

Síntoma: ERR_TOO_MANY_REDIRECTS tras la activación de Cloudflare.

Mecanismo: el modo "Flexible SSL" de Cloudflare significa que la conexión entre el visitante y Cloudflare es HTTPS, pero la conexión entre Cloudflare y tu servidor es HTTP. Si tu servidor está configurado para redirigir HTTP a HTTPS, redirige la petición de Cloudflare a HTTPS. Cloudflare recibe esa redirección, pero reenvía la petición en HTTP (modo Flexible). El servidor redirige de nuevo a HTTPS, y así sucesivamente.

Diagnóstico: verifica el modo SSL/TLS en el dashboard de Cloudflare. Si es "Flexible" y tu servidor fuerza HTTPS, has encontrado la causa.

Corrección: cambia el modo SSL/TLS de Cloudflare a "Full" o "Full (Strict)". Con el modo Full, Cloudflare se comunica en HTTPS con tu servidor, lo que elimina el conflicto. Asegúrate de que tu servidor tenga un certificado TLS válido (Let's Encrypt es suficiente).

5. Cookies corruptas o bucle de autenticación

Síntoma: ERR_TOO_MANY_REDIRECTS solo para ciertos usuarios, o solo en modo conectado.

Mecanismo: la aplicación redirige a los usuarios no conectados a la página de login. La página de login verifica una cookie de sesión, detecta que el usuario no está conectado (cookie corrupta, expirada o mal formateada) y redirige a la página de login otra vez. O bien, después de la conexión, la aplicación redirige a una página protegida que no reconoce la cookie y vuelve a enviar al login.

Diagnóstico: prueba el sitio en navegación privada (sin cookies). Si el problema desaparece, las cookies son la causa. Pide al usuario afectado que borre sus cookies para el dominio.

Corrección: si el problema es generalizado, verifica la configuración de las cookies de sesión (dominio, ruta, atributo Secure, atributo SameSite). Una cookie con Secure=true no se enviará en una conexión HTTP. Una cookie con un dominio incorrecto (.www.captaindns.com en lugar de .captaindns.com) no se leerá en la variante sin www.

6. Archivo .htaccess con reglas en conflicto

Síntoma: ERR_TOO_MANY_REDIRECTS en un servidor Apache, a menudo tras una modificación manual del .htaccess.

Mecanismo: el archivo .htaccess contiene varios bloques RewriteRule que se contradicen. Por ejemplo, una regla redirige /page a /page/, y otra redirige /page/ a /page. O bien, una regla genérica (catch-all) captura URLs que debían ser excluidas por una regla anterior, pero el orden de las reglas es incorrecto.

Diagnóstico: examina el archivo .htaccess en la raíz del sitio y en todos los subdirectorios. Busca los bloques RewriteRule que apuntan a patrones similares.

Corrección: simplifica el .htaccess. Agrupa todas las redirecciones en un solo bloque, ordénalas de la más específica a la más genérica y añade el flag [L] (last) a las reglas terminales.

Ejemplo de .htaccess limpio que gestiona HTTP a HTTPS y www a sin-www sin conflicto:

RewriteEngine On
# Forzar HTTPS
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}/$1 [R=301,L]
# Forzar sin-www
RewriteCond %{HTTP_HOST} ^www\.(.+)$ [NC]
RewriteRule ^(.*)$ https://%1/$1 [R=301,L]

El orden importa: primero forzar HTTPS, luego gestionar el www. El flag [L] garantiza que cada regla es terminal: una vez activada, Apache no continúa con las reglas siguientes.

7. CDN o reverse proxy mal configurado

Síntoma: ERR_TOO_MANY_REDIRECTS tras implementar un CDN (Cloudflare, Fastly, AWS CloudFront) o un reverse proxy (Nginx, HAProxy).

Mecanismo: el CDN o el reverse proxy modifica las cabeceras de la petición (protocolo, host, ruta) antes de transmitirla al servidor de origen. El servidor de origen toma una decisión de redirección basada en esas cabeceras modificadas y devuelve una respuesta que desencadena una nueva redirección a nivel del CDN. El ciclo se repite.

El caso clásico: el CDN termina la conexión TLS y transmite la petición en HTTP al servidor de origen. El servidor ve HTTP y redirige a HTTPS. El CDN intercepta esa redirección, pero vuelve a enviar en HTTP.

Diagnóstico: prueba el sitio evitando el CDN (accede directamente a la IP del servidor). Si el sitio funciona sin CDN pero no con él, el problema está en la configuración del proxy.

Corrección: configura el servidor de origen para reconocer las cabeceras de proxy (X-Forwarded-Proto). En Nginx, usa $http_x_forwarded_proto en lugar de $scheme. En Apache, verifica %{HTTP:X-Forwarded-Proto} en los RewriteCond.

Ejemplo Nginx con soporte de proxy:

server {
    listen 80;
    server_name captaindns.com;

    # Redirige a HTTPS solo si la petición no llega ya vía HTTPS desde el CDN
    if ($http_x_forwarded_proto != "https") {
        return 301 https://$server_name$request_uri;
    }
}

¿Cómo diagnosticar un bucle de redirección?

Una vez que sabes que existe un bucle (el navegador muestra el error), hay que localizarlo con precisión. Tres métodos complementarios permiten reconstruir la cadena de redirecciones e identificar el punto de retorno.

Método 1: el Redirect Checker de CaptainDNS

El método más rápido. Introduce la URL en el Redirect Checker y lanza el análisis. La herramienta sigue cada redirección, registra el código HTTP, la URL de destino, las cabeceras de respuesta y el tiempo de respuesta de cada salto. Cuando detecta que una URL aparece dos veces en la cadena, señala el bucle e indica exactamente en qué salto comienza.

La ventaja: la herramienta sigue hasta 30 saltos (frente a 20 de los navegadores), lo que permite detectar bucles largos. También muestra las cabeceras HTTP completas, esenciales para diagnosticar conflictos de protocolo y problemas de X-Forwarded-Proto.

Método 2: curl en línea de comandos

Para los administradores que prefieren la terminal, curl con la opción -v (verbose) y -L (follow redirects) muestra cada paso de la cadena:

curl -v -L --max-redirs 25 https://captaindns.com/page-a 2>&1 | grep -E "^(< HTTP|< Location|> GET)"

Este comando muestra el código HTTP y la cabecera Location de cada respuesta, así como la petición GET enviada en cada paso. Cuando la URL de la petición GET coincide con una URL ya vista más arriba en la salida, has encontrado el bucle.

La opción --max-redirs 25 aumenta el límite por defecto de curl (50) a un nivel suficiente para detectar la mayoría de los bucles sin generar una salida demasiado larga.

Para una salida más concisa, limítate a las cabeceras:

curl -sI -L --max-redirs 25 https://captaindns.com/page-a 2>&1 | grep -iE "^(HTTP/|Location:)"

Método 3: las DevTools del navegador

Abre las herramientas de desarrollo (F12), ve a la pestaña "Network" (Red) y carga la URL problemática. El navegador muestra cada petición HTTP en orden cronológico. Verás una serie de peticiones con códigos 301 o 302, cada una con una URL diferente, hasta que el navegador alcanza su límite y muestra el error.

La ventaja de las DevTools: muestran las cookies enviadas y recibidas en cada petición, indispensable para diagnosticar los bucles de autenticación (causa 5). La limitación: el navegador solo muestra las primeras 20 peticiones (16 en Safari).

Tabla comparativa de los tres métodos

Criterio	Redirect Checker	curl	DevTools
Facilidad de uso	Alta (interfaz web)	Media (terminal)	Media (navegador)
Número máximo de saltos	30	Configurable	16 a 20
Detección automática de bucle	Sí	No (análisis manual)	No (análisis manual)
Visualización de cookies	No	Sí (con -v)	Sí
Visualización de tiempos de respuesta	Sí (por salto)	Sí (con -w)	Sí
Requiere instalación	No	Sí (presente en Linux/macOS)	No
Compartir resultados	Sí (URL de informe)	No	No (captura de pantalla)

Para un diagnóstico rápido, empieza por el Redirect Checker. Complementa con las DevTools si el problema implica cookies, o con curl para la automatización en pipeline CI/CD.

Las cadenas de redirección: impacto SEO y rendimiento

Una cadena de redirección es una secuencia lineal de redirecciones sucesivas. A diferencia del bucle, la cadena llega a una página de contenido, pero pasa por una o varias URLs intermedias antes de llegar. El problema no es la inaccesibilidad (la página termina cargando), sino la degradación progresiva del SEO y el rendimiento.

¿Cuántos saltos antes de que sea un problema?

Un solo salto de redirección es perfectamente normal. Es el caso estándar de un enlace antiguo que redirige a la nueva URL. El problema empieza cuando los saltos se acumulan.

Número de saltos	Evaluación	Impacto
1	Normal	Ningún impacto medible
2	Aceptable	Impacto mínimo, no se requiere acción
3	Advertencia	Latencia perceptible, posible dilución SEO
4 a 5	Problema	De 400 a 2500 ms de latencia añadida, pérdida SEO probable
6 o más	Crítico	Google puede abandonar el seguimiento, página potencialmente no indexada

Google sigue oficialmente hasta 10 redirecciones en una cadena. Sin embargo, John Mueller del equipo de Google Search ha precisado que la transferencia de señal SEO puede degradarse mucho antes de alcanzar ese límite. La recomendación práctica es no superar nunca 2 saltos entre la URL de origen y el destino final.

Impacto SEO: dilución del PageRank y pérdida de indexación

Cada redirección intermedia en una cadena crea una oportunidad de pérdida de señal SEO. Aunque Google afirma que una redirección 301 única transfiere el 100% del PageRank, el comportamiento con cadenas múltiples está menos documentado y es menos fiable.

El problema concreto: cuando Googlebot encuentra una cadena de 5 redirecciones, realiza 6 peticiones HTTP. Cada una consume crawl budget. Para sitios voluminosos con miles de cadenas, Google pasa tiempo siguiendo redirecciones en vez de rastrear contenido nuevo.

Además, si una redirección intermedia es una 302 en lugar de una 301, la transferencia de PageRank se interrumpe en ese punto. Una sola 302 en una cadena de 301 basta para bloquear la transferencia de autoridad.

Impacto en rendimiento: la latencia se suma

Cada salto de redirección añade un viaje de ida y vuelta completo entre el navegador y el servidor. En la práctica, esto supone de 100 a 500 ms por salto, según la latencia de red y la ubicación geográfica del visitante.

Para un visitante en Europa accediendo a un servidor en Norteamérica, cada salto añade de 150 a 200 ms. Una cadena de 4 saltos añade de 600 a 800 ms antes de que el contenido empiece a cargarse.

Este impacto se concentra en el LCP (Largest Contentful Paint), la métrica Core Web Vitals que mide el tiempo de visualización del contenido principal. Un LCP superior a 2,5 segundos se clasifica como "deficiente" por Google. Si tu página carga normalmente en 1,8 segundos pero una cadena de 3 redirecciones añade 600 ms, pasas a la zona roja.

Buena noticia: las redirecciones 301 almacenadas en caché por el navegador ya no tienen impacto después de la primera visita. Es un argumento más para preferir las 301 a las 302 en las cadenas.

Cómo se forman las cadenas: el caso de la migración en varias etapas

Las cadenas de redirección rara vez se crean intencionalmente. Se acumulan con el tiempo, con cada migración, rediseño o cambio de estructura.

Escenario típico:

1. 2022: el sitio está en http://captaindns.com. Migración a HTTPS. Redirección 301 de http:// a https://.
2. 2023: rediseño del sitio. Cambio de estructura de URL. Redirección 301 de /tools/dns-check a /es/tools/dns/test-propagation.
3. 2025: consolidación del subdominio. Redirección 301 de https://outils.captaindns.com/dns-check a https://captaindns.com/tools/dns-check.

Un backlink publicado en 2022 que apunta a http://outils.captaindns.com/dns-check ahora atraviesa 3 redirecciones:

http://outils.captaindns.com/dns-check
→ 301 → https://outils.captaindns.com/dns-check
→ 301 → https://captaindns.com/tools/dns-check
→ 301 → https://captaindns.com/es/tools/dns/test-propagation

Cada migración individual fue correcta. Pero la acumulación crea una cadena de 3 saltos que consume crawl budget y añade latencia.

La solución: después de cada migración, actualiza las redirecciones antiguas para apuntar directamente al destino final. En este ejemplo, la primera redirección debería actualizarse a https://captaindns.com/es/tools/dns/test-propagation, eliminando los dos intermediarios.

¿Cómo detectar las cadenas en tu sitio?

El método más eficaz es probar tus URLs críticas (páginas con más tráfico, páginas con más backlinks) con el Redirect Checker. La herramienta indica el número de saltos para cada URL y señala las cadenas de más de 2 saltos.

Para una auditoría a gran escala, exporta la lista de tus URLs desde Google Search Console (informe "Páginas") y pruébalas por lotes. Prioriza las URLs con más tráfico orgánico y más backlinks.

También puedes usar el Page Crawl Checker para analizar las cadenas de redirección en el contexto de un rastreo completo de página, incluyendo los recursos cargados (CSS, JavaScript, imágenes) que también pueden atravesar cadenas.

Enlaces acortados: ¿adónde llevan realmente?

Los servicios de acortamiento de URL (bit.ly, t.co, tinyurl.com, ow.ly, goo.gl) reemplazan una URL larga por una URL corta que redirige al destino. Esta operación es transparente para el usuario legítimo: hace clic, el servicio redirige, la página carga. Pero esta transparencia es también un vector de ataque importante.

El problema de seguridad de los enlaces acortados

Un enlace acortado oculta completamente el destino. El usuario no puede saber, antes de hacer clic, si el enlace lleva a un documento legítimo de Google o a un sitio de phishing que imita la página de inicio de sesión de su banco.

Los atacantes explotan esta opacidad de forma sistemática. Un email de phishing que contiene https://bit.ly/3xYz123 es mucho más difícil de detectar que un email con una URL sospechosa en texto plano. Los filtros anti-phishing tienen dificultades para analizar los enlaces acortados, ya que el dominio visible (bit.ly) es legítimo. Es el destino final el que es malicioso.

Según las investigaciones de Palo Alto Networks (Unit 42), más del 70% de los dominios maliciosos se registraron hace menos de 32 días (Newly Registered Domains). Los enlaces acortados son el principal vector para distribuir estos dominios recientes.

Técnicas de ofuscación avanzadas

Los atacantes no se limitan a acortar un enlace malicioso. Combinan varias técnicas para hacer la detección aún más difícil.

Cadena de acortadores: un enlace bit.ly redirige a tinyurl, que redirige a ow.ly, que lleva al sitio de phishing. Cada capa añade una barrera para las herramientas de detección. El Redirect Checker sigue la cadena completa y revela el destino final.

Redirecciones condicionales: el servicio redirige a un sitio diferente según el país, el navegador o el momento del día. Los visitantes objetivo ven la página de phishing, los demás son redirigidos a un sitio legítimo.

Dominios expirados reutilizados: el atacante compra un dominio que tenía buena reputación, instala contenido malicioso y luego distribuye enlaces acortados hacia ese dominio. La reputación histórica engaña a los filtros de seguridad.

Cómo el Redirect Checker desenmascara los enlaces acortados

Cuando introduces un enlace acortado en el Redirect Checker, la herramienta sigue cada redirección hasta el destino final, registrando el código HTTP, la URL de destino, las cabeceras y el tiempo de respuesta de cada salto. Señala automáticamente varios indicadores de riesgo:

Dominios recientemente registrados (NRD): si el destino final es un dominio registrado hace menos de 30 días, la herramienta emite una advertencia. Los dominios NRD son estadísticamente mucho más propensos a ser maliciosos que los dominios establecidos.

Número excesivo de redirecciones: un enlace legítimo acortado suele implicar 1 o 2 redirecciones (del acortador al destino). Si la cadena contiene 4 redirecciones o más, es una señal de alerta.

Cambio de protocolo sospechoso: si una redirección en la cadena pasa de HTTPS a HTTP, es un indicador de riesgo. Los sitios legítimos usan HTTPS. Un retorno a HTTP en mitad de la cadena puede indicar un intento de downgrade para interceptar el tráfico.

Homógrafos IDN: cuando el dominio parece otro

Los ataques por homógrafo IDN (Internationalized Domain Name) explotan caracteres Unicode que se parecen visualmente a letras latinas. Por ejemplo, el carácter cirílico "a" (U+0430) es visualmente idéntico al "a" latino (U+0061), pero se trata de un carácter diferente.

Un atacante puede registrar cаptaindns.com (con una "a" cirílica) que se ve exactamente igual a captaindns.com en la barra de direcciones. Detrás de un enlace acortado, esta diferencia es totalmente invisible.

El Redirect Checker muestra la URL de destino en ASCII Punycode cuando contiene caracteres IDN. La URL cаptaindns.com aparece entonces como xn--cptaindns-r6a.com, revelando inmediatamente que no es el dominio esperado.

Para proteger tu marca, verifica regularmente que las variantes homógrafas de tu dominio no estén registradas por terceros. El Phishing URL Checker analiza específicamente los riesgos de homografía y typosquatting en las URLs que le envíes.

¿Cómo corregir los problemas de redirección?

El diagnóstico está hecho, el problema identificado. Estos son los pasos de corrección para cada tipo de problema.

Corregir un bucle de redirección

Paso 1: identificar el punto de entrada y el punto de retorno. Usa el Redirect Checker para reconstruir la cadena completa. Anota en qué salto reaparece la URL.

Paso 2: identificar el componente responsable del retorno. Es el servidor, el CDN, el CMS o el plugin que genera la redirección hacia la URL ya vista. Consulta la sección "Las 7 causas" más arriba para identificar el patrón.

Paso 3: romper el ciclo. Modifica la configuración del componente responsable para que deje de generar la redirección circular. En la mayoría de los casos, esto significa eliminar o modificar una regla de redirección en uno de los componentes implicados.

Paso 4: probar inmediatamente. Tras la corrección, limpia la caché del navegador (las 301 pueden estar en caché) y prueba con el Redirect Checker. Verifica que la cadena termine con un código 200 y no con un ciclo.

Ejemplo concreto: bucle entre Cloudflare (Flexible SSL) y un servidor Apache que fuerza HTTPS.

Antes de la corrección:
https://captaindns.com → Cloudflare (HTTP hacia servidor) → Apache (redirige a HTTPS)
→ Cloudflare (HTTP hacia servidor) → Apache (redirige a HTTPS) → bucle

Corrección: cambiar Cloudflare a modo "Full (Strict)"

Después de la corrección:
https://captaindns.com → Cloudflare (HTTPS hacia servidor) → Apache (sin redirección, código 200)

Corregir una cadena de redirección

Principio: acortar la cadena a un solo salto. Cada URL de origen debe apuntar directamente al destino final, sin intermediarios.

Paso 1: listar todas las redirecciones de la cadena. Usa el Redirect Checker para obtener la secuencia completa.

Paso 2: identificar el destino final. Es la última URL de la cadena, la que devuelve un código 200.

Paso 3: actualizar cada redirección intermedia. Modifica la configuración de cada servidor o servicio implicado para que las URLs intermedias redirijan directamente al destino final.

Ejemplo:

Antes de la corrección:
http://captaindns.com/old-page
→ 301 → https://captaindns.com/old-page
→ 301 → https://captaindns.com/es/old-page
→ 301 → https://captaindns.com/es/tools/new-page

Después de la corrección:
http://captaindns.com/old-page → 301 → https://captaindns.com/es/tools/new-page
https://captaindns.com/old-page → 301 → https://captaindns.com/es/tools/new-page
https://captaindns.com/es/old-page → 301 → https://captaindns.com/es/tools/new-page

Cada URL de origen apunta ahora directamente al destino final en un solo salto. El navegador y Googlebot solo tienen una redirección que seguir.

Verificación posterior a la corrección

Después de cada corrección, prueba sistemáticamente con el Redirect Checker:

1. Verifica que la cadena termina con un código 200.
2. Verifica que el número de saltos es inferior o igual a 2.
3. Verifica que todas las redirecciones intermedias usan el código 301 (salvo caso específico de redirección temporal).
4. Verifica que el protocolo final es HTTPS.
5. Prueba las 4 variantes de la URL: http://, https://, http://www., https://www..

Si has corregido varias cadenas, espera de 48 a 72 horas y luego verifica en Google Search Console que los errores de redirección han desaparecido del informe "Páginas".

Buenas prácticas para evitar problemas futuros

Usar un solo punto de control para las redirecciones. No configures la misma redirección en dos lugares diferentes (servidor web y CDN, CMS y .htaccess). Elige un solo componente para gestionar cada tipo de redirección.

Usar siempre 301 para las redirecciones permanentes. Las 302 no transfieren el PageRank y no se almacenan en caché por el navegador. Salvo caso específico (redirección condicional, test A/B), la 301 es la opción por defecto.

Actualizar las redirecciones antiguas después de cada migración. No dejes que las cadenas se acumulen. Después de cada cambio de estructura de URL, revisa las redirecciones antiguas y actualízalas para apuntar directamente al destino final.

Documentar todas las redirecciones activas. Mantén una tabla resumen de todas las reglas de redirección activas, con el origen, el destino, el código HTTP y la fecha de creación. Esta tabla es imprescindible para evitar conflictos en futuras modificaciones.

Probar antes de desplegar. Antes de poner en producción una nueva regla de redirección, pruébala en un entorno de staging o con curl -I. Verifica que la redirección funciona y que no crea conflicto con las reglas existentes.

Plan de acción recomendado

Aquí tienes una checklist en 5 pasos para auditar y corregir los problemas de redirección en tu sitio.

Paso 1: escanear las URLs críticas

Identifica tus 20 a 50 URLs más importantes: páginas de inicio, páginas de producto, artículos de blog con alto tráfico, páginas de conversión. Prueba cada una con el Redirect Checker.

Para cada URL, anota:

• El número de saltos
• La presencia eventual de un bucle
• El código HTTP del destino final (debe ser 200)
• El protocolo del destino final (debe ser HTTPS)

Paso 2: identificar bucles y cadenas de más de 3 saltos

Entre las URLs probadas, aísla las que presentan un problema:

• Bucle detectado: prioridad máxima, la página es inaccesible
• 5 saltos o más: prioridad alta, impacto SEO y rendimiento significativo
• 3 a 4 saltos: prioridad media, a corregir en el próximo ciclo de mantenimiento
• 1 a 2 saltos: no se requiere acción

Paso 3: corregir las configuraciones del servidor

Para cada problema identificado, aplica la corrección apropiada:

• Bucle: identifica el componente responsable (ver las 7 causas) y rompe el ciclo
• Cadena: actualiza cada redirección intermedia para apuntar al destino final
• Conflicto CDN/servidor: alinea la configuración SSL/TLS entre el CDN y el servidor de origen
• Conflicto .htaccess: simplifica las reglas, añade los flags [L], ordena de la más específica a la más genérica

Paso 4: verificar los enlaces acortados en tus emails y newsletters

Revisa los enlaces acortados presentes en tus plantillas de newsletter, tus firmas de email y tus campañas de marketing activas. Para cada enlace acortado:

• Prueba el destino con el Redirect Checker
• Verifica que el destino es tu sitio (y no un dominio de terceros)
• Reemplaza los enlaces acortados por enlaces directos cuando sea posible
• Si el enlace acortado es necesario (tracking, código QR), verifica que la cadena no supere 2 saltos

Paso 5: volver a probar después de la corrección

Después de cada corrección, vuelve a las URLs corregidas y verifica que:

• El bucle está resuelto (código 200 al final de la cadena)
• La cadena está acortada (2 saltos como máximo)
• Las 4 variantes de la URL (HTTP/HTTPS, www/sin-www) funcionan correctamente
• No se ha introducido ningún problema nuevo

Planifica una auditoría de seguimiento a 30 días para verificar que las correcciones se mantienen y que no se ha formado ninguna cadena nueva.

Casos prácticos: diagnósticos comunes y soluciones

Caso 1: sitio WordPress inaccesible tras activar Really Simple SSL

Síntoma: ERR_TOO_MANY_REDIRECTS inmediatamente después de la activación del plugin.

Diagnóstico con el Redirect Checker:

Salto 1: https://captaindns.com → 301 → http://captaindns.com (¿plugin fuerza HTTP?)
Salto 2: http://captaindns.com → 301 → https://captaindns.com (servidor fuerza HTTPS)
Salto 3: https://captaindns.com → 301 → http://captaindns.com
→ Bucle detectado en el salto 3

Causa: el archivo wp-config.php contiene define('FORCE_SSL_ADMIN', false) o la URL del sitio en la base de datos está en HTTP, lo que entra en conflicto con el plugin que intenta forzar HTTPS.

Solución: desactiva el plugin vía FTP (renombra su carpeta), actualiza las opciones siteurl y home en wp_options para usar HTTPS, añade define('FORCE_SSL_ADMIN', true) en wp-config.php, y luego reactiva el plugin.

Caso 2: enlace acortado en un email que lleva a un sitio de phishing

Síntoma: un empleado recibe un email con un enlace https://bit.ly/3Ab4Cd5 que supuestamente lleva a un documento compartido.

Diagnóstico con el Redirect Checker:

Salto 1: https://bit.ly/3Ab4Cd5 → 301 → https://tinyurl.com/y7x8z9
Salto 2: https://tinyurl.com/y7x8z9 → 301 → https://docs-google-verification.com/login
→ Destino final: https://docs-google-verification.com/login
→ ALERTA: dominio registrado hace 3 días (NRD)
→ ALERTA: el dominio imita "docs.google.com" (homografía potencial)

Indicadores de riesgo: dos acortadores en cadena (técnica de ofuscación), dominio de destino registrado hace 3 días (NRD), nombre de dominio que imita un servicio legítimo (Google Docs), URL que contiene "/login" (intento de robo de credenciales).

Acción: no hacer clic. Reportar el email como phishing. Alertar al equipo de seguridad. Si se hizo clic en el enlace, cambiar inmediatamente la contraseña del servicio imitado y activar la autenticación de dos factores.

Redirecciones y seguridad: los ataques basados en redirecciones

Las redirecciones no son solo un problema de configuración. También son un vector de ataque explotado activamente por los ciberdelincuentes.

Open redirect: cuando tu propio sitio se convierte en un vector de ataque

Una vulnerabilidad "open redirect" existe cuando tu sitio acepta un parámetro de URL que controla el destino de una redirección sin validar ese parámetro. Ejemplo: https://captaindns.com/login?redirect=https://sitio-malicioso.com. Si tu aplicación redirige ciegamente al valor del parámetro redirect, un atacante puede usar tu dominio legítimo como primer paso de una cadena de phishing.

Protección: valida siempre las URLs de redirección del lado del servidor. Acepta solo las redirecciones a tu propio dominio o a una lista blanca de dominios autorizados.

Ataque por cadena de redirecciones

Un atacante puede explotar redirecciones legítimas para construir cadenas que eluden los filtros de seguridad. La cadena típica: un email contiene un enlace a un acortador legítimo (bit.ly), el acortador redirige a un sitio reputado que tiene una vulnerabilidad open redirect, el open redirect envía al sitio de phishing. Cada paso pasa los filtros individualmente. Es la combinación la que es maliciosa. Solo una herramienta que sigue la cadena completa hasta el destino final puede detectar el ataque.

Buenas prácticas de seguridad para las redirecciones

1. Nunca hacer clic en un enlace acortado sin verificarlo. Usa el Redirect Checker para revelar el destino antes de hacer clic.
2. Auditar tu propio sitio en busca de open redirects. Busca todos los endpoints que aceptan un parámetro de URL como destino de redirección.
3. Verificar los dominios NRD en los emails. Un dominio de menos de 30 días en un enlace de email es una señal de alerta fuerte.
4. Sensibilizar a los equipos. Los enlaces acortados en los emails internos siempre deberían ir acompañados de la URL completa de destino en texto plano.

FAQ

¿Qué significa ERR_TOO_MANY_REDIRECTS?

Este mensaje de error significa que el navegador ha alcanzado su límite de redirecciones sucesivas (20 para Chrome y Firefox, 16 para Safari) sin llegar a una página de contenido. La causa es un bucle de redirección (dos o más URLs que se redirigen mutuamente) o una cadena de redirección excesivamente larga. Para identificar la causa exacta, prueba la URL con el Redirect Checker, que sigue la cadena completa y señala automáticamente los bucles.

¿Cómo corregir un bucle de redirección en WordPress?

Los bucles en WordPress suelen estar causados por un conflicto entre un plugin (Really Simple SSL, Wordfence, W3 Total Cache) y la configuración del servidor. La corrección en 4 pasos: 1) desactiva los plugins uno a uno vía FTP (renombra la carpeta en wp-content/plugins/) para identificar al culpable; 2) verifica que las URLs siteurl y home en la tabla wp_options usan el protocolo correcto (HTTPS); 3) limpia el archivo .htaccess de reglas de redirección duplicadas; 4) reactiva el plugin y ajusta sus parámetros para no duplicar las redirecciones del servidor.

¿Cuántas redirecciones puede seguir Google?

Google sigue oficialmente hasta 10 redirecciones en una cadena. Más allá, Googlebot abandona y la página final no se rastrea ni se indexa. En la práctica, John Mueller recomienda no superar nunca 2 saltos. Cada redirección consume crawl budget y puede diluir la señal SEO, especialmente si una 302 se cuela en una cadena de 301.

¿Son peligrosos los enlaces acortados?

Los enlaces acortados no son intrínsecamente peligrosos, pero ocultan el destino real, lo que los convierte en un vector privilegiado para el phishing y la distribución de malware. Según las investigaciones de Palo Alto Networks, más del 70% de los dominios maliciosos se registraron hace menos de 32 días, y los enlaces acortados son el principal medio para distribuir estos dominios en emails. La buena práctica es verificar siempre el destino de un enlace acortado antes de hacer clic, usando una herramienta que siga la cadena de redirecciones hasta el final.

¿Cómo saber adónde lleva un enlace bit.ly?

Existen varios métodos. El más fiable es usar el Redirect Checker de CaptainDNS: introduce el enlace bit.ly y la herramienta sigue todas las redirecciones hasta el destino final, mostrando cada salto intermedio. También puedes añadir un "+" al final de la URL de bit.ly (por ejemplo, https://bit.ly/3xYz123+) para acceder a la página de estadísticas de bit.ly que muestra el destino, pero este método no funciona con todos los acortadores y no sigue las redirecciones múltiples.

¿Cuál es la diferencia entre un bucle y una cadena de redirección?

Un bucle es un ciclo: la URL A redirige a B, que redirige a C, que redirige de nuevo a A. El navegador da vueltas en círculo y nunca alcanza una página de contenido. El resultado es un error ERR_TOO_MANY_REDIRECTS. Una cadena es una secuencia lineal: A redirige a B, que redirige a C, que devuelve un código 200 (página de contenido). La cadena llega a su destino, pero cada salto intermedio añade latencia y puede diluir la señal SEO. Los bucles son bloqueantes (la página es inaccesible), las cadenas son degradantes (la página carga, pero peor).

¿Funciona el Redirect Checker con los enlaces acortados?

Sí. El Redirect Checker sigue todas las redirecciones HTTP, sin importar el dominio de origen. Cuando introduces un enlace bit.ly, tinyurl.com, t.co o cualquier otro acortador, la herramienta sigue la cadena completa hasta el destino final. Muestra cada salto intermedio con el código HTTP, la URL de destino y el tiempo de respuesta. También señala los dominios recientemente registrados (NRD) y las cadenas anormalmente largas que pueden indicar un intento de ofuscación.

¿Cómo detectar un enlace de phishing oculto?

Varios indicios permiten detectar un enlace de phishing detrás de un acortador. Verifica el destino con el Redirect Checker y busca estas señales de alerta: 1) el dominio de destino se registró hace menos de 30 días (NRD); 2) la cadena contiene más de 2 redirecciones (técnica de ofuscación); 3) el dominio imita un servicio conocido (homógrafo IDN o typosquatting); 4) la URL final contiene palabras como "login", "verify", "secure" o "update"; 5) el protocolo pasa de HTTPS a HTTP en medio de la cadena. La presencia de 2 o más de estos indicadores sugiere fuertemente un enlace malicioso.

¿Las redirecciones meta refresh crean bucles?

Sí, las redirecciones meta refresh pueden crear bucles exactamente igual que las redirecciones HTTP. La página A contiene una etiqueta <meta http-equiv="refresh"> que redirige a la página B, y la página B contiene una etiqueta similar que redirige a A. La diferencia es que las meta refresh son más lentas (el navegador debe descargar y analizar el HTML antes de redirigir) y más difíciles de diagnosticar porque no son visibles en las cabeceras HTTP. Las herramientas de línea de comandos como curl no las detectan sin una opción específica.

¿Cómo evitar que las cadenas de redirección se acumulen con el tiempo?

La mejor práctica es actualizar las redirecciones antiguas después de cada migración. Cuando añades una nueva capa de redirección (cambio de dominio, cambio de estructura de URL, migración a HTTPS), revisa las redirecciones anteriores y actualízalas para apuntar directamente al destino final. Documenta todas las redirecciones activas en una tabla centralizada con el origen, el destino, el código HTTP y la fecha. Planifica una auditoría trimestral de tus URLs principales con el Redirect Checker para detectar las cadenas antes de que se vuelvan problemáticas.

Glosario

• Bucle de redirección: ciclo en el que dos o más URLs se redirigen mutuamente. El navegador muestra ERR_TOO_MANY_REDIRECTS tras 16 a 20 intentos.
• Cadena de redirección: secuencia lineal de redirecciones sucesivas. La cadena llega a destino, pero degrada el SEO y el rendimiento.
• ERR_TOO_MANY_REDIRECTS: mensaje de error de los navegadores Chromium cuando se alcanza el límite de redirecciones. Equivalente a "La página no está redirigiendo adecuadamente" en Firefox.
• NRD (Newly Registered Domain): dominio registrado hace menos de 32 días. Estadísticamente más propenso a ser malicioso.
• Homógrafo IDN: dominio internacionalizado que utiliza caracteres Unicode visualmente similares a letras latinas para imitar un dominio legítimo.
• Meta refresh: etiqueta HTML <meta http-equiv="refresh"> que activa una redirección del lado del cliente. Desaconsejada por Google para el SEO.
• Enlace acortado: URL corta (bit.ly, t.co, tinyurl.com) que redirige a un destino más largo ocultando la URL real.
• Open redirect: vulnerabilidad en la que una aplicación acepta un parámetro de URL como destino de redirección sin validación, permitiendo el phishing.

Fuentes

• RFC 7231, sección 6.4: HTTP Redirection: definición oficial de los códigos de redirección HTTP 301, 302, 303 y 307
• Google Search Central: URL redirections: documentación oficial de Google sobre el tratamiento de las redirecciones por el motor de búsqueda
• Palo Alto Networks Unit 42: Newly Registered Domains: investigación sobre el uso malicioso de los dominios recientemente registrados