HSTS en WordPress 2026: activalo sin romper tu sitio

En pocas palabras: El hardening SSL en WordPress se logra forzando HTTPS y activando el header Strict-Transport-Security (RFC 6797) con max-age=31536000; includeSubDomains a nivel servidor, más precarga opcional en Chrome. HSTS funciona en todos los navegadores principales desde julio de 2015, según MDN.

Activar HSTS en WordPress le dice al navegador que tu sitio solo se visita por HTTPS, sin excepciones. El header Strict-Transport-Security hace que, ante cualquier intento de conexión por HTTP, el navegador conecte directo por HTTPS, sin mostrar la página insegura ni dejar que el usuario la vea.

HSTS (HTTP Strict Transport Security) es un header de seguridad definido en el RFC 6797 que obliga a los navegadores a acceder a un dominio exclusivamente por HTTPS, según la documentación oficial de MDN. En WordPress, el hardening SSL completo implica forzar HTTPS en la configuración del sitio, sumar este header a nivel servidor y chequear que no quede contenido mixto rompiendo la cadena de confianza. Dicho así suena a checklist de tres puntos, y en el fondo lo es, pero el diablo está en el orden en que hacés esos tres puntos, no en la lista en sí.

¿Por qué tener un certificado SSL no significa que tu WordPress esté «hardeneado»?

Tener el candadito verde en la barra del navegador no significa que tu WordPress esté protegido contra downgrade attacks ni SSL stripping. Un certificado válido solo garantiza que la conexión, cuando se establece por HTTPS, está cifrada. No garantiza que esa conexión se establezca siempre por HTTPS.

Ponele que instalaste tu certificado, todo carga con el candado, te quedás tranquilo. Pero si alguien escribe tu dominio sin el «https://» delante, o hace clic en un link viejo que apunta a la versión http, el navegador arranca la conexión en texto plano. Ahí, durante esa fracción de segundo, un atacante en la misma red (un Wi-Fi público, por ejemplo) puede interceptar la conexión y redirigir al usuario a una versión falsa del sitio antes de que llegue el redirect a HTTPS. Nada exótico: es literalmente el escenario que describe el equipo de Chromium cuando explica por qué HSTS existe: los usuarios «tienden a escribir http:// en el mejor de los casos, y a omitir el esquema por completo la mayoría de las veces». Hardening real es otra cosa. Significa tres capas trabajando juntas: redirect forzado de http a https, header Strict-Transport-Security bien seteado, y cero contenido mixto colgando de páginas viejas. Si te falta cualquiera de las tres, tenés HTTPS, no tenés hardening. Y sí, la diferencia entre esos dos estados es exactamente la ventana de la que se aprovecha un atacante.

¿Cómo forzar HTTPS en WordPress paso a paso?

Forzar HTTPS en WordPress requiere dos cambios: actualizar la URL del sitio en Ajustes Generales y agregar una regla de redirect permanente en el servidor. Sin el segundo paso, cualquier link viejo o bookmark que apunte a http:// sigue funcionando en texto plano.

El primer paso es entrar a Ajustes → Generales y cambiar tanto «Dirección de WordPress (URL)» como «Dirección del sitio (URL)» para que empiecen con https://. Guardás, listo.

Eso resuelve las URLs internas que genera WordPress, pero no evita que alguien entre por http:// directamente. Para eso necesitás una regla en el .htaccess (si tu hosting corre Apache). Más contexto en tener backups a prueba de ransomware.

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

Ojo con esto: el redirect tiene que ser 301 (permanente), no 302 (temporal). MDN es clara al respecto: la respuesta al pedido inseguro «debe ser un redirect permanente (como el código de estado 301)» con la URL https en el header Location, y ese redirect en particular no debe llevar el header HSTS, porque HSTS solo se puede enviar sobre una conexión HTTPS ya establecida. Si mandás el header en una respuesta http, el navegador directamente lo ignora, como medida contra ataques de intermediario.

¿Qué es HSTS y qué hace el header Strict-Transport-Security en WordPress?

El header Strict-Transport-Security le dice al navegador, después de la primera visita segura, que memorice tu dominio como «solo HTTPS» durante un tiempo determinado. A partir de ahí, cualquier intento de acceso por http:// se reescribe a https:// del lado del navegador, antes de que salga un solo paquete por la red insegura.

La sintaxis completa, según MDN, tiene tres piezas:

