Passare il sito al protocollo HTTPS: la procedura e i reindirizzamenti

HTTPS è la versione cifrata del protocollo HTTP. È diventato la norma: Chrome e Firefox segnalano come «Non sicure» le pagine in HTTP, i visitatori esitano a inserirvi i propri dati e Google tiene conto dell'HTTPS nel posizionamento.

Passare un sito a HTTPS è una migrazione a tutti gli effetti. Il nome di dominio non cambia, ma cambia il protocollo di tutte le URL, e Google considera http:// e https:// due indirizzi diversi: ogni pagina va reindirizzata al suo equivalente in HTTPS, in un solo salto. Questo articolo dà la procedura, poi le regole di reindirizzamento, con o senza www, e l'ordine in cui scriverle. Per l'altro lato, quello del visitatore, vedi come riconoscere un sito sicuro.

L'HTTPS offre tre garanzie:

• la riservatezza: gli scambi tra il browser e il server sono cifrati; su un Wi-Fi pubblico nessuno può leggere una password o un numero di carta;
• l'integrità: le pagine e i dati non possono essere modificati durante il trasporto;
• l'autenticazione: il certificato attesta che il sito è proprio quello di quel nome di dominio.

Chrome non mostra più la dicitura «Sicuro» per i siti in HTTPS: è il contrario, le pagine in HTTP portano la dicitura «Non sicuro», che diventa rossa appena vi si inseriscono dati. L'HTTPS è anche un segnale di posizionamento per Google, modesto: non sostituisce un contenuto pertinente.

La maggior parte degli hosting fornisce gratuitamente un certificato Let's Encrypt, da attivare dall'area clienti e rinnovato automaticamente. Per un certificato a pagamento, la procedura passa da una CSR (richiesta di firma del certificato), generata sul server: contiene la chiave pubblica e il nome di dominio da certificare, ed è ciò che si trasmette all'autorità di certificazione. Anche qui, di solito se ne occupa l'hosting.

Esistono tre livelli di convalida: solo il dominio (DV), l'organizzazione (OV) e la convalida estesa (EV), che verifica più a fondo l'identità dell'azienda. Tutti cifrano allo stesso modo, e dal 2019 i browser non distinguono più i certificati EV nella barra degli indirizzi. Verificate che il certificato copra tutte le varianti servite: exemple.fr e www.exemple.fr, ed eventuali sottodomini.

Prima del passaggio, sostituite gli indirizzi in http:// con https:// ovunque il sito li scriva: link interni dei contenuti, menu, tag canonical e hreflang, sitemap, dati strutturati. Anche le risorse caricate dalle pagine (immagini, script, fogli di stile, font) devono essere in HTTPS: altrimenti il browser segnala contenuto misto e può bloccare la risorsa.

Su WordPress, aggiornate l'«Indirizzo WordPress» e l'«Indirizzo sito» nelle impostazioni generali, poi sostituite i vecchi indirizzi nel database con uno strumento di ricerca e sostituzione che rispetti i dati serializzati (WP-CLI search-replace, ad esempio). Rivedete anche le impostazioni dei plugin che salvano indirizzi, e l'indirizzo della sitemap nel robots.txt.

Non serve reindirizzare le pagine una per una: cambia solo il protocollo, quindi una regola nella configurazione del server basta per tutte le URL, percorso compreso. È un reindirizzamento 301, permanente: indica a Google di sostituire il vecchio indirizzo con il nuovo nel suo indice, e porta alla pagina giusta i visitatori che hanno conservato un preferito in HTTP. Le regole, con o senza www, e il loro ordine sono descritti più sotto.

Una proprietà di tipo «Dominio» copre già tutte le varianti, in HTTP e in HTTPS. Altrimenti, aggiungete la proprietà https:// del sito (con o senza www, quella che sarà canonica), poi inviatevi la sitemap in HTTPS. Google scoprirà prima i nuovi indirizzi e potrete seguirne l'indicizzazione nel rapporto sulle pagine.

Controllate il certificato (valido, su ogni variante di host), l'assenza di contenuto misto e soprattutto i reindirizzamenti: ogni vecchio indirizzo deve rispondere con un solo 301 verso il suo indirizzo finale. Seguite poi indicizzazione e traffico nelle settimane successive; in caso di calo, controllate prima i reindirizzamenti e il certificato.

Una stessa pagina può rispondere sotto quattro indirizzi: http://exemple.fr, http://www.exemple.fr, https://exemple.fr e https://www.exemple.fr. Sceglietene uno, la versione canonica (qui, in HTTPS con www), e reindirizzate gli altri tre verso di essa, in un solo salto e con lo stesso percorso.

L'errore più comune è scrivere due regole che si concatenano: una che passa a HTTPS, un'altra che aggiunge il www. http://exemple.fr/page va allora a https://exemple.fr/page, poi a https://www.exemple.fr/page: due reindirizzamenti invece di uno, più lenti per il visitatore e per Google. La scelta tra www e senza www è trattata nel nostro articolo sul reindirizzamento www.

Nel file .htaccess alla radice del sito, o nella configurazione del server:

RewriteEngine On

