WordPress migracija į HTTPS: žingsnis po žingsnio savininkams

WordPress svetainės perkėlimas į HTTPS vyksta keturiais pagrindiniais etapais: įdiegiate SSL sertifikatą, atnaujinate WordPress adresus, pakeičiate duomenų bazės URL ir nustatote serverinius 301 peradresavimus. Prieš bet ką kitą, padarykite pilną failų ir duomenų bazės atsarginę kopiją. Tai ne rekomendacija, o privaloma sąlyga.

Trumpas veiksmų žemėlapis:

1. Padarykite pilną atsarginę kopiją (failai + duomenų bazė).
2. Įdiekite SSL sertifikatą per hostingą (cPanel, DirectAdmin arba kreipkitės į palaikymo komandą).
3. Atnaujinkite WordPress adresus: „Settings → General“ arba per wp-config.php.
4. Pakeiskite visus HTTP URL duomenų bazėje naudodami WP-CLI arba Better Search Replace.
5. Nustatykite serverinius 301 peradresavimus (.htaccess arba nginx konfigūracijoje).
6. Ištaisykite mixed content klaidas naršyklės DevTools arba skaneriais.
7. Patikrinkite SSL grandinę, peradresavimus ir indeksavimą Google Search Console.

Pagrindinės išvados

Sėkminga WordPress migracija į HTTPS reikalauja trijų dalykų: tinkamo SSL sertifikato, serverinių 301 peradresavimų ir pilno duomenų bazės URL perrašymo su WP-CLI arba Better Search Replace.

Turinys

• Kodėl verta pereiti į HTTPS: saugumas, naršyklių įspėjimai ir SEO
• Prieš pradėdami: atsarginės kopijos ir SSL sertifikato pasirinkimas
• Kaip įdiegti SSL sertifikatą hostinge: cPanel ir DirectAdmin žingsniai
• Kaip atnaujinti WordPress nustatymus ir priversti HTTPS
• Kaip saugiai pakeisti URL duomenų bazėje: WP-CLI ir Better Search Replace
• Kaip rasti ir ištaisyti mixed content klaidas WordPress svetainėje
• Peradresavimai ir SEO: 301 redirect, Search Console ir sitemap atnaujinimas
• HSTS: kada ir kaip įjungti, pavojai ir preload procesas
• Kaip patikrinti svetainę prieš ir po migracijos
• Dažniausios problemos ir kaip grįžti atgal
• Kada verta kreiptis į DMNT: sudėtingi serveriai ir didelės svetainės
• DMNT požiūris: kodėl rankiniai sprendimai laimi ilgalaikėje perspektyvoje
• DMNT padeda su HTTPS migracija: kas įeina į paslaugą
• Šaltiniai
• Dažniausiai užduodami klausimai

Kodėl verta pereiti į HTTPS: saugumas, naršyklių įspėjimai ir SEO

HTTPS saugo duomenų srautą tarp naršyklės ir serverio bei neleidžia atsirasti Chrome ir Firefox „Not secure“ įspėjimams, kurie tiesiogiai kenkia vartotojų pasitikėjimui. Kai lankytojas mato tokį įspėjimą kontaktų ar mokėjimo formoje, didelė dalis jų tiesiog palieka svetainę.

Google oficialiai patvirtino HTTPS kaip reitingo signalą dar 2014 m. Pats signalas yra nedidelis, tačiau neteisingai atlikta migracija, pavyzdžiui, be 301 peradresavimų arba su mixed content klaidomis, gali sukelti reikšmingus pozicijų praradimus. Todėl migracijos kokybė yra svarbesnė nei pats HTTPS faktas.

Google Search Console yra pirmasis įrankis, kurį turėtumėte atidaryti migracijos metu: čia pridėsite naują HTTPS nuosavybę, pateiksite atnaujintą sitemap.xml ir stebėsite indeksavimo eigą. Be šio žingsnio Google gali ilgiau indeksuoti naujus HTTPS adresus.

Prieš pradėdami: atsarginės kopijos ir SSL sertifikato pasirinkimas

Atsarginė kopija yra vienintelis garantas, jei kas nors nueina ne taip. Kopijuokite tiek failus, tiek duomenų bazę, ir patikrinkite, kad kopija tikrai atkuriama. Daugelis hostingo paslaugų teikėjų Lietuvoje siūlo automatines kopijas, tačiau prieš didelę migraciją padarykite papildomą rankinę kopiją.