• max-age=<segundos>: cuánto tiempo el navegador recuerda la política. 31536000 son 365 días, el mínimo aceptado para preload.
• includeSubDomains (opcional): extiende la política a todos los subdominios. Si tenés mail.tudominio.com o dev.tudominio.com sin certificado, esto te rompe el acceso a esos subdominios.
• preload (opcional): marca tu intención de sumarte a la lista de precarga de los navegadores. Requiere max-age de al menos un año e includeSubDomains obligatorio.

¿Y qué pasa si el certificado vence o hay un error de configuración mientras HSTS está activo? El navegador no te deja «hacer click y continuar igual», como sí pasa con un certificado inválido en un sitio sin HSTS. La conexión se corta, punto. Esa es exactamente la garantía que ofrece: sin atajos para el usuario, ni siquiera cuando el usuario quiere arriesgarse. Es una garantía linda de tener hasta el día que la sufrís del lado equivocado, algo que vamos a ilustrar más abajo con un caso hipotético.

¿Cómo activar HSTS en WordPress sin romper el sitio?

Activar HSTS en WordPress sin romper nada requiere sumar el header a nivel servidor (no hay un ajuste nativo en el panel de WordPress) y empezar con un max-age bajo antes de subirlo a un año. Esto se hace en Apache dentro de un bloque mod_headers, o en Nginx con add_header. En activar la autenticación en dos pasos profundizamos sobre esto.

En Apache, el snippet va en el .htaccess, dentro de <IfModule mod_headers.c> para que no rompa el sitio si el módulo no está cargado en tu hosting:

<IfModule mod_headers.c>
Header always set Strict-Transport-Security "max-age=300"
</IfModule>

En Nginx, el equivalente va en el bloque server de tu configuración:

add_header Strict-Transport-Security "max-age=300" always;

Fijate que ese ejemplo arranca en 300 segundos (5 minutos), no en un año. Es a propósito. Subís el header con un max-age chico, navegás el sitio entero (posts viejos, páginas con formularios, el checkout si tenés WooCommerce), revisás la consola del navegador buscando warnings de contenido mixto, y recién ahí subís el valor. hstspreload.org recomienda textualmente ir «ramping up» el max-age de forma gradual antes de comprometerte a un año.

El ejemplo de dos años con includeSubDomains y preload que aparece en la propia documentación de MDN es max-age=63072000; includeSubDomains; preload, el mismo valor que usa hstspreload.org como referencia en su formulario de envío.

Ejemplo hipotético: por qué el orden de los subdominios importa más que el valor del max-age

Ejemplo hipotético, para ilustrar el razonamiento (no es un caso real ni una experiencia propia): imaginate un sitio ficticio, «tienda.ejemplo.com», que corre WordPress con WooCommerce. Además del dominio principal, tiene un subdominio «blog.ejemplo.com» activo y otro, «staging.ejemplo.com», que quedó de un rediseño de hace dos años y nadie se acordó de dar de baja. Nunca tuvo certificado propio porque era solo un ambiente de prueba interno.

Si esta tienda ficticia activara HSTS directo con max-age=31536000; includeSubDomains sin pasar por las fases de la tabla anterior, el problema aparece rápido: «staging.ejemplo.com» queda atrapado. No puede recibir HTTPS (no tiene certificado) y el navegador ya no le permite HTTP (por includeSubDomains). El subdominio queda inaccesible durante todo el año que dura el max-age, sin forma de acelerar eso desde el servidor.

La secuencia razonable, en este ejemplo, sería: primero relevar qué subdominios existen y cuáles tienen certificado vigente (blog sí, staging no). Después, tomar una decisión explícita sobre staging: emitirle certificado, darlo de baja, o directamente no usar includeSubDomains hasta resolver ese punto. Recién con los tres subdominios cubiertos, o con includeSubDomains descartado a propósito, tendría sentido subir el max-age a un año y, siendo un e-commerce con checkout, evaluar preload como paso posterior.

El detalle que vale la pena sacar de este ejemplo: el riesgo no está en el valor del max-age en sí, sino en activar includeSubDomains sin haber auditado antes qué cuelga de tu dominio. Un subdominio olvidado es más peligroso que un max-age alto.

¿Qué errores pueden bloquear tu sitio si configurás mal HSTS?

El error más común es activar HSTS con includeSubDomains cuando tenés un subdominio sin certificado válido, algo que deja ese subdominio completamente inaccesible hasta que expire el max-age. Ese es el error que más dolores de cabeza genera, porque no se nota hasta que alguien reporta que «el mail no anda» o que el subdominio de staging tira error de certificado. Cubrimos ese tema en detalle en configurar correctamente las cabeceras HTTP.

