ERR_TOO_MANY_REDIRECTS: qué es, causas y cómo solucionarlo

ERR_TOO_MANY_REDIRECTS es un error del navegador que aparece cuando una URL genera un bucle infinito de redirecciones: el servidor redirige la solicitud a una nueva URL, esa URL redirige a otra, y así sucesivamente hasta que el navegador detecta el ciclo y aborta la conexión. El navegador de Chrome aborta tras 20 redirecciones consecutivas. La causa es siempre una configuración incorrecta del servidor, el CMS o el CDN, nunca del navegador en sí. Es especialmente frecuente en migraciones de HTTP a HTTPS y en configuraciones con Cloudflare o proxies inversos.

Qué significa ERR_TOO_MANY_REDIRECTS

Cuando tu navegador solicita una URL y el servidor responde con un código de redirección (301, 302, 307 o 308), el navegador sigue automáticamente la nueva URL indicada en la cabecera Location. Si esa nueva URL redirige a otra, y esa a otra, el navegador entra en un bucle. Para evitar que esto continúe indefinidamente, los navegadores modernos tienen un límite de redirecciones consecutivas:

• Google Chrome: aborta tras 20 redirecciones y muestra ERR_TOO_MANY_REDIRECTS
• Firefox: aborta tras 20 redirecciones y muestra "La página no está redireccionando correctamente"
• Safari: aborta tras un número similar y muestra "Safari no puede abrir la página porque demasiados redireccionamientos"

El mensaje exacto varía según el navegador, pero el problema subyacente es siempre el mismo: un bucle de redirecciones en el lado del servidor.

Por qué ocurre: el mecanismo del bucle

El bucle más frecuente es el de HTTP a HTTPS. Para entender por qué ocurre, hay que entender cómo funciona la cadena de redirección:

1. El usuario solicita http://tudominio.com
2. El servidor tiene una regla: "redirige todo el tráfico HTTP a HTTPS" → redirige a https://tudominio.com
3. El navegador solicita https://tudominio.com
4. Si hay un proxy inverso (Nginx, Cloudflare) que reenvía la solicitud al servidor en HTTP interno, el servidor recibe la solicitud como HTTP y vuelve a redirigir a HTTPS
5. El bucle comienza: HTTP → HTTPS → HTTP → HTTPS → ...

El problema no está en la regla de redirección en sí, sino en que el servidor no sabe que la solicitud que recibe en HTTP ya llegó originalmente en HTTPS. El proxy la "desnuda" de HTTPS antes de pasarla al servidor de aplicación.

Causas más comunes de ERR_TOO_MANY_REDIRECTS

1. Migración HTTP a HTTPS con proxy inverso o CDN

Es la causa número uno. Ocurre en esta combinación:

• El servidor de aplicación (Apache + PHP) tiene una regla en el .htaccess que redirige todo HTTP a HTTPS.
• Hay un proxy delante (Nginx, Cloudflare, balanceador de carga) que habla HTTPS con el navegador pero reenvía las solicitudes al servidor en HTTP interno.
• El servidor de aplicación no comprueba si la solicitud ya venía de HTTPS antes de redirigir.

La regla problemática en .htaccess es esta:

# INCORRECTO — crea bucle con proxy inverso:
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

Esta regla comprueba si HTTPS está "off" en el servidor, pero cuando hay un proxy inverso, esa variable siempre es "off" porque el proxy termina el SSL antes de pasar la solicitud. La solución es añadir la comprobación de la cabecera X-Forwarded-Proto que el proxy incluye para indicar el protocolo original:

# CORRECTO — comprueba también X-Forwarded-Proto:
RewriteCond %{HTTP:X-Forwarded-Proto} !https
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

Con esta versión, si el proxy incluye X-Forwarded-Proto: https, la condición no se cumple y no se genera la redirección, rompiendo el bucle.

2. Cloudflare en modo SSL Flexible

Este es el escenario más frecuente cuando se usa Cloudflare. El modo SSL "Flexible" de Cloudflare funciona así:

