Protocollo HTTPS: cos’è, come funziona e perché serve davvero

Articolo di Max Del Rosso
pubblicato il 18 giugno 2026

Il protocollo HTTPS protegge lo scambio di dati tra il browser e il server che ospita un sito. Lo fa usando TLS, un sistema crittografico che cifra la comunicazione, ne controlla l’integrità e permette di verificare l’identità del server.

Dietro quella “S” aggiunta a HTTP, quindi, non c’è soltanto il simbolo mostrato nella barra degli indirizzi. Prima che venga caricata una pagina, browser e server devono riconoscersi, scegliere come proteggere la connessione e generare le chiavi temporanee necessarie.

HTTPS non rende infallibile un sito. Non elimina malware, configurazioni sbagliate o vulnerabilità del software. Risolve però un problema preciso: impedire che i dati viaggino in chiaro e possano essere letti o modificati lungo il percorso.

Che cos’è il protocollo HTTPS

HTTPS significa HyperText Transfer Protocol Secure. Più che un protocollo completamente separato, è HTTP trasmesso attraverso un canale protetto da TLS. Le normali richieste e risposte del Web rimangono HTTP; cambia il modo in cui viaggiano tra client e server.

TLS ha sostituito SSL, tecnologia ormai superata ma ancora presente nel linguaggio comune. Per questo si continua a parlare di “certificato SSL”, anche quando il server utilizza TLS 1.2 o TLS 1.3.

Per HTTPS, la porta registrata da IANA è la 443. HTTP non cifrato utilizza invece, di norma, la porta 80.

Come funziona HTTPS

Per capire come funziona HTTPS, conviene separare tre operazioni: il controllo del certificato, l’handshake TLS e la cifratura della sessione.

Avvengono in pochi istanti. Sono però indispensabili, perché il browser non dovrebbe inviare dati sensibili prima di sapere con quale server sta comunicando e come verrà protetto lo scambio.

Il certificato digitale identifica il server

Quando apre una connessione, il server presenta al browser il proprio certificato digitale. Il certificato contiene la chiave pubblica, i domini coperti, il periodo di validità e le informazioni sull’autorità che lo ha emesso.

Il browser verifica che il dominio visitato corrisponda a quello indicato e che la catena di certificazione sia considerata attendibile. Controlla inoltre le scadenze e le eventuali anomalie. Se qualcosa non torna, mostra un errore o impedisce la navigazione.

Attenzione, però: un certificato Domain Validation dimostra soprattutto il controllo del dominio. Non certifica l’onestà del proprietario né la qualità dei contenuti pubblicati. Anche un sito ingannevole può avere una connessione HTTPS tecnicamente valida.

Durante l’handshake si concordano le chiavi

Superato il primo controllo, inizia l’handshake TLS. Browser e server comunicano le versioni del protocollo e gli algoritmi che possono utilizzare. Il server prova poi di possedere la chiave privata collegata al certificato.

Con TLS 1.3, l’handshake è un accordo autenticato sulle chiavi. Al termine, le due parti hanno derivato i segreti necessari per proteggere la sessione. Il protocollo è progettato per contrastare intercettazioni, manomissioni e falsificazioni dei messaggi.

La chiave privata non viene inviata al browser. Resta sul server e serve, tra le altre cose, a firmare dati dell’handshake. Esporla significherebbe compromettere l’identità crittografica del servizio.

Il traffico viene cifrato con chiavi temporanee

Concluso l’handshake, browser e server utilizzano chiavi simmetriche derivate appositamente per quella connessione. Sono molto più efficienti della crittografia asimmetrica quando occorre proteggere pagine, immagini, cookie, moduli e altre risorse.

Da quel momento, le normali richieste HTTP viaggiano dentro il canale TLS. Chi intercettasse i pacchetti non dovrebbe riuscire a leggerne il contenuto né a modificarlo senza che l’alterazione venga rilevata.

HTTP e HTTPS: le differenze che contano

A prima vista cambia soltanto una lettera. Dal punto di vista della sicurezza, però, la distanza è notevole.

Con HTTP, un intermediario può osservare o alterare il traffico più facilmente. HTTPS protegge invece la comunicazione lungo il tragitto tra il dispositivo e il punto in cui termina la connessione TLS.

Non tutto diventa invisibile. Alcune informazioni necessarie alla connessione, come l’indirizzo IP del server e, in determinate configurazioni, il dominio contattato, possono rimanere osservabili. Il contenuto delle richieste e delle risposte è invece protetto dal canale cifrato.

