WordPress en bucle http https por SSL mal instalado

Qué es el bucle http https en WordPress

El “bucle http https” en WordPress aparece cuando el navegador intenta entrar a su web y, en lugar de cargar la página, se ve atrapado en una secuencia de redirecciones que se repiten. Un ejemplo típico es que el servidor envía al navegador de http a https, pero en el siguiente paso alguna capa intermedia fuerza el retorno a http, o vuelve a aplicar otra redirección a https de forma duplicada. El resultado es una cadena de redirecciones que no termina y que, por seguridad, el navegador corta mostrando errores como ERR_TOO_MANY_REDIRECTS o mensajes del tipo “La página ha redirigido demasiadas veces”.

Este problema no es “un fallo de WordPress” en sentido estricto. Suele ser una colisión de configuraciones entre varios puntos del sistema. Por ejemplo, el certificado SSL puede estar bien, pero WordPress cree que está en http, o al revés. También puede ocurrir que el servidor detecte https, pero un proxy inverso (como Cloudflare o un balanceador) entregue cabeceras ambiguas. Incluso un plugin de forzar https puede empeorar la situación cuando ya existe una regla equivalente en el servidor.

Además, este tipo de incidencia afecta de forma directa a la experiencia de usuario, al rastreo de buscadores y a la conversión. Si su web entra en bucle, Googlebot puede dejar de rastrear URLs, se pueden disparar errores en Search Console y se puede perder autoridad temporalmente por problemas de accesibilidad. La buena noticia es que, con un diagnóstico ordenado, suele resolverse sin cambios drásticos y sin pérdida de SEO, siempre que se actúe con método.

Síntomas y errores más frecuentes

Antes de tocar configuraciones, conviene reconocer las señales típicas. El síntoma más evidente es el error del navegador indicando demasiadas redirecciones. A veces no aparece ese texto exacto y lo que se ve es una pantalla en blanco, un aviso de que no se puede acceder al sitio o un mensaje sugiriendo borrar cookies. En otros casos la web carga, pero al intentar iniciar sesión, acceder a wp-admin o finalizar una compra, vuelve el bucle. Esto es importante, porque indica que la redirección puede depender de rutas concretas, cookies, cabeceras o reglas distintas según el directorio.

También son frecuentes estos signos:

• El navegador cambia varias veces de URL entre http y https al mirar la barra de direcciones.
• En herramientas de auditoría (o al probar con curl) se observan respuestas 301 y 302 encadenadas.
• Se mezcla “www” y “sin www” junto con http y https, lo que multiplica combinaciones posibles.
• El panel de WordPress muestra la URL del sitio en http, aunque el certificado esté instalado.
• Tras activar un plugin para forzar https, el acceso empeora o se rompe el admin.
• Si usa Cloudflare u otro CDN, su navegador ve https, pero el origen recibe http, o viceversa.

Un matiz que suele confundir es el aviso del navegador de “borrar cookies”. A veces funciona porque se elimina un estado temporal que activa una redirección condicional, pero no es una solución real. Si su web depende de cookies para mantener la sesión o gestionar compras, el bucle puede reaparecer en cuanto el usuario vuelva a autenticarse. Por eso el objetivo es estabilizar la configuración, no solo “pasar el error” en un navegador concreto.

Por último, no es raro que el problema empiece justo después de una migración, un cambio de hosting, la activación de un certificado, un cambio de dominio, o una instalación de plugin de seguridad o caché. En esas situaciones, el histórico de redirecciones antiguas puede quedarse activo en varios lugares a la vez, y el sistema entra en conflicto.

Por qué ocurre cuando el SSL está mal instalado

El SSL “mal instalado” no siempre significa que el certificado sea inválido. Muchas veces el certificado es correcto, pero la instalación o la configuración alrededor no está alineada. Hay varias causas habituales:

• Certificado incompleto: falta la cadena intermedia y algunos clientes no validan. Esto puede provocar redirecciones condicionadas o fallos que se interpretan como bucles.
• Redirección duplicada: se fuerza https en el servidor y, además, en WordPress o en un plugin, cada uno con su lógica.
• Proxy inverso: el visitante llega por https, pero el servidor de origen recibe http. Si WordPress toma decisiones con base en lo que “ve” el origen, puede redirigir incorrectamente.
• Cabeceras incorrectas: falta o es errónea la cabecera que indica el esquema original (por ejemplo, X-Forwarded-Proto), y WordPress cree estar en http.
• HSTS mal gestionado: se activa HSTS y luego se intenta volver a http, o se combina con redirecciones inconsistentes. El navegador “recuerda” y fuerza https incluso si usted cambia el servidor.
• Conflicto www: se aplican reglas separadas para www y sin www, con condiciones incompatibles.

Cuando se habla de WordPress en bucle http https, casi siempre hay al menos dos decisiones de redirección actuando. Por ejemplo, el servidor redirige http a https, pero WordPress tiene guardada la URL del sitio en http, y al generar enlaces internos o al interpretar el esquema, devuelve a http. En otra variante, Cloudflare está en modo “Flexible” y conecta al origen por http, mientras WordPress intenta forzar https al detectar un plugin o una regla local. El resultado, de nuevo, es una negociación interminable.

También conviene diferenciar entre “redirección” y “contenido mixto”. El contenido mixto aparece cuando la web carga en https pero incluye recursos en http (imágenes, scripts, fuentes). Eso no suele producir un bucle de redirecciones, pero sí avisos de seguridad y bloqueos de recursos. A veces se confunden ambos problemas y se aplican soluciones que no corresponden. Si lo suyo es un bucle, el foco está en las respuestas 301 o 302 y en la coherencia del esquema.

Checklist rápido antes de tocar nada

En un bucle http https es fácil “arreglar” una cosa y romper otra, sobre todo si hay cachés y reglas persistentes. Antes de aplicar cambios, es recomendable seguir una lista de verificación que reduce riesgos y evita pérdidas de tiempo.

• Haga copia de seguridad del archivo .htaccess, del wp-config.php y, si puede, de la base de datos.
• Identifique su arquitectura: hosting directo, Nginx, Apache, LiteSpeed, proxy, CDN, Cloudflare, balanceador.
• Compruebe el certificado en el dominio exacto: con www y sin www. Confirme que el certificado cubre la variante que usa.
• Revise DNS: asegúrese de que el dominio apunta al servidor correcto. Un cambio reciente puede mezclar entornos.
• Vacíe cachés de CDN y de plugins de caché, pero solo después de saber qué va a cambiar. Evite hacerlo a ciegas.
• Guarde evidencia del bucle: una captura de los headers (301, 302) ayuda a ver el patrón.
• Desactive temporalmente reglas duplicadas, de forma controlada, para aislar la causa.

Si su web es un eCommerce o tiene tráfico activo, un detalle importante es planificar el cambio en una ventana de baja demanda. Un bucle puede impedir compras, formularios y accesos, y cada minuto cuenta. Si tiene un entorno de staging, es ideal replicar el escenario, aunque no siempre es posible cuando el bucle está ligado a cabeceras del proxy o a la capa DNS.

Esta checklist también le ayuda a evitar un error común: aplicar simultáneamente un plugin de forzar https, una regla en .htaccess y una regla en Cloudflare. Eso suele “parecer” razonable, pero en la práctica multiplica puntos de redirección y es una receta frecuente para el bucle. Un enfoque ordenado es más rápido y más estable.

Diagnóstico paso a paso para localizar la redirección

El objetivo del diagnóstico es responder a dos preguntas. Quién está redirigiendo y por qué. Para ello conviene ir de fuera hacia dentro, es decir, desde el navegador y la red hasta WordPress y el servidor.

Paso 1. Verifique el patrón de redirecciones. Use una herramienta de cabeceras o un comando equivalente (por ejemplo, una petición que muestre los headers). Lo que busca es la secuencia de “Location”. Si ve alternancia entre http y https, el bucle está en el esquema. Si alterna entre www y sin www, el conflicto puede ser en reglas de canonicalización. Si la ruta cambia, puede ser un plugin o una lógica basada en cookies.

