Come reindirizzare HTTP a HTTPS in WordPress

Spostare il tuo sito WordPress da HTTP a HTTPS non è più opzionale. I browser segnalano i siti HTTP come "Non sicuro", Google utilizza HTTPS come segnale di ranking e i dati dei tuoi visitatori vengono inviati in chiaro senza crittografia. Dopo aver installato un certificato SSL, devi reindirizzare correttamente tutto il traffico HTTP a HTTPS e risolvere eventuali problemi di mixed content residui. Questa guida copre ogni fase del processo, dall'ottenimento di un certificato al debug dei redirect loop dietro i load balancer.

Perché HTTPS è importante oltre alla sicurezza di base

La ragione ovvia per HTTPS è la crittografia. Senza di essa, qualsiasi cosa tra il browser del tuo visitatore e il tuo server (invii di moduli, credenziali di login, cookie, dati personali) può essere intercettata da chiunque sulla stessa rete. Ma HTTPS è importante per diverse altre ragioni che influenzano direttamente il successo del tuo sito:

• Fattore di ranking SEO: Google ha confermato nell'agosto 2014 che HTTPS è un segnale di ranking. Sebbene sia un segnale leggero, a parità di altre condizioni, la versione HTTPS di una pagina si posizionerà più in alto della versione HTTP. Nelle nicchie competitive, ogni segnale conta.
• Avvisi del browser: Chrome, Firefox, Safari ed Edge mostrano tutti avvisi "Non sicuro" per le pagine HTTP, specialmente quelle con campi di input. Questo mina la fiducia del visitatore e aumenta la frequenza di rimbalzo. Chrome ha reso questi avvisi sempre più prominenti da Chrome 68 (luglio 2018).
• Supporto HTTP/2 e HTTP/3: i protocolli moderni come HTTP/2 e HTTP/3, che migliorano drasticamente la velocità di caricamento delle pagine attraverso multiplexing e compressione delle intestazioni, richiedono HTTPS in pratica. Tutti i principali browser supportano HTTP/2 solo tramite TLS.
• Dati referrer: quando un visitatore clicca su un link da una pagina HTTPS a una pagina HTTP, il browser rimuove l'intestazione referrer. Ciò significa che perdi dati analytics su da dove proviene il tuo traffico. Se il tuo sito è su HTTPS, conservi i dati referrer da altri siti HTTPS.
• Service Worker e PWA: le funzionalità delle Progressive Web App come la cache offline, le notifiche push e il prompt "Aggiungi alla schermata Home" richiedono HTTPS.

Ottenere un certificato SSL gratuito con Let's Encrypt

Non devi pagare per un certificato SSL. Let's Encrypt fornisce certificati gratuiti, automatizzati, domain-validated (DV) che sono affidabili da tutti i principali browser. La maggior parte dei provider di hosting ha integrato Let's Encrypt nei loro pannelli di controllo, ma se gestisci il tuo server, ecco come configurarlo con Certbot:

# Installa Certbot su Ubuntu/Debian
sudo apt update
sudo apt install certbot

# Per Apache
sudo apt install python3-certbot-apache
sudo certbot --apache -d example.com -d www.example.com

# Per Nginx
sudo apt install python3-certbot-nginx
sudo certbot --nginx -d example.com -d www.example.com

Certbot configura automaticamente il tuo server web per utilizzare il certificato e imposta un cron job per il rinnovo automatico. I certificati Let's Encrypt sono validi per 90 giorni, ma il processo di rinnovo automatico lo gestisce in modo trasparente. Per verificare che il rinnovo automatico funzioni:

# Testa il processo di rinnovo (non rinnova effettivamente)
sudo certbot renew --dry-run

# Controlla il timer di rinnovo
sudo systemctl status certbot.timer

Se il tuo provider di hosting offre SSL one-click tramite il loro pannello di controllo (SiteGround, Bluehost, HostGator, ecc.), usalo. È lo stesso certificato Let's Encrypt, ma gestito dal tuo host, il che significa una cosa in meno da mantenere.

Passo 1: aggiorna gli URL di WordPress

Prima di impostare i redirect, dì a WordPress che il tuo sito ora usa HTTPS. Vai a Impostazioni > Generali e aggiorna entrambi i campi:

• Indirizzo WordPress (URL): cambia http://example.com in https://example.com
• Indirizzo del sito (URL): cambia http://example.com in https://example.com