Che cosa protegge HTTPS

Il protocollo HTTPS offre tre garanzie principali.

• Riservatezza: rende il contenuto illeggibile agli intermediari.
• Integrità: permette di rilevare modifiche avvenute durante il trasferimento.
• Autenticazione: verifica l’identità crittografica del server contattato.

Sono proprietà decisive quando si inviano password, dati personali, informazioni di pagamento o cookie di sessione. In realtà, però, non servono soltanto agli ecommerce. Anche una pagina editoriale può essere alterata in transito oppure caricata insieme a risorse manipolate.

Usare HTTPS non significa aver messo in sicurezza l’intero sito. Restano da gestire gli aggiornamenti del CMS, le password, gli accessi amministrativi, i backup e le vulnerabilità del codice.

Il certificato non protegge neppure da un modulo fraudolento pubblicato dal proprietario stesso. Garantisce che i dati arrivino al dominio indicato, non che quel dominio meriti fiducia.

HTTPS e SEO: cosa cambia davvero

La formula “HTTPS SEO” può far pensare a un rapporto semplice: si installa il certificato e il sito guadagna posizioni. Non funziona così.

Nel 2014 Google annunciò l’uso di HTTPS come segnale di ranking molto leggero, con un peso inferiore rispetto alla qualità dei contenuti. La documentazione attuale sulla page experience chiarisce però che gli aspetti diversi dai Core Web Vitals non aiutano direttamente una pagina a salire nei risultati. La sicurezza resta parte di una buona esperienza complessiva, non una leva autonoma con cui scalare la SERP.

Conviene adottare HTTPS perché protegge gli utenti, evita connessioni non sicure e rende disponibili funzioni web che richiedono un contesto protetto. Farlo soltanto per inseguire un presunto bonus SEO sarebbe una motivazione debole.

Il vero rischio SEO è una migrazione mal gestita

Per Google, http://esempio.it/pagina e https://esempio.it/pagina sono URL diversi. Il passaggio va quindi trattato come una migrazione con modifica degli indirizzi, non come l’attivazione di una semplice opzione nel pannello dell’hosting.

Se redirect, canonical e sitemap indicano destinazioni incoerenti, Google riceve segnali contraddittori. Si possono creare duplicazioni, catene di reindirizzamento o pagine non più raggiungibili.

Il calo non è inevitabile. Serve, semmai, una mappa precisa: ogni vecchio URL deve condurre alla sua effettiva controparte HTTPS.

Come passare da HTTP a HTTPS

La migrazione comincia prima dell’installazione del certificato. Bisogna sapere quali URL esistono, quali sottodomini sono attivi e da dove vengono caricate le risorse.

Farne un inventario evita di accorgersi troppo tardi che un’area riservata, un vecchio blog o un sottodominio tecnico utilizza ancora HTTP.

Prima della pubblicazione

Per prima cosa va scelto un certificato adatto ai domini utilizzati. Molti hosting lo gestiscono automaticamente; in alternativa, si può ricorrere a un client ACME. Let’s Encrypt, per esempio, rilascia certificati gratuiti dopo aver verificato il controllo dei domini richiesti.

Conviene poi provare la configurazione in un ambiente di test. Certificato, catena, protocolli supportati e collegamenti interni vanno controllati prima di coinvolgere utenti e motori di ricerca.

Al momento della migrazione

Una volta pronta la versione sicura, occorre coordinare gli interventi:

1. attivare HTTPS su pagine e risorse;
2. aggiornare link interni, canonical e hreflang;
3. generare una sitemap con i nuovi URL;
4. impostare redirect permanenti da HTTP a HTTPS;
5. verificare robots.txt e direttive noindex;
6. aggiornare dati strutturati e configurazioni esterne.

I redirect devono conservare il percorso. La vecchia pagina /servizi/consulenza dovrebbe portare alla stessa pagina su HTTPS, non alla home. Google raccomanda una mappatura tra vecchi e nuovi URL e l’uso di reindirizzamenti lato server per le destinazioni permanenti.

Dopo la messa online

Nelle ore e nei giorni successivi, meglio controllare codici di stato, pagine escluse, errori 404 e risorse bloccate. I log del server aiutano a capire se crawler e utenti incontrano ancora URL HTTP.

Vanno monitorati anche Search Console e gli strumenti di analisi. Un calo improvviso, una crescita degli errori o la permanenza di molte pagine HTTP nell’indice meritano un controllo immediato.

