WordPress HTTPS konvertēšana: drošs un pareizs pāreja no HTTP uz HTTPS

WordPress HTTPS aizsargā pieteikšanās datus, kontaktu veidlapas un sīkfailus, kā arī palīdz man palielināt klasifikāciju un konversiju. Šajā rokasgrāmatā es jums parādīšu pilnīgu pāreju no HTTP uz HTTPS WordPress - ar sertifikātu, URL konvertēšanu, 301 novirzīšanu, jaukta satura labošanu un tīriem SEO soļiem.

Centrālie punkti

• SSL Pareizi aktivizēt un aptvert domēnu
• URL adresi konvertēt uz WordPress
• 301 Piespiedu pārsūtīšana
• Jaukts saturs Mērķtiecīga labošana
• SEO pievelciet un pārbaudiet

Kāpēc WordPress ir svarīgs HTTPS

Bez šifrēšanas uzbrucēji var pārtvert sesijas vai nolasīt veidlapas, tāpēc es nodrošinu visu Transmisija starp pārlūkprogrammu un serveri, izmantojot TLS. HTTPS novērš brīdinājumus pārlūkprogrammā, palielina uzticēšanos un pastiprina signālus, kurus meklētājprogrammas vērtē pozitīvi. Daudziem API, maksājumu pakalpojumiem un pārlūkprogrammas funkcijām tik un tā ir nepieciešami droši savienojumi. Es gūstu labumu arī no HTTP/2 un HTTP/3, kas ar TLS ielādējas ātrāk un nodrošina paralēlo darbību. Tīrs pāreja uz HTTPS novērš satura dublēšanos, jo es varu ierobežot visus variantus ar unikālu Lielgabals (Kanoniskais).

Sagatavot dublējumu un SSL sertifikātu

Pirms pieskaršos jebkādiem iestatījumiem, izveidoju pilnu failu un datubāzes dublējumu, lai jebkurā laikā varētu tiem piekļūt. Drošinātājs var atgriezties. Pēc tam es pasūtu vai aktivizēju sertifikātu - bieži vien pietiek ar Let's Encrypt bez papildu izmaksām, vai arī izmantoju DV/OV/EV sertifikātu atkarībā no savām prasībām. Daudzi mitinātāji nodrošina vedni, kas automātiski izsniedz un atjauno sertifikātus. Ja jums ir nepieciešama palīdzība soli pa solim, izmantojiet šo pamācību vietnē Iestatiet bezmaksas SSL. Pēc tam pārbaudu, vai sertifikātu ķēde ir pilnīga un vai sertifikāts attiecas gan uz www, gan uz apex domēniem (bez www); ņemu vērā arī tādus apakšdomēnus kā staging vai cdn un saglabāju tos. Derīgums īsumā.

Sertifikātu atlase un atslēgu pārvaldība

Papildus sākotnējai aktivizēšanai es atzīmēju arī dažas detaļas, kuru trūkst daudzās instrukcijās: Vai man ir nepieciešams aizstājējzīmju sertifikāts (*.domain.tld) daudziem apakšdomēniem, vai pietiek ar SAN sertifikātu ar vairākiem skaidri norādītiem hostname? Lai nodrošinātu veiktspēju, ja vien iespējams, es izmantoju ECDSA sertifikātus (eliptiskās līknes) klasisko RSA atslēgu vietā - tie ir mazāki un paātrina TLS nodošanu. Es stingri aizsargāju privāto atslēgu (failu atļaujas 600, tikai servera lietotāji) un dokumentēju privāto atslēgu. Atjaunošana-ķēde: Vai automātiskā atjaunošana patiešām tiek veikta, pat ja augšupēji ir pieslēgts CDN vai reversais starpniekserveris? Attiecībā uz ACME izaicinājumiem pārbaudu, vai validācijai netraucē novirzīšana, likmju ierobežojumi vai uzturēšanas lapas. Es arī aktivizēju OCSP saspiešanu un modernos protokolus (TLS 1.2/1.3) tieši tīmekļa serverī, lai pārlūkprogrammas varētu ātrāk apstrādāt sertifikātu pārbaudes.

Mainīt WordPress URL adreses

Es ieiet vadības panelī un atveriet Iestatījumi → Vispārīgi, tad es iestatu "WordPress adrese (URL)" un "Tīmekļa vietnes adrese (URL)" uz https://. Pēc saglabāšanas es atkal piesakos, ja sesija atsākas no jauna. Pēc tam dzēšu pārlūkprogrammas kešatmiņu un, ja iespējams, arī kešatmiņu no sava kešatmiņas spraudņa, lai apmeklētāji uzreiz saņemtu drošo versiju. Pēc tam aplūkoju logrīkus, izvēlnes un cietās saites, jo tajās joprojām var būt http saites. Attiecībā uz ziņojumos esošajiem multivides līdzekļiem es rediģēju atsevišķu saturu vai plānoju tīru Meklēšana datu bāzē (sk. turpmāk).

