HSTS: HTTP Strict Transport Security para SEO

TL;DR — HSTS es una pequeña instrucción que su servidor envía a los navegadores y que dice: «usa siempre HTTPS para mi sitio, nunca HTTP sin cifrar». Tapa un diminuto agujero de seguridad que deja abierto una redirección normal de HTTP→HTTPS, y no perjudica al SEO. Pero es estricto a propósito: una vez activado, un certificado roto deja su sitio inaccesible sin que los visitantes puedan saltarse el aviso con un clic. Actívelo solo cuando su configuración de HTTPS sea realmente sólida.

Qué es HSTS

Ya sabe que debería estar en HTTPS: la versión cifrada, con candado, de su sitio. La forma habitual de forzarlo es una redirección: cuando alguien escribe http://yoursite.com, su servidor le envía una redirección 301 a https://yoursite.com. Eso funciona, pero queda una rendija abierta. Esa primerísima petición —la que se produce antes de que se dispare la redirección— sigue viajando por HTTP sin cifrar. Un atacante conectado a la misma red Wi-Fi puede abalanzarse en esa ventana.

HSTS —HTTP Strict Transport Security— cierra esa brecha. Es una instrucción breve (una «cabecera») que su servidor añade a sus respuestas, pero solo a las servidas por una conexión genuinamente segura; la misma cabecera enviada por HTTP sin cifrar se ignora, ya que de lo contrario un atacante podría inyectarla o eliminarla. Le dice a ese navegador concreto: durante los próximos tantos meses, ni siquiera intentes HTTP para este sitio; ve directo a HTTPS. Es una política que cada navegador aprende y almacena por su cuenta, no algo que cambie su servidor. Una vez que un navegador la ha visto, actualiza los enlaces http:// a https:// por sí mismo, antes de que nada salga del dispositivo. Evidence for this claim After receiving HSTS, a browser upgrades future HTTP attempts to HTTPS before sending the request. Scope: MDN documents user-agent enforcement after the header has been learned; first-visit protection requires preload or a prior secure visit. Confidence: high · Verified: 2026-07-14 MDN: Strict-Transport-Security header

¿HSTS ayuda o perjudica al SEO?

Ni una cosa ni la otra, de forma directa. HSTS es una función de seguridad y confianza, no una palanca de posicionamiento. No le hará subir en los resultados, pero, bien hecho, tampoco le perjudicará. Lo único que hay que entender es que HSTS no sustituye a sus redirecciones. Sigue necesitando sus redirecciones 301 reales del lado del servidor de HTTP a HTTPS, porque eso es lo que Google y Bing ven y usan realmente. HSTS funciona dentro del navegador para visitantes humanos reales; los rastreadores no dependen de él. Mantenga ambos.

La gran advertencia

HSTS es deliberadamente implacable. Una vez que un navegador ha «aprendido» que su sitio es solo HTTPS, se negará a cargar el sitio por completo si su certificado llega a caducar o a quedar mal configurado, sin ningún botón de «continuar de todos modos». Ese es precisamente el objetivo (impide que los atacantes engañen a la gente y la lleven a una versión falsa en HTTP), pero significa que un certificado caducado pasa de ser un «aviso molesto» a «el sitio está caído para cualquiera que lo haya visitado antes».

También existe una versión reforzada llamada preload que integra su dominio en el propio navegador. Es excelente, pero salir después de la lista preload es lento y doloroso: cuente en meses. Así que preload es una puerta de un solo sentido: atraviésela solo cuando esté seguro. Evidence for this claim HSTS preload requires at least a one-year max-age, includeSubDomains, and preload; removal can take months to reach users. Scope: The Chromium preload service documents submission and removal behavior; requirements can change and should be rechecked before submission. Confidence: high · Verified: 2026-07-17 Chromium: HSTS Preload List Submission

¿Quiere la sintaxis de la cabecera, la redirección interna que solo ocurre en el navegador y que los rastreadores nunca ven, los requisitos de preload y los escenarios reales de bloqueo? Cambie a la pestaña Avanzado.

TL;DR — HSTS es la cabecera de respuesta Strict-Transport-Security, que solo se respeta cuando un navegador la recibe por una conexión segura y que se almacena por cliente como política futura para ese host. Cierra el «problema de la primera petición» que una 301 por sí sola deja abierto: la petición HTTP inicial de un visitante nuevo es insegura hasta que se dispara la redirección, y esa es la ventana que busca un atacante que practique SSL stripping. Tres directivas: max-age (obligatoria, en segundos), includeSubDomains y preload. Cuando un navegador aplica HSTS, reescribe el URI a HTTPS internamente, antes de que ninguna petición llegue a un servidor —el RFC 6797 no obliga a un código de estado concreto para esa reescritura, aunque las herramientas suelen mostrarla como un 307—, de modo que sus 301 del lado del servidor siguen siendo obligatorias para los motores de búsqueda y para la autoridad de enlaces (link equity); HSTS se suma a ellas, no las sustituye. Preload integra su dominio en el navegador a través de hstspreload.org (requiere max-age ≥ 31536000, includeSubDomains y preload) y es casi irreversible: la eliminación es un envío aparte que tarda meses en llegar a los usuarios. Y HSTS está diseñado para fallar en duro ante cualquier error de certificado, así que actívelo solo cuando HTTPS sea robusto en todos los subdominios.

El hub de HTTPS presenta HSTS como una protección de la capa del navegador que se apoya sobre sus 301. Esta página es el análisis a fondo: la sintaxis exacta de la cabecera, la redirección interna que confunde a los SEO, la casi irreversibilidad de la lista preload y las formas reales en que HSTS deja a la gente fuera.

El problema que HSTS resuelve realmente: la primera petición

Imagine un sitio migrado correctamente. Todas las URL http:// redirigen con un 301 a su gemela https://, el certificado es válido, las canónicas apuntan a HTTPS. Parece hermético. No lo es del todo.

Cuando un visitante completamente nuevo escribe yoursite.com (sin esquema) o hace clic en un enlace antiguo http://yoursite.com, la primera petición del navegador sale por HTTP sin cifrar. Su servidor responde con la 301 y todas las peticiones posteriores son seguras. Pero ese primer viaje de ida y vuelta ocurrió en claro, y esa es exactamente la ventana que busca un atacante que practique SSL stripping en la misma red. Intercepta la petición HTTP, mantiene a la víctima en HTTP mientras hace de proxy en HTTPS hacia su servidor, y lee o reescribe todo.

