Il sito si apre con HTTPS, ma alcune fotografie spariscono, il menu cambia aspetto o un modulo smette di funzionare.
Il certificato può essere valido e il problema trovarsi nei file richiamati dalla pagina. Prima di cambiare hosting o installare altri plugin, verifica se il browser segnala contenuti misti: risorse ancora richieste tramite HTTP dentro una pagina HTTPS.
Indice della guida
Distingui i contenuti misti dagli altri errori
Una pagina HTTPS può includere un vecchio indirizzo HTTP per un’immagine, un foglio di stile o uno script. La documentazione MDN sui contenuti misti spiega che i browser aggiornano automaticamente alcune richieste e ne bloccano altre. Il risultato può essere una pagina solo parzialmente funzionante.
Non attribuire ogni elemento mancante a questa causa. Un file cancellato, un servizio esterno interrotto o un errore JavaScript richiedono controlli diversi. Se invece compare un avviso che impedisce di aprire il sito, parti dalla guida alla connessione non privata e al certificato HTTPS. Il segnale da cercare qui è una richiesta non sicura dentro una pagina già aperta.
Annota dove si interrompe il percorso del cliente
Scrivi l’indirizzo completo della pagina, il dispositivo utilizzato e l’azione che non riesce. “Il pulsante preventivo non risponde nella pagina assistenza” è più utile di “il sito è rotto”. Annota se il problema è iniziato dopo l’attivazione di HTTPS, una migrazione o la sostituzione di un componente.
Prova la stessa pagina da visitatore, senza l’accesso amministratore, e confronta computer e telefono. Salva una schermata e l’orario della prova. Se gestisci un ecommerce, indica anche se il blocco riguarda catalogo, carrello o pagamento: questa informazione permette di stabilire la priorità dell’intervento. Evita ordini reali ripetuti solo per riprodurre l’errore.
Trova la risorsa segnalata dal browser
Su Chrome, gli strumenti per sviluppatori raccolgono problemi di questo tipo nel pannello Issues. Se non conosci questi strumenti, chiedi al tecnico di esaminare quella pagina e consegnargli il caso raccolto. La console può mostrare il riferimento alla risorsa aggiornata automaticamente o bloccata.
Ricarica la pagina con gli strumenti aperti e ripeti l’azione interessata. Conserva l’URL della pagina, quello della risorsa e il messaggio completo. Distingui il dominio del sito da quello di un fornitore esterno. Non pubblicare esportazioni indiscriminate delle richieste: possono contenere identificativi o informazioni della sessione. Per la diagnosi iniziale bastano i riferimenti pertinenti.
Risali al punto che genera il vecchio indirizzo
Un richiamo HTTP può essere scritto nel testo di una pagina, nelle impostazioni del tema, in un widget o in un file prodotto dal costruttore visuale. Una modifica al certificato non riscrive necessariamente questi riferimenti. Chiedi di identificare l’origine prima di sostituire indirizzi in tutto il sito.
Prepara un elenco semplice: risorsa, componente che la inserisce, pagine interessate e responsabile. Per esempio, se tutte le pagine richiamano lo stesso font esterno, la correzione riguarda probabilmente un’impostazione comune. Se manca solo la foto di un vecchio articolo, il punto da verificare è diverso. Questo inventario evita interventi ripetuti che nascondono il sintomo senza correggere la sorgente.
Correggi WordPress con una copia di sicurezza
Prima di intervenire su file e database, prepara un backup verificabile del sito. La guida ufficiale alla migrazione WordPress segnala che riferimenti precedenti possono restare nei dati e nei template. Controlla anche gli indirizzi nelle impostazioni e nei componenti che costruiscono le pagine.
Una sostituzione testuale indiscriminata nel database può danneggiare valori memorizzati in un formato particolare. Chi segue la manutenzione può usare strumenti appropriati: WP-CLI search-replace gestisce i dati serializzati e permette una simulazione con --dry-run. Definisci l’ambito, controlla il risultato previsto e prova la modifica su una copia del sito prima di applicarla alla versione pubblica.
Verifica le risorse esterne prima di cambiare protocollo
Non basta sostituire http:// con https:// senza controllare la destinazione. La risorsa deve essere disponibile all’indirizzo sicuro e continuare a svolgere la funzione prevista. Per un widget di prenotazione, chiedi al fornitore il codice di incorporamento attuale; per una libreria inserita nel tema, coinvolgi chi mantiene quel componente.
Se il servizio non offre una versione utilizzabile in HTTPS, valuta una sostituzione o rimuovi l’integrazione, predisponendo un percorso alternativo comprensibile. Non chiedere ai clienti di consentire contenuti non sicuri nelle impostazioni del browser. Annotare il fornitore e la soluzione scelta aiuta anche chi dovrà seguire la manutenzione successiva.
Controlla cache e funzionamento dopo la correzione
Quando il richiamo è stato corretto, verifica che il sito pubblico consegni la versione nuova. Cache del sito, file generati dal tema e servizi intermedi possono mantenere copie precedenti. La guida alle modifiche non visibili per la cache aiuta a organizzare questi controlli senza confondere il salvataggio con la pubblicazione effettiva.
Ripeti le prove iniziali: pagina servizi, menu, richiesta di preventivo e conferma di ricezione. Per un negozio includi il percorso di acquisto in un ambiente di prova appropriato. Controlla nuovamente gli avvisi, anche se l’aspetto sembra corretto. Una homepage sistemata non dimostra che lo siano tutte le pagine o le funzioni caricate solo dopo un clic.
Conserva un riscontro utile per l’assistenza
Al termine chiedi un breve riepilogo: quale componente richiamava HTTP, dove è stato corretto e quali percorsi sono stati verificati. Conserva gli esempi prima e dopo insieme al riferimento del backup. Se il difetto riappare dopo un aggiornamento, questi elementi aiutano a capire se una configurazione viene sovrascritta.
Inserisci le pagine commerciali più importanti nei controlli periodici: non solo l’apertura del sito, ma anche moduli, prenotazioni e download. Quando chiedi aiuto, invia URL, errore completo e cambi recenti. Il risultato atteso è il corretto funzionamento per i clienti; correggere contenuti misti non costituisce una garanzia di posizionamento su Google.
Domande frequenti
Un certificato valido esclude i contenuti misti?
No. La pagina può usare un certificato valido e richiamare ancora risorse tramite HTTP. Occorre controllare gli indirizzi dei file caricati e gli avvisi del browser.
Basta installare un plugin per risolvere?
Non sempre. Prima va individuato il componente che genera il richiamo e verificata la disponibilità della risorsa in HTTPS. Un intervento automatico non sostituisce il controllo del percorso dei clienti.
Posso sostituire tutti gli indirizzi HTTP nel database?
Evita sostituzioni indiscriminate. Su WordPress alcuni dati richiedono strumenti compatibili con la serializzazione. Prepara un backup, definisci l’ambito e verifica una simulazione e una copia di prova.
Perché il problema resta visibile dopo la modifica?
Potresti vedere una copia precedente oppure aver corretto solo uno dei richiami. Verifica cache, file generati e pagina pubblica, poi ripeti l’azione che faceva comparire il problema.
Fonti ufficiali e approfondimenti
Riferimenti per verificare le funzioni e i controlli descritti nella guida.