Droša pieteikšanās un admin

Attiecībā uz administratora apgabalu es ieviešu TLS ar nelielu papildinājumu sadaļā wp-config.php. Lai to izdarītu, virs rindas "/* Tas ir viss, pārtrauciet rediģēšanu! */" un augšupielādējiet failu:

define('FORCE_SSL_ADMIN', true);

Tas nozīmē, ka pieteikšanās, sīkfaili un visa backend daļa darbojas tikai ar HTTPS. Ja augšupēji ir pieslēgts reversais starpniekserveris vai CDN slānis, es pārliecinos, ka WordPress pareizi interpretē galveni "X-Forwarded-Proto: https". Pretējā gadījumā lietojumprogramma nepareizi uzskata savienojumu par nedrošu un iestata sīkfailus bez Drošs-flag.

Drošākas WordPress konstantes un proxy noteikšana

Ja es nevaru sasniegt URL backend (piemēram, cilpa caur plugins), Es uz laiku noteikt skaidras konstantes wp-config.php un tādējādi novērst nepareizus iestatījumus:

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

Es arī pievienoju atklāšanu aiz starpniekservera, lai is_ssl() pareizi:

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

Tas novērš nepareizu jaukta satura ģenerēšanu backendā un nodrošina, ka autentificēšanas sīkfaili ir konsekventi saistīti ar. Drošs-atribūts tiek piegādāts.

301 novirzīšanas iestatīšana .htaccess failā

Lai nodrošinātu, ka visi pieprasījumi pastāvīgi tiek pārsūtīti uz drošo versiju, izveidoju Pārsūtīšana no http uz https. Klasiskajā Apache vidē es atveru .htaccess WordPress saknē un pievienoju noteikumus virs WordPress bloka:

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