Koks SSL sertifikatas tinka jūsų svetainei?

Let’s Encrypt teikia nemokamus, automatizuotus ir viešai pasitikinčius SSL/TLS sertifikatus, tinkamus daugumai standartinių svetainių. Sertifikatas atsinaujina automatiškai reguliariais intervalais, todėl nereikia sekti galiojimo datų rankiniu būdu. Tai tinkamas pasirinkimas tinklaraščiams, vizitinėms kortelėms ir daugumai verslo svetainių.

Mokami sertifikatai aktualūs konkrečiais atvejais: wildcard sertifikatas apima visus subdomenus vienu įrašu, o organizacinio lygio (OV) arba išplėstinio patvirtinimo (EV) sertifikatai reikalingi, kai verslas nori rodyti papildomą identiteto patvirtinimą naršyklės juostoje. Finansų ar sveikatos sektoriaus svetainėms tai gali turėti rinkodaros vertę.

Profesionalus patarimas: Prieš diegdami patikrinkite, ar sertifikatas apima pagrindinį domeną ir jo www versiją. Jei ne, naršyklė gali rodyti klaidą kitam variantui.

Kaip įdiegti SSL sertifikatą hostinge: cPanel ir DirectAdmin žingsniai

Sertifikato įdiegimas per hostingo valdymo skydelį yra pirmasis techninis žingsnis, kuris dažnai užtrunka trumpai.

SSL diegimas per cPanel

1. Prisijunkite prie cPanel ir raskite skyrių „Security“.
2. Atidarykite „SSL/TLS“ arba „Let’s Encrypt SSL“ (priklauso nuo hostingo).
3. Pasirinkite domeną ir spustelėkite „Issue“ arba „Install“.
4. Patikrinkite, kad sertifikatas apima ir pagrindinį domeną, ir www variantą.
5. Palaukite kelias minutes, kol sertifikatas aktyvuojamas, ir patikrinkite naršyklėje.

SSL diegimas per DirectAdmin

1. Prisijunkite prie DirectAdmin ir eikite į „Account Manager → SSL Certificates“.
2. Pasirinkite „Free & automatic certificate from Let’s Encrypt“.
3. Pažymėkite domeną ir www subdomeną, tada spustelėkite „Save“.
4. Jei hostingas palaiko AutoSSL, sertifikatas gali būti išduodamas automatiškai.

Jei hostingo skydelyje nerandate SSL parinkties arba svetainė veikia per sudėtingesnę serverio konfigūraciją, kreipkitės į hostingo palaikymo komandą. Dauguma Lietuvos hostingo tiekėjų tai padaro per kelias valandas.

Profesionalus patarimas: Niekada nesidalinkite privataus rakto (private key) failu su niekuo, išskyrus patikimą serverio administratorių. Jei raktas nutekėjo, sertifikatą reikia nedelsiant atšaukti ir išduoti naują.

Kaip atnaujinti WordPress nustatymus ir priversti HTTPS

Atnaujinkite WordPress adresus iš karto po sertifikato įdiegimo. Eikite į „Settings → General“ ir pakeiskite abu laukus: „WordPress Address (URL)“ ir „Site Address (URL)“ iš http:// į https://. Išsaugokite pakeitimus.

Jei dėl neteisingų nustatymų negalite pasiekti administravimo skydelio, laikinai nustatykite adresus wp-config.php faile:

define('WP_HOME', 'https://jusudomenas.lt');
define('WP_SITEURL', 'https://jusudomenas.lt');

Šias eilutes įterpkite virš eilutės /* That's all, stop editing! */. Kai tik atgausite prieigą per naršyklę, galite šias eilutes pašalinti ir naudoti standartinį nustatymų skydelį.

Serveriniai 301 peradresavimai yra efektyvesni nei peradresavimai per PHP ar įskiepius: jie veikia greičiau, nepriklauso nuo WordPress įkėlimo ir perduoda pilną nuorodos vertę (link equity). PHP lygio peradresavimai yra tinkamas laikinas sprendimas, bet ilgalaikiam stabilumui naudokite serverio konfigūraciją.