Se non riesci ad accedere al dashboard di amministrazione (ad esempio, se sei già bloccato in un redirect loop), puoi impostare questi valori direttamente in wp-config.php:

define('WP_HOME', 'https://example.com');
define('WP_SITEURL', 'https://example.com');

Oppure aggiorna direttamente il database tramite WP-CLI:

wp option update siteurl 'https://example.com'
wp option update home 'https://example.com'

Passo 2: redirect HTTP-a-HTTPS a livello di server

Il redirect dovrebbe avvenire a livello di server (non in PHP) per due motivi: è più veloce perché non deve caricare WordPress e garantisce che tutte le richieste (inclusi file statici, immagini e chiamate API) vengano reindirizzate, non solo gli URL gestiti da WordPress.

Apache (.htaccess)

Aggiungi questo all'inizio del tuo file .htaccess, prima delle regole di rewrite di WordPress (prima del commento # BEGIN WordPress):

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

Il flag R=301 invia un redirect permanente, che dice ai motori di ricerca di aggiornare il loro indice alla versione HTTPS. Non utilizzare R=302 (redirect temporaneo) perché i motori di ricerca non trasferiranno l'equity dei link al nuovo URL.

Nginx

Nella tua configurazione Nginx, crea un server block separato per HTTP che reindirizza tutto a HTTPS:

server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://$host$request_uri;
}

server {
    listen 443 ssl http2;
    server_name example.com www.example.com;

    ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

    # ... resto della tua configurazione
}

Usare return 301 in Nginx è più efficiente che usare rewrite perché non richiede l'elaborazione di regex.

Passo 3: forza HTTPS in wp-config.php

Aggiungi queste righe al tuo file wp-config.php, sopra il commento "That's all, stop editing!":

// Forza SSL per il pannello di amministrazione di WordPress
define('FORCE_SSL_ADMIN', true);

// Gestisce SSL dietro un reverse proxy o load balancer
if (isset($_SERVER['HTTP_X_FORWARDED_PROTO']) && $_SERVER['HTTP_X_FORWARDED_PROTO'] === 'https') {
    $_SERVER['HTTPS'] = 'on';
}

La costante FORCE_SSL_ADMIN garantisce che la pagina di login di WordPress e il dashboard di amministrazione utilizzino sempre HTTPS, anche se qualcuno cerca di accedervi direttamente tramite HTTP.

Risolvere i redirect loop dietro load balancer e reverse proxy

Questo è uno dei problemi più comuni con le installazioni HTTPS di WordPress e confonde molte persone. Se il tuo sito è dietro un load balancer, Cloudflare, un reverse proxy o un CDN, la connessione tra il proxy e il tuo server è spesso solo HTTP, anche se la connessione tra il visitatore e il proxy è HTTPS. Il tuo server vede una richiesta HTTP e cerca di reindirizzarla a HTTPS, il proxy rimanda la richiesta come HTTP e finisci in un redirect loop infinito. Il browser mostra "ERR_TOO_MANY_REDIRECTS".

La soluzione è il controllo dell'intestazione X-Forwarded-Proto sopra. Il proxy aggiunge questa intestazione per dire al tuo server quale protocollo ha utilizzato la richiesta originale. Quando WordPress vede che il protocollo inoltrato è HTTPS, tratta la connessione come sicura e non attiva un redirect.

Se il controllo dell'intestazione predefinita non funziona, il tuo proxy potrebbe utilizzare un'intestazione diversa. Controlla con il tuo provider di hosting. Le variazioni comuni includono:

// Per alcuni load balancer che usano X-Forwarded-Ssl
if (isset($_SERVER['HTTP_X_FORWARDED_SSL']) && $_SERVER['HTTP_X_FORWARDED_SSL'] === 'on') {
    $_SERVER['HTTPS'] = 'on';
}

// Per Cloudflare (che imposta anche X-Forwarded-Proto, ma per sicurezza)
if (isset($_SERVER['HTTP_CF_VISITOR'])) {
    $visitor = json_decode($_SERVER['HTTP_CF_VISITOR']);
    if (isset($visitor->scheme) && $visitor->scheme === 'https') {
        $_SERVER['HTTPS'] = 'on';
    }
}

Passo 4: sostituisci gli URL HTTP nel database

Il tuo database WordPress contiene URL HTTP hardcoded nei contenuti dei post, nelle impostazioni dei widget, nelle opzioni del tema e nei dati serializzati. Devi sostituirli tutti con le versioni HTTPS. Lo strumento migliore per questo è il comando search-replace di WP-CLI:

# Prima esegui un dry run per vedere cosa cambierebbe
wp search-replace 'http://example.com' 'https://example.com' --all-tables --dry-run

# Se il dry run sembra a posto, esegui la sostituzione reale
wp search-replace 'http://example.com' 'https://example.com' --all-tables

# Gestisci anche le varianti www/non-www se applicabile
wp search-replace 'http://www.example.com' 'https://www.example.com' --all-tables

Il flag --dry-run è importante. Ti mostra esattamente quante sostituzioni verrebbero fatte in ogni tabella senza modificare effettivamente nulla. Rivedi l'output prima di eseguire la sostituzione reale. Il flag --all-tables garantisce che le tabelle personalizzate (da plugin come WooCommerce, ACF o page builder) siano incluse.

WP-CLI gestisce correttamente i dati serializzati, il che è cruciale. Se provi una semplice find-and-replace SQL, romperai gli array serializzati perché i valori della lunghezza delle stringhe non corrisponderanno più. Non eseguire mai una query SQL REPLACE() grezza per questo scopo.

Risolvere i problemi di mixed content

Il mixed content si verifica quando la tua pagina HTTPS carica risorse (immagini, script, fogli di stile, iframe) su HTTP. I browser bloccano completamente il mixed content attivo (script, fogli di stile) e possono avvisare per il mixed content passivo (immagini). Questo si traduce in funzionalità rotte o icone di avviso gialle nella barra degli indirizzi.

Per trovare i problemi di mixed content:

1. Console del browser: apri DevTools (F12) e visualizza la scheda Console. Gli avvisi di mixed content appaiono come messaggi gialli o rossi con gli URL esatti delle risorse incriminate.
2. InspectWP: esegui una scansione e rivedi la sezione HTML. InspectWP rileva risorse non sicure (HTTP) caricate nelle tue pagine HTTPS ed elenca ciascuna di esse.
3. Why No Padlock: il sito whynopadlock.com scansiona la tua pagina e segnala tutte le risorse di mixed content con i loro URL di origine.

Cause comuni di mixed content e come risolverle:

• URL hardcoded nei file del tema: cerca nei file PHP e CSS del tuo tema riferimenti a http://. Sostituiscili con https:// o, meglio ancora, usa URL relativi al protocollo (//) o funzioni WordPress come esc_url().
• Immagini nei contenuti dei post: il comando search-replace di WP-CLI (Passo 4) gestisce la maggior parte di questi. Per casi ostinati, controlla l'HTML grezzo nell'editor di testo.
• Widget e impostazioni del Customizer: gli URL delle immagini in widget, header personalizzati e impostazioni del Customizer sono memorizzati come dati serializzati. WP-CLI search-replace li gestisce correttamente.
• Contenuti dei page builder: Elementor, Beaver Builder, Divi e altri page builder memorizzano i loro contenuti in formati personalizzati. WP-CLI con --all-tables di solito li cattura, ma verifica caricando pagine create con il tuo page builder.
• Risorse esterne: se carichi font, script o immagini da domini esterni su HTTP, aggiorna quegli URL. La maggior parte dei CDN e dei servizi di font (Google Fonts, cdnjs, ecc.) supportano HTTPS.

Usare Really Simple SSL come alternativa

Se l'approccio manuale ti sembra opprimente, il plugin Really Simple SSL automatizza la maggior parte del processo. Installalo, attivalo e:

• Rileva automaticamente il tuo certificato SSL.
• Aggiorna l'URL del sito WordPress e l'URL Home a HTTPS.
• Imposta un redirect 301 da HTTP a HTTPS tramite PHP (o .htaccess se possibile).
• Risolve il mixed content sostituendo gli URL HTTP al volo.

Lo svantaggio di Really Simple SSL è che risolve dinamicamente il mixed content ad ogni caricamento di pagina, aggiungendo una piccola quantità di overhead di elaborazione. È meglio risolvere le cause alla radice (URL del database, riferimenti hardcoded) e poi rimuovere il plugin. Consideralo come un utile ponte durante la migrazione, non come una soluzione permanente.

Passo 5: aggiungi l'intestazione HSTS

HTTP Strict Transport Security (HSTS) dice ai browser di usare sempre HTTPS per il tuo dominio, anche se l'utente digita http:// nella barra degli indirizzi. Dopo aver confermato che HTTPS funziona correttamente sul tuo sito (nessun mixed content, nessun redirect loop), aggiungi l'intestazione HSTS:

Apache (.htaccess)

Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"

Nginx

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;

Il valore max-age=31536000 (un anno) dice ai browser di ricordare la policy HSTS per 12 mesi. Inizia con un valore più breve come max-age=86400 (un giorno) durante i test e aumentalo una volta sicuro che tutto funzioni. La direttiva includeSubDomains estende la policy a tutti i sottodomini. Aggiungi preload solo se intendi inviare il tuo dominio alla lista di preload HSTS (hstspreload.org), che incorpora il requisito HTTPS del tuo dominio nei browser stessi.

Configurazione HTTPS del CDN e di Cloudflare

Se utilizzi Cloudflare o un altro CDN, la configurazione HTTPS ha un ulteriore livello di complessità:

• Cloudflare Flexible SSL: il traffico è crittografato tra il visitatore e Cloudflare, ma la connessione tra Cloudflare e il tuo server è solo HTTP. Questo è il più semplice da configurare (nessun certificato SSL richiesto sul tuo server) ma fornisce una sicurezza incompleta. I dati tra Cloudflare e il tuo server sono non crittografati.
• Cloudflare Full SSL: il traffico è crittografato su entrambi i lati, ma Cloudflare non verifica il certificato del tuo server. Hai bisogno di un certificato SSL sul tuo server, ma può essere self-signed.
• Cloudflare Full (Strict) SSL: l'impostazione raccomandata. Il traffico è crittografato su entrambi i lati e Cloudflare verifica il certificato del tuo server. Usa un certificato Let's Encrypt valido o un Cloudflare Origin Certificate.

Se passi da Flexible a Full (Strict), assicurati prima che il tuo server abbia un certificato SSL valido installato. Altrimenti, il tuo sito andrà offline perché Cloudflare non può stabilire una connessione sicura con il tuo server.

Cloudflare offre anche "Always Use HTTPS" sotto SSL/TLS > Edge Certificates, che esegue il redirect HTTP-a-HTTPS al perimetro Cloudflare. Questo è più veloce di un redirect sul tuo server origin perché il visitatore non raggiunge mai il tuo server per la richiesta HTTP.

Controllare la scadenza del certificato SSL e il rinnovo automatico

Un certificato SSL scaduto è peggio di non averne affatto. I browser mostrano un avviso a tutta pagina che la maggior parte dei visitatori non supererà, e il tuo sito va effettivamente offline. Ecco come monitorare il tuo certificato:

# Controlla la data di scadenza del certificato
echo | openssl s_client -servername example.com -connect example.com:443 2>/dev/null | openssl x509 -noout -dates

# Controlla i giorni alla scadenza
echo | openssl s_client -servername example.com -connect example.com:443 2>/dev/null | openssl x509 -noout -enddate

Se utilizzi Let's Encrypt con Certbot, il rinnovo automatico dovrebbe essere configurato automaticamente. Ma verifica che funzioni effettivamente controllando i log di rinnovo di Certbot:

# Controlla il log di rinnovo Certbot
cat /var/log/letsencrypt/letsencrypt.log | tail -20

# Elenca tutti i certificati e le loro date di scadenza
sudo certbot certificates

Per i siti di produzione, imposta un monitoraggio che ti avvisa quando il tuo certificato si avvicina alla scadenza. Servizi come UptimeRobot, StatusCake o anche un semplice cron job che controlla la data del certificato possono salvarti da downtime imprevisti.

Verifica la tua configurazione HTTPS con InspectWP

Dopo aver completato la migrazione, esegui una scansione InspectWP per verificare che tutto funzioni correttamente. InspectWP controlla diversi aspetti relativi a HTTPS:

• Rilevamento SSL/TLS: conferma che il tuo sito sia servito tramite HTTPS.
• Mixed content: rileva risorse HTTP (immagini, script, fogli di stile) caricate nelle tue pagine HTTPS.
• Intestazione HSTS: verifica che l'intestazione Strict-Transport-Security sia presente e configurata correttamente.
• Redirect HTTP: verifica che la versione HTTP del tuo sito reindirizzi correttamente a HTTPS.
• Intestazioni di sicurezza: esamina altre intestazioni relative alla sicurezza che integrano la tua configurazione HTTPS.

Se InspectWP segnala avvisi di mixed content, usa la console del browser per identificare le risorse specifiche e risolverle utilizzando i metodi descritti sopra. Esegui una nuova scansione dopo ogni correzione fino a quando il report non risulta pulito.