Conversione HTTPS di WordPress: passare da HTTP a HTTPS in modo sicuro e corretto

WordPress HTTPS protegge i dati di accesso, i moduli di contatto e i cookie e mi aiuta ad aumentare il ranking e le conversioni. In questa guida, vi mostrerò il passaggio completo da HTTP a HTTPS in WordPress - con certificato, conversione degli URL, reindirizzamenti 301, correzione dei contenuti misti e passaggi SEO puliti.

Punti centrali

• SSL Attivare correttamente e coprire il dominio
• URL convertire in WordPress
• 301 Forza l'inoltro
• Contenuto misto Rettifica mirata
• SEO serrare e controllare

Perché l'HTTPS è importante per WordPress

Senza crittografia, gli aggressori possono dirottare le sessioni o leggere i moduli. Trasmissione tra il browser e il server con TLS. L'HTTPS previene gli avvisi nel browser, aumenta la fiducia e rafforza i segnali che i motori di ricerca valutano positivamente. Molte API, servizi di pagamento e funzioni del browser richiedono comunque connessioni sicure. Inoltre, traggo vantaggio da HTTP/2 e HTTP/3, che si caricano più velocemente con TLS e consentono la parallelizzazione. Un passaggio netto all'HTTPS impedisce la duplicazione dei contenuti, perché posso restringere tutte le varianti a un unico Cannone (Canonica).

Preparare il backup e il certificato SSL

Prima di toccare qualsiasi impostazione, eseguo un backup completo dei file e del database in modo da potervi accedere in qualsiasi momento. Backup può essere restituito. Quindi ordino o attivo un certificato: Let's Encrypt è spesso sufficiente senza costi aggiuntivi, in alternativa utilizzo un certificato DV/OV/EV a seconda delle mie esigenze. Molti hoster forniscono una procedura guidata che emette e rinnova automaticamente i certificati. Se avete bisogno di una guida passo-passo, utilizzate questo tutorial su Impostare un SSL gratuito. Verifico quindi se la catena di certificati è completa e se i domini www e apex (senza www) sono coperti dal certificato; tengo anche conto di sottodomini come staging o cdn e mantengo i loro Validità in sintesi.

Selezione del certificato e gestione delle chiavi

Oltre all'attivazione iniziale, noto anche alcuni dettagli che mancano in molte istruzioni: È necessario un certificato wildcard (*.domain.tld) per molti sottodomini o è sufficiente un certificato SAN con diversi nomi di host espliciti? Per quanto riguarda le prestazioni, utilizzo i certificati ECDSA (curve ellittiche) invece delle classiche chiavi RSA quando possibile: sono più piccoli e velocizzano l'handshake TLS. Proteggo rigorosamente la chiave privata (permessi per i file 600, solo per gli utenti del server) e documento il Rinnovo-catena: il rinnovo automatico avviene davvero, anche se un CDN o un reverse proxy è collegato a monte? Per le sfide ACME, verifico se i reindirizzamenti, i limiti tariffari o le pagine di manutenzione interferiscono con la convalida. Inoltre, attivo la pinzatura OCSP e i protocolli moderni (TLS 1.2/1.3) direttamente nel server web, in modo che i browser possano elaborare i controlli dei certificati più rapidamente.

Cambiare gli URL di WordPress

Accedo alla dashboard e apro Impostazioni → Generale, quindi imposto "Indirizzo WordPress (URL)" e "Indirizzo sito web (URL)" su https://. Dopo aver salvato, accedo nuovamente se la sessione si riavvia. Elimino quindi la cache del browser e, se disponibile, la cache del mio plugin di caching, in modo che i visitatori ricevano immediatamente la versione sicura. Poi do un'occhiata ai widget, ai menu e agli hard link, perché potrebbero ancora contenere link http. Per quanto riguarda i media nei post, modifico i singoli contenuti o pianifico una pulizia Ricerca nel database (vedi sotto).

