Certificato SSL WordPress: HTTPS, HSTS e perché non è più un'opzione ma una necessità tecnica

Fino a qualche anno fa, HTTPS era una scelta: lo attivavi se avevi un e-commerce o se gestivi dati sensibili, altrimenti restavi su HTTP. Oggi non è più così. Chrome marca ogni sito HTTP come "non sicuro" nella barra degli indirizzi — un cartello rosso che allontana i visitatori prima ancora che leggano il contenuto. Google penalizza i siti HTTP nei risultati di ricerca. E i nuovi protocolli web (HTTP/2, HTTP/3) funzionano solo su HTTPS. Non è un'opzione: è un requisito tecnico.

Ma installare un certificato SSL non basta. Il passaggio da HTTP a HTTPS, se fatto male, è uno dei modi più efficaci di perdere traffico SEO, rompere i redirect legacy, o bloccare gli utenti fuori dal loro stesso sito. Lo vediamo regolarmente: un cliente attiva SSL, fa il redirect da HTTP a HTTPS, e il giorno dopo il traffico crolla del 40% perché Google non riconosce la nuova versione HTTPS come la stessa pagina. Oppure: attiva HSTS preload senza capire cosa fa, e sei mesi dopo non riesce più a tornare indietro.

Il redirect 301: la base che quasi tutti sbagliano

Il primo passo dopo l'attivazione del certificato SSL è il redirect da HTTP a HTTPS. Ma non un redirect qualsiasi: un redirect 301 (permanente), non 302 (temporaneo). Il 301 dice a Google "questa pagina si è trasferita definitivamente"; il 302 dice "è temporaneo, non aggiornare l'indice". Usare 302 è l'errore più comune e il più costoso: Google mantiene la versione HTTP nell'indice, e il traffico si divide tra le due versioni.

Su Apache, il redirect corretto va nel file .htaccess:

# Redirect permanente da HTTP a HTTPS (Apache .htaccess)
<IfModule mod_rewrite.c>
    RewriteEngine On
    RewriteCond %{HTTPS} off
    RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
</IfModule>

# Su Nginx (nel blocco server HTTP, porta 80):
# server {
#     listen 80;
#     server_name example.com www.example.com;
#     return 301 https://$host$request_uri;
# }

Aggiornare gli URL in WordPress (prima del redirect)

Il redirect da HTTP a HTTPS non basta se il contenuto del sito punta ancora a URL HTTP. Le immagini negli articoli, i link interni, le URL nei menu — se puntano a HTTP, il browser mostra avvisi di "contenuto misto" e la connessione non è completamente sicura. WordPress ha due tabelle che contengono gli URL: wp_options (siteurl e home) e wp_posts (i contenuti).

Il modo corretto è aggiornare prima le opzioni in wp-config.php o nel database, poi eseguire una ricerca e sostituzione su tutti i contenuti:

# WP-CLI: aggiorna siteurl e home a HTTPS
wp search-replace 'http://example.com' 'https://example.com' \
  --skip-columns=guid

# Aggiorna anche il www (se usi www)
wp search-replace 'http://www.example.com' 'https://www.example.com' \
  --skip-columns=guid

# Verifica che non restino URL HTTP nel database
wp search-replace 'http://example.com' 'https://example.com' --dry-run

# Importante: --skip-columns=guid evita di cambiare i GUID
# dei post, che devono restare stabili per RSS e integrazioni.

HSTS: la protezione che impedisce il downgrade

HSTS (HTTP Strict Transport Security) è un header che dice al browser: "questo sito va sempre servito su HTTPS, non accettare mai una versione HTTP". Senza HSTS, un attaccante può intercettare la prima richiesta HTTP e fare un man-in-the-middle prima che il redirect a HTTPS avvenga. Con HSTS, il browser sa che il sito è solo HTTPS e non tenta nemmeno la connessione HTTP dopo la prima visita.

L'header HSTS si aggiunge in .htaccess o nella configurazione del server:

# HSTS header in .htaccess
<IfModule mod_headers.c>
    Header always set Strict-Transport-Security \
        "max-age=31536000; includeSubDomains"
</IfModule>

# max-age=31536000 = 1 anno (il minimo consigliato)
# includeSubDomains = applica HSTS a tutti i sottodomini
#
# ATTENZIONE: non aggiungere "preload" finché non sei sicuro.
# Il preload list di HSTS è irreversibile: una volta iscritto,
# non puoi tornare indietro per mesi. Vedi sotto.

HSTS preload: l'arma a doppio taglio

HSTS preload è la versione più aggressiva: iscrivi il tuo dominio alla lista di preload di Chrome (hstspreload.org), e tutti i browser Chrome, Firefox, Safari, Edge non tenteranno mai una connessione HTTP al tuo dominio — nemmeno la prima volta. È la protezione massima contro il downgrade. Ma è anche irreversibile per mesi: una volta iscritto, non puoi rimuovere il dominio dalla lista facilmente, e se in futuro hai bisogno di tornare a HTTP per qualche motivo (non dovrebbe succedere, ma succede), sei bloccato.

La regola operativa: attiva HSTS con max-age e includeSubDomains prima, lascialo attivo per qualche settimana, verifica che tutto funziona, e solo allora considera il preload. Non attivare mai il preload il primo giorno — se hai un sottodominio che usa HTTP per qualcosa (un'API legacy, un servizio interno), il preload lo rompe immediatamente.

Gli altri header di sicurezza (che completano il quadro)

SSL e HSTS sono la base, ma non bastano per un hardening completo. Gli header di sicurezza aggiuntivi che configuriamo sempre su un sito WordPress gestito:

# Header di sicurezza in .htaccess
<IfModule mod_headers.c>
    # HSTS (vedi sopra)
    Header always set Strict-Transport-Security \
        "max-age=31536000; includeSubDomains"

    # Prevenzione clickjacking
    Header always set X-Frame-Options "SAMEORIGIN"

    # Prevenzione MIME sniffing
    Header always set X-Content-Type-Options "nosniff"

    # CSP base (adatta alle tue esigenze)
    Header always set Content-Security-Policy \
        "default-src 'self'; script-src 'self' 'unsafe-inline' 'unsafe-eval'; style-src 'self' 'unsafe-inline'; img-src 'self' data: https:; font-src 'self' data:;"

    # Referrer policy
    Header always set Referrer-Policy "strict-origin-when-cross-origin"
</IfModule>

HTTPS non è un'opzione, ma non è nemmeno un interruttore da accendere e dimenticare. La configurazione corretta — redirect 301, aggiornamento degli URL, HSTS, header di sicurezza — è ciò che separa un sito sicuro da un sito che sembra sicuro ma ha falle. E una volta fatto, si mantiene nel tempo: il certificato si rinnova automaticamente, gli header restano attivi, e il redirect continua a funzionare. Il costo è una volta sola; il beneficio è permanente.