Corregir HSTS mal configurado en WordPress y SSL

Si necesitas corregir HSTS mal configurado en un sitio WordPress con SSL, lo primero es distinguir dónde está realmente el problema. HSTS es una política de seguridad del navegador que obliga a usar HTTPS durante un tiempo definido por la cabecera Strict-Transport-Security. Por eso, un fallo puede venir de WordPress, pero también del servidor, la CDN, un proxy, la caché del navegador o incluso de una política preload ya distribuida.

En la práctica, un error HSTS puede bloquear el acceso, provocar avisos de certificado, mantener un bucle de redirección HTTPS o hacer que los cambios no se reflejen cuando esperas. Antes de tocar cabeceras, conviene revisar certificado, redirecciones, cachés y el punto exacto desde el que se envía la política.

• Comprueba si el certificado SSL/TLS es válido y la cadena está completa.
• Verifica quién envía la cabecera HSTS: servidor, hosting, CDN o plugin.
• Revisa redirecciones, mixed content y cachés antes de cambiar nada.

Qué significa corregir HSTS mal configurado en WordPress y SSL

Corregir HSTS mal configurado no consiste solo en quitar o cambiar una cabecera. Significa alinear varios elementos para que el navegador pueda forzar HTTPS sin encontrar incoherencias. Si el dominio anuncia HSTS pero el certificado falla, la redirección está mal resuelta o algún recurso sigue cargando por HTTP, el usuario puede quedarse sin acceso normal.

En WordPress solo controlas una parte: la URL del sitio, posibles plugins de redirección, recursos internos y algunos ajustes de HTTPS en WordPress. La cabecera HSTS, en cambio, suele gestionarse fuera de WordPress: en Apache, Nginx, panel del hosting, balanceador, reverse proxy o CDN. El navegador también juega su papel, porque puede conservar la política HSTS en caché durante el tiempo indicado por max-age.

Qué suele causar un error HSTS en un sitio WordPress

Las causas más habituales combinan SSL, redirecciones y cabeceras mal aplicadas. No todas dependen del CMS.

• Certificado SSL/TLS caducado, mal emitido o con cadena intermedia incompleta.
• Redirecciones HTTP a HTTPS duplicadas o contradictorias entre WordPress, servidor y CDN.
• Cabecera Strict-Transport-Security enviada desde varios puntos con valores distintos.
• Uso de preload o de un max-age alto sin haber validado antes toda la infraestructura.
• Recursos inseguros o mixed content que siguen llamando a HTTP.
• Caché del navegador, caché del proxy o reglas persistentes en CDN.

A nivel de disponibilidad y confianza, estos problemas SSL en WordPress pueden traducirse en errores de acceso, páginas incompletas o advertencias del navegador. No conviene dramatizarlo, pero sí tratarlo con método.

Cómo revisar la configuración antes de cambiar nada

Antes de editar cabeceras o desactivar reglas, revisa esta secuencia:

1. Certificado y cadena: confirma que el certificado cubre el dominio correcto, no está caducado y presenta la cadena completa.
2. Redirecciones: comprueba si el salto de HTTP a HTTPS ocurre una sola vez y sin bucles.
3. Origen de la cabecera: localiza dónde se envía la cabecera HSTS. Puede estar en .htaccess, en Nginx, en el panel del hosting, en una CDN o en un plugin.
4. Ajustes de WordPress: revisa las URLs del sitio y si algún plugin fuerza HTTPS o reescribe cabeceras.
5. Recursos inseguros: valida mixed content con las herramientas del navegador.
6. Cachés: vacía caché de WordPress, del servidor, de la CDN y, si procede, limpiar caché del navegador o probar en una sesión limpia.

Pasos para corregir una cabecera HSTS incorrecta sin agravar el problema

El objetivo es corregir la política sin introducir más inconsistencias. Un enfoque prudente sería este:

1. Haz una copia de la configuración actual o documenta qué capa está enviando la cabecera.
2. Si detectas múltiples orígenes, deja una sola fuente de verdad para la cabecera Strict-Transport-Security.
3. Corrige primero certificado, cadena SSL/TLS y redirecciones. HSTS no debe compensar un HTTPS defectuoso.
4. Ajusta la política con cautela. Como ejemplo orientativo, puede ser razonable validar primero una duración moderada antes de plantear valores altos o preload.
5. Revisa que no haya llamadas a HTTP en temas, plugins, fuentes, imágenes o scripts.
6. Vacía las cachés relevantes y prueba en navegador limpio o con herramientas de inspección de cabeceras.

Si el sitio está detrás de una CDN o proxy, confirma que no reescriba cabeceras ni aplique reglas propias. Ahí es donde muchos casos de HSTS WordPress se confunden con un problema del CMS cuando realmente está fuera de él.

Cuándo el fallo está en el servidor, la CDN o el navegador y no en WordPress

WordPress no controla por sí solo la negociación TLS ni la política HSTS almacenada en el navegador. Si el error aparece antes de cargar la web, si la cabecera se ve en respuestas estáticas o si la CDN responde con sus propias reglas, probablemente el foco esté fuera de WordPress.

También puede ocurrir que modifiques la configuración correcta en el servidor, pero el navegador siga aplicando una política previa guardada. En ese caso, conviene contrastar resultados con otro navegador, modo privado o un equipo distinto. Si usas herramientas técnicas, una referencia útil es la documentación de Mozilla sobre cabeceras HTTP: MDN Web Docs.

Qué hacer si el dominio quedó afectado por caché o preload

Si el dominio quedó marcado por una política HSTS previa, los cambios no tienen por qué reflejarse al instante. Dependerá del max-age almacenado, de la caché del navegador y, si el dominio entró en HSTS preload, de procesos externos y de la actualización de los navegadores.

La checklist mínima en estos casos es:

• Probar en un navegador distinto o perfil limpio.
• Verificar si la política HSTS sigue presente en la respuesta actual.
• Confirmar si hubo envío previo con includeSubDomains o preload.
• Evitar cambios impulsivos hasta identificar la capa exacta que mantiene el problema.

El error más frecuente es tocar WordPress cuando el origen real está en el servidor o en la CDN, y el riesgo principal es endurecer una política HTTPS sobre una configuración SSL aún inconsistente. El siguiente paso razonable es hacer una auditoría técnica de cabeceras, redirecciones y cachés antes de aplicar cambios permanentes. Si tu web en España sigue mostrando un comportamiento irregular, lo más sensato es revisar el caso con soporte técnico especializado.