Lingue

HSTS: HTTP Strict Transport Security per la SEO

Cosa fa realmente HSTS, la sintassi dell'header Strict-Transport-Security (max-age, includeSubDomains, preload), il redirect interno solo browser che i crawler non vedono mai, perché non sostituisce i redirect permanenti e come il preload può bloccarti — da Patrick Stox.

Prima pubblicazione: 3 lug 2026 · Ultimo aggiornamento: 22 ago 2026 · Advanced
Lingue
AIScritto daAI v2
1 segnale di evidenza in questa pagina

HSTS (HTTP Strict Transport Security) è un header di risposta Strict-Transport-Security — onorato solo quando arriva su una connessione sicura — che dice al browser di usare sempre HTTPS per il tuo dominio d'ora in poi, chiudendo il gap insicuro che la prima richiesta di un nuovo visitatore fa ancora su HTTP prima che il tuo 301 scatti. È una policy a livello di browser, per singolo client, sopra i tuoi redirect lato server, non un sostituto: RFC 6797 fa riscrivere al browser l'URI in HTTPS internamente prima che qualsiasi richiesta parta (spesso mostrato come un redirect interno stile 307, anche se la RFC non impone un codice di stato specifico), quindi nessun server vede mai la forma HTTP e i crawler hanno ancora bisogno del tuo vero 301 per capire il trasferimento e trasferire l'equity dei link. L'header ha tre direttive — max-age (obbligatoria), includeSubDomains e preload. Il preload incorpora il tuo dominio nel browser stesso tramite hstspreload.org (richiedendo max-age di almeno un anno, includeSubDomains e il flag preload) ed è quasi irreversibile — la rimozione è una richiesta separata che richiede mesi per raggiungere gli utenti. HSTS è anche deliberatamente inflessibile: un browser che ti conosce come host HSTS fallirà duramente senza possibilità di clic se il tuo certificato si rompe. Quindi abilitalo solo quando HTTPS è davvero solido su ogni sottodominio, e tratta il preload come una porta a senso unico.

TL;DR — HSTS è l’header di risposta Strict-Transport-Security, onorato solo quando un browser lo riceve su una connessione sicura, e memorizzato da ciascun client come policy futura per quell’host. Chiude il “problema della prima richiesta” che un 301 da solo lascia aperto: la richiesta HTTP iniziale di un nuovo visitatore è insicura finché il redirect non scatta, ed è quella la finestra che un attaccante SSL-stripping vuole. Tre direttive: max-age (obbligatoria, secondi), includeSubDomains, preload. Quando un browser applica HSTS riscrive l’URI in HTTPS internamente, prima che qualsiasi richiesta raggiunga un server — RFC 6797 non impone un codice di stato specifico per quella riscrittura, anche se gli strumenti spesso la mostrano come un 307 — quindi i tuoi 301 lato server sono ancora obbligatori per i motori di ricerca e il trasferimento dell’autorevolezza dei link; HSTS si aggiunge a essi, non li sostituisce. Preload incorpora il tuo dominio nel browser tramite hstspreload.org (richiede max-age ≥ 31536000, includeSubDomains e preload) ed è quasi irreversibile — la rimozione è una richiesta separata che impiega mesi per raggiungere gli utenti. E HSTS è progettato per fallire duramente su qualsiasi errore di certificato, quindi abilitalo solo quando HTTPS è robusto su ogni sottodominio.

L’hub HTTPS introduce HSTS come protezione a livello di browser che si aggiunge ai tuoi 301. Questa pagina è l’approfondimento: la sintassi esatta dell’header, il redirect interno che inganna gli SEO, la quasi-irreversibilità della lista preload e i modi reali in cui HSTS blocca le persone.

Il problema che HSTS risolve davvero: la prima richiesta

Immagina un sito migrato correttamente. Ogni URL http:// fa un 301 redirect alla sua controparte https://, il certificato è valido, i canonical puntano a HTTPS. Sembra a prova di bomba. Non lo è, proprio.