• El navegador del usuario se conecta a Cloudflare en HTTPS ✓
• Cloudflare se conecta al servidor de origen en HTTP (sin cifrado) ✗

Si el servidor de origen tiene una regla que redirige todo HTTP a HTTPS (como debe tener por seguridad), Cloudflare envía HTTP, el servidor redirige a HTTPS, Cloudflare vuelve a enviar HTTP, el servidor redirige otra vez... bucle infinito.

Solución: cambia el modo SSL en Cloudflare a Full (Strict). Ve a tu panel de Cloudflare > SSL/TLS > Overview y selecciona "Full (Strict)". Con este modo, Cloudflare se conecta al servidor de origen en HTTPS, verificando que el certificado SSL es válido, y no hay bucle posible.

Importante: para usar Full (Strict) necesitas tener un certificado SSL válido instalado en tu servidor de origen. En los servidores de sys4net, Let's Encrypt está instalado por defecto en todos los planes. Si no tienes certificado SSL en el origen y usas Cloudflare, usa el modo Full (sin Strict) como mínimo.

3. WordPress con configuración HTTPS incorrecta

WordPress puede generar bucles de redirección cuando las URLs guardadas en la base de datos no coinciden con cómo accede realmente el servidor. Los escenarios más frecuentes:

Escenario A: Forzar HTTPS en WordPress sin soporte del servidor

Si en la configuración de WordPress o en un plugin de seguridad activas "Forzar HTTPS" pero el servidor detrás del proxy no pasa correctamente la cabecera X-Forwarded-Proto, WordPress entra en bucle intentando redirigirse a sí mismo.

La solución es añadir esto en wp-config.php, antes de la línea /* That's all, stop editing! */:

# En wp-config.php — indicar a WordPress la URL correcta:
define('WP_HOME', 'https://tudominio.com');
define('WP_SITEURL', 'https://tudominio.com');

# Si hay proxy inverso que pasa X-Forwarded-Proto:
if (isset($_SERVER['HTTP_X_FORWARDED_PROTO']) &&
    $_SERVER['HTTP_X_FORWARDED_PROTO'] === 'https') {
    $_SERVER['HTTPS'] = 'on';
}

Escenario B: URLs en la base de datos mezclan HTTP y HTTPS

Después de una migración de HTTP a HTTPS, si las URLs guardadas en la tabla wp_options (específicamente los campos siteurl y home) siguen siendo HTTP mientras el servidor fuerza HTTPS, WordPress puede generar redirecciones en bucle.

# Verificar y corregir desde phpMyAdmin o WP-CLI:
wp option get siteurl
wp option get home

# Actualizar si son HTTP:
wp option update siteurl 'https://tudominio.com'
wp option update home 'https://tudominio.com'

# Actualizar todas las URLs en el contenido:
wp search-replace 'http://tudominio.com' 'https://tudominio.com' --skip-columns=guid

4. Cookies de sesión corruptas en el navegador

Algunas aplicaciones web almacenan información de redirección en las cookies de sesión. Si esas cookies contienen datos corruptos o desactualizados que entran en conflicto con las reglas de redirección actuales del servidor, el navegador puede experimentar ERR_TOO_MANY_REDIRECTS solo para ese usuario específico, mientras que otros usuarios acceden sin problema.

Por eso el error a veces desaparece al abrir el navegador en modo incógnito: el modo incógnito no usa las cookies del perfil normal, eliminando la fuente del conflicto.

5. Plugin de caché con reglas de redirección obsoletas

Los plugins de caché como WP Super Cache, LiteSpeed Cache, W3 Total Cache o WP Rocket pueden tener guardadas en caché páginas o reglas de redirección de una configuración anterior. Tras una migración de dominio, de HTTP a HTTPS, o un cambio en la estructura de URLs, estas reglas en caché generan bucles porque apuntan a la configuración antigua mientras el servidor usa la nueva.