HSTS elimina esa ventana para cualquiera que haya visitado el sitio antes. web.dev es directo sobre el mecanismo: “use Strict Transport Security to tell clients they should always connect to your server using HTTPS, even when following an http:// reference. This defeats attacks like SSL Stripping, and avoids the round-trip cost of the 301 redirect.” (traducción) «utilice Strict Transport Security para indicar a los clientes que siempre deben conectarse a su servidor mediante HTTPS, incluso al seguir una referencia http://. Esto neutraliza ataques como el SSL Stripping y evita el costo del viaje de ida y vuelta de la redirección 301.» (web.dev). Esa última cláusula también importa para el rendimiento: un navegador que vuelve se salta por completo el viaje de ida y vuelta HTTP→HTTPS. Evidence for this claim After receiving HSTS, a browser upgrades future HTTP attempts to HTTPS before sending the request. Scope: MDN documents user-agent enforcement after the header has been learned; first-visit protection requires preload or a prior secure visit. Confidence: high · Verified: 2026-07-14 MDN: Strict-Transport-Security header

Dos condiciones límite que conviene precisar. Primero, HSTS es una política almacenada y por cliente: vive en el estado propio de ese navegador concreto para ese host, aprendida de una cabecera entregada por una conexión segura; la misma cabecera enviada en una respuesta HTTP se ignora directamente (un atacante capaz de inyectar o eliminar cabeceras en HTTP sin cifrar podría, de otro modo, neutralizarla), y un cliente que nunca la ha recibido —una instalación nueva, otro navegador, un rastreador— no tiene ninguna política que aplicar. Segundo, la reescritura tiene en cuenta el esquema y el puerto: una petición con puerto 80 implícito pasa a ser una petición con puerto 443 implícito, pero si el URI original nombraba un puerto explícito no predeterminado, el navegador conserva ese mismo número de puerto y simplemente lo contacta por HTTPS.

La sintaxis de la cabecera

HSTS es una única cabecera de respuesta con hasta tres directivas. Según MDN, las formas son:

Strict-Transport-Security: max-age=31536000
Strict-Transport-Security: max-age=31536000; includeSubDomains
Strict-Transport-Security: max-age=63072000; includeSubDomains; preload

• max-age=<seconds> — obligatoria. “The time, in seconds, that the browser should remember that a host is only to be accessed using HTTPS” (traducción) «El tiempo, en segundos, que el navegador debe recordar que solo se puede acceder a un host mediante HTTPS» (MDN). 31536000 es un año; 63072000, dos. El contador se reinicia con cada respuesta que lleve la cabecera, de modo que un sitio activo renueva su política de forma continua. Se trata de un estado relativo y por cliente: eliminar la cabecera sin más no la borra de inmediato; un navegador que ya aprendió la política sigue aplicándola hasta que se agota el max-age almacenado. Para desactivar HSTS en los clientes que ya la aprendieron, hay que servir activamente max-age=0 en una respuesta segura; el navegador olvidará entonces la política en su siguiente visita segura. (max-age=0 borra únicamente una política aprendida: no elimina un dominio de la lista preload, que es aparte.)
• includeSubDomains — opcional. “If this directive is specified, the HSTS policy applies to all subdomains of the host’s domain as well” (traducción) «Si se especifica esta directiva, la política HSTS se aplica también a todos los subdominios del dominio del host» (MDN). Potente y peligrosa a partes iguales: vea los escenarios de bloqueo más abajo.
• preload — opcional. Un indicador que señala su intención de estar en la lista preload del navegador. Por sí solo no hace nada; es un requisito previo para enviar la solicitud a hstspreload.org. Evidence for this claim HSTS preload requires at least a one-year max-age, includeSubDomains, and preload; removal can take months to reach users. Scope: The Chromium preload service documents submission and removal behavior; requirements can change and should be rechecked before submission. Confidence: high · Verified: 2026-07-17 Chromium: HSTS Preload List Submission

El comportamiento, de nuevo según MDN: “Before loading an http URL, the browser checks the domain name against its HSTS hosts list. If the domain name is a case insensitive match for an HSTS host or is a subdomain of one that specified includeSubDomains, then the browser replaces the URL scheme with https.” (traducción) «Antes de cargar una URL http, el navegador coteja el nombre de dominio con su lista de hosts HSTS. Si el nombre de dominio coincide, sin distinguir mayúsculas y minúsculas, con un host HSTS o es un subdominio de uno que especificó includeSubDomains, el navegador sustituye el esquema de la URL por https.»

La actualización interna que los rastreadores nunca ven (aquí está el meollo para el SEO)

Esto es lo que peor se entiende de HSTS, y la razón por la que no puede sustituir a sus redirecciones.

Cuando un navegador actualiza una petición http:// bajo HSTS, reescribe el URI a HTTPS internamente, antes de realizar ninguna petición de red: el RFC 6797 exige la sustitución del esquema en sí, pero no obliga a un código de estado concreto para ella (RFC 6797 §8.3), de modo que un navegador o una herramienta de rastreo pueden representar ese paso interno como prefieran; muchos lo muestran como un 307 interno, pero eso es específico del cliente o la herramienta, no una garantía del protocolo. Lo que importa para el SEO es más simple y se cumple con independencia de la etiqueta: no se contacta con ningún servidor para la versión HTTP, así que ningún rastreador llega a verla. Googlebot y Bingbot no llevan consigo una política HSTS aprendida como sí hace el Chrome de un humano que vuelve: acceden a su servidor en frío, y lo que necesitan encontrar allí es una 301 real del lado del servidor. Evidence for this claim RFC 6797 requires the user agent to rewrite a known-HSTS-host HTTP URI to HTTPS internally, but does not mandate any specific redirect status code for that internal rewrite; how a given browser or crawling tool represents that step (e.g., as an internal 307) is a client/tool implementation detail, not a protocol requirement. Scope: RFC 6797 Section 8.3 ("URI Loading and Port Mapping") specifies the UA MUST replace the URI scheme with https; it does not prescribe an HTTP status code for that internal substitution, since no HTTP exchange occurs for it. Section 7.2's suggestion of status code 301 addresses ordinary server-side redirect behavior, not this internal client-side rewrite. Confidence: high · Verified: 2026-07-17 RFC 6797 §8.3 — URI Loading and Port Mapping

