SSL e HTTPS su WordPress: configurazione e problemi
Cos’è SSL e HTTPS su WordPress e perché compare
Quando si parla di SSL e HTTPS su WordPress si entra nel meccanismo di cifratura TLS che rende sicura la comunicazione tra browser e server. Il passaggio da HTTP a HTTPS avviene quando il certificato SSL viene installato correttamente e il dominio risponde con una catena valida. Quando questa catena si interrompe, il browser può mostrare errori come NET::ERR_CERT_AUTHORITY_INVALID oppure bloccare il caricamento della pagina con avviso di connessione non privata.
La causa più frequente resta un certificato SSL incompleto o non correttamente associato al dominio, spesso dopo migrazione o cambio hosting. In altri casi WordPress continua a generare URL HTTP, creando un mismatch tra contenuto e protocollo attivo. Un’altra situazione tipica riguarda il redirect HTTP→HTTPS duplicato tra server e plugin, che può portare al classico errore ERR_TOO_MANY_REDIRECTS, visibile direttamente nel browser.
Anche Cloudflare o altri proxy possono introdurre incoerenze quando il traffico tra origin e edge non è allineato sullo stesso livello SSL, generando comportamenti intermittenti tra pagina sicura e non sicura.
Come capire la causa: metodo diagnostico per SSL e HTTPS WordPress
La diagnosi parte dal comportamento osservabile nel browser, non dalla configurazione teorica. Si distingue subito tra sito che non apre in HTTPS, sito che entra in loop o sito che mostra contenuti misti. Ogni sintomo produce un segnale preciso: codice di errore, stato HTTP o risorsa bloccata nella console.
Il secondo livello di verifica consiste nel confrontare risposta server, WordPress e eventuale CDN. Qui si osserva se il redirect è unico oppure se esistono catene multiple HTTP→HTTPS→HTTP.
Tabella diagnostica sintomo → causa probabile SSL e HTTPS WordPress
| Sintomo osservato | Segnale concreto | Causa probabile |
|---|---|---|
| Avviso “connessione non privata” | NET::ERR_CERT_AUTHORITY_INVALID nel browser | Certificato SSL mancante o non valido sul dominio |
| Loop HTTP ↔ HTTPS | ERR_TOO_MANY_REDIRECTS nel browser | Redirect duplicato tra .htaccess e plugin |
| Lucchetto ma pagina “non sicura” | Console browser: Mixed Content bloccato su risorse HTTP | Risorse JS/CSS ancora servite in HTTP |
| Sito apre solo in HTTP | Redirect assente in header response | WordPress non forzato su HTTPS in siteurl/home |
| Errori solo su alcune pagine | Network tab: asset con status 404 su CDN o cache | Cache non allineata o CDN con versione HTTP |
| HTTPS solo in /wp-admin | Header server incoerente tra frontend e backend | Virtual host o reverse proxy configurato parzialmente |
Primo step di verifica concreta
Si apre il sito sia in http:// che in https:// e si osserva il comportamento nel browser. Se compare ERR_TOO_MANY_REDIRECTS, il problema è una catena di redirect multipla. Se invece appare NET::ERR_CERT_COMMON_NAME_INVALID, il certificato non corrisponde al dominio effettivo.
Nel pannello Network degli strumenti sviluppatore si controlla la prima risposta HTML: se lo status è 301 ripetuto su più hop, il redirect non è controllato da un solo livello ma da più regole sovrapposte.
Secondo step di verifica tecnica
Attivando WP_DEBUG in wp-config.php, eventuali errori di runtime vengono scritti in debug.log. In presenza di plugin di sicurezza o cache, possono emergere errori come PHP Fatal error: Cannot redeclare wp_redirect() o override di header HTTP.
Se il problema è lato plugin, nella console browser si osservano anche risorse JS bloccate o CSS non caricati con status 403 o 404, tipico di sistemi di minify o cache aggressiva.
Se debug.log non mostra nulla ma il browser evidenzia errori di rete, la causa è quasi sempre a livello server o CDN.
CTA dopo diagnosi
Se non è possibile leggere il debug.log o interpretare i redirect multipli, la verifica viene fatta direttamente sull’ambiente reale. Si analizzano header HTTP, certificato e catena di redirect senza passaggi intermedi, così da isolare il punto esatto in cui HTTPS si interrompe. In questi casi l’accesso tecnico evita tentativi ripetuti che spesso peggiorano la configurazione invece di stabilizzarla.
Risolvere SSL e HTTPS su WordPress: la soluzione più semplice
Step 1 – allineamento URL WordPress e HTTPS
La prima correzione consiste nell’allineare siteurl e home su HTTPS. Quando questi valori restano su HTTP, WordPress genera link incoerenti anche se il certificato è valido. Il risultato è una pagina parzialmente sicura con asset misti.
In ambienti multisite o installazioni gestite da Bedrock/Composer, questo valore può essere sovrascritto da configurazioni esterne, quindi WordPress da solo non ha priorità assoluta.
Step 2 – eliminazione redirect duplicati
Il file .htaccess o la configurazione Nginx deve contenere un solo redirect HTTP→HTTPS. Se un plugin di sicurezza applica la stessa regola, si crea un loop visibile come ERR_TOO_MANY_REDIRECTS.
La verifica avviene controllando gli header response nel tab Network: deve esistere un solo salto 301 verso HTTPS, senza ritorni intermedi.
Step 3 – verifica finale certificato e contenuti misti
Si controlla che il certificato copra dominio principale e varianti www/non-www. Poi si analizza la console browser filtrando “Mixed Content”, dove eventuali risorse HTTP vengono evidenziate come bloccate o passive.
Un sito può risultare tecnicamente in HTTPS ma non “sicuro” finché anche una sola risorsa resta in HTTP.
Caso particolare: Cloudflare e SSL Flexible vs Full
Con Cloudflare, la modalità SSL modifica completamente la catena di sicurezza. In modalità Flexible il browser vede HTTPS ma la connessione tra Cloudflare e server resta HTTP, creando segnali incoerenti e redirect instabili.
In modalità Full o Full (strict) la catena TLS resta coerente end-to-end. La differenza è visibile nel pannello Network dove gli header mostrano chiaramente se la connessione origin è cifrata oppure no.
Non riesci a risolvere? Intervento tecnico a distanza
Quando SSL e HTTPS su WordPress non si stabilizzano, il problema non è quasi mai singolo ma distribuito tra server, WordPress e CDN. In questi casi si analizzano contemporaneamente certificato, redirect chain, header HTTP e comportamento reale del browser su più endpoint.
L’intervento remoto permette di leggere i log del server e confrontarli con ciò che il browser mostra, individuando il punto esatto in cui la catena HTTPS si rompe. Questo evita tentativi ripetuti su plugin o impostazioni che spesso non sono la causa reale del problema ma solo un effetto secondario.
Domande frequenti su SSL e HTTPS WordPress
Perché il mio sito WordPress non mostra il lucchetto HTTPS
Il lucchetto scompare quando il certificato SSL non è valido oppure quando il browser rileva risorse HTTP nella pagina. Anche un singolo file JS caricato in HTTP genera Mixed Content e rompe la percezione di sicurezza.
Come risolvere ERR_TOO_MANY_REDIRECTS su WordPress
L’errore indica una catena di redirect HTTP↔HTTPS ciclica. Nella maggior parte dei casi deriva da duplicazione tra .htaccess, plugin di redirect e impostazioni siteurl/home non allineate.
Cosa significa NET::ERR_CERT_AUTHORITY_INVALID
Il browser non riconosce l’autorità del certificato SSL o il certificato non è installato correttamente sul dominio. Può accadere dopo migrazione o installazione incompleta sul server.
Perché HTTPS funziona solo in alcune pagine
Questo accade quando cache e CDN servono versioni diverse del sito. Alcune richieste arrivano in HTTP dalla cache mentre altre sono già aggiornate in HTTPS, creando comportamento intermittente.
Cloudflare può rompere SSL su WordPress
Sì, soprattutto in modalità Flexible. In quel caso il browser mostra HTTPS ma la connessione tra origin e proxy non è cifrata, generando errori di sicurezza o redirect inconsistenti.
Vuoi che il problema venga risolto direttamente? → Richiedi un intervento
Quando il sito continua a mostrare errori SSL o redirect instabili, la causa reale si trova spesso nella combinazione tra server, WordPress e CDN. L’intervento diretto permette di analizzare header HTTP, certificato, catena TLS e log del server in parallelo, senza affidarsi a tentativi successivi. Si interviene sull’ambiente reale per isolare il punto preciso in cui HTTPS si interrompe e ripristinare una configurazione coerente e stabile nel tempo.