Il rapporto tra HTTPS e SEO è uno dei pochi argomenti su cui posso mostrarti una mia previsione sbagliata, datata e firmata. Questa pagina ospita dal 2014 la traduzione integrale dell’annuncio con cui Google dichiarò il protocollo cifrato un segnale di ranking, e in fondo, nella sezione “cosa farò”, c’era la mia posizione dell’epoca: aspetto e sto a guardare, per un blog il certificato non serve. Dodici anni dopo quella frase si può valutare, e la valutazione è che avevo torto. Non però nel modo in cui pensa la maggior parte degli articoli che stai leggendo in giro. Qui trovi il verdetto completo, quello che è successo davvero al protocollo cifrato come fattore di posizionamento, e i controlli che quasi nessuna PMI italiana ha fatto sul proprio certificato.
HTTPS e SEO: cosa disse Google nel 2014, testualmente
Il 6 agosto 2014, sul blog ufficiale per i webmaster, due Webmaster Trends Analyst annunciarono che le connessioni cifrate sarebbero entrate fra i segnali dell’algoritmo. La parte importante non è il titolo, è la clausola che quasi nessuno cita: si trattava di “un segnale molto leggero, interessa meno dell’1% delle ricerche globali, e pertanto pesa meno rispetto ad altri segnali, come i contenuti di alta qualità”. Puoi leggere il testo originale nel post HTTPS come indicatore di ranking, che è ancora online.
Nello stesso annuncio Google si riservava la possibilità di rafforzare il segnale col tempo. Poco dopo, in un hangout del settembre 2014, John Mueller fu ancora più netto: non aspettarti nessun cambiamento di posizione dalla sola migrazione, l’effetto è molto piccolo e molto sottile, semmai avrai fluttuazioni di breve periodo mentre Google riscansiona tutto.
C’era un precedente quasi identico. Nell’aprile 2010 Google aveva annunciato la velocità di caricamento come fattore di ranking, con due portavoce, sullo stesso blog, e con la stessa formula: meno dell’1% delle ricerche. Ci vollero anni prima che quel segnale prendesse un peso riconoscibile, e ci arrivò solo passando per i Core Web Vitals. Come è finita quella storia lo sappiamo: il segnale velocità è diventato leggibile solo quando Google gli ha dato una metrica pubblica.
Dodici anni dopo: la previsione era sbagliata, ma non come credi
Nel 2014 scrissi che non vedevo la necessità, per un blog che non vende nulla e non raccoglie dati, di dotarsi di un certificato. Il ragionamento era coerente con le informazioni disponibili: segnale leggero, nessun beneficio misurabile, costi e complessità reali. Uno studio pubblicato pochi giorni dopo l’annuncio non trovò alcun miglioramento di ranking nelle migrazioni. Sulla base dei dati del 2014, quella posizione era difendibile.
Era comunque sbagliata, e vale la pena capire esattamente dove. Non ho sbagliato la previsione SEO: il protocollo cifrato non è mai diventato il fattore di ranking pesante che tutti aspettavano, e ancora oggi nessun sito scala la SERP perché ha installato un certificato. Ho sbagliato la cornice. Ho valutato una questione di sicurezza con il metro del posizionamento, che è esattamente l’errore che vedo fare ogni settimana nelle aziende.
Quello che è successo davvero è che HTTPS ha smesso di essere un vantaggio competitivo ed è diventato una condizione di accesso. Google lo scrive senza giri di parole nella documentazione tecnica per sviluppatori: proteggi tutti i tuoi siti anche se non gestiscono comunicazioni sensibili, perché il protocollo cifrato è ormai obbligatorio per molte funzionalità del browser, come spiegato nella guida perché HTTPS è importante. Geolocalizzazione, notifiche push, service worker, fotocamera, microfono, HTTP/2 e HTTP/3 nella pratica dei browser: senza connessione sicura non funziona nulla di tutto questo. Il sito senza HTTPS non viene penalizzato, viene semplicemente escluso dal web moderno.
Quindi la domanda “conviene passare a HTTPS per la SEO” è mal posta da dieci anni. Il tema HTTPS e SEO non è più un tema di ranking. La domanda giusta è un’altra, ed è quella che occupa il resto di questo articolo.
Il certificato non è il traguardo, è la riga di partenza
Qui arriva la parte che nella letteratura su HTTPS e SEO manca quasi del tutto, e che vedo con l’altro cappello che porto, quello della sicurezza informatica. Nella nostra pratica, quando analizziamo il sito di una PMI che “ha già l’HTTPS”, il lucchetto verde nella barra degli indirizzi dice pochissimo. Sotto quel lucchetto ci sono cinque cose che vanno storte con una regolarità impressionante.
Versioni obsolete del protocollo ancora attive. Molti server che servono pagine in HTTPS accettano tuttora TLS 1.0 e 1.1. Le raccomandazioni AgID sono esplicite: sono protocolli obsoleti, non supportano i moderni algoritmi crittografici, risultano vulnerabili ad attacchi e vanno ritenuti deprecati. Il documento fissa anche i requisiti minimi lato server e le cipher suite ammesse, e lo trovi nelle raccomandazioni in merito allo standard Transport Layer Security. Il browser dell’utente non te lo dirà mai: negozia la versione più alta disponibile e mostra il lucchetto lo stesso.
Cipher suite deboli. Il certificato dice chi sei, la cipher suite dice quanto bene stai cifrando. Sono due cose diverse e la seconda la configura il server, non il fornitore del certificato.
Catena incompleta. Il certificato intermedio manca o è installato male. Sui browser desktop spesso non si nota, perché il browser recupera il pezzo mancante per conto suo. Su alcuni client mobile, e su molti crawler e bot, la connessione fallisce e basta.
Mixed content residuo. È il classico dopo migrazione: la pagina è servita in modo cifrato ma richiama immagini, script o fogli di stile in chiaro. Le risorse attive vengono bloccate dal browser e la pagina si rompe, quelle passive passano ma degradano la sicurezza. Stesso discorso per i collegamenti in uscita ereditati da anni fa, che nel frattempo sono rimasti in chiaro dentro pagine sicure: ne ho parlato in dettaglio nell’articolo sui link in uscita.
Scadenza non presidiata. Il rinnovo automatico esiste, funziona, e ogni tanto smette di funzionare senza avvisare nessuno. Un certificato scaduto non è un problema estetico: il browser blocca la pagina con un interstiziale a tutto schermo, Googlebot smette di scansionare, e il sito è di fatto offline finché qualcuno se ne accorge. Nella maggior parte delle aziende che ho visto, quel qualcuno è un cliente al telefono.
Nessuno di questi cinque punti è un problema SEO. Tutti e cinque diventano un problema SEO nel momento in cui bloccano la scansione o rompono le pagine. Se vuoi che qualcuno li guardi con occhi tecnici, è il tipo di controllo che rientra in un intervento di sicurezza informatica, non in un audit di contenuti.
Passare da http a https senza perdere posizionamento
Veniamo alla parte operativa, perché la migrazione a HTTPS è il momento in cui si fanno i danni veri, ed è l’unico punto in cui HTTPS e SEO si toccano sul serio. Una cosa va detta subito, e viene dalla fonte: i reindirizzamenti permanenti non fanno perdere autorevolezza. Google lo mette nero su bianco nella documentazione sugli spostamenti di sito. La perdita di posizioni dopo una migrazione non arriva mai dal 301 in sé, arriva da quello che si dimentica intorno.
Questa è la sequenza che seguiamo, nell’ordine.
- Prepara la mappatura. Ogni URL in chiaro deve avere una destinazione cifrata corrispondente, uno a uno. Le migrazioni che finiscono male sono quasi sempre quelle in cui metà del vecchio sito atterra in home page.
- Configura i redirect permanenti a livello di server, non con un plugin. Una regola sola, senza catene: da chiaro a cifrato in un salto. Se hai già altri 3xx accumulati negli anni, questo è il momento di rifarli, e la logica la trovo spiegata in redirect 301 e 3xx nella SEO.
- Aggiorna i canonical, gli hreflang e i dati strutturati. Un canonical rimasto in chiaro dentro una pagina cifrata è un segnale contraddittorio che Google prende sul serio.
- Riscrivi i link interni. Non lasciarli al redirect: un sito che si autoreindirizza a ogni click spreca crawl budget e rallenta l’utente.
- Genera una sitemap nuova con i soli URL cifrati e aggiorna il riferimento nel robots.txt. Non bloccare la scansione della versione sicura, errore che nel 2014 Google elencava già fra i più comuni e che continuo a trovare.
- Verifica la proprietà del nuovo protocollo in Search Console. Sono proprietà distinte, e qui c’è il dettaglio che quasi nessun articolo italiano riporta: per una migrazione da chiaro a cifrato non si usa lo strumento Cambio di indirizzo, come specificato nella guida ufficiale su spostamenti e migrazioni di siti. Serve solo per i cambi di dominio.
- Monitora per almeno sei settimane. Copertura, scansione, prestazioni, entrambe le proprietà. Come si leggono quei report l’ho scritto nella guida a Google Search Console.
- Attiva HSTS solo alla fine, quando sei sicuro che tutto funzioni. È una scelta difficile da revocare: dice al browser di rifiutare la versione in chiaro per un periodo che decidi tu, e se hai un sottodominio ancora scoperto lo tagli fuori.
Fluttuazioni nelle prime settimane sono normali e non significano che hai sbagliato. Se dopo due mesi non sei tornato ai livelli precedenti, allora sì, c’è un errore nella mappatura o nei canonical, e va cercato lì.
In Italia il protocollo cifrato non è più una scelta di marketing
C’è un pezzo del discorso che gli articoli su HTTPS e SEO ignorano sistematicamente, ed è quello che oggi pesa di più per un’azienda italiana. Il GDPR, all’articolo 32, chiede misure tecniche adeguate al rischio e cita espressamente la cifratura fra gli esempi. Un modulo di contatto che trasmette nome, email e telefono in chiaro non è una scelta discutibile di web design, è un trattamento senza misura adeguata.
Sopra questo si è aggiunta la direttiva NIS2, recepita in Italia nel 2024, che ha ampliato enormemente la platea dei soggetti obbligati ad adottare misure di gestione del rischio informatico, comprese le politiche sull’uso della crittografia. Molte PMI che si consideravano fuori perimetro oggi ci sono dentro, spesso come fornitori di soggetti obbligati. E se lavori con la pubblica amministrazione, le raccomandazioni AgID sul TLS che ho citato sopra non sono un consiglio: sono il riferimento tecnico con cui verrai valutato.
Non sto dando consulenza legale, che non mi compete, e ogni situazione va guardata nel merito. Sto dicendo una cosa più semplice: la domanda “mi conviene per la SEO” è diventata irrilevante perché è arrivata prima un’altra domanda, quella sull’obbligo. Ed è anche il motivo per cui la mia previsione del 2014 era sbagliata: stavo rispondendo alla domanda giusta con il metro sbagliato.
Il collegamento con l’E-E-A-T, che nessuno fa
Un’ultima osservazione su HTTPS e SEO, e riguarda il modo in cui Google valuta l’affidabilità. La T di Trust nel framework E-E-A-T non si esaurisce nel contenuto: comprende la sicurezza della transazione e la protezione dei dati dell’utente, ed è il criterio che nelle linee guida per i quality rater pesa di più su siti che gestiscono denaro o salute.
Non esiste un moltiplicatore che trasforma il certificato in Trust, e chi te lo racconta sta semplificando. Esiste però il contrario, e questo è documentabile: un sito che chiede dati con un avviso di connessione non sicura in barra fallisce il criterio di Trust prima ancora che qualcuno legga una riga dei suoi contenuti. È lo stesso ragionamento del 2014, solo capovolto. Non guadagni per averlo, perdi per non averlo.
I cinque controlli sul tuo HTTPS da fare in dieci minuti
Chiudo con la parte utile. Nessuno di questi controlli richiede competenze da sistemista, e li puoi fare adesso.
Apri un test SSL pubblico, ce ne sono di gratuiti e affidabili, e lancialo sul tuo dominio: ti dice versione del protocollo negoziata, cipher suite accettate, stato della catena e data di scadenza. Poi apri una pagina qualsiasi del sito, premi F12, vai alla scheda console e cerca gli avvisi di mixed content. Digita il tuo dominio in chiaro nella barra e verifica che arrivi alla versione cifrata in un solo salto, non in tre. Controlla che la sitemap contenga solo URL sicuri. Infine guarda in Search Console se la proprietà sicura è verificata e se il report Copertura mostra ancora URL in chiaro indicizzati.
Se qualcuno di questi cinque punti dà esito negativo, il problema non è il posizionamento. Il problema è che stai servendo un sito che credi protetto e non lo è del tutto. E il problema, a differenza di quasi tutto il resto del lavoro SEO, si risolve in un pomeriggio.
Riepilogo dei punti chiave
Il rapporto fra HTTPS e SEO va riletto. Google dichiarò il protocollo cifrato un segnale di ranking il 6 agosto 2014, precisando che riguardava meno dell’1% delle ricerche globali, e quel segnale non è mai diventato pesante: nessun sito scala la SERP perché ha installato un certificato. Nel frattempo però HTTPS ha smesso di essere un vantaggio ed è diventato una condizione di accesso, perché senza connessione sicura non funzionano geolocalizzazione, notifiche, service worker, HTTP/2 e HTTP/3. Il vero rischio oggi non è il sito in chiaro, ormai raro: è il sito cifrato male, con TLS 1.0 e 1.1 ancora attivi e deprecati secondo AgID, cipher suite deboli, catena del certificato incompleta, mixed content residuo e scadenze non presidiate. Sul fronte migrazione, i redirect permanenti non fanno perdere autorevolezza: i danni arrivano da mappature incomplete, canonical rimasti in chiaro, link interni non riscritti e sitemap non rigenerate. Nota operativa poco nota: per il passaggio da HTTP a HTTPS non si usa lo strumento Cambio di indirizzo di Search Console. Infine, in Italia la questione è uscita dal marketing ed è entrata nella compliance, fra articolo 32 del GDPR, recepimento di NIS2 e raccomandazioni AgID sul TLS.
Domande frequenti su HTTPS e SEO
Che cos’è il protocollo HTTPS?
È la versione cifrata del protocollo con cui browser e server si scambiano le pagine web. La cifratura è garantita da TLS, il successore di SSL, e serve a tre cose: impedire che un terzo legga i dati in transito, impedire che li modifichi lungo il percorso, e permettere al browser di verificare che il server sia davvero quello che dichiara di essere. Il certificato installato sul server è lo strumento che rende possibile quest’ultima verifica.
È più sicuro HTTP o HTTPS?
HTTPS, senza margini di discussione. Con il protocollo in chiaro chiunque si trovi sul percorso di rete, dal wi-fi del bar al provider, può leggere e modificare quello che viaggia fra il browser e il sito. Con la versione cifrata il contenuto è illeggibile ai terzi e qualsiasi manomissione viene rilevata. Non esiste uno scenario legittimo in cui il protocollo in chiaro sia preferibile su un sito pubblico.
I siti con HTTPS sono sicuri?
No, e questo è l’equivoco più diffuso. Il lucchetto certifica che la connessione fra il tuo browser e quel server è cifrata, non che il sito sia onesto, aggiornato o privo di malware. Un sito di phishing con un certificato valido mostra lo stesso identico lucchetto della tua banca. Inoltre un sito cifrato può essere configurato male, con versioni obsolete del protocollo o cipher suite deboli, e il browser continuerà a mostrare il lucchetto.
Qual è la differenza tra protocollo HTTP e HTTPS?
La differenza è un livello di cifratura in mezzo. HTTP trasmette in chiaro: chiunque intercetti il traffico legge tutto, dalle pagine visitate ai dati inseriti nei moduli. HTTPS incapsula lo stesso protocollo dentro una sessione TLS, quindi il traffico è cifrato, integro e autenticato. Sul piano pratico cambiano anche l’indirizzo, che passa da http:// a https://, la porta usata, e la disponibilità delle funzionalità moderne del browser, che nella versione in chiaro sono disattivate.
HTTPS è ancora un fattore di ranking nel 2026?
Formalmente sì, praticamente è irrilevante come leva. Google lo annunciò nel 2014 come segnale molto leggero, che interessava meno dell’1% delle ricerche, e non ha mai comunicato di averlo rafforzato. Dato che oggi la stragrande maggioranza dei siti indicizzati è cifrata, un segnale posseduto da quasi tutti non differenzia nessuno. Il ragionamento corretto è al negativo: non guadagni posizioni perché hai il certificato, ne perdi se non ce l’hai o se è configurato male al punto da bloccare la scansione.
Passare da HTTP a HTTPS fa perdere posizionamento?
Non di per sé. Google specifica che i reindirizzamenti permanenti non causano perdita di autorevolezza. Quello che fa perdere posizioni è la migrazione fatta male: mappatura incompleta con pagine che finiscono tutte in home, catene di redirect, canonical rimasti sul vecchio protocollo, sitemap non rigenerata, versione sicura bloccata dal robots.txt. Attenditi fluttuazioni per qualche settimana mentre Google riscansiona. Se dopo due mesi non sei rientrato, cerca l’errore nella mappatura.
Serve il certificato SSL anche a un sito vetrina che non vende nulla?
Sì, e nel 2014 su questa stessa pagina avevo sostenuto il contrario. La risposta è cambiata per tre motivi che allora non esistevano: i browser segnalano attivamente come non sicure le pagine in chiaro che raccolgono dati, comprese quelle con un semplice modulo di contatto; molte funzionalità del browser sono disponibili solo su connessione cifrata; e l’articolo 32 del GDPR chiede misure adeguate al rischio, citando la cifratura fra gli esempi. Un sito vetrina con un form di contatto tratta dati personali.
Che tipo di certificato serve a una PMI?
Per la quasi totalità dei siti aziendali un certificato con validazione del dominio è sufficiente, ed è quello che la maggior parte degli hosting rilascia e rinnova automaticamente. I certificati con validazione estesa non danno vantaggi di posizionamento e i browser hanno smesso da anni di dare loro un trattamento visivo speciale. Se hai più sottodomini valuta un wildcard. La scelta che conta non è il tipo di certificato: è come è configurato il server che lo usa.
Cosa resta di quell’articolo del 2014
Lascio online la traduzione dell’annuncio e la previsione sbagliata, perché un archivio serve a questo. Se dovessi riscrivere oggi la sezione “cosa farò”, scriverei che il certificato va messo subito e senza discutere, e che il lavoro comincia il giorno dopo averlo installato.
Il passo successivo, se hai un sito con qualche anno di storia e una migrazione alle spalle fatta da qualcun altro, è lanciare quei cinque controlli. Nella nostra esperienza, su un sito aziendale medio almeno due danno esito negativo, e nessuno se n’era accorto.
Prenota una consulenza strategica se preferisci che il controllo lo faccia qualcuno con gli strumenti giusti: partiamo da un’analisi della configurazione TLS e della migrazione del tuo sito, e vediamo cosa è rimasto indietro.
