HTTPS per la SEO

TL;DR — HTTPS è la versione sicura e cifrata di HTTP: quella associata all’icona del lucchetto nel browser. Storicamente Google ha attribuito alle pagine HTTPS un vantaggio di posizionamento minimo, ma i motivi reali per effettuare il passaggio sono altri: Chrome contrassegna i siti in semplice HTTP come “Non sicuri” e oggi HTTPS è ciò che il web si aspetta. La migrazione è sicura se viene eseguita correttamente: reindirizza ogni vecchio URL http:// alla corrispondente versione https:// senza rompere nulla durante il processo.

Che cos’è HTTPS

Quando carichi un sito web, il browser comunica con un server. Con il semplice HTTP, la conversazione avviene in chiaro: chiunque si trovi nel tratto di rete intermedio (il provider Internet, il Wi-Fi di un bar, un aggressore) può leggerla o alterarla. HTTPS è la stessa conversazione, ma cifrata. La “S” significa “Secure”, cioè sicuro. Per abilitarlo si installa sul server un certificato TLS (ancora spesso chiamato “certificato SSL”).

Puoi verificare se una pagina lo usa dalla barra degli indirizzi: l’URL inizia con https:// e di solito compare l’icona di un lucchetto. In Chrome, una semplice pagina http:// mostra invece l’etichetta “Non sicuro”.

HTTPS protegge soltanto la connessione: non garantisce ciò che si trova nella pagina. Il lucchetto indica che i dati in transito sono cifrati; non dice nulla sull’affidabilità dei contenuti del sito, sulla legittimità di un modulo presente nella pagina o sull’effettiva esistenza dell’azienda che vi sta dietro. Anche i siti di phishing possono usare, e usano, certificati HTTPS validi.

HTTPS aiuta la SEO?

Storicamente, un po’. Nel 2014 Google ha confermato di utilizzare HTTPS come segnale di posizionamento, ma di entità molto ridotta; all’epoca lo stesso team di Google lo descrisse come un criterio di spareggio: a parità di ogni altro fattore, la pagina sicura poteva prevalere. Non farà superare a una pagina debole una pagina forte e le attuali indicazioni di Google non ribadiscono oggi un aumento diretto del posizionamento dovuto a HTTPS. Chi promette grandi miglioramenti “semplicemente aggiungendo SSL” sta esagerando.

I motivi davvero importanti sono questi:

• Chrome mostra “Non sicuro”. Dal 2018 ogni pagina HTTP riceve questo avviso, che allontana i visitatori a prescindere da ciò che pensa Google.
• Ora è lo standard di base. Si stima che 9 siti su 10 usino già HTTPS (W3Techs, 2026). Essere tra le eccezioni dà l’impressione che il sito non funzioni correttamente.
• Le funzionalità moderne lo richiedono. Molte capacità del browser, e le connessioni più veloci tramite HTTP/2, semplicemente non funzionano senza HTTPS.

Il passaggio può danneggiare il posizionamento?

No, se viene eseguito con attenzione. Il passaggio da HTTP a HTTPS è un tipo di migrazione del sito e la regola fondamentale è la stessa di ogni migrazione: reindirizza ogni vecchio URL verso la sua nuova versione sicura con un reindirizzamento 301. Se fatto bene, il posizionamento viene mantenuto. Se fatto in modo approssimativo, con reindirizzamenti mancanti o link interrotti a immagini e script, può comportare una perdita di traffico. Il passaggio in sé è sicuro; sono gli errori di esecuzione a causare danni. Prova a sostegno di questa affermazione Google recommends permanent server-side redirects during site moves and says HTTP-to-HTTPS moves do not use the Change of Address tool. Ambito: Google's site-move guide supports redirect and Search Console handling; it does not guarantee that a migration with implementation errors retains traffic. Attendibilità: alta · Verificato: 2026-07-14 Google Search Central: Site moves with URL changes

Vuoi il quadro completo, compresi il peso reale del segnale, la migrazione passo dopo passo, i contenuti misti e HSTS? Passa alla scheda Avanzato.

TL;DR — Le attuali indicazioni di Google sull’esperienza sulle pagine affermano che gli aspetti diversi dai Core Web Vitals “don’t directly help your website rank higher” (traduzione) «non aiutano direttamente il sito a posizionarsi più in alto»: non promettere quindi un vantaggio di posizionamento attuale dovuto a HTTPS. Ciò che è confermato è storico: nell’agosto 2014 Google annunciò HTTPS come un segnale di posizionamento “very lightweight” (traduzione) «molto debole», che interessava meno dell’1% delle query, e nel 2015 Gary Illyes lo descrisse come un criterio di spareggio. Sono osservazioni datate, non un meccanismo attuale documentato. Separatamente, oggi le indicazioni di Google sulla canonicalizzazione preferiscono attivamente le pagine HTTPS come canonical rispetto alle equivalenti HTTP, ma soltanto a determinate condizioni: un certificato non valido, dipendenze non sicure, un reindirizzamento HTTPS→HTTP o un tag canonical HTTP residuo possono invertire tale preferenza, e HSTS non può prevalere. I veri motivi per adottare HTTPS sono l’etichetta “Non sicuro” di Chrome, HTTP/2 in tutti i principali browser, le API moderne dei browser e il fatto che sia ormai un requisito di base, non una leva di crescita. La migrazione è una migrazione del sito: applica un 301 a ogni URL (i 301 non fanno perdere PageRank), correggi i contenuti misti attivi e passivi, aggiorna canonical, sitemap e link interni e verifica nuovamente Search Console. Lo strumento Cambio di indirizzo non serve per un passaggio di protocollo. HSTS e il suo reindirizzamento interno 307 costituiscono una protezione a livello di browser aggiuntiva rispetto ai 301 lato server, non un loro sostituto.