Profesionalus patarimas: Jei svetainė veikia už reverse proxy (pvz., Cloudflare arba load balancer), WordPress gali neatpažinti HTTPS protokolo. Tokiu atveju wp-config.php pridėkite: if (isset($_SERVER['HTTP_X_FORWARDED_PROTO']) && $_SERVER['HTTP_X_FORWARDED_PROTO'] === 'https') { $_SERVER['HTTPS'] = 'on'; } Taip pat galite įjungti define('FORCE_SSL_ADMIN', true); administravimo skydelio apsaugai.

Kaip saugiai pakeisti URL duomenų bazėje: WP-CLI ir Better Search Replace

Duomenų bazėje likusios http:// nuorodos sukels mixed content klaidas net po viso kito konfigūravimo. Naudokite WP-CLI arba specializuotus įrankius, nes paprastas SQL REPLACE gali sugadinti serializuotus duomenis, kuriuose saugomi builderių, temų ir įskiepių nustatymai.

Serializuoti duomenys yra ypač trapūs: juose URL ilgis yra užkoduotas skaičiumi, todėl pakeitus URL tekstą be atitinkamo skaičiaus atnaujinimo, duomenys tampa neįskaitomi. WP-CLI tai tvarko automatiškai.

WP-CLI paieškos ir keitimo seka

1. Prisijunkite prie serverio per SSH.
2. Paleiskite bandomąją komandą (dry-run), kad pamatytumėte, kas bus keičiama:
   wp search-replace 'http://jusudomenas.lt' 'https://jusudomenas.lt' --dry-run --all-tables
3. Peržiūrėkite rezultatus. Jei viskas atrodo teisingai, paleiskite tikrąjį keitimą:
   wp search-replace 'http://jusudomenas.lt' 'https://jusudomenas.lt' --all-tables
4. Išvalykite WordPress talpyklą: wp cache flush

Parametras --dry-run parodo, kiek įrašų bus pakeista, bet nieko nekeičia. Tai privalomas žingsnis prieš tikrąjį vykdymą.

Jei neturite SSH prieigos, naudokite Better Search Replace įskiepį iš WordPress.org. Jis tvarko serializuotus duomenis teisingai ir turi bandomojo paleidimo režimą. Po keitimo įskiepį rekomenduojama išjungti arba pašalinti.

Profesionalus patarimas: Visada padarykite atsarginę kopiją prieš WP-CLI keitimą, net jei kopiją jau turite. Duomenų bazės keitimas yra neatšaukiamas veiksmas be atsarginės kopijos.

Kaip rasti ir ištaisyti mixed content klaidas WordPress svetainėje

Mixed content reiškia, kad HTTPS puslapyje įkeliami resursai per HTTP: paveikslėliai, CSS, JavaScript ar šriftai. Naršyklė blokuoja aktyvų mixed content (skriptus, stilius) ir rodo įspėjimą pasyviam (paveikslėliams). Abiem atvejais tai kenkia vartotojo patirčiai ir pasitikėjimui.

Pradėkite nuo naršyklės DevTools Console skirtuko: atidarykite svetainę, paspauskite F12 ir ieškokite raudonų arba geltonų įspėjimų su „Mixed Content“ tekstu. Čia matysite tikslų failo kelią ir šaltinį.

MalCare paaiškina, kad mixed content dažniausiai kyla iš temų, įskiepių, builderių arba išorinių resursų. Builderių (pvz., Elementor, Divi) sugeneruoti CSS ir JavaScript failai dažnai saugo absoliučius URL, todėl po migracijos juos reikia atnaujinti per WP-CLI arba duomenų bazės keitimą.

Jei išorinis šaltinis (pvz., trečiosios šalies šriftas ar paveikslėlis) neturi HTTPS versijos, pakeiskite jį lokaliu variantu arba raskite alternatyvą su HTTPS palaikymu.

Really Simple SSL ir panašūs įskiepiai gali greitai sumažinti mixed content klaidų skaičių, tačiau KadenceWP ekspertai pabrėžia: įskiepiai yra laikinas sprendimas. Ilgalaikiam stabilumui atnaujinkite URL šaltinyje, duomenų bazėje ir temų konfigūracijose.

