WordPress HTTPS kaitseb sisselogimisandmeid, kontaktvorme ja küpsiseid ning aitab mul suurendada edetabelit ja konversiooni. Selles juhendis näitan teile täielikku üleminekut HTTP-lt HTTPS-ile WordPressis - koos sertifikaadi, URL-i konverteerimise, 301 ümbersuunamise, segatud sisu parandamise ja puhaste SEO sammudega.
Kesksed punktid
- SSL Aktiveerige õigesti ja katke domeen
- URLid teisendada WordPressi
- 301 Forsseerimine
- Segatud sisu Sihtotstarbeline parandus
- SEO pingutage uuesti ja kontrollige
Miks HTTPS on WordPressi jaoks oluline
Ilma krüpteerimiseta saavad ründajad seansse kaaperdada või vorme lugeda, mistõttu ma kaitstakse kogu Edastamine brauseri ja serveri vahel TLS-i abil. HTTPS hoiab ära hoiatusteated brauseris, suurendab usaldust ja tugevdab signaale, mida otsingumootorid positiivselt hindavad. Paljud API-d, makseteenused ja brauseri funktsioonid nõuavad niikuinii turvalisi ühendusi. Samuti saavad kasu HTTP/2 ja HTTP/3, mis TLSi all kiiremini laadivad ja võimaldavad paralleelsust. Puhas üleminek HTTPS-ile hoiab ära dubleeriva sisu, sest saan piirata kõik variandid unikaalsele Cannon (Canonical).
Valmistage ette varukoopia ja SSL-sertifikaat
Enne kui ma puudutan mingeid seadistusi, varundan ma failid ja andmebaasi täielikult, et saaksin neile igal ajal juurde pääseda. Kaitsmed saab tagasi. Seejärel tellin või aktiveerin sertifikaadi - Let's Encrypt on sageli piisav ilma lisakuludeta, alternatiivina kasutan DV/OV/EV sertifikaati, sõltuvalt minu vajadustest. Paljud veebimajutusteenuse pakkujad pakuvad võlurit, mis väljastab ja uuendab sertifikaate automaatselt. Kui vajate samm-sammulist abi, kasutage seda õpetust aadressil Seadistage tasuta SSL. Seejärel kontrollin, kas sertifikaadi ahel on täielik ja kas nii www- kui ka apex-domeenid (ilma www-ta) on sertifikaadiga hõlmatud; samuti võtan arvesse alamdomeene, nagu staging või cdn, ja hoian nende Kehtivus lühidalt.
Sertifikaadi valik ja võtmehaldus
Lisaks esialgsele aktiveerimisele märgin ka mõned üksikasjad, mis paljudes juhistes puuduvad: Kas ma vajan paljude alamdomeenide jaoks wildcard-sertifikaati (*.domain.tld) või piisab SAN-sertifikaadist, millel on mitu selget hostinime? Jõudluse tagamiseks kasutan klassikaliste RSA-võtmete asemel ECDSA-sertifikaate (elliptilised kõverad), kui see on võimalik - need on väiksemad ja kiirendavad TLS-käitlust. Ma kaitsen rangelt privaatvõtit (failiõigused 600, ainult serveri kasutajad) ja ma dokumenteerin Uuendamine-ahel: Kas automaatne uuendamine läheb tõesti läbi, isegi kui CDN või pöördproxy on ühendatud ülesvoolu? ACME väljakutsete puhul kontrollin, kas ümbersuunamised, määrapiirangud või hoolduslehed segavad valideerimist. Samuti aktiveerin OCSP-klammerdamise ja kaasaegsed protokollid (TLS 1.2/1.3) otse veebiserveris, et veebilehitsejad saaksid sertifikaadi kontrolli kiiremini töödelda.
WordPressi URL-i muutmine
Ma login sisse armatuurlauale ja avan Settings → General, siis panen "WordPress address (URL)" ja "Website address (URL)". https://. Pärast salvestamist login uuesti sisse, kui seanss taaskäivitub. Seejärel kustutan brauseri vahemälu ja, kui see on olemas, ka oma vahemäluplugina vahemälu, nii et külastajad saavad kohe turvalise versiooni. Seejärel vaatan vidinad, menüüd ja kõvad lingid, sest need võivad endiselt sisaldada http-linkke. Postitustes olevate meediakanalite puhul toimetan individuaalset sisu või kavandan puhta Otsi andmebaasis (vt allpool).
Turvaline sisselogimine ja haldamine
Administratiivse ala jaoks jõustan TLS-i väikese lisaga, mis on lisatud wp-config.php. Selleks lisan ma rea "/* See on kõik, lõpetage redigeerimine! */" ja laadin faili üles:
define('FORCE_SSL_ADMIN', true);
See tähendab, et sisselogimine, küpsised ja kogu backend toimivad rangelt HTTPS-i kaudu. Kui ülesvoolu on ühendatud pöördproxy või CDN-kiht, siis veendun, et WordPress tõlgendab "X-Forwarded-Proto: https" päise õigesti. Vastasel juhul käsitleb rakendus ühendust ebaõigesti ebaturvalise ühendusena ja seab küpsised ilma Turvaline-lipp.
Turvalisemad WordPressi konstandid ja proxy tuvastamine
Kui ma ei pääse backend'is URL-idele ligi (nt loop läbi pluginate), sean ma ajutiselt wp-config.php's selgesõnalised konstandid ja kõrvaldan seega valed seaded:
define('WP_HOME', 'https://deinedomain.de');
define('WP_SITEURL', 'https://deinedomain.de');
Ma lisan ka avastamist proxy'de taga, nii et is_ssl() õigesti:
if (isset($_SERVER['HTTP_X_FORWARDED_PROTO']) && $_SERVER['HTTP_X_FORWARDED_PROTO'] === 'https') {
$_SERVER['HTTPS'] = 'on';
}
See hoiab ära ebaõige segatud sisu genereerimise backendis ja tagab, et auth-küpsised on järjepidevalt seotud Turvaline-atribuut on tarnitud.
Seadistage 301 ümbersuunamised .htaccessis
Selleks, et tagada, et kõik taotlused lähevad püsivalt turvalisse versiooni, seadistasin ma Edasisaatmine http-lt https-le. Klassikalises Apache'i keskkonnas avan .htaccessi WordPressi juurest ja lisan reeglid WordPressi ploki kohale:
RewriteEngine On
RewriteCond %{HTTPS} !=on
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
Nginxi puhul toimub edastamine serveri konfiguratsioonis (server { listen 80; return 301 https://$host$request_uri; }). Üksikasjad, variandid ja tõrkeotsing, leiate selge juhendi HTTPS edastamine. Tähtis: ma hoian ümbersuunamisahela lühikese, st http→https ja vajadusel www→non-www või vastupidi ühes hüppes, nii et ümbersuunamisahelas ei oleks asjatuid hüppeid. Laadimisaeg suurenemine.
Puhas ümbersuunamisstrateegia ilma silmusteta
Lisaks põhilisele edastamisele sean ma järjepidevuse reeglid: Kas www või mitte-www - mitte kunagi mõlemat. Apache'i puhul lahendan selle ühe sammuga hostide kontrollimisega:
RewriteEngine On
RewriteCond %{HTTPS} !=on [OR]
RewriteCond %{HTTP_HOST} !^deinedomain\.de$ [NC]
RewriteRule ^ https://deinedomain.de%{REQUEST_URI} [L,R=301]
Ma saan päringustringid (UTM-parameetrid) automaatselt, vähendan ümbersuunamisi ühe hüppega ja väldin silmuseid, kuna ei aktiveeri ühtegi konkureerivat reeglit pluginas või CDNis. Kui servaproxy kasutab "Flexible SSL" (Browser→CDN krüpteeritud, CDN→Origin krüpteerimata), lülitan ma ümber "Full (strict)", et TLS oleks jõustatud nii külastaja kui ka päritolu jaoks - muidu on oht, et tekivad loop-probleemid ja segaprotokollid.
Segatud sisu äratundmine ja kõrvaldamine
Pärast ümbersuunamist kontrollin lehte brauseritööriistadega "segatud sisu", st sisu, millele saab endiselt juurde pääseda läbi http on laaditud. Tihti on mõjutatud pildid, kirjatüübid, skriptid või stiililehed teemades, leheküljeehitajates või vidinates. Parandan kõvasti kodeeritud URL-aadressid, muutes need https-ks redaktoris, kohandajas või pluginate seadetes. Sellised tööriistad nagu "Really Simple SSL" aitavad lühiajaliselt, kuid parem on alaline allikate puhastamine. Blokeeritud sisu põhjustab stiilivigu või varjatud funktsioone, seega puhastan kõik ära, kuni brauser ei blokeeri ühtegi sisu. Hoiatused näitab rohkem.
Segatud sisu professionaalne kontrollnimekiri
- Aktiveerin CSP direktiivi testina.
upgrade-insecure-requestsainult aruande režiimis, et näha, mida brauser automaatselt https-ile uuendab - siis ma puhastan allikaid jäädavalt. - Kirjatüübid ja välised stiilid nõuavad sageli CORS-pealkirju; ilma
Access-Control-Allow-Originnad ilmuvad blokeeritud. - Tunnistan CSS-foonipildid, millel on arendajatööriistades absoluutsed http-linkid, ja asendan need suhteliste teede või https-ga.
- ifraamid (nt kaardid, videod) peavad samuti rääkima https, vastasel juhul peidab brauser need ära.
- Teemades väldin kõvasti kodeeritud teekondi ja kasutan selliseid funktsioone nagu
home_url(),site_url(),plugins_url()jacontent_url()nii, et WordPress annab õige baas-URL-i.
Samm-sammuline ülevaade
Alljärgnevas tabelis on kõik üleminekuga seotud ülesanded kompaktselt kokku võetud ja see aitab mul Järjestus mida tuleb järgida.
| Samm | Soovitus/selgitus |
|---|---|
| Loo varukoopia | Enne iga muudatuse lõpetamist Kaitsmed failid ja andmebaas |
| SSL-sertifikaadi seadistamine | Aktiveeri Let's Encrypt või tasuline versioon koos hosteriga |
| Kohandada URL-i | Seadistage https tagaküljel seadete → Üldine all. |
| Seadistage ümbersuunamised | Konfigureeri .htaccess või Nginx serveri blokeerimine 301 HTTPS-le |
| Kontrollida segatud sisu | Asendage kõvad http-linkid sisus, teemades ja pistikprogrammides |
| Andmebaasi asendamine | Asendage kõik http esinemised varukoopia ja usaldusväärse tööriistaga |
| Google/SEO uuendamine | Kohandage Search Console'i omadusi, saidikaarti, analüütikat ja kaanonikaale |
Asendage andmebaasi URL-aadressid puhtalt
Mõnikord lebavad http-linkid vidinates, lühikoodides või kasutaja määratud väljadel, nii et ma kasutan järeleproovitud ja testitud Tööriistad nagu "Better Search Replace". Ma otsin "http://deinedomain.de" ja asendan selle "https://deinedomain.de", kõigepealt kuivalt, siis päriselt koos varundusega. WP-CLI kaudu toimuvaks seeriaviisiliseks ümbernimetamiseks kasutan ma "wp search-replace", mis on suurte lehekülgede puhul palju kiirem. Seeriaviisilised massiivid ja objektid peavad olema korrektselt käsitletud, nii et ma toetun tööriistadele, mis seda korralikult käitlevad. Pärast asendamist kontrollin juhuslikke näidiseid frontendis ja olulistes Plaanid.
Andmebaas: Mida ma pimesi ei asenda
Ma puudutan GUID veergu wp_posts ainult siis, kui ma tegelikult muudan domeeni. Puhas protokolli muutmine https-ks nõuab tavaliselt ei ole GUIDide muutmine, kuna need on eelkõige unikaalseid identifikaatoreid. Enne globaalset asendamist kontrollin ka seda, kas pluginad viitavad http-ga välistele lõpp-punktidele (webhooks, API-d) - eelistan neid konkreetselt uuendada ja testida tagastuskanalit. Suurte projektide puhul planeerin lühikese sisu külmutamise etapi, et otsingu asendamise ajal ei tekiks uusi postitusi vanade skeemidega. Kasutan WP-CLI-d, et tagada kiirus ja reprodutseeritavus:
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
SEO kontrollid pärast üleminekut
Pärast muudatust loen Search Console'is uue https-iga vara ja esitan uuendatud Sisukaart edasi. Ma kontrollin sisemisi linke, kanoonilisi silte, hreflangi viiteid ja avatud graafi silte https-i jaoks. Jälgimisliigid (analytics, tag manager, pixel) peavad samuti kasutama turvalist aadressi. SEO-pistikprogrammides kontrollin ümbersuunamisreegleid ja veendun, et ei ole "pehmeid 404-id". Kui sotsiaalse jagamise loendurid on olulised, siis testin, kuidas tööriist töötab koos uue Aadress käepidemed.
Peenhäälestus sööda, robotite ja kaanonite häälestamine
Ma kontrollin, kas RSS/Atom feedid on kättesaadavad https-i kaudu ja kas need edastavad kehtivat sisu. Staatiliselt hallatavas robots.txt-s kohandan vajaduse korral veebilehtede marsruudid https-ile. Sean kanoonilised URL-id järjepidevalt absoluutselt https-iga, et otsingumootorid tõlgendaksid signaale üheselt mõistetavalt. hreflang-paarid (mitmekeelsed saidid) ei tohi protokolli poolest erineda, muidu tekib ebajärjekindlus.
Vahemälu, CDN ja jõudlus HTTPSi all
HTTPS tasub ära ka kiiruse mõttes, kuna HTTP/2/3 võimaldab multipleksimist ja päiste tihendamist läbi Ühendus. Ma pööran tähelepanu TLS-seansi jätkamisele, OCSP-klammerdamisele ja kaasaegsetele salakirjade komplektidele, mis kiirendab käepigistusi. CDN toimetab staatilised varad külastajale lähemale, kuid peab jooksma järjekindlalt https-i peal. Caching pluginates aktiveerin võimaluse "Cache for HTTPS", kui see on saadaval, ja kustutan vanad artefaktid. Seejärel mõõdan tööriistadega nagu Lighthouse ja võrdlen Times enne ja pärast muutust.
CDN/Proxy omadused
Ülesvoolu CDNi puhul sean ma alati "Full (strict)" Originile, laadin sertifikaadi sinna üles või kasutan Origin-sertifikaati ja luban ainult https-i edastamist. Ma kontrollin, kas CDN-i vahemälu suunab ümbersuunamisi (muidu näen vanu seisundeid) ja tühjendan pärast üleminekut serveri vahemälu. Brotli compression, HTTP/3/QUIC ja 0-RTT võivad samuti aidata - kuid oluline on, et kogu lehte hõlmavad reeglid ei süstiks enam http-ressursse. Lõpuks saadan ma õige Kliendi IP-header (nt X-Forwarded-For) ja konfigureerige veebiserver nii, et logid näitaksid külastaja tegelikku IP-aadressi.
HSTS ja muud turvaotsikud
Kui sait töötab täielikult HTTPS-i kaudu, aktiveerin HTTP Strict Transport Security (HSTS), nii et brauserid kasutavad ainult HTTPS-i. HTTPS-variant. Mina panen päise näiteks niimoodi: Strict-Transport-Security: max-age=31536000; includeSubDomains; preload - aga ainult siis, kui kõik alamdomeenid on tõesti turvaliselt kättesaadavad. Võimaluste ja lõkse kohta soovitan juhendit HSTS-i aktiveerimine. Lisaks sellele määrasin turvapealkirjad nagu X-Content-Type-Options, X-Frame-Options ja range sisu turvapoliitika, mis lubab https-allikaid. Need päised tugevdavad kaitsekihti sisu süstimise, klikkimise ja MIME-Nuusutamine.
Turvalisuse päise peenhäälestamine
Lisaks HSTSile lisan ma pragmaatilise päise konfiguratsiooni: Referrer policy: strict-origin-when-cross-origin piirab tundlike radade edastamist, Lubade poliitika piirab brauseri APIsid (nt kaamera, mikrofon) ja mõõdukas CSP koos default-src 'self' https: takistab soovimatuid välisallikaid. Ma alustan Ainult aruanneMa kogun rikkumisi ja siis karmistan suuniseid. Nii väldin, et turvapealkirjad ei "rikuks" tahtmatult saiti.
Testimine, järelevalve ja tõrkeotsing
Ma katsetan üleminekut privaatses aknas ja mobiilseadmetes, nii et ükski vana Küpsised või vahemälu. Brauseri konsoolilogi näitab kiiresti segatud sisu hoiatusi ja blokeeritud ressursse. Kasutan "curl -I http://deinedomain.de", et kontrollida, kas toimub 301 https-versioonile ja kas tekivad muud ahelad. Seejärel jälgin vealogisid serveris ja 404-aruandeid SEO pluginas või Search Console'is. Kui üksikud pluginad ei lae enam, siis kontrollin nende väliseid Sõltuvused ja ajakohastage see uusima versiooniga.
Kontroll ja pidev järelevalve
- Ma valikuliselt aktiveerin lühikese hooldusrežiimi enne üleminekut, et luua järjepidevad ümbersuunamised ja vahemälud.
- Jälgin sertifikaatide aegumist (alarmid), et ei tuleks ebameeldivaid üllatusi.
- Esimestel päevadel jälgin 404-arvu, edetabelikõveraid, roomamisstatistikat ja Core Web Vitals'i, et võtta varajasi vastumeetmeid.
- Kampaaniate puhul kontrollin, kas UTM-parameetrid säilivad täielikult 301 ümberjuhtimise kaudu.
Multisite, proxy ja stage'i eripära
Multisaitide puhul muudan võrgu aadressi https-ks ja kohandan kaardistusi nii, et kõikidel saitidel oleks standardne Edasisaatmine kasutada. Koormuse tasakaalustajate või CDNide taga peab veebiserver jälgima "X-Forwarded-Proto" päise, vastasel juhul arvab WordPress, et ühendus on ebaturvaline ja seab valed URLid. Staging-süsteemide puhul kasutan ma oma sertifikaate või kaitsen neid Basic Authiga, et otsingumootorid neid ei indekseeriks. Pärast live-muutust lülitan vahemälud uuesti sisse, soojendan neid ja jälgin koormust. Keskkondades, kus on oma proxyd või tulemüürid, dokumenteerin kõik muudatused, et hilisemad juurutused saaksid kasutada Konfiguratsioon võtta üle.
Multisite ja kaubanduse üksikasjad, mis sageli puuduvad
Mitme saidi seadistustes uuendan ma iga saidi kohta järgmist. siteurl ja koju väärtused, eriti kui tegemist on domeeni kaardistamisega. Kui sunrise.php või spetsiaalsete kaardistuspistikprogrammide puhul kontrollin, kas nad on https-tundlikud. Kauplustes (nt WooCommerce) sean järjekindlalt "Checkout" ja "My account" https-ile, testin makse ja Veebikonks-pöördumised ja tänukirjad. Makseteenuse pakkujad ja saatmise API-d nõuavad sageli uuendatud tagasikutsumise URL-id - ma kohandan neid ja kontrollin allkirja kontrolli pärast muudatust.
Üldised lõkse ja kiired lahendused
Väärad sertifikaadid põhjustavad punaseid hoiatusmärke - seetõttu kontrollin sertifikaadi väljastamise perioodi, ahelat ja seda, kas kõik domeenid on sertifikaadiga hõlmatud, nii et Ühendus töötab katkematult. Puuduvad 301 ümbersuunamised loovad dubleeritud sisu; ma reguleerin seda selgete, lühikeste reeglitega ja väldin mitmekordseid hüppeid. Segatud sisu pärineb sageli kõvasti kodeeritud teemafailidest; siinkohal asendan http-skeemid või kasutan skeemita URL-aadresse ("//...") asjakohastes kohtades. Välised teenused, mis viitavad endiselt http-blokeeringutele; siin uuendan veebikonksud, lõpp-punktid ja võtmed. Kui plugin ei saa üleminekuga hakkama, testin uuendust või asendan selle lahendusega, mis toetab täielikult HTTPS-i. Toetab.
Kokkuvõte: turvaliselt HTTPS-ile üle läinud
Ma alustan täieliku varukoopia tegemisega, aktiveerin SertifikaatMa lülitan WordPressi URL-id https-i, rakendan 301 ümbersuunamist ja puhastan järjepidevalt segatud sisu. Seejärel asendan andmebaasis allesjäänud http-kirjed, uuendan SEO-sätteid ja mõõdan jõudlust. HSTS ja turvaotsikud suurendavad turvalisust veelgi, kui kõik alamdomeenid reageerivad korralikult https-le. Hostingu puhul toetun hea toe, automaatse uuendamise ja kiire TLS-varustamisega teenusepakkujatele, nagu webhoster.de, mis teeb minu töö palju lihtsamaks. See hoiab saidi turvalisena, kiire ja nähtavana - see on täpselt see, mida ma ootan jätkusuutlikust veebisaidist. HTTPS-vahetus.