Google promette attualmente un vantaggio di posizionamento dovuto a HTTPS?

Parti da ciò che Google afferma oggi, non nel 2014. La sua attuale documentazione sull’esperienza sulle pagine dichiara che, oltre ai Core Web Vitals, gli aspetti dell’esperienza sulle pagine, tra i quali figura HTTPS, “don’t directly help your website rank higher in search results.” (traduzione) «non aiutano direttamente il sito a posizionarsi più in alto nei risultati di ricerca». È l’indicazione diretta più recente disponibile e non giustifica la promessa di un aumento attuale del posizionamento grazie a HTTPS.

Il segnale del 2014 e l’idea del “criterio di spareggio”: storia, non meccanica attuale

Ciò che è confermato appartiene alla storia: Google annunciò HTTPS come segnale di posizionamento il 6 agosto 2014 e fu insolitamente esplicita sul suo peso minimo al lancio. La formulazione originale era: “very lightweight signal—affecting fewer than 1% of global queries, and carrying less weight than other signals such as high-quality content” (traduzione) «un segnale molto debole, che interessa meno dell’1% delle query globali e pesa meno di altri segnali, come i contenuti di alta qualità». Il post aggiungeva che Google “may decide to strengthen it” (traduzione) «potrebbe decidere di rafforzarlo» nel tempo per favorirne l’adozione: “rafforzarlo”, non il “boost” con cui la stampa SEO lo ha spesso parafrasato. Prova a sostegno di questa affermazione Google announced HTTPS as a very lightweight ranking signal affecting fewer than one percent of global queries at launch. Ambito: Google's 2014 announcement establishes the signal and its weight at launch; it does not quantify the signal's current weight. Attendibilità: alta · Verificato: 2026-07-14 Google Search Central: HTTPS as a ranking signal

Un anno dopo, nel settembre 2015, Gary Illyes descrisse il segnale come un criterio di spareggio: “it acts more like a tiebreaker. For example, if all quality signals are equal for two results, then the one that is on HTTPS would get … or may get … the extra boost” (traduzione) «agisce più come un criterio di spareggio. Per esempio, se tutti i segnali di qualità sono uguali per due risultati, quello in HTTPS otterrebbe, o potrebbe ottenere, il vantaggio aggiuntivo». Nello stesso anno fu netto sulle priorità: “you should switch to HTTPS for users, not as a ranking signal” (traduzione) «dovresti passare a HTTPS per gli utenti, non come segnale di posizionamento». Anche l’impostazione proposta da John Mueller nello stesso periodo, secondo cui non bisogna aspettarsi variazioni visibili di posizionamento dal solo passaggio, va nella stessa direzione.

Considera “tiebreaker” (traduzione) «criterio di spareggio» come un commento rappresentativo ma datato di Illyes del 2015–2016, non come qualcosa che Google documenta attualmente come meccanismo di posizionamento attivo. La formulazione sull’esperienza sulle pagine citata sopra è la fonte più prudente e attuale. La risposta onesta e contestualizzata nel tempo alla domanda “HTTPS aiuta la SEO?” è quindi questa: nel 2014 Google confermò un segnale minore, nel 2015 un dipendente di Google lo descrisse come criterio di spareggio e le indicazioni attuali non ribadiscono direttamente tale meccanismo. Se devi decidere dove investire gli sforzi, HTTPS è un requisito di igiene tecnica, non una leva di crescita, qualunque sia oggi il peso esatto del segnale storico.

La preferenza di Google per HTTPS come canonical: condizionata, non basata soltanto sul protocollo

Separata dal segnale di posizionamento del 2014 è una preferenza di canonicalizzazione che Google documenta oggi: “Google prefers HTTPS pages over equivalent HTTP pages as canonical, except when there are issues or conflicting signals such as” (traduzione) «Google preferisce come canonical le pagine HTTPS rispetto alle equivalenti HTTP, tranne quando sono presenti problemi o segnali contrastanti come» un certificato SSL non valido, dipendenze non sicure diverse dalle immagini, una pagina HTTPS che reindirizza gli utenti verso o attraverso una pagina HTTP oppure una pagina HTTPS con un rel="canonical" diretto alla versione HTTP.