Profesionalus patarimas: Patikrinkite ne tik pagrindinį puslapį, bet ir vidines kategorijų, produktų bei kontaktų formos puslapius. Mixed content klaidos dažnai pasirodo tik konkrečiuose puslapiuose, ne visoje svetainėje.

Peradresavimai ir SEO: 301 redirect, Search Console ir sitemap atnaujinimas

Serveriniai 301 peradresavimai yra patikimesni ir greitesni nei PHP lygio peradresavimai, todėl konfigūruokite juos tiesiogiai serveryje. InspectWP patvirtina, kad serverio lygio peradresavimai perduoda pilną nuorodos vertę ir veikia nepriklausomai nuo WordPress įkėlimo.

Apache serveriuose peradresavimas nustatomas .htaccess faile: pridedama taisyklė, kuri visus HTTP užklausimus nukreipia į HTTPS. Nginx serveriuose tai daroma serverio bloko konfigūracijoje su return 301 direktyva. Abiem atvejais svarbu patikrinti, kad peradresavimas veikia tik vieną kartą (ne grandinė), nes keli peradresavimai iš eilės lėtina puslapį.

SEO veiksmai po migracijos:

• Pridėkite naują HTTPS nuosavybę Google Search Console ir patvirtinkite domeną.
• Pateikite atnaujintą sitemap.xml su HTTPS adresais.
• Patikrinkite Google Analytics nuosavybės parametrus ir atnaujinkite svetainės URL.
• Atnaujinkite visas išorines nuorodas, kurias kontroliuojate (socialiniai tinklai, katalogai, partnerių svetainės).

Reindeksavimas gali užtrukti kelias savaites. Stebėkite indeksavimo pažangą Search Console „Coverage“ ataskaitoje ir tikrinkite, ar nėra klaidų. WordPress saugumo patikra po migracijos padeda užtikrinti, kad visi pakeitimai atlikti teisingai.

HSTS: kada ir kaip įjungti, pavojai ir preload procesas

HSTS (HTTP Strict Transport Security) priverčia naršykles visada naudoti HTTPS net tada, kai vartotojas įveda adresą be protokolo. Tai papildomas saugumo sluoksnis, tačiau prieš aktyvuojant reikia suprasti pasekmes.

HTTP Strict Transport Security yra naršyklių palaikomas standartas, kuris veikia per serverio atsakymo antraštę. Pavyzdinis header:

Strict-Transport-Security: max-age=86400; includeSubDomains

Pradėkite nuo max-age=86400 (1 diena) testavimui. Jei viskas veikia teisingai, padidinkite iki max-age=31536000 (1 metai). includeSubDomains parametras taikomas visiems subdomenams, todėl prieš jį įjungdami patikrinkite, kad visi subdomenai veikia per HTTPS.

Preload įtraukimas yra atskiras žingsnis: jūsų domenas įrašomas į naršyklių preload sąrašą, kuris yra beveik neatšaukiamas. Jei vėliau reikės grįžti prie HTTP (pvz., techniniams darbams), tai bus labai sudėtinga. Įtraukite į preload tik tada, kai esate visiškai tikri, kad svetainė visada veiks per HTTPS.

Profesionalus patarimas: Prieš įjungdami HSTS su includeSubDomains, patikrinkite kiekvieną subdomeną atskirai. Vienas subdomenų be SSL sertifikato padarys visą domeną nepasiekiamą vartotojams, kurie jau gavo HSTS antraštę.

Kaip patikrinti svetainę prieš ir po migracijos

Visada patikrinkite sertifikatą, peradresavimus ir mixed content prieš paskelbdami pakeitimus viešai. Testavimas trunka 15–30 minučių, bet sutaupo valandas trikčių šalinimo.

1. SSL grandinė: naudokite SSL Labs (ssllabs.com/ssltest) ir patikrinkite, ar gausite „A“ arba „A+“ įvertinimą. Čia matysite ir grandinės klaidas, ir sertifikato galiojimo datą.
2. 301 peradresavimas: naudokite redirect checker įrankį (pvz., redirect-checker.org) ir patikrinkite, kad http://jusudomenas.lt nukreipia į https://jusudomenas.lt vienu peradresavimu.
3. Mixed content: atidarykite kelis puslapius naršyklės DevTools Console ir ieškokite įspėjimų.
4. Sitemap: patikrinkite, kad sitemap.xml adresai prasideda https://.
5. Search Console: patikrinkite, ar nėra naujų klaidų „Coverage“ ataskaitoje.
6. CDN ir talpykla: išvalykite CDN talpyklą (pvz., Cloudflare) ir WordPress talpyklos įskiepį po visų pakeitimų.