Accesso e amministrazione sicuri

Per l'area di amministrazione, applico il TLS con una piccola aggiunta nel file wp-config.php. Per farlo, aggiungo il seguente testo sopra la riga "/* That's all, stop editing! */" e carico il file:

define('FORCE_SSL_ADMIN', true);

Ciò significa che il login, i cookie e l'intero backend funzionano rigorosamente via HTTPS. Se un reverse proxy o un livello CDN è connesso a monte, mi assicuro che WordPress interpreti correttamente l'intestazione "X-Forwarded-Proto: https". In caso contrario, l'applicazione tratta erroneamente la connessione come insicura e imposta i cookie senza Sicuro-flag.

Costanti WordPress e rilevamento proxy più sicuri

Se non riesco a raggiungere gli URL nel backend (ad esempio, attraverso i plugin), imposto temporaneamente delle costanti esplicite in wp-config.php, eliminando così le impostazioni errate:

define('WP_HOME', 'https://deinedomain.de');
define('WP_SITEURL', 'https://deinedomain.de');

Aggiungo anche il rilevamento dietro i proxy in modo che is_ssl() correttamente:

se (isset($_SERVER['HTTP_X_FORWARDED_PROTO']) && $_SERVER['HTTP_X_FORWARDED_PROTO'] === 'https') {
    $_SERVER['HTTPS'] = 'on';
}

In questo modo si evita la generazione errata di contenuti misti nel backend e si garantisce che i cookie di autenticazione siano coerentemente collegati all'elemento Sicuro-attributo vengono consegnati.

Impostare i reindirizzamenti 301 in .htaccess

Per assicurarsi che tutte le richieste vadano permanentemente alla versione sicura, ho impostato un'opzione Inoltro da http a https. In un ambiente Apache classico, apro il file .htaccess nella root di WordPress e aggiungo le regole sopra il blocco di WordPress:

RewriteEngine On
RewriteCond %{HTTPS} !=on
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

Con Nginx, l'inoltro avviene nella configurazione del server (server { listen 80; return 301 https://$host$request_uri; }). Per i dettagli, le varianti e la risoluzione dei problemi, si può trovare una guida chiara al Inoltro HTTPS. Importante: mantengo la catena di reindirizzamento breve, cioè http→https e, se necessario, www→non-www o viceversa in un unico salto, in modo che non ci siano salti inutili nella catena di reindirizzamento. Tempo di caricamento aumento.

Strategia di reindirizzamento pulita senza loop

Oltre all'inoltro di base, ho impostato regole di coerenza: O www o non-www, mai entrambi. Con Apache, risolvo questo problema in un solo passaggio con un controllo dell'host:

RewriteEngine On
RewriteCond %{HTTPS} !=on [OR]
RewriteCond %{HTTP_HOST} !^deinedomain\.de$ [NC]
RewriteRule ^ https://deinedomain.de%{REQUEST_URI} [L,R=301]

Ricevo automaticamente le stringhe di query (parametri UTM), riduco i reindirizzamenti a un solo hop ed evito i loop non attivando alcuna regola concorrente nel plugin o nel CDN. Se un edge proxy utilizza "Flexible SSL" (Browser→CDN crittografato, CDN→Origine non crittografato), passo a "Full (strict)" in modo che il TLS sia applicato sia per il visitatore che per l'origine, altrimenti c'è il rischio di problemi di loop e di protocolli misti.

Riconoscere ed eliminare i contenuti misti

Dopo il reindirizzamento, controllo la pagina con gli strumenti del browser per verificare la presenza di "contenuti misti", cioè di contenuti che possono ancora essere accessibili tramite http vengono caricati. Spesso sono interessati immagini, font, script o fogli di stile nei temi, nei page builder o nei widget. Correggo gli URL hard-coded cambiandoli in https nell'editor, nel personalizzatore o nelle impostazioni del plugin. Strumenti come "Really Simple SSL" aiutano a breve termine, ma è meglio una pulizia permanente delle fonti. I contenuti bloccati causano errori di stile o funzioni nascoste, quindi pulisco tutto finché il browser non blocca più alcun contenuto. Avvertenze mostra di più.

