Demasiadas redirecciones después de mover WordPress a HTTPS

Qué significa este error y cómo reconocerlo

• El sitio funcionaba mediante HTTP antes de la migración a HTTPS y después empezó a mostrar «demasiadas redirecciones».
• El navegador cambia repetidamente entre HTTP y HTTPS, o solicita repetidamente la misma dirección HTTPS.
• Puede fallar todo el sitio, o solo /wp-admin, la página de inicio de sesión o determinadas rutas.
• Abrir la dirección HTTP puede producir una redirección HTTPS esperada seguida de redirecciones repetidas, en lugar de una respuesta normal.
• La navegación privada u otro dispositivo pueden comportarse de forma diferente debido a redirecciones, cookies o datos del sitio almacenados en caché.

Causas principales, ordenadas por probabilidad

1. La configuración de URL de WordPress todavía usa HTTP. Si WordPress Address (URL) o Site Address (URL) sigue usando HTTP mientras otra capa exige HTTPS, WordPress puede redirigir a un esquema que entra en conflicto con la política del servidor.
2. La exigencia de HTTPS existe en varias capas. Un plugin de seguridad, la lógica de wp-config.php, una regla de .htaccess o Nginx, una configuración del hosting y una regla del proxy pueden solaparse o hacer suposiciones diferentes sobre el esquema de la solicitud.
3. Una CDN o un proxy inverso termina TLS. El visitante se conecta mediante HTTPS, mientras que la conexión con el origen usa HTTP. Si el protocolo original falta, es incorrecto o no se confía en él de forma segura, WordPress puede creer repetidamente que la solicitud no es segura.
4. Un plugin o un tema redirige una ruta específica. Los plugins de inicio de sesión, administración, URL canónicas, seguridad y membresías pueden afectar únicamente a /wp-login.php, /wp-admin o determinadas páginas.
5. Una redirección almacenada en caché o una cookie del navegador obsoleta oculta la corrección. Es menos probable que sea la causa original, pero puede hacer que una configuración corregida parezca seguir fallando.
6. Quedan referencias antiguas a HTTP en el contenido o la configuración. Normalmente provocan advertencias de contenido mixto o una redirección adicional, no un bucle de redirecciones en todo el sitio; investígalas después de corregir la cadena principal.

Cómo solucionarlo

1. Inspecciona la cadena de redirecciones

Usa una ventana de navegación privada para realizar una comprobación inicial. Si tienes acceso al shell, asigna una variable de shell con la dirección HTTPS real del sitio afectado y ejecuta esta solicitud de solo lectura:

SITE_URL='the actual HTTPS site address'
curl -IL "$SITE_URL"

Registra cada código de estado y cada encabezado Location:. La alternancia entre HTTP y HTTPS suele indicar un conflicto en la detección del esquema o en las reglas de redirección. La repetición de la misma dirección HTTPS apunta más a una redirección canónica, de un plugin, del proxy o almacenada en caché. No incluyas credenciales, cookies ni encabezados de autorización.

2. Comprueba ambas configuraciones de URL de WordPress

Si el escritorio está disponible, abre Settings → General y verifica que WordPress Address (URL) y Site Address (URL) usen el mismo origen HTTPS previsto, incluido cualquier subdirectorio necesario.

Si el bucle bloquea el escritorio, un administrador autorizado con acceso SFTP o a la base de datos puede definir temporalmente los valores en wp-config.php:

define( 'WP_HOME', 'the actual canonical HTTPS address' );
define( 'WP_SITEURL', 'the actual canonical HTTPS address' );

Haz una copia de seguridad del archivo primero y realiza un único cambio controlado. Estas constantes sustituyen a los campos correspondientes del escritorio mientras están definidas, así que elimínalas o gestiónalas deliberadamente después de realizar las pruebas.

3. Determina dónde termina TLS

Determina si el navegador se conecta directamente al servidor web o a través de una CDN, un balanceador de carga o un proxy inverso. Cuando un proxy termina TLS, el origen puede recibir una conexión HTTP aunque el visitante haya usado HTTPS.

Pide al administrador del hosting o del proxy que confirme que el protocolo original se reenvía de forma coherente y que WordPress está configurado para reconocerlo únicamente desde el proxy de confianza previsto. No confíes ciegamente en X-Forwarded-Proto procedente de clientes arbitrarios; un encabezado reenviado sin validación puede crear problemas de seguridad.

4. Reduce la exigencia de HTTPS a una sola capa definida

Enumera todos los lugares que pueden redirigir HTTP a HTTPS:

• Reglas de la CDN o del balanceador de carga
• Configuración SSL del panel de hosting
• Configuración de Apache .htaccess o Nginx
• Plugins de seguridad o SSL
• Código personalizado de wp-config.php o del tema

Mantén la exigencia en la capa que corresponda a la arquitectura del hosting, normalmente el extremo de la red o el servidor web, y desactiva las redirecciones conflictivas a nivel de aplicación. Haz copias de seguridad de la configuración y obtén la aprobación del administrador antes de cambiar las reglas del servidor. Valida la configuración antes de cualquier recarga o reinicio aprobado; no reinicies un servidor web de producción como primer paso de diagnóstico.

5. Prueba por separado las rutas de inicio de sesión y administración

Si la interfaz pública funciona pero /wp-admin o el inicio de sesión entra en un bucle, revisa los plugins de seguridad, inicio de sesión, URL canónicas y caché modificados recientemente mediante un procedimiento de mantenimiento aprobado. Un conflicto entre plugins es más probable cuando solo entra en bucle una ruta. Si es necesario desactivar un plugin para realizar pruebas, registra el cambio, conserva los controles de acceso y vuelve a activarlo o sustitúyelo después de la prueba.

6. Purga las cachés y vuelve a probar

Después de registrar el comportamiento original y realizar una corrección controlada, borra los datos del sitio del navegador y purga las cachés de páginas u objetos de WordPress, además de las cachés del hosting y la CDN. Vuelve a probar la dirección HTTP, la página de inicio HTTPS, la página de inicio de sesión y una página interna representativa. Una respuesta 301 o 302 almacenada en caché puede persistir después de corregir la configuración activa.

7. Actualiza las referencias HTTP restantes

Una vez corregida la cadena de redirecciones, haz una copia de seguridad de la base de datos antes de cambiar las URL almacenadas. Usa una herramienta de migración de WordPress fiable o una búsqueda y sustitución con WP-CLI, empezando por una ejecución de prueba, y utiliza una herramienta que gestione los datos serializados de WordPress. Sustituye únicamente el origen antiguo del sitio por el origen HTTPS; no reemplaces de forma general todos los valores http://, porque las URL de terceros y los recursos externos intencionados pueden no pertenecer al sitio.

Prevención y cómo verificar la solución

• Registra el origen HTTPS canónico del sitio y actualiza ambas configuraciones de URL de WordPress durante la migración.
• Elige una ubicación documentada para la redirección HTTP a HTTPS y revisa las demás capas antes de activar un plugin de forzado de SSL.
• Documenta si una CDN o un proxy inverso termina TLS y cómo obtiene el origen el protocolo original.
• Prueba la página de inicio, una página interna, el inicio de sesión y el escritorio después de cada cambio en la configuración HTTPS.
• Haz copias de seguridad de la configuración y de la base de datos antes de editar wp-config.php, las reglas de reescritura o las URL almacenadas.
• Cuando las redirecciones funcionen, realiza una migración específica de URL a HTTPS y comprueba si quedan referencias de contenido mixto.

Preguntas frecuentes