Questa è la sfumatura che quasi tutte le altre guide trascurano e contraddice una semplificazione comune, compresa la frase di Illyes del 2016 secondo cui il segnale di posizionamento “basically [looks] at the first five characters in front of the URL” (traduzione) «in pratica guarda i primi cinque caratteri davanti all’URL»: quella scorciatoia descrive il segnale di posizionamento del 2014, non questa decisione di canonicalizzazione. Le indicazioni di Google chiariscono che un certificato errato o un reindirizzamento con downgrade prevalgono sulla preferenza per HTTPS: “Avoid bad TLS/SSL certificates and HTTPS-to-HTTP redirects because they cause Google to prefer HTTP very strongly” (traduzione) «Evita certificati TLS/SSL non validi e reindirizzamenti da HTTPS a HTTP, perché inducono Google a preferire fortemente HTTP». HSTS non può risolvere il problema: “Implementing HSTS cannot override this strong preference” (traduzione) «L’implementazione di HSTS non può prevalere su questa forte preferenza».

La conseguenza pratica è che un certificato scaduto o configurato male non costituisce soltanto un problema di UX: può anche spingere Google a indicizzare la pagina HTTP anziché quella HTTPS che vuoi posizionare. Per conoscere i tipi di errore dei certificati e come diagnosticarli, consulta Certificati SSL/TLS; per interpretare il rapporto dedicato di Search Console su questa specifica decisione, consulta il rapporto HTTPS.

Perché HTTPS conta davvero

Mettendo da parte la questione del posizionamento, gli argomenti a favore di HTTPS sono schiaccianti, con una precisazione da chiarire subito: HTTPS protegge il canale di trasporto tra browser e server. Non controlla il codice dell’applicazione, non garantisce gli endpoint e non certifica le intenzioni dell’utente. Un sito HTTPS compromesso, un modulo di phishing servito tramite HTTPS e una violazione dei dati dopo la decifratura restano tutti possibili. HTTPS è un requisito di igiene necessario, non una garanzia di sicurezza per tutto ciò che avviene dopo la connessione.

Definito questo ambito, ecco gli aspetti pratici:

• L’avviso “Non sicuro” di Chrome. Da Chrome 68 (luglio 2018), Chrome contrassegna tutte le pagine HTTP come “non sicure”. L’etichetta compare nella barra degli indirizzi davanti ai visitatori reali: un problema di conversione molto più rilevante di qualsiasi piccolo vantaggio di posizionamento.
• È il prerequisito pratico per HTTP/2 e HTTP/3. Nessun browser diffuso implementa HTTP/2 sul semplice HTTP: tutti i principali browser lo negoziano soltanto tramite TLS, anche se la specifica HTTP/2 non impone la cifratura. Come osserva la documentazione di Google, “in some cases, TLS can improve performance, mostly as a result of making HTTP/2 possible.” (traduzione) «In alcuni casi TLS può migliorare le prestazioni, soprattutto perché rende possibile HTTP/2». È un “può”, non una garanzia: l’overhead di TLS, la configurazione del server e il riutilizzo delle connessioni continuano a contare. Tuttavia, il multiplexing e la compressione degli header di HTTP/2 rendono spesso un sito HTTPS+HTTP/2 più veloce di uno in semplice HTTP/1.1, il contrario del vecchio timore secondo cui TLS aggiunge latenza.
• Le funzionalità moderne del browser lo richiedono. Service worker, API di geolocalizzazione, fotocamera e microfono e applicazioni web progressive richiedono in genere un contesto sicuro; verifica la specifica funzionalità e il browser per eccezioni come localhost. Google afferma: “HTTPS is required for many new browser features, especially those required for progressive web apps” (traduzione) «HTTPS è necessario per molte nuove funzionalità dei browser, in particolare quelle richieste dalle applicazioni web progressive».
• Dati di provenienza e “dark traffic”: per impostazione predefinita, non universalmente. I browser che applicano la moderna Referrer-Policy predefinita (strict-origin-when-cross-origin) eliminano completamente l’header Referer quando un link porta da una pagina HTTPS a una destinazione HTTP; una navigazione con lo stesso protocollo o un upgrade continua a inviare almeno l’origine. Se il sito è ancora in HTTP, il traffico in uscita, e l’attribuzione in entrata, può quindi finire per apparire “diretto” per impostazione predefinita. L’header Referrer-Policy del sito può però modificare questo comportamento in entrambe le direzioni, quindi non trattarlo come una regola assoluta quando analizzi il divario nei dati di qualcun altro.
• È un requisito di base. Si stima che circa l’89% dei siti usi HTTPS (W3Techs, 2026: è una stima indicativa, non un conteggio attuale esatto). La questione SEO non è il vantaggio del passaggio, ma il rischio di essere l’eccezione visibile.