Paso 2. Aísle Cloudflare o CDN si existe. Una prueba sencilla es acceder al origen directamente, sin el proxy, si su hosting lo permite (por ejemplo, mediante una URL temporal, una IP con Host header, o desactivando temporalmente el proxy). Si al saltarse el CDN el bucle desaparece, el conflicto está en esa capa. Si persiste, el origen o WordPress tiene el problema.

Paso 3. Revise la configuración de WordPress: WordPress Address (URL) y Site Address (URL). Si están en http mientras el sitio funciona en https, es una pista clara. Si no puede acceder al admin, se puede revisar en la base de datos (tabla options) o forzar temporalmente en wp-config.php.

Paso 4. Revise redirecciones del servidor. En Apache, .htaccess es sospechoso habitual. En Nginx, lo son los bloques server y las reglas rewrite. Si usa panel tipo Plesk o cPanel, puede haber reglas gestionadas por el propio panel. También existen redirecciones en el nivel de aplicación del hosting, por ejemplo “force https” a nivel de hosting.

Paso 5. Compruebe cabeceras en proxys. Si el sitio está tras proxy, WordPress necesita saber el esquema real del cliente. Si el proxy termina https, pero al origen llega http, es esencial que llegue una cabecera correcta que indique el esquema original. Si no existe, WordPress puede detectar http y redirigir, aunque el visitante ya esté en https. Ese choque es una fuente típica de WordPress en bucle http https.

Con este diagnóstico, en lugar de hacer cambios aleatorios, podrá decir con bastante precisión “la redirección se origina en el CDN” o “se origina en .htaccess” o “se origina en WordPress al interpretar la URL del sitio”. Esa claridad hace que la corrección sea mucho más rápida y menos arriesgada.

Corregir .htaccess y reglas de redirección

En entornos Apache o LiteSpeed, el archivo .htaccess suele ser el primer lugar donde se acumulan reglas de redirección. Muchas guías recomiendan “forzar https” añadiendo directivas, pero el problema aparece cuando ya existen otras reglas, como forzar www, redireccionar a un subdirectorio, o reglas antiguas de migraciones. Dos reglas correctas por separado pueden ser incompatibles juntas.

Una corrección prudente consiste en simplificar. Mantenga una sola regla para el esquema y, si necesita canonicalizar www o no www, hágalo en la misma lógica, evitando redirecciones en cadena. También compruebe que no se redirige desde https a http en ningún punto. Hay plugins o configuraciones que insertan reglas en el .htaccess. Si identifica bloques generados por plugins, es preferible desactivar la función desde el plugin y luego limpiar el .htaccess, en lugar de dejar reglas “huérfanas”.

Además, revise si hay condiciones basadas en cabeceras del proxy. Por ejemplo, algunas reglas miran HTTPS=on, pero tras un proxy puede no estar activado, aunque el cliente sí esté en https. En esos casos, el servidor redirige constantemente a https, mientras el proxy ya entrega https al cliente. Eso, combinado con WordPress, puede crear bucles.

Otro punto es el módulo de reescritura de WordPress. WordPress añade un bloque estándar para “pretty permalinks”. Ese bloque no debería incluir redirecciones http https. Si ve reglas extra dentro o alrededor que no reconoce, conviene compararlas con la versión estándar de WordPress y restaurar el bloque base. Después, aplique solo la redirección necesaria y verifique el resultado.

Si su sitio está en Nginx, la lógica es distinta porque no hay .htaccess. Aun así, el principio es idéntico: una sola decisión para https, con canonicalización clara. En Nginx, revise los bloques server que escuchan en 80 y 443, y confirme que el server_name coincide con lo que usa su dominio. Un error típico es redirigir 80 a 443, pero luego 443 redirige a un host alternativo que a su vez redirige de vuelta.

Ajustes en WordPress, URL y wp-config

Si el servidor está bien, pero WordPress “cree” que el sitio está en http, es muy fácil que aparezcan redirecciones inesperadas. WordPress usa dos valores principales, Site URL y Home URL. Cuando están en http y su instalación ya funciona en https, el admin puede redirigir, los enlaces pueden generarse en http y los plugins pueden intentar corregirlo, creando un choque de criterios.