Solución: vaciar completamente la caché del plugin de caché, y también la caché de Cloudflare si se usa. En WP Rocket: Panel > WP Rocket > Borrar caché. En Cloudflare: Caching > Configuration > Purge Everything.

6. Redirecciones circulares en el código o la base de datos

En aplicaciones web personalizadas (no WordPress), un error de lógica en el código puede crear redirecciones circulares:

• La página A redirige a la página B
• La página B redirige de vuelta a la página A

En WordPress, esto puede ocurrir si en el plugin de gestión de redirecciones (Redirection, Yoast SEO) se configura accidentalmente una redirección de una URL a sí misma, o dos URLs que se redirigen mutuamente.

7. Reglas de redirección duplicadas o contradictorias en el servidor

En servidores con múltiples capas de configuración (archivo de configuración de Apache + .htaccess + plugin de WordPress + reglas de Nginx), pueden existir reglas de redirección contradictorias en distintas capas que generan bucles. Por ejemplo: Apache tiene una regla que redirige /antigua/ a /nueva/, pero el plugin de WordPress tiene una regla que redirige /nueva/ de vuelta a /antigua/.

Cómo diagnosticar ERR_TOO_MANY_REDIRECTS paso a paso

Paso 1: Prueba en modo incógnito

Abre una ventana de incógnito (Ctrl+Shift+N en Chrome, Ctrl+Shift+P en Firefox) y accede a la URL problemática.

• Si en modo incógnito carga correctamente: la causa son las cookies del navegador normal. Limpia todas las cookies para ese dominio (ver Paso 2) y el problema se resolverá.
• Si en modo incógnito también da ERR_TOO_MANY_REDIRECTS: la causa está en la configuración del servidor, el CMS o el CDN, no en las cookies.

Paso 2: Limpia las cookies y la caché del navegador

Incluso si en incógnito también falla, limpia la caché y las cookies del navegador para descartar esa posibilidad:

• Chrome: Ctrl+Shift+Del > Intervalo de tiempo: Todo > marca Cookies y Caché > Borrar datos
• Firefox: Ctrl+Shift+Del > Todo > marca Cookies y Caché > Borrar ahora
• Safari: Safari > Preferencias > Privacidad > Gestionar datos del sitio > Eliminar todo

Para limpiar solo las cookies de un dominio específico en Chrome: abre las herramientas de desarrollo (F12) > Application > Cookies > selecciona el dominio > botón derecho > Clear.

Paso 3: Analiza la cadena de redirecciones con DevTools

Antes de hacer ningún cambio en el servidor, identifica exactamente el bucle que se está produciendo:

1. Abre Chrome DevTools (F12)
2. Ve a la pestaña Network (Red)
3. Activa "Preserve log" (Conservar registro) para que no se borre al redirigir
4. Recarga la página con Ctrl+R
5. Observa la lista de solicitudes: verás la cadena completa de redirecciones antes del error final

La cadena típica de un bucle HTTP/HTTPS se verá así:

GET http://tudominio.com          → 301 → https://tudominio.com
GET https://tudominio.com         → 301 → http://tudominio.com
GET http://tudominio.com          → 301 → https://tudominio.com
...
(x20 veces)
ERR_TOO_MANY_REDIRECTS

Si el bucle es entre HTTP y HTTPS, el problema está en la configuración SSL (ver causas 1, 2 o 3). Si el bucle es entre dos URLs del mismo protocolo, el problema está en las reglas de redirección del servidor o del plugin.

También puedes usar curl desde la terminal para ver la cadena completa de redirecciones sin límite de navegador:

# Ver todas las redirecciones con cabeceras:
curl -I -L --max-redirs 10 https://tudominio.com

# Ver solo los códigos de estado y las URLs de destino:
curl -sI -L --max-redirs 10 https://tudominio.com | grep -E "^HTTP|^Location"

Paso 4: Revisa y corrige el archivo .htaccess

# Renombra temporalmente para probar:
mv .htaccess .htaccess_bak

# Si el error desaparece: la causa está en el .htaccess
# Busca y corrige la regla de redirección HTTPS:

# Versión incorrecta (sin comprobación de proxy):
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

# Versión correcta (con comprobación de X-Forwarded-Proto):
RewriteCond %{HTTP:X-Forwarded-Proto} !https
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

Paso 5: Verifica la configuración de WordPress

# En wp-config.php — asegúrate de que las URLs son HTTPS:
define('WP_HOME', 'https://tudominio.com');
define('WP_SITEURL', 'https://tudominio.com');

# Si hay proxy inverso, añade la detección de X-Forwarded-Proto:
if (isset($_SERVER['HTTP_X_FORWARDED_PROTO']) &&
    $_SERVER['HTTP_X_FORWARDED_PROTO'] === 'https') {
    $_SERVER['HTTPS'] = 'on';
}

# Verifica los valores en la base de datos con WP-CLI:
wp option get siteurl
wp option get home

Paso 6: Cambia el modo SSL de Cloudflare a Full (Strict)

Si usas Cloudflare:

1. Accede al panel de Cloudflare
2. Selecciona tu dominio
3. Ve a SSL/TLS > Overview
4. Cambia el modo de "Flexible" a "Full (Strict)"
5. Espera 30 segundos y recarga la página

Paso 7: Vacía todas las cachés

Después de corregir la configuración, vacía todas las capas de caché para asegurarte de que el navegador y el servidor usan las nuevas reglas:

• Caché del navegador: Ctrl+Shift+Del
• Plugin de caché en WordPress: desde el panel del plugin
• Caché de Cloudflare: Caching > Configuration > Purge Everything
• Caché de Nginx (si tienes FastCGI cache): sudo find /var/cache/nginx -type f -delete && sudo systemctl reload nginx

ERR_TOO_MANY_REDIRECTS en configuraciones específicas

LEMP stack (Linux + Nginx + MySQL + PHP-FPM)

En un stack LEMP donde Nginx hace de proxy inverso para PHP-FPM, el bucle puede generarse si tanto Nginx como el .htaccess tienen reglas de redirección HTTPS. La solución es gestionar la redirección solo en Nginx y eliminarla del .htaccess:

# En la configuración de Nginx — bloque server para HTTP:
server {
    listen 80;
    server_name tudominio.com www.tudominio.com;
    return 301 https://tudominio.com$request_uri;
}

# En el bloque server para HTTPS, pasar X-Forwarded-Proto a PHP:
server {
    listen 443 ssl;
    server_name tudominio.com;

    # Pasar el protocolo original a PHP-FPM:
    location ~ \.php$ {
        fastcgi_param HTTPS on;
        fastcgi_param HTTP_X_FORWARDED_PROTO https;
        # ... resto de la configuración fastcgi
    }
}

WordPress detrás de Nginx con PHP-FPM

Si WordPress está en un stack LEMP (Nginx + PHP-FPM) sin ningún proxy adicional, y sigue dando ERR_TOO_MANY_REDIRECTS después de migrar a HTTPS, la causa más probable es que WordPress no está detectando correctamente que la conexión es HTTPS. Añade en wp-config.php:

# wp-config.php — forzar detección HTTPS para Nginx + PHP-FPM:
$_SERVER['HTTPS'] = 'on';

# O de forma más segura, solo si viene de HTTPS:
if (!empty($_SERVER['HTTP_X_FORWARDED_PROTO']) &&
    $_SERVER['HTTP_X_FORWARDED_PROTO'] === 'https') {
    $_SERVER['HTTPS'] = 'on';
}
if (!empty($_SERVER['HTTP_X_FORWARDED_SSL']) &&
    $_SERVER['HTTP_X_FORWARDED_SSL'] === 'on') {
    $_SERVER['HTTPS'] = 'on';
}

Plesk con Apache y Nginx