Migrazione da HTTP a HTTPS

Il passaggio HTTP→HTTPS è una migrazione del sito e merita la stessa disciplina. La buona notizia arriva direttamente dalle indicazioni di Google sulle migrazioni dei siti: “301 and other permanent redirects don’t cause a loss in PageRank” (traduzione) «I reindirizzamenti 301 e gli altri reindirizzamenti permanenti non causano una perdita di PageRank». Il vecchio timore che il passaggio faccia perdere l’autorevolezza dei link è un mito: il rischio risiede interamente nell’esecuzione, non nel cambio di protocollo. Sono i 301 mancanti, i contenuti misti, i canonical obsoleti e una proprietà HTTPS non verificata in Search Console a costare realmente traffico.

La disciplina essenziale in un paragrafo: misura prima il sito HTTP attivo (scansione, posizionamenti, esportazione di Search Console, profilo dei backlink); procurati un certificato TLS (un certificato DV gratuito di Let’s Encrypt trasmette lo stesso segnale di uno OV/EV a pagamento); reindirizza con 301 ogni URL HTTP alla corrispondente versione HTTPS uno a uno; rendi HTTPS canonical ovunque (link interni, sitemap, hreflang: non affidarti ai reindirizzamenti per nascondere link interni obsoleti); correggi i contenuti misti prima del passaggio; verifica nuovamente tutte e quattro le proprietà di Search Console (lo strumento Cambio di indirizzo non serve per un cambio di protocollo); mantieni attivi i reindirizzamenti per almeno un anno. Aspettati oscillazioni temporanee del posizionamento: un calo che si riassorbe indica che la migrazione si sta assestando; se persiste, qualcosa si è rotto.

Questa è la mappa dei rischi, non il manuale operativo. Per la sequenza dettagliata, la prova in ambiente di staging, la mappatura dei reindirizzamenti su larga scala, il piano di rollback e la checklist completa, consulta Migrazione da HTTP a HTTPS. Questa pagina resta una panoramica concisa, così da non divergere dalla guida più approfondita.

Contenuti misti

Si parla di contenuti misti quando una pagina HTTPS carica una sottorisorsa tramite HTTP. Ne esistono due tipi e la distinzione determina le priorità:

• Contenuti misti attivi — script, fogli di stile, iframe, XMLHttpRequest. I browser li bloccano completamente, perché uno script alterato può riscrivere l’intera pagina. È ciò che può rompere davvero il sito dopo una migrazione, quindi va corretto per primo.
• Contenuti misti passivi — immagini, audio e video. In genere i browser li mostrano comunque, ma riducono l’indicatore di sicurezza e visualizzano un avviso.

Individuali eseguendo una scansione del sito HTTPS (Ahrefs Site Audit, Screaming Frog), osservando la console di Chrome DevTools oppure raccogliendo i report CSP. La soluzione preventiva più pulita è l’header Content-Security-Policy: upgrade-insecure-requests, che indica al browser di riscrivere automaticamente le richieste di sottorisorse da http:// a https:// prima di effettuarle: un’utile rete di sicurezza durante e dopo la migrazione. I normali link di ancoraggio verso pagine HTTP non sono contenuti misti; producono semplicemente una navigazione.

HSTS e perché non sostituisce i reindirizzamenti 301

HSTS, HTTP Strict Transport Security, è un header di risposta (Strict-Transport-Security) che dice ai browser di usare sempre HTTPS per il dominio, anche quando l’utente digita o seleziona un link http://. Risolve il “first request problem” (traduzione) «problema della prima richiesta»: con il solo 301, la primissima richiesta di un nuovo visitatore viene comunque inviata tramite HTTP prima che scatti il reindirizzamento, creando la finestra cercata da un aggressore che esegue SSL stripping. Secondo la documentazione di Google, HSTS consente di “avoid the cost of the 301 redirect” (traduzione) «evitare il costo del reindirizzamento 301» per i visitatori di ritorno e “defeats attacks like SSL Stripping” (traduzione) «contrasta attacchi come SSL stripping».

Due aspetti che chi si occupa di SEO deve tenere distinti:

• HSTS non sostituisce i 301 lato server. Quando un browser rispetta HSTS, esegue un reindirizzamento 307 interno verso HTTPS. Ciò accade però all’interno del browser, dove i crawler non lo vedono. I motori di ricerca hanno comunque bisogno del vero 301 lato server per comprendere la migrazione e trasferire l’autorevolezza dei link. Servono entrambi.
• Il precaricamento HSTS è quasi permanente. Puoi inviare il dominio alla lista di precaricamento incorporata nei browser, che richiede un max-age di almeno un anno, includeSubDomains e preload, chiudendo il divario anche per chi visita il sito per la prima volta. Uscire dalla lista è però lento e difficile. Google avverte: “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 abilitare HSTS finché non sei certo che il sito sia abbastanza solido da non pubblicare mai HTTPS con errori di convalida del certificato». Considera il precaricamento una scelta quasi irreversibile.