Después está el contenido mixto: imágenes, hojas de estilo o scripts que un post viejo carga por http:// en vez de https://. Con HTTPS forzado pero sin HSTS, el navegador a veces igual muestra el recurso con un warning. Con HSTS activo, esos recursos directamente pueden no cargar, porque el navegador ya no negocia con http en ese dominio.

Y el tercero, el que más bronca da: subir directo a max-age=31536000 sin haber probado nada antes. Subís el header, lo probás en producción sin pasar por las fases previas, todo funciona bárbaro durante la demo, lo das por cerrado, y una semana después alguien reporta que el subdominio de facturación quedó afuera por un certificado que venció y ahora tenés un año de navegadores bloqueando el acceso hasta que expire la política (spoiler: no hay forma de apurar eso desde el lado del servidor una vez que el navegador ya guardó la política).

¿Qué es la lista de precarga (preload) de HSTS y cuándo conviene sumarse?

La lista de precarga de HSTS es un listado que mantiene Chrome (y que Firefox, Safari y Edge usan como base) con dominios que se consideran «solo HTTPS» desde antes de la primera visita del usuario, según hstspreload.org. Sin preload, hay una ventana de vulnerabilidad en la primera conexión: el navegador todavía no conoce tu política HSTS porque nunca recibió el header. Con preload, esa ventana desaparece porque el navegador ya trae tu dominio marcado de fábrica.

Los requisitos para entrar, según el mismo sitio, son puntuales:

• Certificado válido en todo momento, sin excepciones.
• Redirect de HTTP a HTTPS en el mismo host si escuchás en el puerto 80.
• HTTPS en todos los subdominios, incluyendo el subdominio www si existe el registro DNS.
• Header HSTS con max-age de al menos 31.536.000 segundos, includeSubDomains y preload presentes en simultáneo.

Ahora bien, acá viene algo que no todo el mundo te cuenta: la propia hstspreload.org dice textualmente que «los beneficios de la precarga de HSTS son mínimos comparados con los beneficios de HSTS» en sí mismo, y que «mientras HSTS es recomendado, la precarga de HSTS no es recomendada» como paso automático para cualquier sitio. La razón es simple: sacar tu dominio de la lista, si te arrepentís, tarda meses en propagarse a los usuarios a través de las actualizaciones de Chrome, y no hay garantías sobre otros navegadores. Si tenés un blog personal o un sitio institucional chico, probablemente no necesites preload. Si manejás un e-commerce con tráfico sensible o un sitio de servicios financieros, ahí sí tiene sentido evaluarlo, siempre después de haber corrido las fases de la tabla anterior sin sobresaltos.

Criterios rápidos para decidir tu configuración

Con todo lo anterior, la decisión se puede resumir en cuatro preguntas. No hace falta responderlas con precisión de auditoría, pero sí con honestidad:

• ¿Tenés subdominios activos sin certificado vigente? Si la respuesta es sí (o «no estoy seguro»), todavía no actives includeSubDomains. Primero auditá, después decidís.
• ¿Tu sitio maneja pagos, login de usuarios o datos sensibles? Si sí, vale la pena evaluar preload, pero solo después de haber pasado por las fases de prueba y producción sin incidentes.
• ¿Es un blog, sitio institucional o landing sin login? Con HTTPS forzado y HSTS a un año (sin includeSubDomains si tenés dudas sobre tus subdominios), alcanza y sobra.
• ¿Podés comprometerte a mantener HTTPS en todo el dominio y sus subdominios durante años, sin excepciones? Solo si la respuesta es un sí rotundo tiene sentido avanzar a preload, porque salir de la lista es lento y no depende solo de vos.

¿Si usás Cloudflare u otro proxy delante de WordPress, qué tener en cuenta para evitar conflictos con HSTS?

Si usás un proxy o CDN delante de WordPress (como Cloudflare, entre otros), conviene asegurarte de que la conexión viaje cifrada de punta a punta: desde el navegador hasta tu servidor de origen, sin tramos intermedios en HTTP. Si algún tramo del camino queda en HTTP mientras tu .htaccess también está forzando HTTPS puertas adentro, podés terminar con loops de redirección. El header Strict-Transport-Security lo podés setear tanto en el propio WordPress (con el snippet que vimos antes) como en las reglas de tu proxy o CDN, pero conviene que coincida en ambos lados: mismo max-age, misma configuración de includeSubDomains. Si tenés dudas sobre cómo está configurado tu servidor de origen a nivel infraestructura, vale la pena consultarlo directamente con tu proveedor de hosting.