Así que la regla es tajante: HSTS no sustituye a sus 301 del lado del servidor. La 301 es lo que los motores de búsqueda usan para entender el cambio de protocolo y para consolidar señales (“301 and other permanent redirects don’t cause a loss in PageRank” (traducción) «las redirecciones 301 y otras redirecciones permanentes no provocan una pérdida de PageRank», según Google). La actualización interna que solo ocurre en el navegador es una capa de experiencia de usuario y seguridad por encima. Necesita ambas, haciendo trabajos distintos:

• 301 (del lado del servidor): para rastreadores, indexación y link equity.
• Actualización interna de estilo 307 (del lado del navegador, por HSTS): para humanos que vuelven y para la protección frente al SSL stripping; la representación exacta del estado varía según el cliente o la herramienta.

Cualquier guía que le diga que HSTS «se encarga de la redirección, así que puede eliminar su 301» está equivocada de una forma que le saldrá cara sin que se dé cuenta.

HSTS preload: la versión casi permanente

max-age protege a los visitantes que vuelven, pero tiene un problema de arranque: un visitante que llega por primera vez y nunca ha recibido su cabecera sigue expuesto en esa petición inicial. Preload lo resuelve codificando su dominio en el propio código fuente del navegador, de modo que el navegador sabe que usted es solo HTTPS antes incluso de haberse conectado nunca.

Puede darse de alta en hstspreload.org. Los requisitos son exactos:

1. “Serve a valid certificate.” (traducción) «Sirva un certificado válido.»
2. “Redirect from HTTP to HTTPS on the same host, if you are listening on port 80.” (traducción) «Redirija de HTTP a HTTPS en el mismo host, si está escuchando en el puerto 80.»
3. “Serve all subdomains over HTTPS” (traducción) «Sirva todos los subdominios por HTTPS», incluido en particular el subdominio www si existe un registro DNS.
4. En la respuesta HTTPS del dominio base, una cabecera HSTS donde “the max-age must be at least 31536000 seconds (1 year),” (traducción) «el max-age debe ser de al menos 31536000 segundos (1 año)», “the includeSubDomains directive must be specified,” (traducción) «debe especificarse la directiva includeSubDomains» y “the preload directive must be specified.” (traducción) «debe especificarse la directiva preload». (hstspreload.org)

Por eso el ejemplo de dos años de más arriba (max-age=63072000; includeSubDomains; preload) es la forma que la gente envía. Tenga en cuenta que estos son los requisitos exactos de envío tal y como los publica hstspreload.org: trátelos como el listón actual, no como una constante permanente, y vuelva a consultar la página en vivo antes de enviar su solicitud.

Conviene tener claros cuatro estados distintos, porque se confunden constantemente:

La eliminación recorre los mismos cuatro estados a la inversa, y con la misma lentitud: quitar la directiva preload de su cabecera le hace elegible para el formulario de eliminación, después el envío queda pendiente, y el dominio sigue aplicándose para cualquier usuario con una compilación del navegador que todavía lo incluya, hasta que esa compilación quede fuera de circulación.

Ahora, la parte que convierte preload en una puerta de un solo sentido. Del propio sitio de envío: “Be aware that inclusion in the preload list cannot easily be undone. Domains can be removed, but it takes months for a change to reach users with a Chrome update and we cannot make guarantees about other browsers.” (traducción) «Tenga en cuenta que la inclusión en la lista preload no se puede deshacer con facilidad. Los dominios se pueden eliminar, pero un cambio tarda meses en llegar a los usuarios con una actualización de Chrome y no podemos ofrecer garantías respecto a otros navegadores.» (hstspreload.org). Y su propio consejo: “Don’t request inclusion unless you’re sure that you can support HTTPS for your entire site and all its subdomains in the long term.” (traducción) «No solicite la inclusión a menos que esté seguro de que puede mantener HTTPS en todo su sitio y en todos sus subdominios a largo plazo.»

Traducción práctica: preload es una postura de seguridad realmente excelente, pero si alguna vez necesita servir cualquier cosa —un subdominio heredado, una marca adquirida, una herramienta interna— por HTTP sin cifrar de nuevo, se quedará esperando a que los ciclos de publicación de los navegadores lleguen a todos los usuarios. La guía de Kinsta expone la realidad operativa sin rodeos: puede ser un proceso difícil y lento conseguir que se elimine su dominio. Trate preload como algo permanente.

Por qué HSTS está diseñado para doler cuando algo se rompe

La rigidez de HSTS no es un fallo: es toda su garantía de seguridad. web.dev explica la contrapartida: “Clients that have listed your site as a known HSTS Host are likely to hard-fail if your site ever has an error in its TLS configuration, (such as an expired certificate). HSTS is explicitly designed this way to ensure that network attackers can’t trick clients into accessing the site without HTTPS.” (traducción) «Es probable que los clientes que han registrado su sitio como un host HSTS conocido fallen en duro si su sitio llega a tener un error en su configuración TLS (como un certificado caducado). HSTS está diseñado explícitamente así para garantizar que los atacantes de red no puedan engañar a los clientes para que accedan al sitio sin HTTPS.» (web.dev).

La conclusión que saca Google es la frase que le tatuaría a cualquiera que esté a punto de activar esto: “Don’t enable HSTS until you’re certain your site operation is robust enough to avoid ever deploying HTTPS with certificate validation errors.” (traducción) «No active HSTS hasta que esté seguro de que la operación de su sitio es lo bastante robusta como para no desplegar nunca HTTPS con errores de validación del certificado.» (web.dev).

«Fallar en duro» significa exactamente eso: ningún enlace de «continuar de todos modos», ningún clic para saltárselo. En una página HTTPS normal, un certificado caducado muestra un intersticial alarmante que un usuario decidido puede esquivar. En un host HSTS, el navegador se niega en redondo. Así que el modo de fallo de una renovación de certificado olvidada cambia de categoría: pasa de «el tráfico baja porque la gente se asusta» a «el sitio es inaccesible para todos los visitantes que ya habían estado antes».

Escenarios reales de bloqueo

Las formas en que HSTS muerde en la práctica casi siempre se remontan a que includeSubDomains o preload se adelantan a su cobertura real de HTTPS:

• El subdominio olvidado. Activa includeSubDomains en example.com, pero legacy.example.com (una aplicación antigua, una página de estado, una herramienta de un proveedor) solo habla HTTP o tiene un certificado que no lo cubre. Todos los navegadores que vieron la cabecera se niegan ahora a cargar ese subdominio. En ese servidor no cambió nada: la política se extendió hacia abajo y lo rompió.
• El hueco del certificado comodín. Un comodín *.example.com cubre foo.example.com pero no foo.bar.example.com (un comodín cubre una sola etiqueta DNS de profundidad). Si un subdominio más profundo depende de HTTP o de un certificado que no coincide, includeSubDomains lo deja bloqueado.
• El certificado caducado en un host HSTS. La automatización de la renovación falla, el certificado vence y, en lugar de un aviso que se puede esquivar, tiene un sitio caído para todos aquellos cuyo navegador recuerde su política, hasta que recupere un certificado válido y se reconecten y reciban una respuesta segura nueva. No hay forma más rápida de anularlo.
• El arrepentimiento por preload. Hizo preload y después una necesidad de negocio obliga a poner un servicio solo por HTTP bajo el dominio. Revertirlo son dos trabajos distintos y nada instantáneos, no uno: servir max-age=0 por HTTPS solo borra la política aprendida en los clientes que se reconecten antes de que su antiguo max-age hubiera expirado de todos modos, mientras que sacar el dominio de la lista preload es un envío aparte que aun así tarda ciclos de publicación de los navegadores —meses— en llegar a los usuarios, con independencia de lo que cambie en su servidor.
• Colisiones con desarrollo local y staging. Hacer preload de example.com con includeSubDomains puede hacer que dev.example.com o un host interno de tipo localhost bajo el mismo apex rechacen HTTP, rompiendo flujos de trabajo locales de formas sorprendentes.

Nada de esto es motivo para evitar HSTS. Son motivos para desplegarlo por fases: primero un max-age corto, añadir includeSubDomains solo después de auditar todos los subdominios y reservar preload para cuando esté seguro.

HSTS no es una jugada de posicionamiento (y no decide la URL principal)

Para ser claros sobre el encuadre SEO: HSTS no es un factor de posicionamiento. HTTPS en sí mismo es uno deliberadamente diminuto —Google lo llamó una “very lightweight signal” (traducción) «señal muy ligera» que afecta a menos del 1 % de las consultas— y HSTS es una capa sobre HTTPS, no una entrada de posicionamiento aparte. Tampoco decide directamente la URL principal ni la indexación. Sin embargo, la propia documentación de Google es más específica que un simple «no importa»: Google prefiere HTTPS como URL principal frente a una página HTTP equivalente excepto cuando hay un certificado no válido, dependencias inseguras en la página, una página HTTPS que redirige a HTTP o una etiqueta rel="canonical" en HTTP (Google: consolidating duplicate URLs). HSTS no puede arreglar ni anular nada de eso. Es una política del lado del navegador sin ninguna influencia en la elección de Google: un certificado defectuoso o una cadena de redirecciones rota todavía pueden empujar a Google hacia una URL principal en HTTP, diga lo que diga su cabecera HSTS. Esa elección la impulsan sus redirecciones, su certificado, su rel="canonical" y sus enlaces internos. HSTS se gana su sitio por seguridad, confianza del usuario y por cerrar la brecha del SSL stripping: hágalo por esas razones, mantenga sus redirecciones y su certificado realmente sólidos, y de todos modos nunca verá HSTS en un informe de posiciones.

Si está haciendo el cambio general de HTTP→HTTPS, HSTS es lo último que activa, no lo primero: le corresponde después de que la migración se haya asentado, como parte de la disciplina más amplia de la migración web.

Resumen de IA

Una versión condensada de la pestaña Advanced:

• HSTS = la cabecera de respuesta Strict-Transport-Security. Indica a los navegadores que usen siempre HTTPS para su dominio, cerrando el «problema de la primera petición» que una 301 por sí sola deja abierto: la petición HTTP inicial de un visitante nuevo es insegura hasta que se dispara la redirección, que es la ventana del SSL stripping.
• Tres directivas: max-age (obligatoria, en segundos; se reinicia con cada respuesta; eliminar la cabecera no borra una política ya aprendida: en su lugar hay que servir max-age=0 por HTTPS), includeSubDomains (se aplica a todos los subdominios) y preload (un indicador para darse de alta en la lista preload del navegador; token presente, elegible, enviado y realmente listado son cuatro estados distintos).
• El meollo de la actualización interna: cuando un navegador aplica HSTS, reescribe el URI a HTTPS internamente antes de que ninguna petición llegue a un servidor —el RFC 6797 no obliga a un código de estado concreto para esa reescritura, aunque las herramientas suelen mostrarla como un 307—, de modo que ningún servidor la ve y los rastreadores nunca la ven. Sus 301 del lado del servidor siguen siendo obligatorias para los motores de búsqueda y para el link equity. HSTS se suma a sus 301, nunca las sustituye.
• Preload codifica su dominio en el navegador a través de hstspreload.org (requiere max-age ≥ 31536000, includeSubDomains y preload). Es casi irreversible: la eliminación es un envío aparte que tarda meses en llegar a los usuarios, navegador por navegador.
• Diseñado para fallar en duro: un host HSTS con un certificado roto o caducado se niega a cargar, sin posibilidad de continuar con un clic. Google: “Don’t enable HSTS until you’re certain your site operation is robust enough to avoid ever deploying HTTPS with certificate validation errors.” (traducción) «No active HSTS hasta que esté seguro de que la operación de su sitio es lo bastante robusta como para no desplegar nunca HTTPS con errores de validación del certificado.»
• Los escenarios de bloqueo se agrupan en torno a includeSubDomains y preload adelantándose a su cobertura de HTTPS: subdominios HTTP olvidados, huecos de profundidad de los certificados comodín, certificados vencidos, arrepentimiento por preload y colisiones con staging.
• No es un factor de posicionamiento ni puede anular la elección de URL principal. Google prefiere HTTPS excepto cuando un certificado no es válido, las dependencias son inseguras, una página HTTPS redirige a HTTP o la etiqueta principal apunta a HTTP, y HSTS no tiene poder para arreglar ni anular nada de eso. Deje que sus redirecciones, su certificado y sus etiquetas principales hagan el trabajo de SEO.

Documentación oficial

Documentación de fuente primaria de los equipos de navegadores y de estándares.

Google / web.dev

• Activar HTTPS en tus servidores (web.dev) — la sección sobre HSTS: la cabecera, el SSL stripping, la advertencia sobre el fallo en duro y el «no active HSTS hasta que esté seguro».
• Migraciones de sitio con cambios de URL — por qué la 301 del lado del servidor sigue siendo obligatoria (las redirecciones no pierden PageRank).
• Comprender la experiencia de página — dónde encaja HTTPS (y por extensión HSTS) en el encuadre de Google.