Si puede acceder al panel, revise en Ajustes y confirme que ambas URL estén en https y con la variante correcta de dominio (www o no). Si no puede acceder, puede corregirse desde la base de datos (opciones del sitio) o, de forma temporal, definir constantes en wp-config.php. Esa medida es útil para recuperar acceso cuando el bucle impide entrar al admin, aunque no debería dejarse como “parche” permanente si luego va a modificar la base de datos, porque puede enmascarar el problema real.

Otro punto importante son las variables de servidor. WordPress determina si está en https mirando variables como $_SERVER['HTTPS'] y, en entornos con proxy, $_SERVER['HTTP_X_FORWARDED_PROTO'] u otras. Si su arquitectura incluye Cloudflare, un balanceador o un reverse proxy, es posible que WordPress nunca reciba la señal correcta. En ese caso, aunque usted ponga las URL en https, WordPress puede seguir “detectando” http y forzar redirecciones.

También revise plugins relacionados con SSL y caché. Plugins como los que “fuerzan https” son útiles en algunos escenarios, pero si ya tiene el servidor bien configurado, pueden introducir redirecciones duplicadas. En esos casos, lo más estable suele ser desactivar la redirección del plugin y dejar que el servidor haga el 301. Si necesita el plugin por la gestión de contenido mixto, intente mantener solo esa parte y no la redirección.

Por último, si su sitio tiene multisite, subdirectorios o un WordPress instalado en una carpeta, sea especialmente cuidadoso. En esas configuraciones, la URL base, la URL del admin y las reglas de reescritura pueden ser más sensibles. El método recomendado es cambiar una cosa cada vez, validar el comportamiento y solo entonces pasar a la siguiente capa. Así evitará que un ajuste “aparentemente correcto” le esconda el origen del bucle.

Cloudflare, CDN y proxys cuando duplican la redirección

Cuando hay un CDN o un proxy inverso, el bucle http https se vuelve más probable porque hay dos conexiones distintas. La del usuario al CDN y la del CDN al servidor de origen. Si ambas capas intentan “arreglar” https por su cuenta, el choque es casi inevitable.

Un ejemplo común es Cloudflare en modo Flexible. En ese modo, el usuario ve https, pero Cloudflare conecta al origen por http. Si en el origen usted fuerza https, el origen redirige a https. Cloudflare recibe esa respuesta y, dependiendo de la configuración, puede volver a conectar por http o interpretar la redirección de forma que termina en bucle. En cambio, si el modo es Full o Full (strict), Cloudflare conecta al origen por https y el circuito es coherente.

Además del modo SSL, Cloudflare ofrece opciones de redirección, reglas de página y “Always Use HTTPS”. Si activa “Always Use HTTPS” y, además, su servidor redirige, tendrá dos reglas. A veces funciona, pero en combinación con www o con rutas específicas puede romper. Lo más estable es elegir un solo lugar para el 301 final.

• Si el origen tiene certificado válido y control de redirecciones, deje el 301 en el origen y desactive duplicados en el CDN.
• Si quiere centralizar redirecciones en el CDN, entonces el origen debe aceptar tanto http como https sin redirigir, o al menos no contradecir el criterio.
• Si hay balanceador, asegúrese de que reenvía el esquema real con cabeceras correctas.

También existen proxys de hosting, aceleradores, WAF y soluciones de seguridad que actúan como intermediarios. Si ha activado recientemente un firewall o un servicio anti bot, revise si modifica redirecciones o fuerza un esquema. Un WAF puede redirigir a una página de desafío, que a su vez vuelve a su dominio con otra política, dando lugar a bucles difíciles de ver.

La forma más eficaz de resolverlo en estos entornos es aislar. Primero, asegure el origen funcionando correctamente sin el CDN. Segundo, active el CDN con una configuración mínima y sin reglas extra. Tercero, si necesita reglas, añádalas una a una. Este orden reduce enormemente la posibilidad de que “cure” un síntoma mientras el problema real sigue latente.