InspectWP rekomenduoja pakartoti testavimą po 24–48 valandų, nes kai kurios talpyklos atsinaujina lėčiau. Indeksavimo ir reitingų pokyčius stebėkite kelias savaites.

Dažniausios problemos ir kaip grįžti atgal

Dažniausiai pasitaikančios klaidos po migracijos yra redirect loop, netinkamas sertifikato vardas, mixed content ir talpyklos problemos. Kiekviena iš jų turi aiškų sprendimą.

Redirect loop atsiranda, kai WordPress ir serveris peradresuoja vienas kitą. Patikrinkite wp-config.php dėl WP_HOME ir WP_SITEURL reikšmių ir įsitikinkite, kad reverse proxy X-Forwarded-Proto nustatymas teisingas. Laikinai išjunkite .htaccess peradresavimą ir tikrinkite žingsnis po žingsnio.

Netinkamas sertifikato vardas reiškia, kad sertifikatas neapima naudojamo domeno varianto (pvz., sertifikatas išduotas example.lt, bet svetainė pasiekiama per www.example.lt). Sprendimas: išduokite naują sertifikatą su abiem variantais.

Mixed content po DB keitimo dažniausiai reiškia, kad kai kurie URL liko nepakeisti (pvz., builderių talpykloje). Išvalykite talpyklą ir paleiskite WP-CLI keitimą dar kartą su --all-tables.

Rollback žingsniai, jei reikia greitai grįžti:

1. Atkurkite duomenų bazę iš atsarginės kopijos per phpMyAdmin arba WP-CLI.
2. Atkurkite failus (ypač wp-config.php ir .htaccess) iš atsarginės kopijos.
3. Pašalinkite arba komentuokite HTTPS peradresavimo taisykles .htaccess faile.
4. Pakeiskite WordPress adresus atgal į http:// per wp-config.php.

Jei negalite atkurti svetainės per kelias minutes, įjunkite priežiūros (maintenance) režimą, kad vartotojai matytų aiškų pranešimą, o ne klaidą.

Kada verta kreiptis į DMNT: sudėtingi serveriai ir didelės svetainės

Kreipkitės į specialistą, jei svetainė turi daugiau nei 500 puslapių, naudoja e-komercijos sprendimus (WooCommerce su mokėjimų integracijomis), veikia už load balancer ar Cloudflare, arba turi kelis subdomenus su skirtingomis konfigūracijomis. Tokiais atvejais klaidos kaina yra žymiai didesnė.

Kriterijai, kada samdyti profesionalą:

• Svetainė turi aktyvias pardavimų ar checkout integracijas (mokėjimų vartai, CRM).
• Naudojate nestandartinius serverio nustatymus arba VPS be valdymo skydelio.
• Baiminatės SEO nuostolių ir norite garantuoto testavimo bei rollback plano.
• Svetainė veikia keliuose domenų variantuose arba turi daugiau nei vieną WordPress diegimą.

Prieš samdydami bet kurį tiekėją, užduokite šiuos klausimus: ar jie turi patirties su WP-CLI ir DB migracijomis, kokia jų atsarginių kopijų politika, ar pateiks testavimo ir rollback planą, ir koks yra darbų laikotarpis bei kaina.

DMNT teikia WordPress svetainių priežiūros paslaugas, įskaitant HTTPS migracijas su garantuotomis atsarginėmis kopijomis ir testavimo procedūromis.

DMNT požiūris: kodėl rankiniai sprendimai laimi ilgalaikėje perspektyvoje

Dažnai matome svetaines, kuriose HTTPS „veikia“, bet tik todėl, kad įskiepis kiekvieną kartą dinamiškai perrašo URL. Tai reiškia papildomą apkrovą kiekvienam puslapiui ir potencialų konfliktą su kitais įskiepiais ar temomis. Kai įskiepis atnaujinamas arba pašalinamas, problemos grįžta.