Quando un visitatore nuovo di zecca digita yoursite.com (senza schema) o clicca un vecchio link http://yoursite.com, la prima richiesta del browser parte su HTTP semplice. Il tuo server risponde con il 301, e ogni richiesta successiva è sicura. Ma quello singolo round-trip iniziale è avvenuto in chiaro — ed è esattamente la finestra che un attaccante SSL-stripping sulla stessa rete vuole. Intercettano la richiesta HTTP, mantengono la vittima su HTTP mentre fanno da proxy HTTPS verso il tuo server, e leggono o riscrivono tutto.

HSTS elimina quella finestra per chiunque abbia già visitato il sito. web.dev è diretto sul meccanismo: “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.” (traduzione) «Usa Strict Transport Security per dire ai client che dovrebbero sempre connettersi al tuo server usando HTTPS, anche quando seguono un riferimento http://. Questo sconfigge attacchi come SSL Stripping ed evita il costo del round-trip del redirect 301.» (web.dev). Anche quell’ultima clausola conta per le prestazioni: un browser di ritorno salta del tutto il round-trip 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: MDN: Strict-Transport-Security header

Due condizioni al contorno su cui essere precisi. Primo, HSTS è una policy memorizzata, per-client — vive nello stato di quel singolo browser per quell’host, appresa da un header consegnato su una connessione sicura; lo stesso header inviato su una risposta HTTP viene ignorato del tutto (un attaccante che può iniettare o rimuovere header su HTTP semplice potrebbe altrimenti neutralizzarlo), e un client che non lo ha mai ricevuto — una nuova installazione, un browser diverso, un crawler — non ha alcuna policy da applicare. Secondo, la riscrittura è consapevole di schema e porta: una richiesta implicita sulla porta 80 diventa una richiesta implicita sulla porta 443, ma se l’URI originale nominava una porta esplicita non predefinita, il browser mantiene quello stesso numero di porta e semplicemente la contatta su HTTPS invece.

La sintassi dell’header

HSTS è un header di risposta con fino a tre direttive. Secondo MDN, le forme sono:

Strict-Transport-Security: max-age=31536000
Strict-Transport-Security: max-age=31536000; includeSubDomains
Strict-Transport-Security: max-age=63072000; includeSubDomains; preload
  • max-age=<seconds> — obbligatorio. “The time, in seconds, that the browser should remember that a host is only to be accessed using HTTPS” (traduzione) «Il tempo, in secondi, per cui il browser dovrebbe ricordare che un host è accessibile solo tramite HTTPS» (MDN). 31536000 è un anno; 63072000 sono due. L’orologio si azzera a ogni risposta che trasporta l’header, quindi un sito attivo rinnova continuamente la sua policy. Questo è uno stato relativo, per client: semplicemente rimuovere l’header non lo cancella immediatamente — un browser che ha già appreso la policy continua a farla rispettare fino a quando il suo max-age memorizzato non scade. Per disattivare HSTS per i client che l’hanno già appresa, devi servire attivamente max-age=0 su una risposta sicura; il browser poi dimentica la policy alla sua prossima visita sicura. (max-age=0 cancella solo una policy appresa — non rimuove un dominio dalla lista separata di preload.)
  • includeSubDomains — opzionale. “If this directive is specified, the HSTS policy applies to all subdomains of the host’s domain as well” (traduzione) «Se questa direttiva è specificata, la policy HSTS si applica anche a tutti i sottodomini del dominio dell’host» (MDN). Potente e pericoloso in egual misura — vedi gli scenari di blocco qui sotto.
  • preload — opzionale. Un flag che segnala la tua intenzione di essere nella lista di preload del browser. Non fa nulla da solo; è un prerequisito per l’invio 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: Chromium: HSTS Preload List Submission

Il comportamento, sempre da 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.” (traduzione) «Quando sta per caricare un URL http, il browser verifica il dominio rispetto alla propria lista di host HSTS. Se trova una corrispondenza senza distinzione tra maiuscole e minuscole, oppure un sottodominio coperto da includeSubDomains, sostituisce lo schema dell’URL con https.»