# Ogni indirizzo in http, o su un host diverso da www.exemple.fr, va con un solo reindirizzamento a https://www.exemple.fr, stesso percorso
RewriteCond %{HTTPS} off [OR]
RewriteCond %{HTTP_HOST} !^www\.exemple\.fr$ [NC]
RewriteRule ^ https://www.exemple.fr%{REQUEST_URI} [L,R=301]

Le due condizioni sono unite da [OR]: la regola si applica se la richiesta arriva in HTTP, o su un host diverso da quello canonico, e invia direttamente all'indirizzo finale. Dietro una CDN o un bilanciatore di carico che termina l'HTTPS, il server riceve tutte le richieste in HTTP: %{HTTPS} vale allora sempre off, ed è l'intestazione X-Forwarded-Proto che va testata, pena un ciclo di reindirizzamenti.

Un blocco server per l'HTTP, un altro per l'HTTPS senza www; il sito vero e proprio è servito dal blocco https://www.exemple.fr:

# http, con o senza www: verso https://www.exemple.fr, stesso percorso
server {
    listen 80;
    server_name exemple.fr www.exemple.fr;
    return 301 https://www.exemple.fr$request_uri;
}

# https senza www: verso https://www.exemple.fr (il certificato deve coprire exemple.fr)
server {
    listen 443 ssl;
    server_name exemple.fr;
    return 301 https://www.exemple.fr$request_uri;
}

Quando il passaggio a HTTPS accompagna un restyling, cambiano anche le URL: il server porta allora due tipi di regole. I reindirizzamenti precisi, uno per URL, sono il piano di reindirizzamento: quella vecchia pagina verso quella nuova. Le regole generiche si applicano a tutto un insieme di indirizzi: il passaggio a HTTPS, l'aggiunta del www, un'intera directory spostata.

Apache legge le regole in ordine e si ferma alla prima che reindirizza. Se la regola generica viene prima, http://exemple.fr/ancienne-page.html va prima a https://www.exemple.fr/ancienne-page.html, poi una seconda richiesta trova il reindirizzamento preciso verso /nouvelle-page: una catena di due reindirizzamenti, e una tappa intermedia che non esiste. Mettete quindi prima i reindirizzamenti precisi, con l'indirizzo finale completo (protocollo e host compresi), poi le regole per schema, infine le regole generiche:

RewriteEngine On

# 1. I reindirizzamenti precisi, URL per URL (il piano di reindirizzamento), verso l'indirizzo finale completo
RewriteRule "^/?ancienne-page\.html$" "https://www.exemple.fr/nouvelle-page" [L,R=301,NC,QSD,NE]
RewriteRule "^/?categorie/produit-42$" "https://www.exemple.fr/boutique/produit-42" [L,R=301,NC,QSD,NE]

# 2. Le regole per schema (un'intera directory)
RewriteRule ^actualites/(.*)$ https://www.exemple.fr/blog/$1 [L,R=301]

# 3. Le regole generiche: da http a https, host senza www verso www
RewriteCond %{HTTPS} off [OR]
RewriteCond %{HTTP_HOST} !^www\.exemple\.fr$ [NC]
RewriteRule ^ https://www.exemple.fr%{REQUEST_URI} [L,R=301]

Così il vecchio indirizzo in HTTP porta in un solo salto al nuovo indirizzo in HTTPS; gli indirizzi senza reindirizzamento preciso passano dalla regola generica. La stessa logica vale tra una regola per schema e le eccezioni che copre: prima l'eccezione.

Con Nginx, un return scritto direttamente nel blocco server viene eseguito prima di qualsiasi blocco location: i reindirizzamenti precisi messi nei blocchi location non verrebbero mai letti per le richieste in HTTP. Consultateli prima della regola generica, ad esempio con una map:

# Nel contesto http: i reindirizzamenti precisi, percorso per percorso
map $uri $nouvelle_adresse {
    default "";
    /ancienne-page.html /nouvelle-page;
    /categorie/produit-42 /boutique/produit-42;
}

server {
    listen 80;
    server_name exemple.fr www.exemple.fr;
    # Prima i reindirizzamenti precisi, poi la regola generica (stesso test nel blocco 443)
    if ($nouvelle_adresse) {
        return 301 https://www.exemple.fr$nouvelle_adresse;
    }
    return 301 https://www.exemple.fr$request_uri;
}

Il file .htaccess esportato da Swan contiene solo reindirizzamenti precisi, uno per URL, verso l'indirizzo completo del dominio di produzione (o di test), protocollo e host compresi: metteteli prima delle vostre regole generiche. Non contiene regole di passaggio a HTTPS, che restano da scrivere nella configurazione del sito. Per decidere dove tenere queste regole, vedi dove collocare il piano di reindirizzamento.

Per verificare che un vecchio indirizzo porti in un solo salto alla sua destinazione, interrogatelo in HTTP: la risposta deve essere un 301 la cui intestazione Location sia l'indirizzo finale in HTTPS.

curl -sI http://exemple.fr/ancienne-page.html

HTTP/1.1 301 Moved Permanently
Location: https://www.exemple.fr/nouvelle-page

Se Location indica un indirizzo intermedio (la stessa pagina in HTTPS, o l'host senza www), una regola generica viene prima del reindirizzamento preciso. I rischi di una catena di reindirizzamenti per la SEO sono trattati nel nostro articolo sui rischi dei reindirizzamenti per la SEO.