Lista di controllo professionale a contenuto misto

• Attivo la direttiva CSP come test richieste di aggiornamento non sicure in modalità solo report per vedere cosa il browser aggiorna automaticamente a https - poi ripulisco definitivamente i sorgenti.
• I font e gli stili esterni spesso richiedono intestazioni CORS; senza di esse Controllo dell'accesso - Consenti origine appaiono come bloccati.
• Riconosco le immagini di sfondo CSS con collegamenti http assoluti negli strumenti per sviluppatori e le sostituisco con percorsi relativi o https.
• Anche gli iframe (ad es. mappe, video) devono parlare https, altrimenti il browser li nasconderà.
• Nei temi, evito i percorsi codificati e uso funzioni come home_url(), sito_url(), plugins_url() e content_url()in modo che WordPress fornisca l'URL di base corretto.

Panoramica passo dopo passo

La seguente tabella riassume in modo compatto tutti i compiti coinvolti nel passaggio al nuovo sistema e mi aiuta a Sequenza da rispettare.

Passo	Raccomandazione/spiegazione
Creare un backup	Prima di ogni modifica completare Backup di file e database
Impostare il certificato SSL	Attivare Let's Encrypt o la versione a pagamento presso l'hoster
Personalizzare gli URL	Impostare su https nel backend in Impostazioni → Generale
Impostare i reindirizzamenti	Configurare .htaccess o il blocco del server Nginx per 301 a HTTPS
Controllare il contenuto misto	Sostituire i link hard http nei contenuti, nei temi e nei plugin
Sostituire il database	Sostituire tutte le occorrenze http con un backup e uno strumento affidabile
Aggiornare Google/SEO	Personalizzazione di proprietà, sitemap, analisi e canonicals di Search Console

Sostituire gli URL del database in modo pulito

A volte i link http rimangono inattivi nei widget, negli shortcode o nei campi definiti dall'utente. Strumento come "Better Search Replace". Cerco "http://deinedomain.de" e lo sostituisco con "https://deinedomain.de", prima a secco, poi per davvero con un backup. Per la rinominazione seriale tramite WP-CLI, uso "wp search-replace", che è molto più veloce per le pagine di grandi dimensioni. Gli array e gli oggetti serializzati devono essere gestiti correttamente, quindi mi affido a strumenti che lo facciano correttamente. Dopo la sostituzione, controllo i campioni casuali nel frontend e in importanti Layout.

Database: cosa non sostituisco alla cieca

Tocco la colonna GUID in wp_posts solo quando cambio effettivamente il dominio. La modifica del protocollo puro a https di solito richiede nessuno Cambiare i GUID, perché servono principalmente come identificatore univoco. Prima di una sostituzione globale, verifico anche se i plugin fanno riferimento a endpoint esterni (webhook, API) con http - preferisco aggiornarli specificamente e testare il canale di ritorno. Per i progetti di grandi dimensioni, prevedo una breve fase di congelamento dei contenuti, in modo che non vengano creati nuovi post con vecchi schemi durante la sostituzione della ricerca. Utilizzo WP-CLI per garantire velocità e riproducibilità:

wp search-replace 'http://deinedomain.de' 'https://deinedomain.de' --all-tables-with-prefix --precise --dry-run
wp search-replace 'http://deinedomain.de' 'https://deinedomain.de' --all-tables-with-prefix --precise

Controlli SEO dopo il passaggio al nuovo sistema