DMNT prioritetas yra saugumas ir SEO stabilumas, o tai reiškia serverinius peradresavimus ir duomenų bazės perrašymą kaip pagrindinį sprendimą. Įskiepiai kaip Really Simple SSL yra naudingi greitam taisymui arba kaip laikinas sprendimas, kol atliekamas pilnas DB keitimas. Bet jie neturėtų būti galutinis atsakymas.

Kitas dažnas klaidingas supratimas: HTTPS migracija yra vienkartinis įvykis. Iš tikrųjų tai yra WordPress atnaujinimų plano dalis. Sertifikatai baigia galioti, įskiepiai atnaujinami, temos keičiamos, ir kiekvienas toks pokytis gali sukelti naujų mixed content klaidų. Reguliari saugumo patikra po migracijos yra ne prabanga, o priežiūros standartas.

Planuokite migraciją naktiniam ar mažos apkrovos laikui ir visada turėkite paruoštą testavimo kopiją. Tai sutaupo nervų ir laiko.

DMNT padeda su HTTPS migracija: kas įeina į paslaugą

WordPress svetainės perkėlimas į HTTPS su DMNT apima visą procesą nuo pradžios iki pabaigos: SSL sertifikato įdiegimą, serverinius 301 peradresavimus, duomenų bazės URL perrašymą, mixed content klaidų taisymą, testavimą ir Google Search Console atnaujinimą. Jums nereikia spręsti techninių detalių patiems.

Kiekviena migracija atliekama su garantuota atsargine kopija prieš darbus ir rollback procedūra, jei kažkas nueina ne taip. Tai ypač svarbu e-komercijos svetainėms ir svetainėms su aktyviu srautu, kur prastovos kaina yra reali.

Jei norite, kad HTTPS migracija būtų atlikta teisingai ir be SEO rizikos, susisiekite su DMNT per svetainių kūrimo ir priežiūros paslaugų puslapį arba užpildykite užklausos formą. Gausite aiškų darbų planą ir kainą.

Šaltiniai

Šie resursai padės giliau suprasti atskirus migracijos etapus arba patikrinti technines detales:

• Let’s Encrypt
• WordPress
• Jak przekierować HTTP na HTTPS w WordPress | InspectWP
• WordPress Mixed Content: Find the HTTP Leak and Fix It Safely
• Fixing mixed content errors in WordPress | KadenceWP

Dažniausiai užduodami klausimai

Ar Let’s Encrypt sertifikatas tinka verslo svetainei?

Taip, Let’s Encrypt sertifikatas tinka daugumai verslo svetainių: jis viešai pasitikinamas, nemokamas ir atsinaujina automatiškai. Mokamas sertifikatas reikalingas tik tada, kai reikia wildcard ar organizacinio lygio patvirtinimo.

Kiek laiko užtrunka WordPress migracija į HTTPS?

Mažai svetainei migracija trunka 1–2 dienas: viena diena testavimui ir viena aktyvacijai. Didelėms svetainėms su e-komercija ar sudėtingomis integracijomis planuokite etapais ir skirkite testavimo aplinką.

Kas yra mixed content ir kaip jį rasti?

Mixed content atsiranda, kai HTTPS puslapyje įkeliami resursai per HTTP. Atidarykite naršyklės DevTools (F12), eikite į Console skirtuką ir ieškokite „Mixed Content“ įspėjimų, kuriuose nurodytas tikslus failo kelias.

Ar galima atlikti migracijos rollback, jei kažkas nueina ne taip?

Taip, jei turite atsarginę kopiją. Atkurkite duomenų bazę ir failus iš kopijos, pašalinkite HTTPS peradresavimo taisykles .htaccess faile ir pakeiskite WordPress adresus atgal į http:// per wp-config.php.

Ar HTTPS migracija paveiks Google pozicijas?

Teisingai atlikta migracija su 301 peradresavimais ir Search Console atnaujinimu neturėtų sukelti ilgalaikių pozicijų praradimų. Trumpalaikiai svyravimai per pirmąsias 2–4 savaites yra normalūs; stebėkite indeksavimą per SEO audito įrankius.

Rekomendacija

• WordPress svetainių priežiūra 2026 | DMNT
• WordPress greičio optimizavimas Lietuvoje: geriausi 2026 m.
• Geriausia WordPress priežiūra Lietuvoje: ką pasirinkti