Estándares y referencias de navegadores

• MDN — Strict-Transport-Security — sintaxis completa de la cabecera, las tres directivas y cómo el navegador actualiza el esquema.
• RFC 6797 — HTTP Strict Transport Security (HSTS) — la especificación original.
• HSTS Preload List submission (hstspreload.org) — los requisitos exactos de preload y las advertencias sobre la eliminación, mantenidos por el proyecto Chromium.

Citas de la fuente

Declaraciones oficiales de Google/web.dev y del servicio de preload de Chromium. Cada enlace salta al pasaje citado en la página de origen (o apunta a él).

web.dev (Google) — qué hace HSTS y las advertencias

• “Use HTTP Strict Transport Security (HSTS) to avoid the cost of the 301 redirect.” (traducción) «Utilice HTTP Strict Transport Security (HSTS) para evitar el costo de la redirección 301.» Ir a la cita
• “First, use Strict Transport Security to tell clients they should always connect to your server using HTTPS, even when following an http:// reference. This defeats attacks like SSL Stripping, and avoids the round-trip cost of the 301 redirect.” (traducción) «En primer lugar, utilice Strict Transport Security para indicar a los clientes que siempre deben conectarse a su servidor mediante HTTPS, incluso al seguir una referencia http://. Esto neutraliza ataques como el SSL Stripping y evita el costo del viaje de ida y vuelta de la redirección 301.» Ir a la cita
• “Clients that have listed your site as a known HSTS Host are likely to hard-fail if your site ever has an error in its TLS configuration, (such as an expired certificate). HSTS is explicitly designed this way to ensure that network attackers can’t trick clients into accessing the site without HTTPS.” (traducción) «Los clientes que hayan registrado el sitio como host HSTS probablemente fallen de forma definitiva si aparece un error en la configuración TLS, como un certificado caducado. HSTS funciona así expresamente para impedir que un atacante de red engañe al cliente y lo haga acceder sin HTTPS.» Ir a la cita
• “Don’t enable HSTS until you’re certain your site operation is robust enough to avoid ever deploying HTTPS with certificate validation errors.” (traducción) «No active HSTS hasta que esté seguro de que la operación de su sitio es lo bastante robusta como para no desplegar nunca HTTPS con errores de validación del certificado.» Ir a la cita

Servicio de preload de Chromium — hstspreload.org

• “Be aware that inclusion in the preload list cannot easily be undone. Domains can be removed, but it takes months for a change to reach users with a Chrome update and we cannot make guarantees about other browsers.” (traducción) «La inclusión en la lista preload no se revierte fácilmente. Aunque un dominio puede retirarse, el cambio tarda meses en llegar a los usuarios mediante una actualización de Chrome y no existe garantía para otros navegadores.» Fuente
• “Don’t request inclusion unless you’re sure that you can support HTTPS for your entire site and all its subdomains in the long term.” (traducción) «No solicite la inclusión a menos que esté seguro de que puede mantener HTTPS en todo su sitio y en todos sus subdominios a largo plazo.» Fuente

MDN — el comportamiento de la cabecera

• “Before loading an http URL, the browser checks the domain name against its HSTS hosts list. If the domain name is a case insensitive match for an HSTS host or is a subdomain of one that specified includeSubDomains, then the browser replaces the URL scheme with https.” (traducción) «Antes de abrir una URL http, el navegador compara el dominio con su lista de hosts HSTS. Si coincide sin distinguir mayúsculas de minúsculas, o es subdominio de un host que declaró includeSubDomains, cambia el esquema de la URL a https.» Fuente

¿Debería activar HSTS y hasta dónde?

Recórralo de arriba abajo. Cada «no» es una señal de stop, no un quizá. Una distinción antes de empezar: las cifras exactas de max-age que aparecen a continuación (unos minutos para una prueba canaria, un año para un estado de reposo) son las recomendaciones operativas de despliegue por fases de Patrick, no requisitos del protocolo; el único requisito numérico estricto es el mínimo de preload de hstspreload.org (max-age ≥ 31536000), que se indica explícitamente en ese paso. Ajuste las duraciones de las fases a su propia tolerancia al riesgo y a su cadencia de despliegue.

1. ¿Está ya todo su sitio en HTTPS con un certificado válido y se ha asentado la migración?

• No → No toque HSTS todavía. Termine primero la migración a HTTPS: redirija con 301 todas las URL, corrija el contenido mixto, verifique en Search Console. HSTS es el último interruptor, no el primero.
• Sí → continúe.

2. ¿La renovación de su certificado está automatizada y monitorizada (para que un vencimiento no le pille por sorpresa)?

• No → Arréglelo primero. En un host HSTS, un certificado vencido es una caída total, no un aviso. Ponga en marcha la renovación automática y las alertas de vencimiento, y después continúe.
• Sí → continúe. Active un max-age corto (por ejemplo, de unos minutos a un día) sin includeSubDomains todavía, y confirme que nada se rompe.

3. ¿Ha auditado todos los subdominios —incluidos www, aplicaciones heredadas, páginas de estado y hosts de proveedores— y ha confirmado que cada uno sirve HTTPS válido?

• No → Mantenga includeSubDomains desactivado. Añadirlo ahora se extendería hacia abajo y rompería cualquier subdominio que solo funcione por HTTP o con un certificado que no coincida.
• Sí → Suba max-age hasta un año y añada includeSubDomains. Este es un estado de reposo seguro y sólido para la mayoría de los sitios.

4. ¿Quiere cerrar también la brecha de la primerísima visita y está seguro de que nunca necesitará servir nada bajo este dominio por HTTP sin cifrar otra vez?

• No / no estoy seguro → Pare aquí. max-age=31536000; includeSubDomains (sin preload) es una postura excelente. La ganancia marginal de preload no compensa su irreversibilidad si no lo tiene claro.
• Sí, seguro → Añada el indicador preload y envíe la solicitud en hstspreload.org. Trátelo como permanente: la eliminación tarda meses en llegar a los usuarios.

Rama aparte, siempre cierta: ¿activar HSTS significa que puedo eliminar mis 301?

• Nunca. Los rastreadores no ven la actualización interna de HSTS, que solo ocurre en el navegador. Mantenga sus 301 del lado del servidor sin importar hasta dónde llegue en este árbol.