L’upgrade interno che i crawler non vedono mai (questo è il nodo SEO)

Ecco la cosa più fraintesa di HSTS, e il motivo per cui non può sostituire i tuoi redirect.

Quando un browser aggiorna una richiesta http:// sotto HSTS, riscrive l’URI in HTTPS internamente, prima che venga fatta qualsiasi richiesta di rete — RFC 6797 richiede la sostituzione dello schema stesso ma non impone un codice di stato specifico per essa (RFC 6797 §8.3), quindi un dato browser o strumento di crawling può rappresentare quel passaggio interno come preferisce — molti lo mostrano come un 307 interno, ma è specifico del client/strumento, non una garanzia di protocollo. Ciò che conta per la SEO è più semplice e vale indipendentemente dall’etichetta: nessun server viene contattato per la versione HTTP, quindi nessun crawler la vede mai. Googlebot e Bingbot non portano con sé una policy HSTS appresa come fa il browser di un visitatore abituale: contattano il server senza stato pregresso e devono trovarvi un vero 301 lato server. 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: RFC 6797 §8.3 — URI Loading and Port Mapping

Quindi la regola è netta: HSTS non sostituisce i tuoi 301 lato server. Il 301 è ciò che i motori di ricerca usano per capire il passaggio di protocollo e per consolidare i segnali (“301 and other permanent redirects don’t cause a loss in PageRank” (traduzione) «i redirect 301 e gli altri redirect permanenti non causano perdite di PageRank»; Google). L’upgrade interno solo browser è un livello esperienza utente e sicurezza sopra. Ti servono entrambi, con funzioni diverse:

  • 301 (lato server): per crawler, indicizzazione ed equità dei link.
  • Upgrade interno stile 307 (lato browser, da HSTS): per gli umani che ritornano e la protezione contro lo stripping SSL — la rappresentazione esatta dello stato varia in base a client/strumento.

Qualsiasi guida che ti dica che HSTS “gestisce il redirect così puoi eliminare il tuo 301” è sbagliata in un modo che ti costerà silenziosamente.

HSTS preload: la versione quasi permanente

max-age protegge i visitatori di ritorno, ma ha un problema di bootstrap: un visitatore per la prima volta che non ha mai ricevuto il tuo header è ancora esposto su quella richiesta iniziale. Preload lo risolve codificando il tuo dominio nel sorgente del browser stesso, così il browser sa che sei solo HTTPS prima ancora di essersi mai connesso.

Puoi aderire su hstspreload.org. I requisiti sono esatti:

  1. “Serve a valid certificate.” (traduzione) «Il sito deve presentare un certificato TLS valido e verificabile.»
  2. “Redirect from HTTP to HTTPS on the same host, if you are listening on port 80.” (traduzione) «Se il server ascolta sulla porta 80, deve reindirizzare le richieste HTTP verso HTTPS mantenendo lo stesso nome di dominio.»
  3. “Serve all subdomains over HTTPS” (traduzione) «Ogni sottodominio deve essere disponibile tramite una connessione HTTPS valida» — incluso in particolare il sottodominio www se esiste un record DNS.
  4. Sulla risposta HTTPS del dominio di base, un header HSTS dove “the max-age must be at least 31536000 seconds (1 year),” (traduzione) «il valore max-age deve essere almeno 31536000 secondi (1 anno)»; “the includeSubDomains directive must be specified,” (traduzione) «la direttiva includeSubDomains deve essere specificata»; e “the preload directive must be specified.” (traduzione) «la direttiva preload deve essere specificata». (hstspreload.org)

Ecco perché l’esempio di due anni sopra (max-age=63072000; includeSubDomains; preload) è la forma che le persone inviano — nota che questi sono i requisiti di invio esatti come pubblicati da hstspreload.org; trattali come i requisiti attuali, non come una costante permanente, e ricontrolla la pagina live prima di inviare.

