Passare da HTTP a HTTPS significa proteggere la comunicazione tra browser e server tramite TLS. Il certificato, però, è solo il primo componente della migrazione: occorre configurare i redirect permanenti, aggiornare URL e risorse del sito, eliminare il mixed content e allineare canonical, sitemap, Search Console e strumenti di analisi.
Una migrazione incompleta può produrre redirect multipli, pagine duplicate, errori del certificato, contenuti bloccati dal browser e perdita temporanea di visibilità organica.
Come passare da HTTP a HTTPS in breve
Per migrare correttamente un sito da HTTP a HTTPS occorre:
Eseguire backup e mappatura degli URL;
Ottenere e installare un certificato TLS valido;
Rendere disponibile l’intero sito in HTTPS;
Aggiornare URL interni, risorse, canonical e sitemap;
Impostare redirect permanenti 301 da ogni URL HTTP al corrispondente URL HTTPS;
Correggere mixed content, catene di redirect ed errori applicativi;
Verificare Search Console, analytics, log e indicizzazione.
La regola fondamentale è mantenere invariati dominio, struttura degli URL e contenuti durante il passaggio. La modifica simultanea di protocollo, CMS, grafica e permalink rende più difficile isolare gli errori e aumenta il rischio SEO.
Differenza tra HTTP e HTTPS
HTTP è il protocollo applicativo utilizzato per trasferire richieste e risposte tra client e server. Con HTTP non cifrato, un soggetto in grado di intercettare il traffico può leggerlo o alterarlo.
HTTPS è HTTP trasportato all’interno di una connessione TLS. Offre tre proprietà principali:
- cifratura: limita la lettura dei dati in transito;
- integrità: permette di rilevare alterazioni della comunicazione;
- autenticazione: il certificato consente al browser di verificare l’identità del dominio raggiunto.
HTTPS non dimostra che un sito sia affidabile e non impedisce phishing, malware o vulnerabilità del codice. Dimostra che la connessione al dominio indicato è protetta da TLS con un certificato valido.
Per un approfondimento sul funzionamento dei protocolli, consulta HTTP vs HTTPS: differenze e funzionamento.
Preparare la migrazione da HTTP a HTTPS
Prima di modificare il sito occorre creare una baseline tecnica. Le attività minime sono:
- backup completo di file e database;
- esportazione degli URL indicizzati e della sitemap;
- scansione del sito per rilevare status code, canonical, redirect e collegamenti interni;
- inventario di sottodomini, CDN, API, moduli, gateway di pagamento e servizi esterni;
- verifica delle varianti www e non www;
- controllo di analytics, Tag Manager e Search Console;
- prova della configurazione in staging, quando l’architettura lo consente.
La mappatura deve associare ogni URL HTTP al suo equivalente HTTPS. Non bisogna reindirizzare in blocco tutte le vecchie pagine verso la home page: ogni risorsa deve conservare il proprio percorso.
Scegliere il certificato SSL/TLS
Il termine “certificato SSL” è ancora molto usato, ma SSL è obsoleto: i siti moderni utilizzano certificati TLS.
Per la maggior parte dei siti è sufficiente un certificato DV, Domain Validation, che verifica il controllo del dominio. I certificati OV ed EV aggiungono verifiche sull’organizzazione richiedente, ma non rendono la cifratura più forte rispetto a un DV configurato con gli stessi protocolli e algoritmi.
Un certificato gratuito non è tecnicamente meno sicuro solo perché gratuito. Let’s Encrypt, ad esempio, emette certificati DV gratuiti, supporta più nomi nello stesso certificato tramite SAN e rilascia anche certificati wildcard mediante validazione DNS-01. I certificati standard durano 90 giorni e devono essere rinnovati automaticamente.
La scelta dipende quindi da:
- domini e sottodomini da coprire;
- possibilità di automatizzare emissione e rinnovo;
- necessità di validazione dell’organizzazione;
- supporto operativo richiesto;
- compatibilità con hosting, reverse proxy, CDN e bilanciatori.
Per il processo di emissione automatizzata puoi consultare il tutorial Let’s Encrypt.
Installare il certificato e configurare il server
Il certificato deve essere installato sul punto in cui termina la connessione TLS: web server, reverse proxy, load balancer o CDN. La configurazione deve includere il certificato del dominio, la relativa chiave privata e la catena intermedia completa.
Molti hosting gestiti e pannelli come cPanel consentono di attivare HTTPS e il rinnovo automatico direttamente dalla sezione SSL/TLS. In architetture con CDN o reverse proxy occorre verificare anche la connessione tra proxy e server di origine: la modalità che cifra solo il tratto browser–proxy lascia non protetto il traffico verso l’origine.
Prima di forzare i redirect occorre verificare che:
- il certificato sia valido e copra tutti gli hostname utilizzati;
- le pagine HTTPS rispondano senza errori;
- la catena di certificazione sia completa;
- il rinnovo sia automatizzato e monitorato;
- il server supporti configurazioni TLS moderne.
Aggiornare il sito e WordPress per HTTPS
Quando la versione HTTPS è operativa, tutti i riferimenti interni devono usare il nuovo protocollo:
- URL delle pagine e dei menu;
- immagini, file CSS, JavaScript e font;
- form e relativi endpoint;
- URL delle API e callback OAuth;
- canonical e hreflang;
- dati strutturati;
- Open Graph e metadati social;
- feed RSS;
- sitemap XML e riferimento nel file robots.txt.
Passare WordPress da HTTP a HTTPS
In WordPress la sequenza corretta è:
- attivare il certificato sull’hosting;
- modificare Indirizzo WordPress (URL) e Indirizzo sito (URL) in Impostazioni > Generali;
- sostituire nel database gli URL HTTP del dominio con le versioni HTTPS mediante uno strumento compatibile con i dati serializzati;
- rigenerare CSS e file statici del page builder;
- svuotare cache di WordPress, hosting e CDN;
- controllare menu, widget, template, form e risorse caricate da plugin o tema.
Con WP-CLI è possibile eseguire prima una simulazione:
Dopo aver verificato il risultato, si ripete il comando senza --dry-run. Dominio e variante www devono corrispondere alla configurazione reale. Il campo guid non va modificato.
Eliminare il mixed content
Si parla di mixed content quando una pagina HTTPS carica immagini, script, fogli di stile, font, iframe o altre risorse tramite HTTP. I browser possono aggiornare automaticamente alcune richieste, ma bloccano quelle considerate attive o pericolose, causando errori grafici o funzionali.
La correzione deve avvenire alla fonte:
- sostituire gli URL HTTP nel database e nei template;
- aggiornare risorse e librerie esterne;
- verificare che ogni servizio di terze parti supporti HTTPS;
- controllare la console del browser e la scansione completa del sito.
La direttiva CSP upgrade-insecure-requests può aiutare durante la transizione, ma non sostituisce la correzione degli URL. Se una risorsa esterna non è realmente disponibile in HTTPS, il semplice aggiornamento forzato può interromperne il caricamento.
Reindirizzare HTTP a HTTPS con un redirect permanente
Il sito deve rispondere alle richieste HTTP con un redirect permanente lato server, normalmente 301, verso lo stesso URL in HTTPS. La destinazione deve essere anche la versione canonica scelta, con o senza www.
Esempio per Apache tramite .htaccess, con www.example.it come hostname canonico:
Esempio per Nginx:
Gli esempi vanno adattati al dominio reale. Se TLS termina su Cloudflare, un load balancer o un reverse proxy, la regola deve tenere conto del protocollo originale e degli header del proxy fidato; una regola duplicata o non coerente può generare loop.
Il risultato corretto è un solo passaggio:http://example.it/pagina → https://www.example.it/pagina
Sono da evitare catene come:http://example.it → http://www.example.it → https://www.example.it
I redirect devono essere mantenuti stabilmente. I link interni vanno comunque aggiornati alla destinazione HTTPS, evitando di utilizzare il redirect come meccanismo ordinario di navigazione.
Allineare canonical, sitemap e Search Console
Dopo il passaggio da HTTP a HTTPS, ogni pagina deve dichiarare come canonical il proprio URL HTTPS. Anche sitemap, hreflang e dati strutturati devono contenere esclusivamente URL HTTPS canonici.
In Google Search Console:
- una proprietà Dominio comprende protocolli e sottodomini;
- con proprietà di tipo Prefisso URL occorre verificare anche la variante HTTPS;
- bisogna inviare la sitemap contenente i nuovi URL HTTPS;
- non si deve usare lo strumento Cambio di indirizzo per il solo passaggio da HTTP a HTTPS;
- vanno monitorati indicizzazione, pagine escluse, errori di scansione, query e click.
È normale osservare oscillazioni temporanee mentre Google elabora i redirect e consolida i segnali sui nuovi URL. Redirect diretti, canonical coerenti e sitemap pulita riducono l’incertezza.
Vanno inoltre aggiornati:
- proprietà e filtri degli strumenti analytics, se dipendono dal protocollo;
- URL nelle campagne pubblicitarie;
- profili social e directory aziendali;
- webhook, callback e integrazioni esterne;
- backlink ad alto traffico, quando modificabili.
Attivare HSTS solo dopo la verifica
L’header HTTP Strict Transport Security, HSTS, comunica al browser di utilizzare esclusivamente HTTPS per le connessioni future al dominio. Riduce il rischio di downgrade e SSL stripping, ma deve essere attivato solo quando HTTPS funziona stabilmente su tutti gli hostname coinvolti.
Esempio:
includeSubDomains estende il vincolo a tutti i sottodomini. Se anche un solo sottodominio non supporta HTTPS, può diventare irraggiungibile. L’inserimento nella preload list dei browser è una scelta ancora più vincolante e richiede una valutazione separata.
Checklist dopo il passaggio da HTTP a HTTPS
La migrazione può considerarsi completata quando:
- tutti gli URL HTTP rispondono con un redirect permanente verso l’equivalente HTTPS;
- non esistono catene o loop di redirect;
- le pagine HTTPS restituiscono lo status previsto;
- il certificato è valido per tutti hostname e la catena è completa;
- il rinnovo automatico è operativo e monitorato;
- non esiste mixed content;
- canonical, hreflang, sitemap e dati strutturati usano HTTPS;
- menu e link interni puntano direttamente a URL HTTPS;
- form, login, checkout, API, webhook e download funzionano;
- analytics e Tag Manager ricevono correttamente gli eventi;
- cache e CDN non servono vecchi redirect o contenuti HTTP;
- Search Console non evidenzia errori anomali di scansione o indicizzazione;
- i log del server non mostrano picchi inattesi di errori 4xx o 5xx.
HTTPS migliora la SEO?
Google utilizza HTTPS come segnale di ranking, ma non deve essere presentato come una leva capace da sola di produrre un forte aumento delle posizioni. Il beneficio principale è rendere il sito conforme allo standard di sicurezza atteso da browser e utenti.
Il passaggio può invece danneggiare temporaneamente la visibilità se viene eseguito male: redirect mancanti, canonical HTTP, sitemap non aggiornata, risorse bloccate o pagine non raggiungibili creano duplicazioni e disperdono i segnali.
HTTPS non rende sicura un'applicazione web
Il certificato TLS protegge il canale di comunicazione, ma non verifica la sicurezza del codice e delle funzioni applicative. Un sito in HTTPS può continuare a essere vulnerabile a errori di autenticazione e autorizzazione, injection, esposizione di dati, configurazioni errate, componenti obsoleti e vulnerabilità delle API.
Il tuo sito usa HTTPS, ma l’applicazione e le API sono realmente sicure?
Nexsys esegue Web Application Penetration Test su siti, portali aziendali e API, combinando verifiche automatiche e manuali. Il servizio produce evidenze tecniche, classificazione del rischio e piano di remediation.
Domande frequenti sul passaggio da HTTP a HTTPS
Installare il certificato basta per passare da HTTP a HTTPS?
No. Dopo l’installazione occorre aggiornare il sito, correggere il mixed content, impostare redirect permanenti, modificare canonical e sitemap e verificare Search Console e strumenti di analisi.
Un certificato gratuito è meno sicuro di uno a pagamento?
Non per la cifratura. A parità di configurazione TLS, la differenza principale riguarda il tipo di validazione, i servizi accessori, il supporto e le modalità di gestione. Let’s Encrypt emette certificati DV gratuiti affidabili e automatizzabili.
Il redirect da HTTP a HTTPS deve essere 301 o 302?
Per una migrazione definitiva si usa un redirect permanente lato server, normalmente 301. Un 302 segnala invece una variazione temporanea.
Il passaggio a HTTPS può causare una perdita di traffico SEO?
Sono possibili oscillazioni temporanee. Perdite persistenti indicano normalmente errori come redirect mancanti, catene, canonical incoerenti, sitemap errata, risorse bloccate o pagine HTTPS non equivalenti alle precedenti.
Bisogna creare una nuova proprietà in Google Search Console?
Una proprietà Dominio include HTTP, HTTPS e sottodomini. Se si utilizzano proprietà Prefisso URL, la versione HTTPS deve essere aggiunta e verificata. Lo strumento Cambio di indirizzo non va usato per il solo cambio di protocollo.
HTTPS impedisce gli attacchi al sito?
No. HTTPS protegge i dati in transito e autentica il dominio, ma non elimina vulnerabilità di applicazione, CMS, plugin, API, credenziali o configurazione del server.
Verifica la sicurezza oltre il certificato
Per siti istituzionali, portali aziendali, e-commerce e servizi esposti su Internet, il controllo del certificato è solo una verifica di base. Nexsys analizza la superficie esposta, valida le vulnerabilità realmente sfruttabili e definisce priorità e interventi correttivi tramite attività di Penetration Test e consulenza cybersecurity.