Lista de comprobación para desplegar HSTS

Trabaje de arriba abajo: cada etapa condiciona la siguiente. Las duraciones por fases que aparecen aquí son recomendaciones operativas, no requisitos del protocolo; la única cifra estricta es el mínimo de max-age ≥ 31536000 para preload de la etapa 3.

Antes de activar nada

• Todo el sitio (apex + www + todos los subdominios) sirve HTTPS con un certificado válido.
• Las redirecciones 301 de HTTP→HTTPS están en su sitio, del lado del servidor y una a una.
• La renovación automática del certificado está configurada y existe monitorización o alertas de vencimiento.
• La migración de HTTP→HTTPS se ha asentado (Search Console limpio, sin caída libre de posiciones).

Etapa 1: demostrar que es seguro

• Añada Strict-Transport-Security con un max-age corto (de minutos a un día).
• Sin includeSubDomains todavía. Sin preload todavía.
• Confirme que el sitio carga con normalidad en distintos navegadores y que no se rompió nada.

Etapa 2: comprometerse

• Suba max-age al menos a 31536000 (un año).
• Audite todos los subdominios (incl. www, heredados, de estado, de proveedores) en busca de HTTPS válido.
• Solo después de que esa auditoría pase, añada includeSubDomains.
• Vuelva a comprobar que cada subdominio carga por HTTPS.

Etapa 3: preload (opcional, casi permanente)

• Está seguro de que nunca volverá a necesitar HTTP bajo este dominio.
• La cabecera es max-age=31536000 (o más) ; includeSubDomains; preload.
• HTTP en el puerto 80 redirige a HTTPS en el mismo host.
• Envíe la solicitud y confirme el estado en hstspreload.org.

Siempre cierto: no se lo salte

• Las 301 del lado del servidor se mantienen (los rastreadores nunca ven la actualización interna que solo ocurre en el navegador).
• Tiene un plan de reversión documentado: max-age=0 servido por HTTPS borra una política aprendida (sin preload) en los clientes que se reconecten antes de que hubiera expirado de todos modos. Los dominios con preload necesitan en su lugar el proceso aparte y más lento del formulario de eliminación.

Los modelos mentales

1. HSTS es una capa, no un sustituto. 301 del lado del servidor = para rastreadores y link equity. Actualización interna del lado del navegador (por HSTS, a menudo mostrada como un 307 aunque el RFC no exija ese código exacto) = para humanos que vuelven y para la protección frente al SSL stripping. Públicos distintos, trabajos distintos. Siempre necesita ambos; HSTS nunca resta una 301.

2. HSTS cierra una brecha que la 301 no puede. Una 301 protege desde la segunda petición en adelante. La primera —antes de que se dispare la redirección— sigue siendo HTTP. HSTS (para visitantes que vuelven) y preload (para quienes llegan por primera vez) son lo único que cierra esa ventana concreta.

3. Suba por trinquete, nunca de un salto. max-age corto → largo. Cabecera simple → includeSubDomains (tras auditar los subdominios) → preload (solo si está seguro). Todos los peldaños son reversibles salvo el último. No se salte peldaños por ahorrar tiempo.

4. La rigidez es la característica, y corta por los dos lados. El mismo fallo en duro que detiene a un atacante le detiene también a usted cuando se rompe un certificado. Así que el requisito previo no es «¿quiere seguridad?» —todo el mundo la quiere—, sino «¿es su operación de certificados lo bastante robusta como para no fallar nunca?».

5. Preload es una puerta de un solo sentido. Un HSTS sin preload se puede relajar en un cliente la próxima vez que haga una petición segura y reciba max-age=0: no más rápido que eso, y solo para los clientes que se reconecten. Preload va un paso más allá: la eliminación es un envío aparte que tarda meses en llegar a los usuarios, versión de navegador tras versión de navegador. Métalo en el cajón de las «decisiones que no podemos deshacer con facilidad» y trátelo en consecuencia.

6. HSTS es ortogonal a los rankings, pero tampoco puede rescatar una mala elección de URL principal. No es un factor de posicionamiento y no controla directamente la elección de URL ni la indexación. Júzguelo por seguridad y confianza, no por su beneficio en SEO: no hay ninguno. Pero tampoco es una red de seguridad: la preferencia de Google por HTTPS sigue cediendo ante un certificado defectuoso, dependencias inseguras, una redirección HTTPS→HTTP o una etiqueta principal en HTTP, y HSTS no tiene poder para anular eso.

HSTS — hoja de referencia rápida

Las directivas de la cabecera

Valores habituales de la cabecera (las cifras de despliegue por fases que siguen son sugerencias operativas, no requisitos del protocolo; el mínimo estricto es el de la fila de preload)

Redirecciones: cuál es cuál y quién la ve

Datos rápidos

• Preload requiere max-age ≥ 31536000 + includeSubDomains + preload, verificado contra los requisitos publicados actualmente por hstspreload.org.
• La eliminación de preload es un envío aparte que tarda meses en llegar a los usuarios, navegador por navegador: trátelo como permanente.
• En un host HSTS, un certificado roto = fallo en duro, sin posibilidad de continuar con un clic.
• HSTS no es un factor de posicionamiento y no sustituye a sus 301.

Configurar la cabecera HSTS

Añada la cabecera únicamente en el bloque de servidor HTTPS, y empiece con un max-age corto hasta que haya confirmado que nada se rompe. Añada ; preload solo cuando tenga intención de enviar la solicitud a hstspreload.org: es casi irreversible.

Apache (.htaccess)

<IfModule mod_headers.c>
  # Start short (300s) to prove it's safe; raise to 31536000 once confident.
  Header always set Strict-Transport-Security "max-age=300"
  # Full posture once every subdomain is verified HTTPS:
  # Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"
  # Only add ; preload when submitting to hstspreload.org:
  # Header always set Strict-Transport-Security "max-age=63072000; includeSubDomains; preload"
</IfModule>

Nginx

# On the HTTPS (listen 443) server block:
add_header Strict-Transport-Security "max-age=300" always;
# Full posture once subdomains are verified:
# add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
# Preload shape (near-irreversible):
# add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" always;

Comprobar si HSTS está configurado (y leer su valor)

macOS / Linux

# Print only the Strict-Transport-Security response header
curl -sI https://example.com/ | grep -i strict-transport-security
# → strict-transport-security: max-age=31536000; includeSubDomains

Windows (PowerShell)