Miti comuni

• “HTTPS offre oggi un grande vantaggio di posizionamento.” No: il segnale “molto debole” del 2014, che interessava meno dell’1% delle query, e l’idea del “criterio di spareggio” del 2015 sono osservazioni datate; le indicazioni attuali affermano che gli aspetti dell’esperienza sulle pagine diversi dai Core Web Vitals “don’t directly help you rank higher” (traduzione) «non aiutano direttamente a posizionarsi più in alto».
• “Il passaggio farà crollare il posizionamento.” Non se i reindirizzamenti sono eseguiti correttamente: i 301 non fanno perdere PageRank. Sono le migrazioni mal gestite a danneggiare il sito, non il cambio di protocollo.
• “Serve lo strumento Cambio di indirizzo.” Non per HTTP→HTTPS: serve soltanto per i cambi di dominio.
• “Un certificato scaduto rovina soltanto la UX, non la SEO.” No: un certificato non valido è una delle condizioni esplicitamente indicate che possono spostare la preferenza canonical di Google dalla pagina HTTPS a quella HTTP, oltre a rendere la pagina inaccessibile agli utenti.
• “HTTPS conta soltanto nelle pagine di pagamento.” No: Chrome segnala ogni pagina HTTP e le API moderne richiedono in genere un contesto sicuro.
• “TLS rende i siti più lenti.” Nella pratica spesso accade il contrario, perché HTTPS abilita HTTP/2, anche se TLS “può” migliorare le prestazioni e non lo garantisce.

La migrazione HTTP→HTTPS rientra nella disciplina più ampia delle migrazioni dei siti. Se stai cambiando contemporaneamente anche dominio o piattaforma, consulta prima quella guida, perché sovrapporre più migrazioni moltiplica il rischio.

Riepilogo IA

Una sintesi della versione Avanzato:

• Le attuali indicazioni di Google non promettono un aumento del posizionamento. Il documento sull’esperienza sulle pagine afferma che gli aspetti diversi dai Core Web Vitals “don’t directly help your website rank higher” (traduzione) «non aiutano direttamente il sito a posizionarsi più in alto»; HTTPS è elencato tra questi.
• Il segnale del 2014 e l’idea del “criterio di spareggio” del 2015 sono storici. “Molto debole”, meno dell’1% delle query nel 2014; la frase di Illyes sul criterio di spareggio nel 2015: commenti datati, non un meccanismo attuale ribadito. In ogni caso, non considerare HTTPS una leva di crescita.
• La preferenza canonical di Google per HTTPS è separata e condizionata. Oggi Google preferisce le pagine HTTPS come canonical, tranne quando esistono un certificato non valido, dipendenze non sicure diverse dalle immagini, un reindirizzamento HTTPS→HTTP o un tag canonical HTTP residuo; HSTS non può prevalere. Un certificato non valido è un rischio di canonicalizzazione, non soltanto di UX.
• HTTPS protegge soltanto il trasporto, non la logica dell’applicazione, gli endpoint o l’intento dell’utente; una pagina di phishing può funzionare con HTTPS valido.
• I veri motivi per adottare HTTPS: l’etichetta “Non sicuro” di Chrome su tutte le pagine HTTP dal luglio 2018; HTTP/2 in tutti i browser principali, spesso più veloce di HTTP/1.1, pur senza garanzia di miglioramento da TLS; funzionalità dei browser che richiedono un contesto sicuro e PWA; comportamento predefinito, ma modificabile, dei dati di provenienza; un’adozione stimata di circa l’89% del web, che ne fa un requisito di base.
• La migrazione è una migrazione del sito, qui descritta in sintesi. Reindirizza con 301 ogni URL uno a uno (i 301 non fanno perdere PageRank), rendi HTTPS canonical, aggiorna link interni, sitemap e hreflang, correggi i contenuti misti, verifica nuovamente in GSC (HTTP e HTTPS sono proprietà separate), mantieni i reindirizzamenti per almeno un anno e non usare lo strumento Cambio di indirizzo per un cambio di protocollo. I passaggi completi sono nella pagina dedicata alla migrazione.
• Contenuti misti: quelli attivi (script e iframe) vengono bloccati e vanno corretti per primi; quelli passivi (immagini) producono un avviso. La CSP upgrade-insecure-requests è una rete preventiva.
• HSTS chiude il divario della prima richiesta, ma usa un 307 visibile soltanto al browser e invisibile ai crawler: si aggiunge ai 301 lato server, non li sostituisce. Il precaricamento è quasi permanente; non affrettarlo.

Documentazione ufficiale

Documentazione di prima fonte dei motori di ricerca e dei team dei browser.

Google