Errores comunes al configurar HSTS en WordPress

• Activar preload sin haber testeado el rollout completo. El flag preload compromete tu dominio a años de HTTPS obligatorio en todos los navegadores. Si metés preload en el primer intento y algo falla, la salida de la lista tarda meses.
• Olvidarse de renovar el certificado a tiempo. Con HSTS activo, un certificado vencido no muestra la clásica pantalla de «proceder de todas formas». El sitio queda directamente inaccesible hasta renovarlo, sin bypass posible para el usuario.
• Mezclar reglas de HSTS en .htaccess con headers duplicados en Cloudflare o en el plugin de seguridad. Dos headers Strict-Transport-Security con valores distintos generan comportamiento inconsistente entre navegadores.
• Usar includeSubDomains sin auditar todos los subdominios activos primero. Un subdominio de testing sin certificado, olvidado hace tiempo, puede quedar bloqueado durante meses (el ejemplo hipotético de más arriba es exactamente este caso).
• Confundir el redirect 301 con el header HSTS y pensar que alcanza con uno de los dos. El redirect protege desde la segunda visita en adelante si el atacante no intercepta el primer request; HSTS protege incluso en la primera visita si el dominio ya está en la lista de precarga.

Preguntas Frecuentes

¿Qué es HSTS y para qué sirve en WordPress?

HSTS es un header de seguridad (Strict-Transport-Security) que obliga al navegador a conectarse a tu WordPress exclusivamente por HTTPS durante el tiempo que indique el max-age. Sirve para cerrar la ventana de ataque que queda abierta cuando un usuario escribe tu dominio sin especificar https://, algo que un simple redirect 301 no cubre en la primera conexión. Te puede servir nuestra cobertura de reforzar el sitio con Patchstack.

¿Cómo fuerzo HTTPS en WordPress con htaccess?

Agregás una regla RewriteCond %{HTTPS} off seguida de un RewriteRule que redirija con código 301 a la versión https:// del mismo request. Eso va en el .htaccess de la raíz de tu instalación, después de cambiar las URLs en Ajustes Generales del panel de WordPress.

¿Qué pasa si activo HSTS y mi sitio tiene contenido mixto?

Los recursos cargados por http:// (imágenes, scripts, hojas de estilo de posts viejos) pueden dejar de cargar directamente, porque el navegador ya no negocia conexiones inseguras con ese dominio. Por eso conviene revisar la consola del navegador buscando warnings de contenido mixto antes de subir el max-age a un valor alto.

¿Es seguro sumar mi dominio a la lista de precarga (preload) de HSTS?

Es seguro si ya validaste que todos tus subdominios, incluido www, sirven HTTPS con certificado válido de forma permanente. La propia hstspreload.org aclara que los beneficios de preload son menores comparados con los de HSTS solo, y que la salida de la lista, si te arrepentís, tarda meses en propagarse.

¿Qué tener en cuenta si usás Cloudflare u otro proxy delante de WordPress para que no choque con HSTS?

Conviene asegurarte de que la conexión completa, desde el navegador hasta tu servidor de origen, viaje cifrada de punta a punta. Si algún tramo queda en HTTP mientras tus reglas HSTS o tu .htaccess fuerzan HTTPS puertas adentro, podés terminar con loops de redirección.

Conclusión

Hardenear SSL en WordPress en 2026 no termina con instalar un certificado. Termina cuando el redirect a HTTPS es permanente, el header Strict-Transport-Security está seteado con un max-age que probaste en fases (no el que copiaste de un tutorial), y no queda un solo subdominio colgado sin certificado si activaste includeSubDomains. El ejemplo de la tienda ficticia de más arriba sirve para eso: el problema casi nunca es el número del max-age, es el subdominio que nadie auditó.

Si administrás un sitio chico, con forzar HTTPS y un HSTS con max-age de un año, sin includeSubDomains si no estás seguro de tus subdominios, alcanza y sobra. Si manejás algo más sensible (e-commerce, sitio con login de usuarios, datos de pago), ahí vale la pena evaluar preload, pero después de correr el rollout completo, no antes. El orden importa: probar, medir, recién después comprometerte a un año de HTTPS obligatorio sin vuelta atrás fácil.

Fuentes

• MDN – Strict-Transport-Security header, documentación oficial del header HSTS
• HSTS Preload List Submission – requisitos y formulario oficial de precarga
• Chromium – HTTP Strict Transport Security, explicación del equipo de Chrome