# Same check in PowerShell
(Invoke-WebRequest -Uri "https://example.com/" -Method Head).Headers["Strict-Transport-Security"]

Inspeccionar y borrar una entrada HSTS en Chrome (DevTools / net-internals)

Si está haciendo pruebas y un navegador ha «aprendido» una política HSTS que necesita borrar:

1. Open a new tab and visit:  chrome://net-internals/#hsts
2. Under "Query HSTS/PKP domain", enter your host to see the stored policy.
3. Under "Delete domain security policies", enter the host and Delete.
   (This clears the *learned* policy — it does NOT remove a *preloaded* domain,
   which lives in the browser binary and can't be cleared this way.)

Úselo para confirmar que su cabecera se está almacenando realmente y para restablecer un host de pruebas, no como arreglo en producción, donde la solución es servir activamente max-age=0 por HTTPS (eliminar la cabecera sin más no borra una política que un cliente ya aprendió; solo surte efecto cuando ese cliente se reconecta y recibe la respuesta con max-age=0).

Errores de HSTS que muerden

1. Eliminar sus redirecciones permanentes porque «ya se encarga HSTS». El clásico. La redirección de HSTS es una actualización interna que solo ocurre en el navegador y que los rastreadores nunca ven. Si elimina esas redirecciones del lado del servidor, los motores de búsqueda pierden la señal que consolida su cambio. Mantenga ambas, siempre.

2. Activar includeSubDomains antes de auditar los subdominios. La forma más habitual de dejar un subdominio fuera de servicio. Si algún subdominio —una aplicación heredada, una página de estado, un host de un proveedor, el propio www— no está en HTTPS válido, la política se extiende hacia abajo y lo rompe para todos los navegadores que vieron la cabecera.

3. Saltar directamente a un max-age de un año (o a preload) el primer día. Sin red de seguridad. Empiece corto (max-age=300), confirme que nada se rompe y después suba por trinquete. Un max-age largo configurado en un sitio mal configurado es una caída autoinfligida que permanece en los navegadores durante un año.

4. Hacer preload antes de que HTTPS sea realmente a prueba de balas. Preload es casi irreversible: la eliminación tarda meses. La propia frase de Google: no actives HSTS hasta tener la certeza de que el funcionamiento del sitio es suficientemente robusto — (traducción) «no active HSTS hasta que esté seguro de que la operación de su sitio es lo bastante robusta». Preload multiplica lo que está en juego.

5. Tratar un certificado vencido como un problema menor. En un sitio sin HSTS, un certificado caducado es un aviso que se puede esquivar. En un host HSTS es una caída total sin posibilidad de continuar con un clic. Si activa HSTS, la automatización de la renovación de certificados y las alertas de vencimiento dejan de ser algo deseable.

6. Poner la cabecera en la respuesta HTTP. Los navegadores ignoran HSTS entregado por HTTP (por diseño: un atacante podría inyectarlo o eliminarlo). Debe enviarse en la respuesta HTTPS para que cuente.

7. Olvidar el límite de profundidad de los certificados comodín. Un comodín *.example.com no cubre foo.bar.example.com. Active includeSubDomains y cualquier subdominio más profundo que dependa de ese certificado quedará bloqueado.

Manual de incidentes: un host HSTS queda bloqueado

1. Confirme el fallo desde una red limpia y en más de un navegador. Registre los nombres de host afectados y el error exacto del certificado. Una política HSTS recordada puede hacer que el síntoma difiera entre visitantes que vuelven y visitantes que llegan por primera vez.
2. Restablezca primero un HTTPS válido. Si el certificado está caducado, no coincide o le falta un intermedio, renuévelo o sustitúyalo y despliegue la cadena completa. Un navegador con HSTS no ofrecerá una vía segura de escape por HTTP.
3. Delimite el alcance de la política. Inspeccione la cabecera Strict-Transport-Security en vivo y determine si includeSubDomains o preload extienden la caída más allá del nombre de host que la envió.
4. Inventaríe todos los subdominios afectados. Para un host olvidado que solo funcione por HTTP, ponga delante un certificado válido y un endpoint HTTPS antes de decidir si conservar, migrar o redirigir el servicio.
5. Corrija la política solo después de restablecer el acceso. Si el alcance no es seguro, reduzca o elimine la cabecera en las respuestas HTTPS. Eso no borra al instante una política ya almacenada en caché por los navegadores, y la eliminación de preload es un proceso aparte y lento.
6. Verifique la recuperación. Compruebe en el apex, en www y en cada subdominio afectado que hay una cadena válida, el nombre de host correcto, una redirección HTTP→HTTPS de un solo salto y la cabecera HSTS prevista. Mantenga la monitorización de vencimiento de certificados sobre ese mismo inventario.

No desmonte la redirección de HTTP ni diga a los usuarios que se salten el aviso. El arreglo duradero es un endpoint HTTPS válido en todos los lugares a los que llegue la política HSTS activa.

Auditar una política HSTS en vivo

Act as a security-minded technical SEO. Review this Strict-Transport-Security
header, the HTTP redirect response, and the supplied subdomain inventory.

For the header, parse max-age, includeSubDomains, and preload. Explain the effective
scope, identify subdomains whose HTTPS or certificate coverage is unproven, and
separate browser-side HSTS behavior from the server-side 301 search engines need. Use
GET requests (HEAD can behave differently on some servers/clients), and record which
client or tool produced each observation and its version, since internal-redirect
representation is client/tool-specific rather than a fixed protocol value.

Recommend the next rollout stage: keep a short max-age canary, lengthen max-age,
add includeSubDomains, or consider preload. Do not recommend preload unless the
evidence shows a valid certificate, same-host HTTP→HTTPS redirects, HTTPS on every
subdomain, max-age of at least 31536000, includeSubDomains, and the preload token.

Return: observed configuration, risks, blocking evidence, next action, rollback
constraint, and exact validation checks.

Triaje de un bloqueo por HSTS

Given the affected hostnames, browser error, certificate details, DNS/CDN layout,
and live response headers, identify whether this is an expired certificate, hostname
mismatch, incomplete chain, includeSubDomains spillover, or preload issue. Prioritize
restoring valid HTTPS. Explain why removing a header does not immediately erase a
cached browser policy, then provide recovery and verification steps.

Kit de inspección de HSTS

• HTTP Header Checker — inspeccione la cabecera Strict-Transport-Security en vivo y confirme que aparece en las respuestas HTTPS.
• curl -I — compare la redirección HTTP con la cabecera HTTPS sin depender del estado HSTS que recuerde un navegador.
• DevTools del navegador — confirme las cabeceras de la respuesta final y el error de certificado que ve un cliente real.
• Estado de preload de HSTS — consulte los requisitos de envío y si el dominio ya está representado en el proceso de preload.

Use al menos dos perspectivas: la salida de línea de comandos muestra la respuesta del servidor, mientras que un navegador expone además la aplicación del lado del cliente y los fallos en duro por certificado. Prefiera GET sobre HEAD al comparar herramientas —algunos servidores y clientes representan ambos métodos de forma distinta— y anote el cliente, la herramienta y la versión exactos detrás de cada lectura.

Pruebas para un despliegue de HSTS por fases

Prueba 0: la matriz de estados (ejecútela antes de cambiar de fase)

El estado de HSTS no es un único hecho: son varios estados independientes que pueden contradecirse. Sígalos por separado, por nombre de host:

Registre el cliente, la herramienta y la versión de cada observación: la representación de la redirección interna y los detalles de aplicación de HSTS varían entre navegadores, rastreadores y herramientas de línea de comandos, y una lectura desactualizada de un cliente puede parecer una contradicción que en realidad no existe.

Prueba 1: prueba canaria con un max-age corto

• Objetivo: Demostrar que la cabecera se emite únicamente desde respuestas HTTPS sanas antes de comprometer a los clientes a una política larga.
• Método: Inspeccione plantillas y hosts representativos con el HTTP Header Checker y curl -I; compare el valor desplegado con la configuración canaria aprobada.
• Resultado esperado: Las respuestas HTTPS llevan el max-age corto previsto; HTTP sigue devolviendo una redirección permanente del lado del servidor hacia HTTPS.
• Disparador de fallo: Cabeceras ausentes o duplicadas, una duración larga inesperada, errores de certificado o cualquier bucle de redirección.
• Siguiente acción: Corrija la cabecera o el endpoint HTTPS y mantenga el despliegue en la fase canaria.

Prueba 2: preparación para includeSubDomains

• Objetivo: Impedir que una política del dominio padre deje bloqueado un nombre de host olvidado.
• Método: Compruebe en todos los nombres de host DNS del inventario de subdominios mantenido que hay una respuesta HTTPS válida, el nombre de certificado correcto y la cadena completa.
• Resultado esperado: Todos los subdominios dentro del alcance funcionan por HTTPS, incluidos los heredados, los de proveedores, los de desarrollo y los de niveles más profundos.
• Disparador de fallo: Cualquier servicio solo por HTTP, certificado caducado o que no coincida, o nombre de host ausente del inventario.
• Siguiente acción: Corrija o reubique el host antes de añadir includeSubDomains.

Prueba 3: preparación para preload

• Objetivo: Verificar que la política casi permanente satisface los requisitos de envío documentados.
• Método: Confirme un certificado válido, redirecciones HTTP→HTTPS en el mismo host, HTTPS en todos los subdominios y una cabecera en el apex con max-age de al menos 31536000, includeSubDomains y preload.
• Resultado esperado: Todos los requisitos pasan y la organización acepta la lenta vía de eliminación.
• Disparador de fallo: Cualquier requisito técnico incumplido o una necesidad sin resolver de un subdominio solo por HTTP.
• Siguiente acción: No envíe la solicitud; permanezca en la política reversible por fases.

Recursos que merecen su tiempo

Mis ponencias

• Más vale prevenir que lamentar con HTTPS — SMX East 2016 (SlideShare) — mi análisis a fondo sobre TLS, los fallos habituales de implementación de HTTPS y las trampas de migración que HSTS cierra y a la vez puede amplificar. (Se aplica el descargo de responsabilidad habitual: es mi interpretación de estos sistemas, y las estadísticas de adopción que contiene son de 2016.)

Mis textos relacionados

• The Beginner’s Guide to Technical SEO — dónde encajan HTTPS y HSTS en el panorama general.

De todo el sector

• Activar HTTPS en tus servidores (web.dev) — la guía de HSTS del propio Google: la cabecera, el SSL stripping y la advertencia sobre el fallo en duro.
• MDN — Strict-Transport-Security — la referencia autorizada de la cabecera: sintaxis, directivas y comportamiento de actualización del esquema.
• Envío a la lista HSTS preload (hstspreload.org) — los requisitos de preload del proyecto Chromium y las advertencias sobre su casi irreversibilidad.
• RFC 6797 — HTTP Strict Transport Security — la especificación original, para cuando necesite la redacción exacta de una directiva.
• HSTS: qué es y cómo usarlo (Kinsta) — una guía práctica de implementación que cubre la redirección interna a nivel de navegador, la lista preload y los riesgos de quedar atrapado.
• Prueba de servidor de SSL Labs (Qualys) — puntúe su configuración TLS y confirme que HSTS se está sirviendo correctamente.

Estadísticas y datos contrastados que merece la pena citar

• Preload requiere max-age ≥ 31536000 (1 año), includeSubDomains y preload. El listón de envío exacto e innegociable para la lista integrada en los navegadores. Fuente
• La eliminación de preload tarda meses en llegar a los usuarios. Del servicio de envío: “inclusion in the preload list cannot easily be undone… it takes months for a change to reach users with a Chrome update.” (traducción) «la inclusión en la lista preload no se puede deshacer con facilidad… un cambio tarda meses en llegar a los usuarios con una actualización de Chrome.» Este es el dato que convierte preload en una puerta de un solo sentido. Fuente
• Los hosts HSTS fallan en duro ante cualquier error de TLS. web.dev: los clientes que conocen su sitio como host HSTS “are likely to hard-fail if your site ever has an error in its TLS configuration.” (traducción) «es probable que fallen en duro si su sitio llega a tener un error en su configuración TLS.» Sin posibilidad de continuar con un clic: un certificado vencido se convierte en una caída. Fuente
• HTTPS en sí mismo es “a very lightweight signal—affecting fewer than 1% of global queries.” (traducción) «una señal muy ligera que afecta a menos del 1 % de las consultas globales.» El encuadre del propio Google, y HSTS es una capa sobre HTTPS, no una entrada de posicionamiento aparte, así que su peso en SEO es efectivamente cero. Ajuste las expectativas en consecuencia. Fuente

Ponga a prueba sus conocimientos: HSTS

Cinco preguntas rápidas sobre HSTS. Elija una respuesta para cada una y después compruébelas.

Registro de cambios