Aiuta a tenere distinti quattro stati, poiché le persone li confondono costantemente:

StatoCosa è vero in realtà
Token presenteIl tuo header include preload. Questo è solo un flag — non fa nulla da solo e non ti mette in nessuna lista.
IdoneoIl tuo sito soddisfa tutti e quattro i requisiti hstspreload.org sopra (certificato, reindirizzamento, sottodomini, forma dell’header). Ancora non nella lista.
Inviato / in attesaHai inviato su hstspreload.org ed è in coda per l’inclusione in una prossima versione del browser. Non ancora applicato per gli utenti reali.
Effettivamente elencatoIl dominio è integrato nella build distribuita di un dato browser. L’applicazione esiste solo per gli utenti su quella build — il rollout non è istantaneo o universale tra i browser.

La rimozione percorre gli stessi quattro stati in ordine inverso, e altrettanto lentamente: rimuovere la direttiva preload dal tuo header ti rende idoneo per il modulo di rimozione, poi l’invio è in attesa, e il dominio rimane applicato per qualsiasi utente su una build del browser che lo include ancora — finché quella build non viene sostituita.

Ora la parte che trasforma preload in una porta a senso unico. Dal sito di invio stesso: “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.” (traduzione) «Tieni presente che l’inclusione nella lista di preload non si annulla facilmente. I domini possono essere rimossi, ma servono mesi perché la modifica raggiunga gli utenti tramite un aggiornamento di Chrome e non è possibile offrire garanzie per gli altri browser.» (hstspreload.org). E il suo stesso consiglio: “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.” (traduzione) «Non richiedere l’inclusione se non sei certo di poter supportare HTTPS a lungo termine per l’intero sito e tutti i suoi sottodomini.»

Traduzione pratica: preload è una postura di sicurezza genuinamente eccellente, ma se mai dovessi servire qualcosa — un sottodominio legacy, un marchio acquisito, uno strumento interno — di nuovo su HTTP semplice, sei bloccato ad aspettare i cicli di rilascio del browser per raggiungere tutti gli utenti. La guida di Kinsta mette chiaramente la realtà operativa: può essere un processo difficile e dispendioso in termini di tempo far rimuovere il tuo dominio. Tratta preload come permanente.

Perché HSTS è progettato per far male quando le cose si rompono

La severità di HSTS non è un bug — è l’intera garanzia di sicurezza. web.dev spiega il compromesso: “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.” (traduzione) «È probabile che i client che hanno registrato il sito come host HSTS noto vadano incontro a un errore non aggirabile se la configurazione TLS presenta un problema, per esempio un certificato scaduto. HSTS è progettato esplicitamente così, per impedire agli aggressori di rete di indurre i client ad accedere al sito senza HTTPS.» (web.dev).

La conclusione che Google trae è la frase che tatuerei su chiunque stia per attivare questa funzione: “Don’t enable HSTS until you’re certain your site operation is robust enough to avoid ever deploying HTTPS with certificate validation errors.” (traduzione) «Non attivare HSTS finché non sei certo che il funzionamento del tuo sito sia abbastanza robusto da evitare di distribuire HTTPS con errori di validazione del certificato.» (web.dev).

“Hard-fail” significa esattamente questo: nessun link «procedi comunque» e nessuna possibilità di ignorare l’avviso. Su una pagina HTTPS normale, un certificato scaduto mostra un avviso intimidatorio che un utente determinato può aggirare. Su un host HSTS, il browser rifiuta categoricamente. Quindi la modalità di errore di una scadenza trascurata del certificato cambia categoria — da “il traffico cala perché le persone sono spaventate” a “il sito è irraggiungibile per ogni visitatore di ritorno.”

Scenari reali di blocco