• HTTPS come segnale di posizionamento (annuncio del 2014) — il post originale sul “very lightweight signal” (traduzione) «segnale molto debole».
• Abilitare HTTPS sui server (web.dev) — certificati, 301, canonical, HSTS e cookie.
• Perché HTTPS conta (web.dev) — sicurezza e funzionalità dei browser.
• Correggere i contenuti misti (web.dev) — contenuti misti attivi e passivi e upgrade-insecure-requests.
• Migrazioni dei siti con modifiche degli URL — la procedura di migrazione, compresi reindirizzamenti e mancato uso dello strumento Cambio di indirizzo per HTTPS.
• Comprendere l’esperienza sulle pagine — la posizione di HTTPS nel quadro dell’esperienza sulle pagine e la fonte attuale per non aspettarsi un aumento diretto del posizionamento.
• Come specificare un URL canonical — l’attuale preferenza condizionata tra HTTPS e HTTP e le eccezioni, come certificati non validi, dipendenze non sicure e reindirizzamenti con downgrade, che prevalgono su di essa.

Chrome / Chromium

• Verso un web più sicuro (2016) — l’inizio dell’introduzione dell’etichetta “Non sicuro”.
• Un web sicuro è qui per restare (2018) — Chrome 68 contrassegna tutti i siti HTTP come “non sicuri”.

Bing / Microsoft

• Linee guida di Bing per webmaster — indicazioni generali; verifica nel browser la formulazione attuale relativa a HTTPS.

Citazioni dalle fonti

Dichiarazioni pubbliche di Google. Ogni link è un collegamento diretto al passaggio citato nella pagina di origine.

Google — l’annuncio del segnale di posizionamento nel 2014

• “We’re starting to use HTTPS as a ranking signal. For now it’s only a very lightweight signal—affecting fewer than 1% of global queries, and carrying less weight than other signals such as high-quality content.” (traduzione) «Stiamo iniziando a usare HTTPS come segnale di posizionamento. Per ora è soltanto un segnale molto debole, che interessa meno dell’1% delle query globali e pesa meno di altri segnali, come i contenuti di alta qualità.» — Zineb Ait Bahajji e Gary Illyes, Google. Vai alla citazione
• “But over time, we may decide to strengthen it, because we’d like to encourage all website owners to switch from HTTP to HTTPS.” (traduzione) «Nel tempo, però, potremmo decidere di rafforzarlo, perché vorremmo incoraggiare tutti i proprietari di siti web a passare da HTTP a HTTPS.» — stesso post. Vai alla citazione

Gary Illyes — l’idea del criterio di spareggio

• “With the HTTPS ranking boost, it acts more like a tiebreaker. For example, if all quality signals are equal for two results, then the one that is on HTTPS would get … or may get … the extra boost that is needed to trump the other result.” (traduzione) «Per quanto riguarda il vantaggio di posizionamento di HTTPS, agisce più come un criterio di spareggio. Per esempio, se tutti i segnali di qualità sono uguali per due risultati, quello in HTTPS otterrebbe, o potrebbe ottenere, il vantaggio aggiuntivo necessario a superare l’altro risultato.» — Gary Illyes, Google (tramite Search Engine Land). Leggi l’articolo
• “You should switch to HTTPS for users, not as a ranking signal.” (traduzione) «Dovresti passare a HTTPS per gli utenti, non come segnale di posizionamento.» — Gary Illyes, SMX East 2015 (tramite Search Engine Land). Leggi l’articolo
• “Basically looking at the first five characters in front of the URL, and if it’s HTTPS … it will get a minimal boost.” (traduzione) «In pratica guarda i primi cinque caratteri davanti all’URL e, se sono HTTPS, otterrà un vantaggio minimo.» — Gary Illyes, 2016 (tramite Search Engine Land). Leggi l’articolo

Google — preferenza canonical per HTTPS (indicazioni attuali)

• “Google prefers HTTPS pages over equivalent HTTP pages as canonical, except when there are issues or conflicting signals such as the following.” (traduzione) «Google preferisce come canonical le pagine HTTPS rispetto alle equivalenti HTTP, tranne quando sono presenti problemi o segnali contrastanti come i seguenti.» — Google Search Central. Vai alla citazione
• “Avoid bad TLS/SSL certificates and HTTPS-to-HTTP redirects because they cause Google to prefer HTTP very strongly.” (traduzione) «Evita certificati TLS/SSL non validi e reindirizzamenti da HTTPS a HTTP, perché inducono Google a preferire fortemente HTTP.» — Google Search Central. Vai alla citazione
• “Implementing HSTS cannot override this strong preference.” (traduzione) «L’implementazione di HSTS non può prevalere su questa forte preferenza.» — Google Search Central. Vai alla citazione

Google — indicazioni su migrazione e HSTS