Dopo la modifica, creo una nuova proprietà con https nella Search Console e invio un aggiornamento Mappa del sito su. Controllo i link interni, i tag canonici, i riferimenti hreflang e i tag open graph per l'https. Anche gli snippet di tracciamento (analytics, tag manager, pixel) devono utilizzare l'indirizzo sicuro. Nei plugin SEO, controllo le regole di reindirizzamento e mi assicuro che non ci siano "soft 404". Se i contatori delle condivisioni sociali sono importanti, verifico il funzionamento dello strumento con il nuovo Indirizzo maniglie.

Ottimizzazione di feed, robot e canonicals

Verifico se i feed RSS/Atom sono accessibili via https e forniscono contenuti validi. In un robots.txt mantenuto staticamente, adatto i percorsi delle sitemap a https, se necessario. Imposto URL canonici coerentemente assoluti con https, in modo che i motori di ricerca interpretino i segnali senza ambiguità. Le coppie di hreflang (siti multilingue) non devono differire nel protocollo, altrimenti si creano incoerenze.

Caching, CDN e prestazioni con HTTPS

HTTPS è utile anche in termini di velocità, in quanto HTTP/2/3 consente il multiplexing e la compressione delle intestazioni tramite una Connessione. Presto attenzione alla ripresa della sessione TLS, alla pinzatura OCSP e alle moderne suite di cifratura, che velocizzano gli handshake. Un CDN fornisce risorse statiche più vicine al visitatore, ma deve funzionare costantemente su https. Nei plugin di cache, attivo l'opzione "Cache per HTTPS", se disponibile, e cancello i vecchi artefatti. Poi misuro con strumenti come Lighthouse e confronto i valori di I tempi prima e dopo la modifica.

Caratteristiche del CDN/Proxy

Con un CDN upstream, imposto sempre "Full (strict)" su Origin, carico il certificato lì o uso un certificato Origin e permetto solo la consegna di https. Verifico se la CDN mette in cache i reindirizzamenti (altrimenti vedo i vecchi stati) e cancello le cache dei bordi dopo il passaggio. Anche la compressione Brotli, HTTP/3/QUIC e 0-RTT possono aiutare, ma è importante che le regole a livello di pagina non iniettino più risorse http. Infine, invio il messaggio corretto IP del cliente-(ad esempio X-Forwarded-For) e configurare il server web in modo che i log mostrino il vero IP del visitatore.

HSTS e altre intestazioni di sicurezza

Se il sito funziona interamente su HTTPS, attivo l'HTTP Strict Transport Security (HSTS), in modo che i browser utilizzino solo il file HTTPS-variante. Ad esempio, ho impostato l'intestazione in questo modo: Strict-Transport-Security: max-age=31536000; includeSubDomains; preload - ma solo se tutti i sottodomini sono realmente accessibili in modo sicuro. Per le opportunità e le insidie, consiglio la guida Attivare HSTS. Inoltre, ho impostato intestazioni di sicurezza come X-Content-Type-Options, X-Frame-Options e una stretta politica di sicurezza dei contenuti che consente fonti https. Queste intestazioni rafforzano gli strati di protezione contro l'iniezione di contenuti, il clickjacking e la pirateria informatica. MIME-Annusare.

Ottimizzazione dell'intestazione di sicurezza

Oltre all'HSTS, aggiungo una configurazione pragmatica dell'intestazione: Politica sui referrer: strict-origin-when-cross-origin limita il trasferimento di percorsi sensibili, Politica dei permessi limita le API del browser (ad es. fotocamera, microfono), e un CSP moderato con default-src 'self' https: impedisce la presenza di fonti estranee indesiderate. Inizio con Solo rapportiRaccolgo le violazioni e poi rendo più severe le linee guida. In questo modo evito che le intestazioni di sicurezza "rompano" involontariamente il sito.

Test, monitoraggio e risoluzione dei problemi

Sto testando il passaggio in una finestra privata e su dispositivi mobili, in modo che non ci siano vecchie Biscotti o cache. Il log della console del browser mostra rapidamente avvisi di contenuto misto e risorse bloccate. Uso "curl -I http://deinedomain.de" per verificare se avviene un 301 verso la versione https e se si verificano altre catene. Quindi monitoro i log degli errori sul server e i rapporti 404 nel plugin SEO o nella Search Console. Se i singoli plugin non vengono più caricati, verifico i loro componenti esterni. Dipendenze e aggiornarlo alla versione più recente.