Izmantojot Nginx, pārsūtīšana notiek servera konfigurācijā (server { klausīties 80; atgriezt 301 https://$host$request_uri; }). Sīkākai informācijai, variantiem un problēmu novēršanai varat atrast skaidru rokasgrāmatu par HTTPS pārsūtīšana. Svarīgi: es saglabāju īsu pāradresēšanas ķēdi, t. i., http→https un, ja nepieciešams, www→non-www vai otrādi vienā lēcienā, lai pāradresēšanas ķēdē nebūtu nevajadzīgu lēcienu. Uzlādes laiks palielināt.

Tīra novirzīšanas stratēģija bez cilpām

Papildus pamatpārsūtīšanai esmu iestatījis arī konsekvences noteikumus: Es esmu izveidojis konsekvences konsekvences iestatījumus: vai nu www, vai newww - nekad ne abus. Izmantojot Apache, es to atrisinu vienā solī, izmantojot uzņēmēja pārbaudi:

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

Es automātiski saņemu vaicājumu virknes (UTM parametrus), samazinu novirzīšanu līdz vienam lēcienam un izvairos no cilpām, neaktivizējot nevienu konkurējošu noteikumu spraudnī vai CDN. Ja malas starpniekserveris izmanto "Flexible SSL" (pārlūks→CDN šifrēts, CDN→Izcelsme nešifrēts), pārslēdzu uz "Full (strict)", lai TLS tiktu nodrošināts gan apmeklētājam, gan izcelsmei - pretējā gadījumā pastāv cilpu un jauktu protokolu risks.

Jaukta satura atpazīšana un novēršana

Pēc pāradresēšanas pārbaudu lapu, izmantojot pārlūkprogrammas rīkus, vai tajā nav "jaukta satura", t. i., satura, kuram joprojām var piekļūt, izmantojot http ir ielādēti. Bieži tiek ietekmēti attēli, fonti, skripti vai stilu lapas tēmās, lapu veidotājos vai logrīkos. Es laboju grūti kodētus URL, mainot tos uz https redaktorā, pielāgojamā programmā vai spraudņa iestatījumos. Īstermiņā palīdz tādi rīki kā "Really Simple SSL", bet labāk ir pastāvīgi iztīrīt avotus. Bloķēts saturs izraisa stilizēšanas kļūdas vai slēptās funkcijas, tāpēc es visu attīru, līdz pārlūkprogramma nebloķē saturu. Brīdinājumi parāda vairāk.

Jaukta satura profesionāļu pārbaudes saraksts

• Es aktivizēju CSP direktīvu kā testu upgrade-insecure-requests tikai atskaites režīmā, lai redzētu, ko pārlūkprogramma automātiski atjaunina uz https - tad es pastāvīgi iztīrīt avotus.
• Šriftiem un ārējiem stiliem bieži vien ir nepieciešami CORS galvenes; bez tiem Access-Control-Allow-Origin tie parādās kā bloķēti.
• Es atpazīstu CSS fona attēlus ar absolūtām http saitēm izstrādātāja rīkos un aizvieto tos ar relatīviem ceļiem vai https.
• iframe (piemēram, kartes, videoklipi) arī ir jānorāda https, pretējā gadījumā pārlūkprogramma tos slēps.
• Tēmās es izvairos no stingri kodētiem ceļiem un izmantoju funkcijas, piemēram. home_url(), site_url(), plugins_url() un content_url()lai WordPress nodrošinātu pareizo bāzes URL.

Soli pa solim

Šajā tabulā visi ar pāreju uz eiro saistītie uzdevumi ir apkopoti kompaktā formātā, un tas palīdz man. Sekvence kas jāievēro.

Solis	Ieteikums/skaidrojums
Rezerves kopijas izveide	Pirms katras izmaiņas pabeidziet Drošinātājs failu un datubāzes
Iestatīt SSL sertifikātu	Aktivizēt Let's Encrypt vai maksas versiju ar hostētāju
Pielāgot URL	Iestatiet https backend sadaļā Iestatījumi → Vispārīgi
Iestatīt novirzīšanas	Konfigurējiet .htaccess vai Nginx servera bloku 301 uz HTTPS
Pārbaudiet jaukto saturu	Aizstāt cietās http saites saturā, tēmās un spraudņos
Aizstāt datubāzi	Aizstāt visus http gadījumus ar dublējumkopiju un cienījamu rīku
Google/SEO atjaunināšana	Pielāgot meklēšanas konsoles īpašumu, vietnes kartes, analītikas un kanonisko elementu pielāgošana

Tīra datubāzes URL vārdu aizstāšana

Dažreiz http saites ir neaktīvas logrīkos, īsajās kodēs vai lietotāja definētos laukos, tāpēc es izmantoju izmēģinātu un pārbaudītu rīku. Rīks piemēram, "Labāka meklēšanas aizstāšana". Es meklēju "http://deinedomain.de" un aizvietoju to ar "https://deinedomain.de", vispirms sausā režīmā, pēc tam pa īstam ar dublējumu. Lai veiktu sērijveida pārdēvēšanu, izmantojot WP-CLI, es izmantoju "wp search-replace", kas ir daudz ātrāka lielu lapu gadījumā. Serializētie masīvi un objekti ir jāapstrādā pareizi, tāpēc es paļaujos uz rīkiem, kas to apstrādā pareizi. Pēc aizstāšanas es pārbaudu nejaušus paraugus frontendā un svarīgos Izkārtojumi.

Datu bāze: Ko es akli neaizvietoju

Es tikai pieskaras GUID kolonnu wp_posts, kad es faktiski mainīt domēnu. Tīra protokola maiņa uz https parasti prasa nav Mainīt GUID, jo tie galvenokārt kalpo kā unikāls identifikators. Pirms globālas aizstāšanas es arī pārbaudu, vai spraudņi atsaucas uz ārējiem galapunktiem (webhooks, API), izmantojot http - es dodu priekšroku īpaši atjaunināt tos un pārbaudīt atgriešanās kanālu. Lieliem projektiem plānoju īsu satura iesaldēšanas fāzi, lai meklēšanas aizstāšanas laikā netiktu izveidotas jaunas ziņas ar vecajām shēmām. Es izmantoju WP-CLI, lai nodrošinātu ātrumu un atkārtojamību:

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 pārbaudes pēc pārejas uz euro

Pēc izmaiņu veikšanas es izveidoju jaunu īpašumu ar https meklēšanas konsolē un iesniedzu atjauninātu Lapas karte par. Es pārbaudu iekšējās saites, kanoniskās birkas, hreflang atsauces un atvērtā grafika birkas https. Izsekošanas fragmentiem (analytics, tagu pārvaldnieks, pikseļi) arī jāizmanto droša adrese. SEO spraudņos pārbaudu pāradresēšanas noteikumus un pārliecinos, ka nav "mīksto 404". Ja ir svarīgi sociālo koplietojumu skaitītāji, pārbaudu, kā rīks darbojas ar jauno Adrese rokturi.

Saskaņojiet plūsmas, robotus un kanoniskos tekstus

Es pārbaudu, vai RSS/Atom plūsmas ir pieejamas, izmantojot https, un vai tās nodrošina derīgu saturu. Statiski uzturētajā robots.txt es vajadzības gadījumā pielāgoju vietnes kartes ceļus https. Konsekventi iestatu kanoniskos URL ar https, lai meklētājprogrammas viennozīmīgi interpretētu signālus. hreflang pāri (daudzvalodu vietnes) nedrīkst atšķirties protokolā, citādi rodas nekonsekvence.

Kešēšana, CDN un veiktspēja HTTPS režīmā

HTTPS ir noderīgs arī ātruma ziņā, jo HTTP/2/3 nodrošina multipleksēšanu un galvenes saspiešanu, izmantojot Savienojums. Es pievēršu uzmanību TLS sesijas atsākšanai, OCSP saspiešanai un mūsdienīgiem šifru komplektiem, kas paātrina rokas satricinājumus. CDN piegādā statiskos aktīvus tuvāk apmeklētājam, bet tam ir konsekventi jādarbojas ar https. Kešēšanas spraudņos aktivizēju opciju "Cache for HTTPS", ja tā ir pieejama, un dzēšu vecos artefaktus. Pēc tam veicu mērījumus, izmantojot tādus rīkus kā Lighthouse, un salīdzinu rezultātus. Times pirms un pēc izmaiņām.

CDN/Proxy funkcijas

Izmantojot augšupejošo CDN, es vienmēr iestatu "Pilnīga (stingra)" uz Izcelsme, augšupielādējiet sertifikātu tur vai izmantojiet Izcelsmes sertifikātu un ļaujiet piegādāt tikai https. Es pārbaudu, vai CDN kešatmiņā ir novirzīšanas (pretējā gadījumā es redzu vecos stāvokļus), un pēc pārejas uz citu tīklu iztīros edge kešatmiņas. Var palīdzēt arī Brotli saspiešana, HTTP/3/QUIC un 0-RTT - taču ir svarīgi, lai lapas mēroga noteikumi vairs neievada http resursus. Visbeidzot, es nosūtu pareizo Klienta IP-header (piemēram, X-Forwarded-For) un konfigurējiet tīmekļa serveri tā, lai žurnālos būtu redzams īstais apmeklētāja IP.

HSTS un citi drošības galvenes

Ja vietne darbojas tikai ar HTTPS, aktivizēju HTTP Strict Transport Security (HSTS), lai pārlūkprogrammas izmantotu tikai HTTPS-variants. Es uzstādīju galveni, piemēram, šādi: Strict-Transport-Security: max-age=31536000; includeSubDomains; preload - bet tikai tad, ja visas apakšdomēnas patiešām ir droši pieejamas. Par iespējām un lamatām es iesaku izmantot rokasgrāmatu Aktivizēt HSTS. Turklāt es iestatīju drošības galvenes, piemēram, X-Content-Type-Options, X-Frame-Options un stingru satura drošības politiku, kas atļauj https avotus. Šīs galvenes pastiprina aizsardzības slāņus pret satura injekciju, klikšķu uzlaušanu un MIME-Šņaušana.

Precīza drošības galvenes noregulēšana

Papildus HSTS es pievienoju pragmatisku galvenes konfigurāciju: Atsauces politika: strict-origin-when-cross-origin ierobežo sensitīvu ceļu pārsūtīšanu, Atļauju politika ierobežo pārlūkprogrammas API (piem., kamera, mikrofons), un mērena CSP ar default-src 'self' https: novērš nevēlamu ārvalstu avotu darbību. Es sāku ar Tikai ziņojumiEs apkopoju pārkāpumus un pēc tam pastiprinu vadlīnijas. Šādi es novēršu, ka drošības galvenes netīšām "salauž" vietni.

Testēšana, uzraudzība un problēmu novēršana

Es testēju pāreju privātā logā un mobilajās ierīcēs, lai neviens vecais Sīkfaili vai kešatmiņas. Pārlūkprogrammas konsoles žurnālā ātri parādās jaukta satura brīdinājumi un bloķētie resursi. Es izmantoju "curl -I http://deinedomain.de", lai pārbaudītu, vai notiek 301 pāreja uz https versiju un vai rodas citas ķēdes. Pēc tam uzraugu kļūdu žurnālus serverī un 404 ziņojumus SEO spraudnī vai meklēšanas konsolē. Ja atsevišķi spraudņi vairs netiek ielādēti, pārbaudu to ārējos Atkarības un atjauniniet to līdz jaunākajai versijai.

Darbības uzsākšanas kontrole un nepārtraukta uzraudzība

• Pirms pārslēgšanās es pēc izvēles aktivizēju īsu uzturēšanas režīmu, lai izveidotu konsekventus novirzienus un kešatmiņas.
• Uzraugu sertifikātu derīguma termiņa beigas (trauksmes signāli), lai nebūtu nepatīkamu pārsteigumu.
• Pirmajās dienās es pārraugu 404. rādītāju, rangu līknes, pārlūkošanas statistiku un Core Web Vitals, lai savlaicīgi veiktu pretpasākumus.
• Attiecībā uz kampaņām pārbaudu, vai UTM parametri tiek pilnībā saglabāti, izmantojot 301 pāradresāciju.

Multisite, proxy un staging īpašās funkcijas

Daudzvietīgajām vietnēm es mainīju tīkla adresi uz https un pielāgoju kartēšanu, lai visām vietnēm būtu standartizēts. Pārsūtīšana izmantot. Aiz slodzes balansētājiem vai CDN tīmekļa serverim ir jāievēro "X-Forwarded-Proto" galvene, pretējā gadījumā WordPress uzskatīs, ka savienojums ir nedrošs, un iestatīs nepareizus URL. Pārbaudes sistēmām es izmantoju savus sertifikātus vai aizsargāju tos ar Basic Auth, lai meklētājprogrammas tos neindeksētu. Pēc izmaiņu veikšanas tiešraidē es atkal ieslēdzu kešatmiņas, iesildīju tās un pārraugu slodzi. Vidēs ar saviem starpniekserveriem vai ugunsmūriem dokumentēju visas izmaiņas, lai vēlākajās izvietošanas reizēs varētu izmantot. Konfigurācija pārņemt.

Daudzvietīga vietne un komercijas informācija, kuras bieži trūkst

Vairāku vietņu iestatījumos es atjauninu katrai vietnei. siteurl un mājas lapa vērtības, jo īpaši, ja tiek veikta domēna kartēšana. Ja sunrise.php vai īpašus kartēšanas spraudņus, es pārbaudu, vai tie atbalsta https. Veikalos (piemēram, WooCommerce) es konsekventi iestatu "Checkout" un "My account" uz https, pārbaudu maksājumu un Webhook-atgriešanās un pateicības lapas. Maksājumu pakalpojumu sniedzējiem un piegādes API bieži vien ir nepieciešami atjaunināti atpakaļsaukuma URL - es tos pielāgoju un pēc izmaiņām pārbaudu paraksta pārbaudi.

Biežāk sastopamās kļūdas un ātrie risinājumi

Nepareizi sertifikāti rada sarkanas brīdinājuma zīmes - tāpēc es pārbaudu izdošanas periodu, ķēdi un to, vai sertifikātā ir iekļauti visi domēni, lai. Savienojums darbojas bez pārtraukuma. Trūkstoši 301 pāradresējumi rada dublējošu saturu; es to regulēju ar skaidriem, īsiem noteikumiem un izvairos no vairākkārtējas pārsūtīšanas. Sajaukts saturs bieži rodas no grūti kodētiem tēmu failiem; šeit es nomainu http shēmas vai izmantoju bezshēmu URL ("//...") attiecīgajās vietās. Ārējie pakalpojumi, kas joprojām atsaucas uz http bloķētajiem pieprasījumiem; šeit es atjauninu tīmekļa āķus, gala punktus un atslēgas. Ja spraudnis nespēj tikt galā ar pāreju, es testēju atjauninājumu vai aizvietoju to ar risinājumu, kas pilnībā atbalsta HTTPS. Atbalsta.

Kopsavilkums: Droši pārslēgts uz HTTPS

Es sāku ar pilnīgu dublējumu, aktivizēju SertifikātsPārslēdzu WordPress URL uz https, īstenoju 301 novirzīšanu un konsekventi sakārtoju jauktu saturu. Pēc tam datubāzē nomainu visus atlikušos http ierakstus, atjauninu SEO iestatījumus un novērtēju veiktspēju. HSTS un drošības galvenes vēl vairāk palielina drošību, ja vien visi apakšdomēni pareizi reaģē uz https. Attiecībā uz hostingu es paļaujos uz pakalpojumu sniedzējiem ar labu atbalstu, automātisku atjaunošanu un ātru TLS nodrošināšanu, piemēram, webhoster.de, kas ievērojami atvieglo manu darbu. Tādējādi vietne ir droša, ātra un redzama - tieši to es sagaidu no ilgtspējīgas vietnes. HTTPS-pāreja uz eiro.