• “301 and other permanent redirects don’t cause a loss in PageRank.” (traduzione) «I reindirizzamenti 301 e gli altri reindirizzamenti permanenti non causano una perdita di PageRank.» — Google Search Central. Vai alla citazione
• “If you’re moving your site from HTTP to HTTPS, you don’t need to use the Change of Address tool.” (traduzione) «Se stai spostando il sito da HTTP a HTTPS, non devi usare lo strumento Cambio di indirizzo.» — Google Search Central. Vai alla citazione
• “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 abilitare HSTS finché non sei certo che il sito sia abbastanza solido da non pubblicare mai HTTPS con errori di convalida del certificato.» — web.dev (Google). Vai alla citazione
• “In some cases, TLS can improve performance, mostly as a result of making HTTP/2 possible.” (traduzione) «In alcuni casi TLS può migliorare le prestazioni, soprattutto perché rende possibile HTTP/2.» — web.dev (Google). Vai alla citazione

Chrome — l’introduzione dell’etichetta “Non sicuro”

• “Beginning in July 2018 with the release of Chrome 68, Chrome will mark all HTTP sites as ‘not secure’.” (traduzione) «A partire da luglio 2018, con il rilascio di Chrome 68, Chrome contrassegnerà tutti i siti HTTP come “non sicuri”.» — Emily Schechter, Chrome Security (Chromium Blog). Vai alla citazione

Checklist per la migrazione HTTP → HTTPS

Una versione sintetica da controllare prima del lancio. Per la checklist completa, la prova in staging e il piano di rollback, consulta Migrazione da HTTP a HTTPS.

Prima

• Salva una scansione completa del sito HTTP attivo (ogni risposta 200 e ogni reindirizzamento esistente).
• Archivia un’istantanea dei posizionamenti, un’esportazione di Search Console e il profilo dei backlink.
• Procurati e testa il certificato TLS (per il segnale va bene un certificato DV gratuito).

Il passaggio

• Ogni URL HTTP viene reindirizzato con un 301 lato server e uno a uno verso il suo equivalente HTTPS.
• Nessuna catena di reindirizzamenti: il vecchio URL deve puntare direttamente all’URL HTTPS finale.
• Nessun reindirizzamento in massa alla home page per URL senza corrispondenza.
• Ogni pagina fa riferimento al proprio URL HTTPS tramite rel="canonical".
• Link interni, sitemap XML e hreflang sono aggiornati a HTTPS, senza lasciare il lavoro ai reindirizzamenti.
• I contenuti misti attivi (script, stili, iframe) sono corretti: vengono bloccati.
• I contenuti misti passivi (immagini e media) sono corretti; è impostata la CSP upgrade-insecure-requests.

Search Console e dopo il passaggio

• La proprietà HTTPS è verificata in GSC, oppure è presente una proprietà Dominio che copre tutte le varianti.
• La nuova sitemap HTTPS è stata inviata.
• Lo strumento Cambio di indirizzo non è stato usato: serve soltanto per le migrazioni di dominio.
• Il file disavow, se presente, è stato controllato per individuare URL HTTP.
• I reindirizzamenti vengono mantenuti per almeno 1 anno, idealmente per tutta la vita del sito.
• Indicizzazione e Statistiche di scansione vengono monitorate; un calo che non si riassorbe indica che qualcosa si è rotto.

I modelli mentali

1. HTTPS è igiene tecnica, non una leva di crescita. “Molto debole”, meno dell’1% delle query, un criterio di spareggio. Dedica gli sforzi per il posizionamento a contenuti e link; adotta HTTPS perché il web lo richiede, poi passa oltre.

2. Separa il segnale di posizionamento del 2014 dall’attuale preferenza canonical. Il segnale di posizionamento del 2014 era storicamente basato sul protocollo; la frase di Illyes sui “primi cinque caratteri” lo descrive ed è un commento datato, non un meccanismo attuale documentato. L’attuale preferenza canonical di Google per HTTPS è diversa e condizionata: un certificato non valido, dipendenze non sicure o un reindirizzamento con downgrade possono spingere Google a indicizzare la pagina HTTP. Un certificato non valido non è quindi soltanto un’emergenza di UX: può costare anche il canonical HTTPS.

3. Una migrazione viene sostenuta dai 301; tutto il resto è un segnale di supporto. I reindirizzamenti, che non fanno perdere PageRank, svolgono il vero lavoro di trasferimento del posizionamento. Canonical, sitemap, aggiornamenti dei link interni e nuova verifica in GSC aiutano soltanto Google a elaborare la migrazione in modo più rapido e pulito.

4. Esistono due livelli per “forzare HTTPS” e servono entrambi. Il 301 lato server è destinato ai crawler e all’autorevolezza dei link. HSTS, con un 307 visibile soltanto al browser, protegge i visitatori umani di ritorno e dagli attacchi di SSL stripping. Risolvono problemi diversi: HSTS non sostituisce mai il 301.

5. Contenuti misti: assegna la priorità in base al comportamento del browser. Quelli attivi (script, stili, iframe) vengono bloccati: correggerli è necessario per il funzionamento e va fatto per primo. Quelli passivi (immagini e media) producono soltanto un avviso: correggili subito dopo. upgrade-insecure-requests è la rete di sicurezza per ciò che sfugge.