I redirect non andrebbero rimossi appena la migrazione sembra conclusa. Vecchi link, preferiti e riferimenti esterni possono continuare a generare traffico ancora a lungo.

Mixed content: quando la pagina è HTTPS solo a metà

Può capitare che il documento principale venga servito su HTTPS, mentre immagini, script o fogli di stile arrivano ancora da indirizzi HTTP. È il cosiddetto mixed content.

I browser distinguono tra risorse aggiornabili e risorse bloccabili. Alcune richieste possono essere convertite automaticamente in HTTPS; altre vengono fermate, con il rischio che la pagina perda funzioni o venga visualizzata male. La soluzione rimane una: caricare tutte le risorse attraverso connessioni sicure.

La direttiva CSP upgrade-insecure-requests può aiutare con siti ricchi di URL storici. Non sostituisce, però, la verifica delle risorse e della loro effettiva disponibilità su HTTPS.

Quando attivare HSTS

Dopo aver stabilizzato la migrazione, si può valutare HSTS, acronimo di HTTP Strict Transport Security. Attraverso questo header, il sito indica al browser di utilizzare soltanto HTTPS per le connessioni future.

HSTS rende più rigida anche la gestione degli errori del certificato: l’utente non può semplicemente ignorarli e proseguire. Proprio per questo non va attivato alla cieca.

La direttiva includeSubDomains estende la regola ai sottodomini. Prima di usarla, bisogna verificare che ciascuno di essi supporti HTTPS. Il preload richiede ancora più prudenza, perché inserisce il dominio in una lista adottata dai browser.

Gli errori che compromettono la migrazione

Alcuni problemi tornano con particolare frequenza:

• il certificato non copre tutti i domini;
• HTTP e HTTPS rimangono entrambi accessibili;
• i redirect formano catene o cicli;
• canonical e sitemap puntano ai vecchi URL;
• script e immagini vengono ancora caricati in HTTP;
• il certificato scade senza rinnovo;
• HSTS viene attivato prima dei test finali.

Non sempre l’errore produce una pagina bianca. A volte il sito sembra funzionare, mentre Google continua a ricevere segnali duplicati oppure alcune risorse vengono bloccate soltanto in determinati browser.

Una scansione completa prima e dopo il passaggio ne intercetta buona parte. Anche la navigazione manuale resta utile: moduli, login, checkout e aree riservate meritano un controllo specifico.

Domande frequenti sul protocollo HTTPS

HTTPS e SSL sono la stessa cosa?

Non esattamente. SSL è il predecessore di TLS ed è ormai superato. L’espressione “certificato SSL” sopravvive nel linguaggio commerciale, ma le connessioni moderne usano TLS.

Un sito HTTPS è sempre affidabile?

No. HTTPS protegge la connessione e permette di verificare il dominio indicato dal certificato. Non garantisce che il proprietario sia onesto, che il contenuto sia corretto o che il sito non contenga malware.

Il protocollo HTTPS migliora il posizionamento?

Non produce automaticamente un aumento delle posizioni. Google lo annunciò nel 2014 come segnale molto leggero; oggi lo considera soprattutto uno degli aspetti di una buona esperienza complessiva. Pertinenza e qualità dei contenuti restano centrali.

È possibile ottenere gratuitamente un certificato?

Sì. Let’s Encrypt è un’autorità di certificazione senza scopo di lucro che rilascia certificati Domain Validation gratuiti e automatizzabili tramite ACME.

Il certificato cifra da solo tutto il sito?

No. Deve essere installato e configurato correttamente, ma occorre anche servire pagine e risorse su HTTPS. Se una pagina sicura richiama script o file HTTP, si crea mixed content.

Come verificare che la migrazione sia riuscita?

Bisogna controllare certificato, redirect, canonical, sitemap, risorse interne e codici di stato. Search Console e i log del server aiutano poi a individuare URL esclusi o ancora richiesti tramite HTTP.

HTTPS è il punto di partenza

Una connessione cifrata non risolve ogni problema di sicurezza. Senza aggiornamenti, controllo degli accessi e manutenzione, il sito rimane esposto anche con un certificato perfettamente valido.

Eppure da HTTPS non si può più prescindere. Protegge lo scambio dei dati e offre agli utenti una base tecnica affidabile. Per la SEO, il punto non è ottenere un bonus: è evitare che una migrazione approssimativa mandi a monte segnali, URL e visibilità costruiti nel tempo.