Controllo e monitoraggio continuo

• Prima di passare ad un altro sistema, attivo facoltativamente una breve modalità di manutenzione per stabilire reindirizzamenti e cache coerenti.
• Monitoro la scadenza dei certificati (allarmi) per evitare brutte sorprese.
• Nei primi giorni, monitoro il tasso di 404, le curve di ranking, le statistiche di crawl e Core Web Vitals per prendere le prime contromisure.
• Per le campagne, verifico se i parametri UTM sono completamente conservati tramite il reindirizzamento 301.

Caratteristiche speciali di multisito, proxy e staging

Per i siti multipli, modifico l'indirizzo di rete in https e regolo le mappature in modo che tutti i siti abbiano un indirizzo standardizzato Inoltro utilizzo. Dietro ai bilanciatori di carico o alle CDN, il server web deve osservare l'intestazione "X-Forwarded-Proto", altrimenti WordPress penserà che la connessione sia insicura e imposterà gli URL sbagliati. Per i sistemi di staging, utilizzo i miei certificati o li proteggo con Basic Auth in modo che i motori di ricerca non li indicizzino. Dopo la modifica live, riaccendo le cache, le riscaldo e monitoro il carico. Negli ambienti con proxy o firewall propri, documento tutte le modifiche in modo che le implementazioni successive possano utilizzare il Configurazione prendere il sopravvento.

Multisito e commercio: dettagli spesso mancanti

Nelle configurazioni multisito aggiorno per ogni sito il file siteurl e casa soprattutto se si tratta di una mappatura del dominio. Se un alba.php o plugin di mappatura speciali, verifico se sono compatibili con https. Nei negozi (ad es. WooCommerce), imposto costantemente "Checkout" e "Il mio account" su https, verifico i pagamenti e Webhook-pagine di restituzione e di ringraziamento. I fornitori di pagamenti e le API di spedizione spesso richiedono URL di callback aggiornati: li personalizzo e verifico il controllo della firma dopo la modifica.

Insidie comuni e soluzioni rapide

I certificati non corretti causano segnali di allarme rossi - per questo motivo verifico il periodo di emissione, la catena e se tutti i domini sono inclusi nel certificato in modo che il Connessione funziona senza interruzioni. I reindirizzamenti 301 mancanti creano contenuti duplicati; li regolo con regole chiare e brevi ed evito i salti multipli. I contenuti misti spesso provengono da file di tema hard-coded; in questo caso sostituisco gli schemi http o utilizzo URL senza schema ("//...") nei punti appropriati. Servizi esterni che fanno ancora riferimento a richieste di blocco http; in questo caso aggiorno webhook, endpoint e chiavi. Se un plugin non è in grado di gestire il passaggio, provo un aggiornamento o lo sostituisco con una soluzione che supporta pienamente l'HTTPS. Supporti.

Sommario: Passaggio sicuro a HTTPS

Inizio con un backup completo, attivo il CertificatoPasso gli URL di WordPress a https, applico i reindirizzamenti 301 e pulisco costantemente i contenuti misti. Quindi sostituisco le voci http rimaste nel database, aggiorno le impostazioni SEO e misuro le prestazioni. L'HSTS e le intestazioni di sicurezza aumentano ulteriormente la sicurezza, a patto che tutti i sottodomini rispondano correttamente all'https. Per l'hosting, mi affido a provider con un buon supporto, rinnovo automatico e provisioning TLS veloce, come webhoster.de, che mi facilita il lavoro. In questo modo il sito rimane sicuro, veloce e visibile, che è esattamente ciò che mi aspetto da un sito web sostenibile. HTTPS-Cambio di destinazione d'uso.