En Plesk, Apache y Nginx funcionan juntos: Nginx actúa como proxy inverso delante de Apache. Si activas "Forzar HTTPS" en la configuración del dominio en Plesk Y tienes también una regla de redirección en el .htaccess, puedes generar un bucle. La solución es usar solo uno de los dos métodos: la opción de Plesk (que configura la redirección en Nginx) o la regla del .htaccess, pero nunca los dos al mismo tiempo.

Impacto en el SEO y en el rastreo de Google

ERR_TOO_MANY_REDIRECTS es uno de los errores más perjudiciales para el SEO porque Googlebot no puede rastrear ni indexar el contenido de la URL afectada. Si el error afecta a la página de inicio o a páginas principales, el impacto es inmediato:

• Googlebot registra el error y no puede acceder al contenido.
• Si la URL tenía posicionamiento previo, Google puede empezar a reducir su ranking al no poder confirmar que el contenido sigue siendo accesible.
• Si el error persiste días o semanas, Google puede desindexar las páginas afectadas.

Verifica el estado en Google Search Console: sección URL Inspection > introduce la URL afectada > Request Indexing. Si el error ya está resuelto, solicita una nueva indexación. En la sección Cobertura puedes ver todas las URLs que Googlebot detectó con errores de redirección.

Cómo prevenir ERR_TOO_MANY_REDIRECTS en el futuro

Preguntas frecuentes sobre ERR_TOO_MANY_REDIRECTS

¿ERR_TOO_MANY_REDIRECTS es un problema del servidor o del navegador?

Siempre es un problema de configuración del servidor, el CMS o el CDN, nunca del navegador. El navegador simplemente detecta el bucle y aborta la conexión para proteger al usuario de un ciclo infinito. Si cambias de navegador o usas el modo incógnito y el error persiste, confirma que la causa está en el servidor.

¿Por qué el error desaparece en modo incógnito?

Porque el modo incógnito no usa las cookies del perfil normal. Si hay una cookie con información de redirección corrupta o en conflicto con la configuración actual del servidor, el modo incógnito no la tiene y puede cargar la página correctamente. Si en incógnito también falla, la causa está definitivamente en el servidor, no en las cookies del navegador.

¿Cómo sé exactamente cuántas redirecciones está generando mi servidor?

Usa curl -sI -L --max-redirs 25 https://tudominio.com | grep -E "^HTTP|^Location" desde la terminal. Este comando sigue todas las redirecciones y muestra la cadena completa con los códigos de estado y las URLs de destino, sin el límite de 20 que impone el navegador. También puedes usar la pestaña Network de Chrome DevTools con "Preserve log" activado para ver visualmente toda la cadena.

¿Puede ERR_TOO_MANY_REDIRECTS afectar solo a algunos usuarios y no a otros?

Sí. Si la causa son las cookies, el error puede aparecer solo para un usuario específico (o para todos los usuarios que visiten desde una determinada IP o con determinadas cookies). Si la causa está en la configuración del servidor, el error afectará a todos los usuarios sin excepción. Pedirle a alguien desde otra red que pruebe la URL es una forma rápida de determinar si el problema es generalizado o específico de un usuario o red.

¿Cuánto tiempo tarda Google en volver a rastrear una URL después de corregir el error?

Depende de la frecuencia de rastreo que Google haya asignado al sitio. En sitios con rastreo frecuente (webs grandes con mucho contenido nuevo), Google puede volver a intentarlo en horas. En sitios pequeños, puede tardar días. Para acelerar el proceso, usa la herramienta URL Inspection de Google Search Console y solicita una nueva indexación de las URLs afectadas tras corregir el error.

¿Por qué aparece ERR_TOO_MANY_REDIRECTS después de instalar un certificado SSL?

Porque al instalar el certificado SSL y activar HTTPS, suele activarse también la redirección automática de HTTP a HTTPS. Si el servidor ya tenía reglas de redirección en el .htaccess o en Nginx, ahora hay dos capas de redirección que pueden entrar en conflicto. La solución es asegurarse de que la redirección HTTPS solo está configurada en un lugar: o en el servidor web (Nginx/Apache) o en el .htaccess, nunca en ambos al mismo tiempo.