Certificado, cadena y servidor cuando el problema está abajo

Si el bucle persiste incluso con WordPress correctamente configurado y sin reglas duplicadas visibles, conviene mirar la capa de certificado y servidor. Un certificado SSL tiene varios componentes: el certificado del dominio, la clave privada, y a menudo uno o varios certificados intermedios que forman la cadena de confianza. Si la cadena está incompleta, algunos clientes pueden fallar y, dependiendo de cómo esté montado el servidor, puede provocar redirecciones inesperadas o reintentos.

Compruebe estos puntos:

• El certificado cubre el dominio exacto y la variante (www o no).
• La cadena intermedia está instalada en el servidor.
• El servidor sirve el certificado correcto y no uno antiguo.
• No hay un virtual host equivocado atendiendo el dominio.
• Si hay varios certificados, no se confunden en SNI.

Un caso típico tras migraciones es que el DNS apunte al servidor nuevo, pero el hosting conserve configuraciones antiguas, o que haya un “alias” de dominio que cae en un vhost distinto. Entonces, una parte de las peticiones va por un sitio y otra por otro, creando comportamientos inconsistentes. Esto se nota especialmente si la redirección cambia según el nodo o si solo falla a ratos.

Otro elemento es HSTS. Si en el pasado se activó HSTS con un tiempo alto, el navegador recordará que ese dominio solo debe abrir en https. Esto no genera por sí solo un bucle, pero puede “interferir” en pruebas y hacerle pensar que el servidor sigue redirigiendo cuando, en realidad, es el navegador el que fuerza https. Para comprobarlo, haga pruebas en un navegador limpio o con un perfil nuevo, y use herramientas que muestren headers de respuesta. Si la cabecera Strict-Transport-Security está presente, considere si realmente debe estarlo y con qué duración.

Finalmente, revise configuraciones del hosting como “force SSL”, redirecciones desde panel, o reglas automáticas de seguridad. A veces el panel crea redirecciones a nivel superior y usted las duplica en .htaccess o en WordPress. En esos casos, el arreglo más limpio es desactivar la opción del panel o eliminar la regla duplicada, y quedarse con un solo mecanismo.

Impacto en SEO y cómo prevenir que vuelva

Un bucle http https no es solo una molestia técnica. Tiene impacto en SEO, en rastreo y en métricas de negocio. Cuando Google o cualquier bot encuentra una cadena de redirecciones demasiado larga, puede abandonar el rastreo de esa URL. Si ocurre a escala, su sitio puede perder visibilidad temporalmente y aumentar errores de cobertura. Además, si se alternan variantes (www y sin www) se diluye la señal canónica y puede aparecer contenido duplicado de forma accidental.

Para minimizar el impacto, el objetivo es dejar una única URL canónica para cada página, con un 301 directo desde cualquier variante hacia esa canónica. Una redirección directa es mejor que dos o tres encadenadas. Además, revise que el sitemap use la variante final (https y host correcto) y que las etiquetas canonical coincidan. Si usa plugins SEO, verifique que no generan canonicals en http.

Medidas preventivas recomendables:

• Documente dónde se gestiona el forzado a https, y evite duplicarlo al instalar plugins o servicios nuevos.
• Antes de migrar o cambiar DNS, revise certificados y vhosts para evitar servir certificados antiguos.
• Use un entorno de staging para probar cambios de SSL, sobre todo con CDN o proxys.
• Revise periódicamente reglas del CDN, porque a veces se añaden por plantillas o automatizaciones.
• Controle el contenido mixto con herramientas apropiadas, pero sin mezclarlo con redirecciones si no hace falta.

En webs con mucha historia, el bucle a veces es el síntoma de una “deuda técnica” de redirecciones acumuladas. La prevención real pasa por simplificar y centralizar decisiones. Una buena práctica es mantener un documento interno con: dominio canónico, si se usa www o no, dónde se fuerza https, si hay proxy, y qué cabeceras se requieren. Esto parece básico, pero en equipos con cambios frecuentes, evita que la solución de hoy se convierta en el problema de mañana.

Preguntas frecuentes