HTTPS protegge le comunicazioni tra il tuo browser ed il server dal venir intercettato e danneggiato da attaccanti. Provvede confidenzialità, integrità ed autenticazione alla grande maggioranza del traffico WWW attuale.
Cosa troverai in questo articolo:
- Le basi di HTTP e HTTPS
- Come funziona il certificato TLS
- Come HTTPS aiuta la SEO
- Come impostare HTTPS
- Come controllare i possibili errori HTTPS in migrazione
Primo, lasciami semplificare ed illustrare la comunicazione tra il client (browser) ed il server quando c’è un attaccante nel mezzo.
Come puoi vedere, gli attaccanti possono ottenere dati sensibili come dettagli di login e pagamenti oppure iniettare codice malevolo nelle risorse richieste.
Attacchi potenziali ai network possono succedere ovunque con un router o ISP non fidato. Ogni network di WiFi pubblico è quindi vulnerabile a questi attacchi. Fortunatamente, sembra che il pubblico generale stia prendendo coscienza di questo fatto (aumentando l’uso di VPN).
Tuttavia, il peso di rendere l’esperienza di navigazione sicura è e dovrebbe essere a carico dei webmaster.
Ecco dove l’adozione del HTTPS viene in aiuto.
HTTPS effettua la crittografia alle richieste HTTP e alle risposte così un attaccante che vuole intercettarle vedrà solamente caratteri casuali invece dei dettagli della carta di credito, ad esempio.
Una analogia di come funziona HTTPS è l’invio di cose di valore dentro una scatola indistruttibile con chiusura a combinazione. Solo le parti emittenti e riceventi conoscono la combinazione e se un attaccante ne viene a conoscenza, non può scoprirne il contenuto.
Ora, succedono molte cose quando si crea una connessione HTTPS. Principalmente, HTTPS si affida alla crittografia TLS (Transfer Layer Security) per assicurare le connessioni.
L’unico modo di abilitare HTTPS nel tuo sito web è l’ottenimento di un certificato TLS e l’installazione nel server. Lo potrai vedere anche come certificato SSL o SSL/TLS ma non ti preoccupare, è la stessa cosa. SSL è una terminologia più diffusa anche se stiamo usando tecnicamente il suo successore TLS.
I certificati TLS sono rilasciati dalle Certificate Authorities (CA). Il ruolo del CA è di essere una terza parte fidata nella relazione client-server. Di base, ognuno potrebbe emettere certificati TLS ma solamente le CA pubblicamente fidate sono supportate dai browser.
Puoi controllare il certificato TLS di ogni sito web e il CA che l’ha rilasciato cliccando nell’icona a lucchetto nella barra degli indirizzi del tuo browser.
Puoi cliccare sul certificato per avere maggiori informazioni. La cosa importante qui è la scritta “Verificato da:” Qui potremmo trovarci di fronte a tipi diversi di standard di validazione per i certificati TLS, che sono la principale differenza tra certificati gratuiti ed a pagamento.
DV, OV ed EV: Cosa significano e quale conviene utilizzare?
I certificati TLS gratuiti che ottieni con il piano del tuo hosting e CDN hanno solamente la validazione del dominio (DV). Questo valida che il proprietario del certificato controlla un dato nome di dominio. Questa tecnica basilare di validazione è abbastanza buona per blog e siti web che non maneggiano informazioni sensibili, ma non sono l’ideale per quelli che lo fanno.
I siti web che utilizzano un certificato TLS DV appaiono sicuri ma non vedrai la linea “Verificato da:” quando clicchi sull’icona del lucchetto.
I certificati TLS DV più comuni provengono da una CA non-profit chiamata Let’s Encrypt. Questo è quello che le aziende che usano come certificati TLS gratuiti rinnovabili.
Non c’è nulla di sbagliato con i certificati solo-DV, dopo tutto è l’unico tipo di certificato TLS che può essere affidato in modo scalabile. Tuttavia, HTTPS è sicuro a seconda del certificato sottostante che autentica i server ai quali stai chiedendo informazioni.
Se il tuo sito web permette pagamenti o registrazioni, dovresti investire in certificati TLS che offrono validazione per l’organizzazione (OV) o validazione estesa (EV). Queste due tipologie si differenziano per il processo di verifica e quello EV è più rigoroso.
Se stai cercando di acquistarne uno, ti consiglio di prendere direttamente il certificato TLS EV. E’ il più affidabile e non costa molto di più dell’OV.
Wildcard e certificati SAN TLS
Ora, lasciamo gli standard di validazione, e parliamo di un’altra categoria di certificati TLS.
Certificati wildcard e SAN sono utilizzati per assicurare multipli (sotto)domini tutti assieme. Se compri un certificato TLS EV standard per esempio.com, ne avrai bisogno di un altro per blog.esempio.com.
I certificati wildcard possono assicurare sottodomini illimitati (esempio.com, blog.esempio.com, docs.esempio.com) mentre i certificati SAN hanno anche l’opzione di assicurare altri domini (esempio.com, blog.esempio.com, diverso.org).
Queste tipologie sono associate alla validazione quindi vedrai ogni tipo di combinazione quando navigherai tra tutte le opzioni che i CA offrono. Ti guideranno anche attraverso il processo di validazione.
Praticamente ogni beneficio di HTTPS coinvolge la SEO:
- Segnale di ranking leggero
- Maggior privacy e sicurezza
- Dati di referral preservati
- Abilita l’uso di protocolli moderni che aumentano la sicurezza e velocità del sito
Segnale di ranking leggero
Google ha annunciato che HTTPS è un leggero fattore di classificazione nel lontano 2014. E’ più una sicurezza rispetto a qualcosa che aumenta vertiginosamente le tue posizioni se le altre variabili di posizionamento restano costanti.
E’ stato un contributo effettivo di Google per velocizzare l’adozione di HTTPS nel mondo.
Maggior privacy e sicurezza
Ne abbiamo già parlato. Ma queste cose come sono legate alla SEO?
Quando arrivi in un sito web non sicuro, vedrai qualcosa simile a questo:
Non è il massimo della fiducia, giusto? Sono cosciente dei miei bias professionali ma io personalmente presto attenzione a questo e mi faccio subito una brutta prima impressione se vedo questo in un sito web.
La mia intuizione è che la migrazione ad HTTPS può aumentare il tempo di permanenza e ridurre l’andirivieni dalla SERP. Mentre queste sono fattori di classificazione solamente teorizzati (e non confermati), voler ‘trattenere’ le persone quando arrivano nel tuo sito web è qualcosa che devi solere indipendentemente dalla SEO.
Dati di referral preservati
Se il tuo sito web è ancora in HTTP e stai usando un servizio di web analytics come Google Analytics, ho una brutta notizia per te: dati no referral sono passati da pagine HTTPS a HTTP.
Siccome molto nel web oggi gira con HTTPS, la fonte di molto traffico referral (click su link da altri siti web) sarà etichettata come diretta in molti software di analytics.
Uno svantaggio di questo è che rende i tuoi dati confusionari ed alterati. Un altro è che non sarai in grado di vedere le tue migliori fonti referral—e questo è uno spreco per le opportunità di link building.
Abilita l’uso di protocolli moderni che aumentino la sicurezza e velocità del sito
Sulla carta, HTTPS è più lento di HTTP per l’aggiunta delle funzionalità di sicurezza. Tuttavia, avere HTTPS è il prerequisito per l’uso delle ultime tecnologie di performance e sicurezza.
In altre parole, sicurezza a parte, HTTPS abilita il miglioramento del tuo sito web nel page speed quando usi protocolli come TLS 1.3 e HTTP/2. Ed oltre alla miglior esperienza utente, Google considera la velocità delle pagine come un segnale leggero di classificazione come per HTTPS:
Ranking wise it’s a teeny tiny factor, very similar to https ranking boost. That particular one is not surprising. You do that primarily to enable users to convert.
— Socially distant Gary Illyes (@methode) April 28, 2020
Dipende dal tuo scenario.
1. Stai lanciando un nuovo sito web
Hai vinto alla lotteria. Comincia subito con HTTPS dall’inizio e non dovrai mai preoccuparti di HTTP ed errori associati con la migrazione.
Tutto ciò che dovrai fare è avere un buon provider per l’hosting che ti guiderà nel processo, e che supporti le ultime versioni del protocollo HTTP e TLS. Dopo che tutto è online e funzionante, implementa HSTS come ultimo passaggio per migliorare la sicurezza.
2. Hai già un sito web abilitato HTTPS
Il fatto che tu stia leggendo questo articolo mi dice che probabilmente non hai le impostazioni corrette. Segui gli avvisi nella prossima sessione per controllare gli errori più comuni.
3. Hai un sito che funziona ancora in HTTP
Servirà un po’ di lavoro per preparare e sistemare tutto. La complessità della migrazione dipende da:
- La dimensione e la complessità del tuo sito web
- Che tipo di CMS utilizzi
- Il tuo provider hosting e CDN
- Le tue capacità tecniche
Mentre credo che i proprietari di piccoli siti web che girano su CMS popolari e buoni hosting possono fare da soli la migrazione, ci sono molte variabili in gioco.
Ti suggerisco di controllare la documentazione del tuo CMS/server/hosting/CDN e di prodecere di conseguenza—e con cautela. Ci sono molti passaggi che devi eseguire quindi crea o segui un elenco di controllo per la migrazione e non provare ad inserirci altre attività.
Se tutto questo ti sembra molto tecnico, assumi un professionista. Ti risparmierà ore del tuo tempo, i tuoi nervi, e ti assicura una implementazione a prova di futuro.
Anche se hai eseguito tutti i punti della lista di controllo di migrazione a HTTPS, ci sono possibilità che tu abbia avuto qualche problema.
Infatti, nel 2016, abbiamo analizzato 10.000 domini in cima alle classifiche per trovare vari errori HTTPS ed abbiamo scoperto che:
- 90,9% dei domini ha una implementazione HTTPS sub-ottimale
- HTTPS non funzionava correttamente nel 65,39% dei domini
- Il 23,01% dei domini utilizzava redirect temporanei 302 invece dei permanenti 301
Mentre molto è cambiato e migliorato da allora, ti raccomanderei di controllare i 5 errori più comuni nella migrazione HTTPS di seguito. Non servirà molto tempo, e molti non sono difficili da sistemare.
Errore 1: pagine rimaste in HTTP
Prima di tutto, devi essere sicuro che tutte le pagine del tuo sito siano già in HTTPS.
Puoi scovare pagine rimaste in HTTP con una navigazione casuale del sito web. Non dovrebbe essere una novità se hai seguito qualche elenco di controllo per migrazione a HTTPS. Assicurati solamente che il crawler abbia tutte le fonti URL richieste così da non lasciare indietro delle pagine.
Se stai usando il Site Audit di Ahrefs, ti raccomando il seguente setup:
Dopo averlo fatto, apri l’ultima scansione, vai su Page Explorer ed applica il seguente filtro:
Esporta la lista degli URL HTTP e reindirizza per concludere la migrazione.
Le pagine che non sono nella tua sitemap e non hanno link che puntano ad esse sono impossibili da scoprire dalla scansione. Può succedere spesso con pagine landing dedicate al PPC. Un modo di trovarle è esportare la lista di URL dal tuo manager di pubblicità come Google Ads o FB Business Manager.
Da lì, assicurati che le pagine orfane siano propriamente migrate. E non scordare di aggiornarle nei cruscotti delle campagne nel nuovo formato HTTPS.
Errore 2: pagine HTTPS con HTTP
Questo errore succede quando il file iniziale HTML è caricato usando HTTPS ma i suoi file di risorse (immagini, CSS, JavaScript) non sono ancora aggiornati a HTTPS.
Se questo è un problema nel tuo sito web, lo vedrai sia nell’anteprima della scansione sia nel report delle pagine interne. Tutti gli errori, avvertimenti e segnalazioni nel Site Audit contengono una descrizione del problema e un suggerimento su come sistemarlo.
Errore 3: link interni non aggiornato a HTTPS
Non aggiornare i tuoi link interni ad HTTPS causa redirect non necessari. Questo è molto meglio rispetto all’atterraggio in una pagina landing HTTP ma siamo già andati oltre a questo errore. E’ facile trovare questi link e sistemarli.
Troverai questi errori nel report Link in Site Audit:
Ti basta riscrivere gli URL con https:// ed avrai risolto. Questo è fattibile se ti sei già assicurato che nessuna pagina è rimasta HTTP utilizzando gli avvisi dell’errore #1.
Errore 4: Tag non aggiornati ad HTTPS
Ci sono 2 tipi di tag che potresti utilizzare nel tuo sito web che chiedono anche loro un aggiornamento dell’URL ad HTTPS: tag canonical e tag Open Graph.
I tag canonical dicono a Google quale consideri come pagina autorevole da un gruppo di pagine simili o duplicate. Puntare ad una versione HTTP potrebbe inviare un brutto segnale a Google e sarebbe quindi ignorato.
Se usi i tag Open Graph per ottimizzare gli articoli del tuo social media, allora i tag URL sono richiesti da Facebook. Dovrebbero essere gli stessi degli URL canonical.
Per trovare pagine con canonical in HTTP e tag OG, imposta questo filtro personalizzato su Page Explorer:
Nuovamente, tutto ciò che è rimasto fuori sarà da riscrivere con https:// per finalizzare la migrazione.
Errore 5: redirect falliti
I redirect possono essere insidiosi. Molte cose possono andare storte—da redirect rotti, a catene e circoli di redirect.
Fortunatamente, è facile individuare questi errori con Site Audit. Controlla il report Redirect e passa attraverso tutte le segnalazioni.
Dopo aver cliccato su “Vedi URL coinvolti”, vedrai un report simile a questo, ma con più colonne di default e metriche:
La miglior cosa da fare è che tu vedi tutti gli URL coinvolti—quelli con redirect, quelli dentro le catene di redirect, e quelli che puntano a quelli reindirizzati.
Ci sono 2 cose che puoi fare ora.
La prima cosa è interrompere i redirect, in questo caso:
https://blog.esempio.com/123/ -> 301 redirect -> https://esempio.com/blog/987/
Questo assicura che tutti i backlink che puntano sia a https://blog.example.com/123/ che https://example.com/blog/123/ saranno reindirizzati solo una volta. Questo è ottimo per i backlink esterni perché contattare i webmaster e chiedere la modifica dei link sarebbe molto inefficace e dispendioso.
Internamente possiamo far meglio.
Dovresti cercare di ridurre al massimo il numero dei redirect. Ecco dove intervengono i numeri in colonna inlinks.
Inlink sono URL con link ad URL affetti da catena di redirect. Dovrai cercare di cambiare i link alle pagine con un URL che restituisca un codice HTTP 200. Se clicchi nei numeri degli inlink, li puoi vedere tutti:
Esempio di report Inlink nel Site Audit di Ahrefs. Qui, dovrai andare in ognuna delle 4 pagine e cambiare i loro link da https://blog.esempio.com/123/ a https://esempio.com/blog/987/.
Certamente, di nuovo, il prossimo passo dovrebbe essere il controllo degli inlink degli URL dentro la catena redirect. Tuttavia, è una priorità minore perché abbiamo già interrotto la catena redirect. Questi saranno taggati come redirect standard 301 nel report 3XX Redirects fino alla prossima scansione.
Conclusioni
Spero che insieme possiamo rendere la navigazione del World Wide Web più veloce e sicura.
Secondo w3techs.com, il 59,4% dei siti web nel loro campione di sondaggio utilizza HTTPS di default. In confronto, Google segnala che tra l’88–99% del tempo speso nella navigazione su Chrome è su siti web HTTPS.
La mia conclusione da questi dati è che la grande maggioranza dei siti web popolari con traffico considerevole abbia già aderito ad HTTPS. Se ti stai chiedendo della grande differenza tra questi due set di dati, lo attribuirei ai siti web cinesi che non sono inclusi nei dati di Google.
C’è ancora molto da fare in termini di qualità di supporto TLS. Come avrai imparato qui, l’impostazione HTTPS non finisce con il processo di migrazione. Restare aggiornati con i trend per le performance e sicurezza web e implementare le nuove funzionalità porta benefici a tutti.
Domande o commenti? Scrivimi su Twitter.
Tradotto da Mauro Marinello