I modi in cui HSTS morde nella pratica quasi sempre riconducono a includeSubDomains o preload che superano la tua copertura HTTPS effettiva:

  • Il sottodominio dimenticato. Imposti includeSubDomains su example.com, ma legacy.example.com (una vecchia app, una pagina di stato, uno strumento del fornitore) parla solo HTTP o ha un certificato che non lo copre. Ogni browser che ha visto l’header ora rifiuta di caricare quel sottodominio. Nulla è cambiato su quel server — la policy è arrivata e lo ha rotto.
  • Il limite di profondità del certificato wildcard. Un wildcard *.example.com copre foo.example.com ma non foo.bar.example.com (copre un solo livello DNS). Se un sottodominio più profondo si affida a HTTP o a un certificato non corrispondente, includeSubDomains lo blocca.
  • Il certificato scaduto su un host HSTS. L’automazione del rinnovo fallisce, il certificato scade, e invece di un avviso aggirabile ottieni un sito che è giù per tutti coloro il cui browser ricorda la tua policy — finché non ripristini un certificato valido e loro si riconnettono e ricevono una nuova risposta sicura. Non esiste una scorciatoia più veloce.
  • Il ripensamento dopo il preload. Hai attivato il preload, poi un’esigenza aziendale impone un servizio solo HTTP sotto il dominio. Annullarlo è due lavori separati e non istantanei, non uno: servire max-age=0 su HTTPS cancella solo la policy appresa per i client che si riconnettono prima che il loro vecchio max-age sarebbe comunque scaduto, mentre rimuovere il dominio dalla lista preload richiede una domanda distinta e comunque cicli di rilascio del browser — mesi — per raggiungere gli utenti, indipendentemente da qualsiasi cosa tu cambi sul tuo server.
  • Collisioni di sviluppo locale / staging. Il preload di example.com con includeSubDomains può far sì che dev.example.com o un host interno stile localhost sotto lo stesso apex rifiuti HTTP, rompendo i flussi di lavoro locali in modi sorprendenti.

Nessuno di questi è un motivo per evitare HSTS. Sono motivi per introdurlo per fasi: prima un max-age breve, aggiungi includeSubDomains solo dopo aver verificato ogni sottodominio, e riserva preload per quando sei certo.

HSTS non è una strategia di ranking (e non tocca la canonicalizzazione)

Per essere chiari sul quadro SEO: HSTS non è un segnale di ranking. HTTPS stesso è un segnale deliberatamente minuscolo — Google lo ha definito un “segnale molto leggero” che influisce su meno dell’1% delle query — e HSTS è un livello sopra HTTPS, non un input di ranking separato. Inoltre non controlla direttamente la canonicalizzazione o l’indicizzazione. La documentazione di Google è però più precisa di un generico «non importa»: Google preferisce HTTPS come canonico rispetto a una pagina HTTP equivalente tranne quando c’è un certificato non valido, dipendenze di pagina non sicure, una pagina HTTPS che reindirizza a HTTP, o un tag rel="canonical" HTTP (Google: consolidare URL duplicati). HSTS non può risolvere o sovrascrivere nulla di tutto ciò. È una policy lato browser senza influenza sulla logica di canonicalizzazione di Google — un certificato difettoso o una catena di reindirizzamenti rotta possono comunque spingere Google verso un canonico HTTP indipendentemente da ciò che dice il tuo header HSTS. La canonicalizzazione è guidata dai tuoi 301, dal tuo certificato, dal tuo rel="canonical" e dai tuoi link interni — HSTS serve per sicurezza, fiducia degli utenti e chiusura della finestra di SSL-stripping — adottalo per questi motivi, mantieni i tuoi 301 e il certificato davvero solidi, e non vedrai mai HSTS stesso su un report di ranking in ogni caso.

Se stai eseguendo la migrazione più ampia da HTTP a HTTPS, HSTS è l’ultima cosa da attivare, non la prima — va dopo che la migrazione si è stabilizzata, come parte della più ampia disciplina della migrazione del sito.

Add an expert note

Pin an expert quote

New person? Create their unclaimed profile at /admin/experts/ → Pin a quote first.