Lucchetto rotto dopo il passaggio a HTTPS: come trovare il contenuto misto

La verifica più veloce

Prima di tutto: apri la pagina che ha perso il lucchetto, premi F12 (o Ctrl+Shift+I) e vai sulla scheda Console. Quando visiti una pagina HTTPS in Google Chrome, il browser segnala il contenuto misto con errori e avvisi nella console JavaScript. Cerca righe che iniziano con "Mixed Content". Quella riga contiene già l'indirizzo esatto della risorsa che sta rompendo la sicurezza: è da lì che si parte, non dalla teoria di HTTP e HTTPS.

Un dettaglio che fa perdere tempo a tutti: gli avvisi di contenuto misto vengono mostrati solo per la pagina che stai visualizzando in quel momento, e la console si svuota ogni volta che navighi verso una nuova pagina. Quindi homepage pulita non vuol dire sito pulito: vanno controllate le pagine interne, soprattutto gli articoli più vecchi.

Cosa significa l'errore, in una riga

Il browser ha caricato la pagina in HTTPS, ma dentro quella pagina c'è un'immagine, uno script o un foglio di stile che viene richiesto ancora in HTTP. Il browser toglie il lucchetto perché non può garantire che tutto il traffico sia cifrato. In alcuni casi Chrome aggiorna automaticamente il contenuto misto passivo: se una risorsa è scritta in HTTP ma è disponibile anche in HTTPS, il browser carica la versione sicura; se non esiste una versione sicura, la risorsa non si carica. Per script, iframe e fogli di stile il discorso è più serio: per il rischio più alto, la maggior parte dei browser blocca già di default questo tipo di contenuto attivo, anche se il comportamento varia tra browser e versioni.

Le cause, in ordine di frequenza

1. L'indirizzo del sito è ancora su http (il caso più comune su WordPress)

Come si capisce. Vai su Impostazioni → Generale nella bacheca di WordPress e guarda i due campi WordPress Address (URL) e Site Address (URL).

Come si risolve. Se mostrano ancora http://, cambiali in https:// e salva. Se il salvataggio ti blocca fuori dalla bacheca per un loop di redirect, l'alternativa è forzare i valori da file, aprendo wp-config.php e aggiungendo, prima della riga "That's all, stop editing!":

define('WP_HOME','https://tuodominio.it');
define('WP_SITEURL','https://tuodominio.it');

Su cPanel puoi modificare lo stesso file da File Manager; su Plesk da Gestione file, dentro la cartella del dominio.

Come si verifica. Ricarica Impostazioni → Generale: entrambi i campi devono mostrare https://.

2. Link http scritti dentro i contenuti (il caso che il redirect non risolve)

Un redirect 301 da http a https fa cambiare protocollo a chi digita l'indirizzo nella barra, ma non tocca gli URL già salvati dentro articoli, pagine, widget o builder: quelli restano scritti in chiaro come http:// e il browser continua a vederli come richieste insicure, bloccate o degradate a prescindere dal redirect.

Come si capisce. Se hai accesso SSH e WP-CLI installato, lancia prima una simulazione senza scrivere nulla:

wp search-replace 'http://tuodominio.it' 'https://tuodominio.it' --dry-run --skip-columns=guid

Il comando e i parametri --dry-run e --skip-columns sono documentati nella pagina ufficiale wp search-replace del WP-CLI Handbook. Il report mostra quante occorrenze verrebbero sostituite in ogni tabella: se il numero non è zero, la causa è questa.

Come si risolve. Rilancia lo stesso comando senza --dry-run:

wp search-replace 'http://tuodominio.it' 'https://tuodominio.it' --skip-columns=guid

Se non hai accesso SSH, lo stesso lavoro si fa da phpMyAdmin con una query UPDATE sulle tabelle wp_posts e wp_postmeta, cercando e sostituendo la stringa http://tuodominio.it con https://tuodominio.it; va fatto con cautela perché una sostituzione troppo larga può rompere dati serializzati nei widget o nei plugin, da cui l'utilità del flag --skip-columns=guid e, nei casi più delicati, di --precise.

Come si verifica. Rilancia il --dry-run: deve riportare zero sostituzioni possibili.

3. Riferimenti scritti a mano nei file del tema o di un plugin

Come si capisce. Su un sistema Ubuntu 24.04 con accesso SSH, cerca le occorrenze dentro la cartella del tema attivo:

grep -rn "http://tuodominio.it" /var/www/tuodominio.it/wp-content/themes/nome-tema/

Su cPanel puoi fare la stessa ricerca dal File Manager con la funzione di ricerca nei file, dentro public_html/wp-content/themes/.

Come si risolve. Sostituisci l'http:// hardcoded con https://, oppure, dove possibile, con un URL relativo generato da WordPress (per esempio tramite get_template_directory_uri() per i file del tema) invece di scrivere il dominio per esteso.

Come si verifica. Ricarica la pagina e ricontrolla la console: l'avviso relativo a quel file deve sparire.

4. Risorse esterne che non sono tue (CDN, font, iframe pubblicitari)

Come si capisce. Nella console del browser, guarda il dominio della risorsa bloccata: se non è il tuo, la causa è un servizio di terzi ancora agganciato in http.

Come si risolve. Copia l'indirizzo della risorsa, aprila in una nuova scheda cambiando http:// in https://: se si carica, basta aggiornare il riferimento nelle impostazioni del plugin o nel codice di embed; se non si carica in https, il fornitore esterno non la supporta e la risorsa va sostituita o rimossa.

Quando è il fornitore. Se il blocco riguarda una risorsa che passa dalla tua CDN o da un proxy del tuo hosting, e persiste dopo aver sistemato database e tema, il problema può essere lato fornitore. All'assistenza vanno allegati: l'indirizzo esatto bloccato copiato dalla console, uno screenshot della scheda Console o Issues di DevTools, e il nome a dominio interessato.

Percorsi utili per controllare le richieste lato server

Se dopo le correzioni resta un dubbio su quale richiesta arrivi davvero in http, può servire guardare i log del webserver:

Ambiente	Percorso log
Ubuntu/Debian con Nginx	/var/log/nginx/access.log e /var/log/nginx/error.log
cPanel (account utente)	~/access-logs/, con archivi più vecchi in ~/logs/
Plesk (per dominio)	/var/www/vhosts/system/esempio.it/logs/ — error_log, access_log e access_ssl_log

I percorsi Ubuntu/Debian sono quelli di default della distribuzione: sui sistemi Ubuntu e Debian, i percorsi predefiniti sono /var/log/nginx/access.log e /var/log/nginx/error.log. Se il percorso è stato personalizzato, va cercato con nginx -T nella direttiva access_log o error_log del file di configurazione attivo.

Come si verifica che è risolto, in generale

1. Riapri la console su ogni pagina che avevi segnato (si pulisce a ogni navigazione, va ricontrollata pagina per pagina).
2. In Chrome guarda anche la scheda Issues, che elenca ogni risorsa insicura con lo stato di blocco.
3. Svuota la cache di eventuali plugin di cache e della CDN prima di ricontrollare: una pagina già in cache può continuare a mostrare l'errore anche dopo la correzione.
4. Solo quando la console è pulita su tutte le pagine controllate, il lucchetto torna stabile.

Nessun prodotto citato in questo articolo è un prodotto Prime Software.