HTTPS per la SEO — scheda di riferimento

La realtà del posizionamento

Informazioni su reindirizzamenti e migrazione

Contenuti misti e HSTS

Forzare HTTPS e impostare HSTS

Esempi per i due stack più comuni. Esegui prima i test in staging: un header HSTS resta memorizzato e un ciclo di reindirizzamento configurato male impedisce l’accesso agli utenti.

Apache (.htaccess)

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

# HSTS — only add once you're confident HTTPS is solid
<IfModule mod_headers.c>
  Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"
</IfModule>

Nginx

# Redirect HTTP → HTTPS
server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://$host$request_uri;
}

# On the HTTPS server block, add HSTS
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;

Aggiungi ; preload all’header HSTS soltanto se intendi inviare il dominio a hstspreload.org: è una scelta quasi irreversibile.

Individuare i contenuti misti dalla riga di comando

Esegui la scansione delle pagine HTTPS e cerca nell’HTML eventuali sottorisorse http:// rimaste.

macOS / Linux

# Pull a page and flag insecure script/img/link/iframe sources
curl -s https://example.com/ \
  | grep -Eo '(src|href)="http://[^"]+"' \
  | sort -u

Windows (PowerShell)

# Same idea in PowerShell
(Invoke-WebRequest -Uri "https://example.com/").Content `
  | Select-String -Pattern '(src|href)="http://[^"]+"' -AllMatches `
  | ForEach-Object { $_.Matches.Value } | Sort-Object -Unique

Per un controllo dell’intero sito, un crawler (Ahrefs Site Audit, Screaming Frog) o la console di Chrome DevTools è più veloce di uno script eseguito pagina per pagina.

Risorse che meritano il tuo tempo

I miei interventi

• Meglio essere prudenti con HTTPS — SMX East 2016 (SlideShare) — il mio approfondimento su TLS, gli errori comuni nell’implementazione di HTTPS e le insidie della migrazione. Vale la consueta precisazione: rappresenta la mia comprensione di questi sistemi e le statistiche sull’adozione risalgono al 2016.

I miei articoli correlati

• Guida introduttiva al SEO tecnico — dove si colloca HTTPS nel quadro generale.

Da altre fonti ufficiali

• Abilitare HTTPS sui server e Correggere i contenuti misti di Google — la raccolta più utile e concentrata di documentazione sull’implementazione.
• hstspreload.org — verifica l’idoneità prima di impegnarti con il precaricamento.
• SSL Labs Server Test — valuta la configurazione TLS.

Dal settore

• HTTPS come fattore di posizionamento — Search Engine Journal — l’analisi di SEJ del segnale, del suo peso reale e del motivo per cui resta un criterio di spareggio anziché una leva.
• Gary Illyes di Google: HTTPS può decidere tra due risultati equivalenti (Search Engine Land) — l’articolo originale sull’idea del “criterio di spareggio” di Illyes.
• Google inizia a favorire nel posizionamento i siti sicuri HTTPS/SSL (Search Engine Land) — la copertura dell’annuncio del 2014 e le prime reazioni del settore.
• HSTS: che cos’è e come usarlo (Kinsta) — guida pratica che tratta i rischi della lista di precaricamento e le difficoltà di uscita.
• Let’s Encrypt — autorità di certificazione DV gratuita e automatizzata, ampiamente usata dai siti che necessitano semplicemente del protocollo https:// senza pagare per OV/EV.
• HTTPS Is Easy (Troy Hunt) — breve serie di video che semplifica la configurazione TLS per chi parte da zero.

Statistiche utili da citare

• HTTPS is “a very lightweight signal—affecting fewer than 1% of global queries.” (traduzione) «HTTPS è un segnale molto debole, che interessa meno dell’1% delle query globali.» È la formulazione di Google sul peso del segnale al lancio nel 2014: un dato storico, ancora il numero migliore per definire correttamente le aspettative, ma non una descrizione dei meccanismi attuali. Fonte
• “Chrome will mark all HTTP sites as not secure.” (traduzione) «Chrome contrassegnerà tutti i siti HTTP come non sicuri.» Questo vale da Chrome 68 (luglio 2018) ed è il motivo pratico più visibile per effettuare il passaggio. Fonte
• Circa l’89% dei siti web usa ormai HTTPS. È un requisito di base: il rischio SEO sta nell’essere tra le eccezioni, non nel mancato vantaggio del passaggio (W3Techs, 2026; verifica il dato attuale).
• “301 and other permanent redirects don’t cause a loss in PageRank.” (traduzione) «I reindirizzamenti 301 e gli altri reindirizzamenti permanenti non causano una perdita di PageRank.» È l’affermazione netta di Google che smentisce il mito secondo cui il passaggio fa perdere autorevolezza dei link. Fonte

Mettiti alla prova: HTTPS per la SEO

Cinque domande rapide su HTTPS per la SEO. Scegli una risposta per ciascuna, poi verifica il risultato.

Cronologia modifiche