Perėjimas nuo HTTP prie HTTPS skamba paprastai: įdiegiate SSL sertifikatą, nukreipiate srautą ir viskas veikia. Realybėje šis procesas turi dešimtis smulkmenų, kurios, nepastebėtos, gali kainuoti jums paieškos pozicijas, nutrūkusius nukreipimus, prarastus lankytojus ir sutrikusius analitinius duomenis.
Šiame vadove rasite kiekvieną žingsnį nuo pasiruošimo iki galutinio patikrinimo. Straipsnis skirtas tiems, kurie nori perkelti svetainę teisingai iš pirmo karto, be skubotų taisymų po mėnesio.
Kodėl perkėlimas į HTTPS nebėra pasirinkimas
Naršyklės nebetoleruoja HTTP
Visos pagrindinės naršyklės, Chrome, Firefox, Safari ir Edge, rodo aiškų „Not Secure” (Nesaugu) įspėjimą prie kiekvienos HTTP svetainės. Chrome tai daro nuo 2018 metų, ir kiekviena nauja naršyklės versija šį įspėjimą padaro vis ryškesnį.
Praktinis poveikis yra tiesmukas: lankytojas, pamatęs raudoną įspėjimą, spaudžia „Atgal” mygtuką. Tyrimai rodo, kad 84 % vartotojų atsisako pirkimo, jei mato, kad ryšys nesaugus. Net jei jūsų svetainė nerenka jokių duomenų, įspėjimas vis tiek rodomas.
Google teikia pirmenybę HTTPS
Google oficialiai patvirtino HTTPS kaip reitingavimo signalą dar 2014 metais. Nuo tada šio signalo svoris tik augo. Kai Google robatas randa ir HTTP, ir HTTPS svetainės versiją, jis indeksuoja HTTPS versiją pagal nutylėjimą. HTTP versija lieka šešėlyje.
Bet svarbiau už patį reitingavimo signalą yra tai, kaip Google traktuoja perkėlimą: jei 301 peradresavimai nustatyti teisingai, SEO vertė (link equity) perduodama iš HTTP į HTTPS beveik be nuostolių. Jei peradresavimai sukonfigūruoti neteisingai, galite prarasti mėnesių ar metų SEO darbo rezultatus.
BDAR ir duomenų apsaugos reikalavimai
Europos Sąjungos Bendrasis duomenų apsaugos reglamentas (BDAR/GDPR) reikalauja „tinkamų techninių priemonių” asmeniniams duomenims apsaugoti. SSL/TLS šifravimas yra viena pagrindinių tokių priemonių. Svetainė, renkanti kontaktines formas, el. pašto adresus ar mokėjimo duomenis per nešifruotą HTTP ryšį, pažeidžia šį reikalavimą.
HTTP/2 protokolo pranašumai
HTTP/2 protokolas, kuris leidžia greičiau perduoti duomenis tarp serverio ir naršyklės, veikia tik per HTTPS. Pereidami prie HTTPS, jūs automatiškai gaunate prieigą prie HTTP/2 (ir HTTP/3) greičio pranašumų: multipleksavimo, serverio push, antraščių kompresijos. Tai reiškia, kad po perkėlimo jūsų svetainė gali iš tikrųjų veikti greičiau nei prieš tai.
Pasiruošimas perkėlimui: ką padaryti prieš pradedant
Skubotas perkėlimas be pasiruošimo yra dažniausia klaida. Prieš paliečiant bet kokį nustatymą, atlikite šiuos žingsnius.
1. Sukurkite pilną svetainės atsarginę kopiją
Prieš bet kokius pakeitimus sukurkite:
- Duomenų bazės atsarginę kopiją (MySQL/MariaDB dump)
- Failų sistemos atsarginę kopiją (visi svetainės failai, temos, įskiepiai)
- Serverio konfigūracijos kopiją (Nginx/Apache/LiteSpeed konfigūraciniai failai, .htaccess)
- DNS įrašų kopiją (užfiksuokite visus esamus DNS įrašus)
# MySQL duomenų bazės atsarginė kopija
mysqldump -u vartotojas -p duomenu_baze > atsargine_kopija_$(date +%Y%m%d).sql
# Failų atsarginė kopija
tar -czf svetaine_atsargine_$(date +%Y%m%d).tar.gz /var/www/jusudomenas.lt/
# Nginx konfigūracijos kopija
sudo cp -r /etc/nginx/ /etc/nginx.backup.$(date +%Y%m%d)
# Apache konfigūracijos kopija
sudo cp -r /etc/apache2/ /etc/apache2.backup.$(date +%Y%m%d)
2. Užfiksuokite dabartinę SEO būseną
Prieš perkėlimą užfiksuokite savo svetainės SEO rodiklius, kad po perkėlimo galėtumėte palyginti ir greitai pastebėti problemas:
- Google Search Console: Eksportuokite pozicijų, paspaudimų ir įspūdžių duomenis bent už paskutinius 3 mėnesius.
- Google Analytics: Užfiksuokite organinio srauto duomenis, puslapių peržiūras ir konversijų rodiklius.
- Indeksuotų puslapių skaičius: Google paieškoje įveskite
site:jusudomenas.ltir užsirašykite rezultatų skaičių. - Išorinės nuorodos (backlinks): Eksportuokite nuorodų profilį iš Ahrefs, Semrush ar Moz.
- Pozicijų stebėjimas: Užfiksuokite svarbiausių raktažodžių pozicijas.
3. Atlikite svetainės auditą
Prieš perkėlimą identifikuokite visus URL, kuriuos reikės peradresuoti:
- Sitemap.xml peržiūra: Patikrinkite, kiek puslapių yra jūsų svetainės žemėlapyje.
- Crawl su Screaming Frog arba Sitebulb: Nuskenuokite visą svetainę ir gaukite pilną URL sąrašą. Šis sąrašas bus jūsų peradresavimo kontrolinis dokumentas.
- Esami peradresavimai: Patikrinkite, ar jau turite 301/302 peradresavimus. Šie peradresavimai turės būti atnaujinti, kad nukreiptų tiesiai į HTTPS versiją (venkite grandininio peradresavimo).
- Kanonines nuorodos (canonical): Patikrinkite, ar jūsų puslapiai turi
<link rel="canonical">žymas ir kokie URL juose nurodyti.
4. Patikrinkite trečiųjų šalių integracijų suderinamumą
Daugelis svetainių naudoja trečiųjų šalių paslaugas, kurios gali būti paveiktos perkėlimo:
- Mokėjimo vartai (Stripe, PayPal, banklink): Patikrinkite, ar callback URL atnaujinti.
- Socialinių tinklų widgetai: Facebook, LinkedIn dalintuvai skaičiuoja „shares” pagal URL. Perėjus prie HTTPS, seni skaičiai gali būti nustatyti iš naujo (Facebook Open Graph).
- El. pašto rinkodaros platformos: Atnaujinkite nuorodas šablonuose (Mailchimp, SendGrid, GetResponse).
- Reklaminės platformos: Google Ads, Facebook Ads nukreipimo URL turi būti atnaujinti.
- CDN tiekėjas: Cloudflare, BunnyCDN, KeyCDN konfigūracija turi palaikyti HTTPS.
- Trečiųjų šalių skriptai: Analitikos kodai, pokalbių widgetai, A/B testavimo įrankiai.
5. Pasirinkite tinkamą laiką perkėlimui
Perkėlimą planuokite tuomet, kai:
- Mažiausias srautas: Savaitgalis arba naktis (jei jūsų auditorija lokali).
- Ne sezono metu: Venkite perkėlimo prieš didžiausias pardavimų akcijas (Juodasis penktadienis, Kalėdos).
- Turimas techninis palaikymas: Įsitikinkite, kad klaidos atveju turite žmogų, galintį greitai reaguoti.
- Ne vienu metu su kitais pakeitimais: Nekeiskite dizaino, turinio struktūros ar domeno tuo pačiu metu kaip HTTPS perkėlimą. Vienas didelis pakeitimas vienu metu.
Žingsnis po žingsnio: HTTP į HTTPS perkėlimo procesas
1 žingsnis: SSL sertifikato diegimas
Jei dar neturite SSL sertifikato, pirmiausia jį įdiekite. Galimi variantai:
Nemokamas Let’s Encrypt (rekomenduojama daugumai svetainių):
# Ubuntu/Debian su Nginx
sudo apt update
sudo apt install certbot python3-certbot-nginx
sudo certbot --nginx -d jusudomenas.lt -d www.jusudomenas.lt
# Ubuntu/Debian su Apache
sudo apt install certbot python3-certbot-apache
sudo certbot --apache -d jusudomenas.lt -d www.jusudomenas.lt
Per cPanel valdymo pultą:
- Prisijunkite prie cPanel.
- Eikite į Security → SSL/TLS Status.
- Spauskite „Run AutoSSL”.
Per Cloudflare:
- Pridėkite domeną Cloudflare.
- Pakeiskite DNS serverius.
- SSL/TLS skiltyje pasirinkite „Full (Strict)” režimą.
Po diegimo patikrinkite, ar HTTPS versija veikia: atidarykite https://jusudomenas.lt naršyklėje ir patikrinkite, ar rodoma spynelės piktograma.
Svarbu: Kol kas nenustatinėkite peradresavimo. Pirmiausia įsitikinkite, kad HTTPS versija veikia teisingai, visi puslapiai kraunasi, paveikslėliai rodomi, formos veikia.
2 žingsnis: vidinių nuorodų atnaujinimas
Prieš įjungiant peradresavimą, atnaujinkite visas vidines nuorodas svetainėje, kad jos vestų tiesiai į HTTPS versiją. Tai sumažina peradresavimo apkrovą ir pagerina greitį.
WordPress svetainėms:
Naudokite WP-CLI arba „Better Search Replace” įskiepį:
# WP-CLI metodas (rekomenduojama)
# Pirmiausia bandomasis paleidimas
wp search-replace 'http://jusudomenas.lt' 'https://jusudomenas.lt' \
--all-tables --precise --dry-run
# Jei rezultatai teisingi, tikras pakeitimas
wp search-replace 'http://jusudomenas.lt' 'https://jusudomenas.lt' \
--all-tables --precise
Rankinis duomenų bazės atnaujinimas (ne WordPress):
-- Atnaujinkite visus vidinius URL duomenų bazėje
UPDATE pages SET url = REPLACE(url, 'http://jusudomenas.lt', 'https://jusudomenas.lt');
UPDATE posts SET content = REPLACE(content, 'http://jusudomenas.lt', 'https://jusudomenas.lt');
UPDATE settings SET value = REPLACE(value, 'http://jusudomenas.lt', 'https://jusudomenas.lt');
Statinėms svetainėms:
Naudokite grep ir sed komandinėje eilutėje:
# Raskite visus failus su HTTP nuorodomis
grep -r "http://jusudomenas.lt" /var/www/jusudomenas.lt/ --include="*.html" --include="*.css" --include="*.js"
# Pakeiskite visus HTTP į HTTPS
find /var/www/jusudomenas.lt/ \( -name "*.html" -o -name "*.css" -o -name "*.js" \) \
-exec sed -i 's|http://jusudomenas.lt|https://jusudomenas.lt|g' {} +
Ką konkrečiai reikia atnaujinti:
- Vidines nuorodas turinyje (straipsniuose, puslapiuose)
- Navigacijos meniu nuorodas
- Paveikslėlių
srcatributus - CSS failus su
url()reikšmėmis - JavaScript failus su API endpoint nuorodomis
- Šablonų failus (header, footer, sidebar)
- Favicon ir logotipo nuorodas
- Struktūrizuotų duomenų (Schema.org) URL
3 žingsnis: canonical žymų atnaujinimas
Kanoninės nuorodos (canonical tags) nurodo paieškos varikliams, kuris URL yra pagrindinis kiekvieno puslapio variantas. Po perkėlimo visos kanoninės nuorodos turi rodyti į HTTPS versiją.
HTML:
<!-- Prieš perkėlimą -->
<link rel="canonical" href="http://jusudomenas.lt/puslapis/" />
<!-- Po perkėlimo -->
<link rel="canonical" href="https://jusudomenas.lt/puslapis/" />
WordPress: Jei naudojate Yoast SEO, Rank Math ar kitą SEO įskiepį, kanoninės nuorodos paprastai generuojamos automatiškai pagal svetainės URL. Po to, kai pakeisite WordPress adresą į HTTPS (Nustatymai → Bendra), kanoninės nuorodos turėtų atsinaujinti automatiškai.
Patikrinimas: Peržiūrėkite puslapio šaltinio kodą (Ctrl+U naršyklėje) ir suraskite <link rel="canonical"> žymą. Ji turi rodyti HTTPS URL.
4 žingsnis: 301 peradresavimo nustatymas
Tai svarbiausias perkėlimo žingsnis. Kiekvienas HTTP URL turi būti peradresuotas į atitinkamą HTTPS URL su 301 (nuolatinio peradresavimo) statusu.
Kodėl būtent 301, ne 302?
- 301 (Permanent Redirect): Pasako paieškos varikliams, kad perkėlimas yra galutinis. SEO vertė (link equity) perduodama iš senojo URL naujajam. Naršyklės išsaugo peradresavimą talpykloje.
- 302 (Temporary Redirect): Pasako, kad perkėlimas laikinas. SEO vertė neperduodama (arba perduodama dalinai). Paieškos varikliai toliau indeksuoja senąjį URL.
Visada naudokite 301 peradresavimą HTTPS migracijai.
Apache (.htaccess):
RewriteEngine On
# Peradresuoti visą HTTP srautą į HTTPS
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
Jei norite kartu nukreipti ir www versiją:
RewriteEngine On
# Peradresuoti HTTP į HTTPS ir ne-www į www
RewriteCond %{HTTPS} off [OR]
RewriteCond %{HTTP_HOST} !^www\. [NC]
RewriteRule ^(.*)$ https://www.jusudomenas.lt/$1 [L,R=301]
Arba atvirkščiai (www į ne-www su HTTPS):
RewriteEngine On
# Peradresuoti HTTP į HTTPS ir www į ne-www
RewriteCond %{HTTPS} off [OR]
RewriteCond %{HTTP_HOST} ^www\. [NC]
RewriteRule ^(.*)$ https://jusudomenas.lt/$1 [L,R=301]
Nginx:
# Atskiras serverio blokas HTTP peradresavimui
server {
listen 80;
server_name jusudomenas.lt www.jusudomenas.lt;
return 301 https://jusudomenas.lt$request_uri;
}
# Jei norite nukreipti www į ne-www per HTTPS
server {
listen 443 ssl http2;
server_name www.jusudomenas.lt;
ssl_certificate /etc/ssl/certs/fullchain.pem;
ssl_certificate_key /etc/ssl/private/privkey.pem;
return 301 https://jusudomenas.lt$request_uri;
}
# Pagrindinis HTTPS serverio blokas
server {
listen 443 ssl http2;
server_name jusudomenas.lt;
ssl_certificate /etc/ssl/certs/fullchain.pem;
ssl_certificate_key /etc/ssl/private/privkey.pem;
# ... kita konfigūracija
}
LiteSpeed (.htaccess arba per WebAdmin):
LiteSpeed supranta Apache .htaccess taisykles, todėl Apache peradresavimo kodas veiks ir LiteSpeed serveryje.
Cloudflare:
Jei naudojate Cloudflare, galite nustatyti peradresavimą per valdymo pultą:
- Eikite į SSL/TLS → Edge Certificates.
- Įjunkite Always Use HTTPS parinktį.
- Tai automatiškai nukreips visą HTTP srautą į HTTPS.
IIS (Windows Server):
<!-- web.config failas -->
<configuration>
<system.webServer>
<rewrite>
<rules>
<rule name="HTTP to HTTPS" stopProcessing="true">
<match url="(.*)" />
<conditions>
<add input="{HTTPS}" pattern="off" ignoreCase="true" />
</conditions>
<action type="Redirect" url="https://{HTTP_HOST}/{R:1}"
redirectType="Permanent" />
</rule>
</rules>
</rewrite>
</system.webServer>
</configuration>
5 žingsnis: peradresavimo testavimas
Po peradresavimo nustatymo kruopščiai patikrinkite, ar viskas veikia teisingai.
Komandinė eilutė (curl):
# Patikrinkite peradresavimo grandinę
curl -I -L http://jusudomenas.lt
curl -I -L http://www.jusudomenas.lt
curl -I -L http://jusudomenas.lt/puslapis/
curl -I -L http://jusudomenas.lt/straipsnis/pavadinimas/
# Tikėtinas rezultatas: 301 Moved Permanently, Location: https://...
Ką tikrinti kiekvienam URL:
- HTTP versija grąžina 301 statusą (ne 302, ne 307).
Locationantraštė nurodo teisingą HTTPS URL.- Nėra peradresavimo grandinės (HTTP → HTTPS → kitas URL). Kiekvienas URL turėtų būti peradresuojamas tiesiogiai į galutinį HTTPS adresą vienu žingsniu.
- Peradresavimas išsaugo pilną URL struktūrą (
/puslapis/lieka/puslapis/, o ne nukreipiamas į pagrindinį puslapį).
Masinis tikrinimas su Screaming Frog:
- Įkelkite savo senąjį HTTP URL sąrašą (iš pasiruošimo etapo).
- Paleiskite crawl ir patikrinkite, ar visi URL grąžina 301 statusą.
- Patikrinkite, ar nėra 404 klaidų, peradresavimo kilpų ar grandinių.
6 žingsnis: sitemap.xml atnaujinimas
Svetainės žemėlapis (sitemap.xml) turi rodyti tik HTTPS URL.
Patikrinkite ir atnaujinkite:
<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
<!-- Visi URL turi prasidėti https:// -->
<url>
<loc>https://jusudomenas.lt/</loc>
<lastmod>2026-06-09</lastmod>
</url>
<url>
<loc>https://jusudomenas.lt/paslaugos/</loc>
<lastmod>2026-06-09</lastmod>
</url>
</urlset>
WordPress: Jei naudojate Yoast SEO ar Rank Math, sitemap.xml bus automatiškai sugeneruotas su naujais HTTPS URL po to, kai pakeisite svetainės adresą.
Rankinis patikrinimas: Atidarykite https://jusudomenas.lt/sitemap.xml naršyklėje ir peržiūrėkite, ar visi URL prasideda https://.
7 žingsnis: robots.txt atnaujinimas
Patikrinkite, ar robots.txt faile nurodytas teisingas sitemap kelias ir ar nėra HTTPS versijos blokavimo:
User-agent: *
Allow: /
Sitemap: https://jusudomenas.lt/sitemap.xml
Dažna klaida: Kai kurie robots.txt failai turi senąjį HTTP sitemap adresą. Būtinai pakeiskite į HTTPS.
Kita dažna klaida: Kartais robots.txt blokuoja kai kuriuos HTTPS URL. Po perkėlimo peržiūrėkite failą ir įsitikinkite, kad jokios Disallow taisyklės neblokuoja svarbių HTTPS puslapių.
8 žingsnis: Google Search Console konfigūracija
Google Search Console traktuoja HTTP ir HTTPS kaip atskiras svetainės savybes (properties). Po perkėlimo turite atlikti šiuos veiksmus:
Naujos savybės pridėjimas:
- Prisijunkite prie Google Search Console.
- Spauskite Add property.
- Pasirinkite Domain tipo savybę ir įveskite
jusudomenas.lt(be protokolo). Domeno tipo savybė automatiškai apims HTTP, HTTPS, www ir ne-www versijas. - Patvirtinkite nuosavybę per DNS TXT įrašą.
Jei jau turite domeno tipo savybę: Puiku, jums nereikia nieko papildomai pridėti. Google Search Console automatiškai matys abu protokolus.
Jei naudojate URL prefix tipo savybes:
- Pridėkite naują savybę:
https://jusudomenas.lt - Pridėkite ir
https://www.jusudomenas.lt(jei naudojate www versiją) - Senųjų HTTP savybių nešalinkite, jos padės stebėti perkėlimo procesą.
Sitemap pateikimas:
- Naujoje HTTPS savybėje eikite į Sitemaps.
- Pateikite
https://jusudomenas.lt/sitemap.xml. - Patikrinkite, ar sitemap būsena yra „Success”.
Adresų pakeitimo įrankis (Change of Address):
Google Search Console turi „Change of Address” įrankį, bet jis skirtas domeno pakeitimui (pvz., senas-domenas.lt → naujas-domenas.lt), ne HTTP → HTTPS perkėlimui. HTTP → HTTPS perkėlimui šio įrankio nereikia naudoti, Google automatiškai aptiks 301 peradresavimus.
9 žingsnis: Google Analytics ir kitų analitikos įrankių atnaujinimas
Google Analytics 4 (GA4):
GA4 automatiškai seka HTTP ir HTTPS srautą kaip vieną srautą, todėl paprastai jokių pakeitimų nereikia. Patikrinkite:
- Eikite į Admin → Data Streams.
- Pasirinkite savo žiniatinklio srautą.
- Patikrinkite, ar svetainės URL rodo HTTPS versiją.
- Jei rodo HTTP, atnaujinkite.
Universal Analytics (jei vis dar naudojate):
- Eikite į Admin → Property Settings.
- Pakeiskite „Default URL” iš
http://įhttps://. - Eikite į Admin → View Settings.
- Pakeiskite „Website’s URL” iš
http://įhttps://.
Kiti analitikos įrankiai (Matomo, Plausible, Fathom):
Patikrinkite kiekvieno įrankio nustatymus ir atnaujinkite svetainės URL į HTTPS versiją.
10 žingsnis: išorinių paslaugų ir profilių atnaujinimas
Po perkėlimo atnaujinkite svetainės URL visose platformose ir profiliuose:
Socialiniai tinklai:
- Facebook puslapio nustatymai (svetainės URL)
- LinkedIn įmonės profilis
- X (Twitter) profilio bio
- Instagram bio nuoroda
- YouTube kanalo nustatymai
- Pinterest profilis
Verslo registrai ir katalogai:
- Google Business Profile (buvęs Google My Business)
- Yelp, TripAdvisor (jei aktualu)
- Lietuvos verslo katalogai
- Industriniai katalogai
Kiti kanalai:
- El. pašto parašai (signature)
- El. pašto šablonai rinkodaros platformose
- Vizitinės kortelės ir spausdinta medžiaga (ilgalaikė užduotis)
- Partnerių svetainėse nurodytos nuorodos
- Reklaminių kampanijų nukreipimo URL (Google Ads, Facebook Ads, LinkedIn Ads)
- Affiliate programų nuorodos
11 žingsnis: HSTS antraštės aktyvavimas
Kai įsitikinsite, kad viskas veikia teisingai, aktyvuokite HSTS (HTTP Strict Transport Security) antraštę. Ši antraštė nurodo naršyklėms visada kreiptis į jūsų svetainę tik per HTTPS, net jei lankytojas įveda HTTP adresą.
Svarbu: Aktyvuokite HSTS tik po to, kai esate 100 % tikri, kad HTTPS versija veikia teisingai. HSTS atšaukti yra sudėtinga, nes naršyklės talpykloje išsaugo šią instrukciją.
Rekomenduojamas laipsniškas HSTS diegimas:
# 1 savaitė: trumpas max-age testavimui
add_header Strict-Transport-Security "max-age=604800" always;
# Po savaitės, jei viskas veikia: 1 mėnuo
add_header Strict-Transport-Security "max-age=2592000" always;
# Po mėnesio: 2 metai su subdomenais
add_header Strict-Transport-Security "max-age=63072000; includeSubDomains" always;
# Galutinis: su preload
add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" always;
Apache atitikmuo:
# .htaccess arba VirtualHost konfigūracijoje
Header always set Strict-Transport-Security "max-age=63072000; includeSubDomains; preload"
HSTS Preload sąrašas:
Kai HSTS su preload parametru veikia stabiliai, galite pateikti savo domeną į HSTS Preload sąrašą (hstspreload.org). Į šį sąrašą įtraukti domenai yra užkoduoti tiesiai naršyklių kode, todėl net pirmas apsilankymas vyks per HTTPS.
Reikalavimai HSTS Preload sąrašui:
- Galiojantis SSL sertifikatas
- Peradresavimas iš HTTP į HTTPS tame pačiame domene
- HSTS antraštė su
max-agebent 31536000 (1 metai) - HSTS antraštėje turi būti
includeSubDomainsirpreloadparametrai - Visi subdomenai turi palaikyti HTTPS
Mixed content klaidų identifikavimas ir taisymas
Mixed content (mišrus turinys) yra dažniausia problema po HTTP → HTTPS perkėlimo. Ji atsiranda, kai HTTPS puslapis bando įkelti resursus (paveikslėlius, CSS, JavaScript, šriftus, iframe) per nešifruotą HTTP ryšį.
Mixed content tipai
Active mixed content (aktyvus mišrus turinys):
- JavaScript failai, kraunami per HTTP
- CSS failai, kraunami per HTTP
- iframe elementai su HTTP šaltiniu
- XMLHttpRequest / Fetch užklausos per HTTP
Naršyklės blokuoja aktyvų mišrų turinį. Tai reiškia, kad jūsų skriptai ir stiliai nebus įkelti, o svetainė gali atrodyti sulūžusi.
Passive mixed content (pasyvus mišrus turinys):
- Paveikslėliai, kraunami per HTTP
- Vaizdo ir garso failai per HTTP
- Šriftai per HTTP (kai kuriose naršyklėse)
Naršyklės leidžia pasyvų mišrų turinį, bet rodo įspėjimą ir nerodys spynelės piktogramos.
Kaip rasti mixed content klaidas
1 būdas: naršyklės konsolė
Atidarykite bet kurį svetainės puslapį, spauskite F12 (DevTools) ir eikite į Console skirtuką. Mixed content klaidos bus pažymėtos geltonai (warning) arba raudonai (error):
Mixed Content: The page at 'https://jusudomenas.lt/puslapis/'
was loaded over HTTPS, but requested an insecure image
'http://jusudomenas.lt/wp-content/uploads/paveikslelis.jpg'.
2 būdas: Security skirtukas DevTools
Chrome DevTools → Security skirtukas rodo bendrą puslapio saugumo būseną ir nurodo, kurie resursai kraunami per HTTP.
3 būdas: masinis tikrinimas su įrankiais
- Screaming Frog: Nuskenuokite HTTPS versiją ir filtruokite „Insecure Content” ataskaitą.
- JitBit SSL Checker: Nemokamas internetinis įrankis, tikrinantis visus puslapio resursus.
- SSL Check (jitbit.com/sslcheck/): Nuskenuoja visą svetainę ir pateikia mixed content ataskaitą.
4 būdas: Content-Security-Policy-Report-Only antraštė
Šis pažangus metodas leidžia rinkti mixed content ataskaitas iš realių lankytojų be turinio blokavimo:
add_header Content-Security-Policy-Report-Only "default-src https:; report-uri /csp-report-endpoint";
Kaip ištaisyti mixed content klaidas
1. Vidiniai resursai (jūsų serverio failai):
Pakeiskite visas HTTP nuorodas į HTTPS. Jei jau atlikote 2 žingsnį (vidinių nuorodų atnaujinimas), dauguma vidinių klaidų turėtų būti ištaisytos.
2. Išoriniai resursai (trečiųjų šalių failai):
<!-- Prieš -->
<script src="http://cdn.example.com/library.js"></script>
<img src="http://images.example.com/photo.jpg" />
<!-- Po: naudokite HTTPS -->
<script src="https://cdn.example.com/library.js"></script>
<img src="https://images.example.com/photo.jpg" />
<!-- Arba protokolo santykinį URL -->
<script src="//cdn.example.com/library.js"></script>
3. CSS failuose esančios HTTP nuorodos:
/* Prieš */
background-image: url('http://jusudomenas.lt/images/fonas.jpg');
@import url('http://fonts.googleapis.com/css?family=Roboto');
/* Po */
background-image: url('https://jusudomenas.lt/images/fonas.jpg');
@import url('https://fonts.googleapis.com/css?family=Roboto');
4. Duomenų bazėje užkoduotos HTTP nuorodos:
WordPress ir kitose TVS (turinio valdymo sistemose) turinys dažnai saugomas duomenų bazėje su pilnais URL. Naudokite search-replace įrankį (žr. 2 žingsnį).
5. Seni įskiepiai ir widgetai:
Kai kurie seni WordPress įskiepiai ar trečiųjų šalių widgetai gali generuoti HTTP nuorodas. Patikrinkite kiekvieno įskiepio nustatymus. Jei įskiepis nebesivysto ir neturi HTTPS palaikymo, ieškokite alternatyvos.
WordPress specifinis perkėlimo vadovas
WordPress yra populiariausia TVS pasaulyje, todėl verta aptarti jai būdingus perkėlimo niuansus.
Pilnas WordPress HTTP → HTTPS perkėlimo procesas
1. Įdiekite SSL sertifikatą serveryje (žr. 1 žingsnį aukščiau).
2. Patikrinkite, ar HTTPS veikia: Atidarykite https://jusudomenas.lt naršyklėje.
3. Pakeiskite WordPress URL:
Eikite į Nustatymai → Bendra ir pakeiskite abu adresus:
- WordPress adresas (URL):
https://jusudomenas.lt - Svetainės adresas (URL):
https://jusudomenas.lt
Alternatyvus būdas per wp-config.php (jei negalite prisijungti prie administravimo):
define('WP_HOME', 'https://jusudomenas.lt');
define('WP_SITEURL', 'https://jusudomenas.lt');
define('FORCE_SSL_ADMIN', true);
4. Atnaujinkite duomenų bazę:
wp search-replace 'http://jusudomenas.lt' 'https://jusudomenas.lt' \
--all-tables --precise --dry-run
# Patikrinkite dry-run rezultatus, tada paleiskite tikrą pakeitimą
wp search-replace 'http://jusudomenas.lt' 'https://jusudomenas.lt' \
--all-tables --precise
5. Nustatykite peradresavimą .htaccess faile:
# Pridėkite prieš WordPress peradresavimo taisykles
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
# BEGIN WordPress
# (WordPress standartinės taisyklės)
# END WordPress
6. Patikrinkite mixed content:
Įdiekite „Better Search Replace” įskiepį arba naudokite WP-CLI. Patikrinkite šiuos šaltinius:
- Straipsnių ir puslapių turinys
- Temos customizer nustatymai (logotipas, favicon, fono paveikslėlis)
- Widgetai (ypač teksto ir HTML widgetai)
- Meniu nuorodos su pilnais URL
- Įskiepių nustatymai (formų nukreipimo URL, analitikos kodai)
7. Išvalykite talpyklą:
# WP-CLI
wp cache flush
# Jei naudojate talpyklos įskiepį
wp w3-total-cache flush all
# arba
wp super-cache flush
Taip pat išvalykite CDN ir serverio talpyklą (Varnish, Redis, Memcached).
WordPress perkėlimo dažnos klaidos
Peradresavimo kilpa po URL pakeitimo:
Jei naudojate reverse proxy (Cloudflare, Load Balancer), WordPress gali neatpažinti HTTPS ir bandyti peradresuoti be galo. Sprendimas, pridėkite į wp-config.php:
if (isset($_SERVER['HTTP_X_FORWARDED_PROTO']) &&
$_SERVER['HTTP_X_FORWARDED_PROTO'] === 'https') {
$_SERVER['HTTPS'] = 'on';
}
Administravimo pultas nepasiekiamas po pakeitimo:
Jei po URL pakeitimo negalite prisijungti:
- Prisijunkite prie duomenų bazės per phpMyAdmin arba SSH.
- Lentelėje
wp_optionsraskite eilutessiteurlirhome. - Grąžinkite jas atgal į HTTP versiją.
- Patikrinkite, ar SSL sertifikatas tinkamai veikia.
- Tada vėl pakeiskite į HTTPS.
Woocommerce ir HTTPS:
Jei naudojate Woocommerce, patikrinkite:
- Mokėjimo vartų callback URL (Stripe, PayPal webhook URL)
- Woocommerce → Nustatymai → Išplėstiniai → Puslapių nustatymai
- Jei Woocommerce turi „Force secure checkout” parinktį, ji turėtų būti aktyvuota
El. komercijos svetainių perkėlimo ypatybės
El. parduotuvių perkėlimas į HTTPS turi papildomų niuansų, kurių neverta ignoruoti.
Mokėjimo vartai
Visi mokėjimo tiekėjai (Stripe, PayPal, Adyen, bankų mokėjimo sistemos) reikalauja HTTPS. Po perkėlimo:
- Prisijunkite prie mokėjimo tiekėjo valdymo pulto.
- Atnaujinkite „Webhook URL” arba „Callback URL” į HTTPS versiją.
- Atnaujinkite „Return URL” ir „Cancel URL”.
- Atlikite bandomąjį mokėjimą (sandbox / test režime).
Produktų srautai (Product Feeds)
Jei teikiate produktų duomenis Google Merchant Center, Facebook Catalog ar kitoms platformoms:
- Atnaujinkite produktų nuorodas sraute į HTTPS.
- Atnaujinkite produktų paveikslėlių URL.
- Iš naujo pateikite srautą platformoje.
- Patikrinkite, ar nėra atmestų produktų dėl URL neatitikimų.
Struktūrizuoti duomenys (Schema.org)
Patikrinkite, ar visi Schema.org žymėjimo URL atnaujinti:
{
"@context": "https://schema.org",
"@type": "Product",
"name": "Produkto pavadinimas",
"url": "https://jusudomenas.lt/produktas/",
"image": "https://jusudomenas.lt/images/produktas.jpg"
}
Open Graph ir Twitter Card žymos
Socialinių tinklų žymos turinyje turi rodyti HTTPS URL:
<meta property="og:url" content="https://jusudomenas.lt/puslapis/" />
<meta property="og:image" content="https://jusudomenas.lt/images/cover.jpg" />
<meta name="twitter:image" content="https://jusudomenas.lt/images/cover.jpg" />
Kelių domenų ir subdomenų perkėlimas
Jei valdote kelis domenus ar subdomenus, perkėlimas tampa sudėtingesnis.
Subdomenų strategija
Wildcard sertifikatas:
Jei turite daug subdomenų (blog.jusudomenas.lt, shop.jusudomenas.lt, api.jusudomenas.lt), Wildcard sertifikatas (*.jusudomenas.lt) yra efektyviausias sprendimas. Vienas sertifikatas apsaugo visus pirmo lygio subdomenus.
Atskiri sertifikatai kiekvienam subdomenui:
Let’s Encrypt leidžia gauti sertifikatą su keliais subdomenais viename sertifikate:
sudo certbot --nginx \
-d jusudomenas.lt \
-d www.jusudomenas.lt \
-d blog.jusudomenas.lt \
-d shop.jusudomenas.lt \
-d api.jusudomenas.lt
Kelių domenų perkėlimas
Jei valdote kelis skirtingus domenus (domenas1.lt, domenas2.com, domenas3.eu):
- Kiekvienam domenui reikia atskiro SSL sertifikato arba vieno Multi-Domain (SAN) sertifikato.
- Peradresavimą nustatykite kiekvienam domenui atskirai.
- Google Search Console savybę pridėkite kiekvienam domenui.
Perkėlimo stebėjimas: ką sekti po migracijos
Pirma savaitė po perkėlimo
Kasdien tikrinkite:
- Google Search Console → Coverage: Ar nėra naujų indeksavimo klaidų (404, 500, peradresavimo klaidos).
- Google Search Console → Crawl Stats: Ar Google robotas sėkmingai apsilanko HTTPS versijoje.
- Serverio žurnalai (logs): Ar 301 peradresavimai veikia teisingai, ar nėra 500 klaidų.
- Svetainės veikimo laikas (uptime): Naudokite UptimeRobot, Pingdom ar panašų įrankį.
# Serverio žurnalų peržiūra: peradresavimų patikrinimas
grep "301" /var/log/nginx/access.log | tail -20
# 404 klaidų paieška
grep "404" /var/log/nginx/access.log | tail -20
# 500 klaidų paieška
grep "500" /var/log/nginx/error.log | tail -20
Pirmas mėnuo po perkėlimo
Kas savaitę tikrinkite:
- Organinio srauto tendencijas: Palyginkite su prieš perkėlimą užfiksuotais duomenimis. Trumpalaikis 5-15 % srauto sumažėjimas yra normalus, nes Google perindeksuoja svetainę.
- Indeksuotų puslapių skaičių: Google paieškoje įveskite
site:jusudomenas.lt. Skaičius turėtų laipsniškai grįžti prie buvusio lygio ir net viršyti jį. - Raktažodžių pozicijas: Stebėkite svarbiausių raktažodžių pozicijas. Svyravimai 1-3 pozicijomis yra normalūs.
- Konversijų rodiklius: Ar formų pateikimai, pardavimai ir registracijos veikia kaip anksčiau.
- Crawl Budget: Google Search Console → Settings → Crawl Stats. Ar Google robotas aktyviai seka HTTPS versiją.
Trečias mėnuo po perkėlimo
Iki trečio mėnesio:
- Organinis srautas turėtų grįžti prie buvusio lygio arba jį viršyti.
- Visi HTTPS puslapiai turėtų būti indeksuoti.
- Senoji HTTP versija Google paieškos rezultatuose turėtų būti pakeista HTTPS versija.
- Jei po 3 mėnesių vis dar matote reikšmingą srauto sumažėjimą, tikrinkite: ar nėra peradresavimo klaidų, ar kanoninės nuorodos yra teisingos, ar sitemap.xml atnaujintas.
Perkėlimo kontrolinis sąrašas
Naudokite šį sąrašą kaip greitą atmintinę kiekviename perkėlimo etape:
Prieš perkėlimą
- [ ] Duomenų bazės atsarginė kopija sukurta
- [ ] Failų sistemos atsarginė kopija sukurta
- [ ] Serverio konfigūracijos kopija sukurta
- [ ] SEO rodikliai užfiksuoti (pozicijos, srautas, indeksuoti puslapiai)
- [ ] Svetainės URL sąrašas surinktas (Screaming Frog / Sitebulb crawl)
- [ ] Trečiųjų šalių integracijų sąrašas sudarytas
- [ ] Perkėlimo laikas suplanuotas
Perkėlimo metu
- [ ] SSL sertifikatas įdiegtas ir veikia
- [ ] HTTPS versija patikrinta naršyklėje (spynelė rodoma)
- [ ] Vidinės nuorodos atnaujintos į HTTPS
- [ ] Canonical žymos atnaujintos
- [ ] 301 peradresavimas nustatytas (HTTP → HTTPS)
- [ ] www / ne-www peradresavimas nustatytas
- [ ] sitemap.xml atnaujintas su HTTPS URL
- [ ] robots.txt atnaujintas (sitemap nuoroda)
- [ ] Mixed content klaidos ištaisytos
- [ ] WordPress / TVS URL nustatymai pakeisti
Po perkėlimo
- [ ] Peradresavimai patikrinti (curl -I -L)
- [ ] SSL Labs testas atliktas (siekiama A+)
- [ ] Google Search Console HTTPS savybė pridėta
- [ ] HTTPS sitemap pateiktas Google Search Console
- [ ] Google Analytics URL atnaujintas
- [ ] Socialinių tinklų profiliai atnaujinti
- [ ] Reklaminių kampanijų URL atnaujinti
- [ ] El. pašto šablonai atnaujinti
- [ ] Mokėjimo vartų callback URL atnaujinti
- [ ] CDN konfigūracija patikrinta
- [ ] HSTS antraštė aktyvuota (laipsniškai)
- [ ] Talpykla išvalyta (serverio, CDN, WordPress)
Stebėjimas (1-3 mėnesiai)
- [ ] Organinis srautas stebimas kas savaitę
- [ ] Indeksavimo klaidos tikrinamos Google Search Console
- [ ] Raktažodžių pozicijos stebimos
- [ ] Konversijų rodikliai palyginami su prieš perkėlimą
Dažniausios klaidos ir jų prevencija
1. Peradresavimo grandinės
Problema: HTTP → HTTPS → www → galutinis URL. Kiekvienas papildomas peradresavimas prideda 50-100 ms vėlinimo ir praranda dalį SEO vertės.
Prevencija: Kiekvienas pradinis URL turi būti peradresuojamas tiesiai į galutinį HTTPS URL vienu 301 peradresavimu.
# Blogai: grandininis peradresavimas
http://jusudomenas.lt → https://jusudomenas.lt → https://www.jusudomenas.lt
# (du peradresavimai)
# Gerai: tiesioginis peradresavimas
http://jusudomenas.lt → https://www.jusudomenas.lt
# (vienas peradresavimas)
2. Nepilna 301 peradresavimo aprėptis
Problema: Peradresuojamas tik pagrindinis puslapis, o vidiniai puslapiai grąžina 404 arba nėra peradresuojami.
Prevencija: Naudokite dinaminį peradresavimą, kuris išsaugo pilną URL struktūrą:
# Gerai: išsaugo URL struktūrą
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
# Blogai: nukreipia viską į pagrindinį puslapį
RewriteRule ^(.*)$ https://jusudomenas.lt/ [L,R=301]
3. Mišrios kanoninės nuorodos
Problema: Kai kurie puslapiai turi HTTP canonical, kiti HTTPS. Google negali nuspręsti, kurią versiją indeksuoti.
Prevencija: Patikrinkite visus puslapius su Screaming Frog, filtruodami canonical stulpelį. Visos kanoninės nuorodos turi rodyti į HTTPS URL.
4. Vidinis susiejimas su HTTP nuorodomis
Problema: Po perkėlimo vidiniuose puslapiuose vis dar yra HTTP nuorodos. Nors peradresavimas veikia, kiekvienas spustelėjimas sukelia papildomą HTTP užklausą ir 301 peradresavimą.
Prevencija: Atlikite išsamų duomenų bazės ir failų search-replace (žr. 2 žingsnį). Po pakeitimo nuskenuokite svetainę su Screaming Frog ir patikrinkite, ar neliko vidinių HTTP nuorodų.
5. Pamirštas sitemap.xml atnaujinimas
Problema: sitemap.xml vis dar rodo HTTP URL. Google robotas seka šias nuorodas, randa 301 peradresavimus ir lėčiau perindeksuoja svetainę.
Prevencija: Regeneruokite sitemap.xml su HTTPS URL ir pateikite jį Google Search Console.
6. Cloudflare ir serverio peradresavimo konfliktas
Problema: Cloudflare nustatytas su „Flexible” SSL režimu, o serveris bando peradresuoti į HTTPS. Rezultatas: begalinė peradresavimo kilpa (ERR_TOO_MANY_REDIRECTS).
Sprendimas:
- Pakeiskite Cloudflare SSL režimą į „Full” arba „Full (Strict)”.
- Jei naudojate „Flexible”, serverio .htaccess peradresavimas turi tikrinti
HTTP_X_FORWARDED_PROTOantraštę, neHTTPSkintamąjį:
RewriteEngine On
RewriteCond %{HTTP:X-Forwarded-Proto} !https
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
7. Pamiršti hardcoded URL šablonuose
Problema: Temos ar įskiepių failuose yra užkoduotos (hardcoded) HTTP nuorodos, kurių search-replace duomenų bazėje nepakeičia.
Prevencija: Patikrinkite temos failus rankiniu būdu:
grep -r "http://jusudomenas.lt" /var/www/jusudomenas.lt/wp-content/themes/
grep -r "http://jusudomenas.lt" /var/www/jusudomenas.lt/wp-content/plugins/
8. CDN resursai per HTTP
Problema: CDN (turinio pristatymo tinklas) vis dar teikia failus per HTTP, nors svetainė veikia per HTTPS.
Prevencija: Patikrinkite CDN nustatymus ir aktyvuokite HTTPS. Dauguma CDN tiekėjų (Cloudflare, BunnyCDN, KeyCDN, AWS CloudFront) palaiko HTTPS pagal nutylėjimą, tačiau reikia tai patvirtinti nustatymuose.
Reverse proxy ir Load Balancer aplinkos
Kai jūsų svetainė veikia už reverse proxy (Cloudflare, AWS ALB, HAProxy, Varnish) arba Load Balancer, HTTPS perkėlimas turi papildomų ypatybių.
SSL Termination ties Load Balancer
Dažna architektūra: SSL šifravimas baigiasi ties Load Balancer, o ryšys tarp Load Balancer ir backend serverio eina per HTTP. Tokiu atveju:
- Backend serveris nemato HTTPS, nes gauna HTTP užklausas iš Load Balancer.
$_SERVER['HTTPS']kintamasis yra tuščias arba „off”.- Aplikacija (WordPress, Laravel ir pan.) gali generuoti HTTP nuorodas.
Sprendimas: Load Balancer perduoda X-Forwarded-Proto antraštę, nurodančią originalų protokolą. Aplikacija turi šią antraštę atpažinti.
Nginx (backend):
# Nustatykite real_ip iš Load Balancer
set_real_ip_from 10.0.0.0/8;
real_ip_header X-Forwarded-For;
# Peradresavimas pagal X-Forwarded-Proto
if ($http_x_forwarded_proto = "http") {
return 301 https://$host$request_uri;
}
Apache (backend):
# .htaccess
RewriteEngine On
RewriteCond %{HTTP:X-Forwarded-Proto} =http
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
WordPress wp-config.php:
// Atpažinti HTTPS iš reverse proxy
if (isset($_SERVER['HTTP_X_FORWARDED_PROTO']) &&
$_SERVER['HTTP_X_FORWARDED_PROTO'] === 'https') {
$_SERVER['HTTPS'] = 'on';
}
// Kai kurios aplinkos naudoja kitą antraštę
if (isset($_SERVER['HTTP_X_FORWARDED_SSL']) &&
$_SERVER['HTTP_X_FORWARDED_SSL'] === 'on') {
$_SERVER['HTTPS'] = 'on';
}
End-to-End šifravimas
Jei saugumo reikalavimai griežti, galite naudoti SSL šifravimą visame kelyje: lankytojas → Load Balancer (HTTPS) → Backend serveris (HTTPS). Tai reiškia, kad ir backend serveryje turi būti įdiegtas SSL sertifikatas.
# Load Balancer upstream konfigūracija su HTTPS
upstream backend {
server 10.0.1.10:443;
server 10.0.1.11:443;
}
server {
listen 443 ssl;
# ...
location / {
proxy_pass https://backend;
proxy_ssl_verify on;
proxy_ssl_trusted_certificate /etc/ssl/certs/backend-ca.crt;
}
}
Dažnai užduodami klausimai
Ar prarasiu visas socialinių tinklų dalinimosi skaičius po perkėlimo?
Deja, taip, tai įmanoma. Facebook, LinkedIn ir kiti socialiniai tinklai skaičiuoja „shares” ir „likes” pagal konkretų URL. http://jusudomenas.lt/straipsnis/ ir https://jusudomenas.lt/straipsnis/ yra du skirtingi URL jų sistemoje. Kai kurie tinklai laikui bėgant sujungia skaičius, bet tai nėra garantuota. Praktinė reikšmė: jei socialinių dalinimosi skaičiai nėra jūsų verslo rodiklis, tai neturėtų stabdyti perkėlimo.
Kiek laiko trunka, kol Google perindeksuoja svetainę po perkėlimo?
Priklauso nuo svetainės dydžio. Maža svetainė (iki 100 puslapių) paprastai perindeksuojama per 1-2 savaites. Vidutinė svetainė (100-1000 puslapių) per 2-4 savaites. Didelė svetainė (10 000+ puslapių) gali užtrukti 1-3 mėnesius. Galite pagreitinti procesą pateikdami HTTPS sitemap Google Search Console ir naudodami URL Inspection įrankį svarbiausių puslapių indeksavimui.
Ar galiu pereiti tik dalimi svetainės (pvz., tik checkout puslapiais)?
Techniškai galima, bet nerekomenduojama. Dalinė migracija sukuria mixed content riziką, sudėtingesnę konfigūraciją ir naršyklės vis tiek rodys „Nesaugu” neapsaugotuose puslapiuose. Perkelkite visą svetainę vienu metu.
Ar perkėlimas paveiks Google Ads kampanijas?
Google Ads automatiškai seks 301 peradresavimus, todėl skelbimų veikimas neturėtų sutrikti. Tačiau rekomenduojama atnaujinti galutinių URL (final URL) nustatymus kampanijose į HTTPS versiją. Tai pašalins nereikalingą peradresavimo žingsnį ir šiek tiek pagerins nukreipimo puslapio greičio įvertinimą.
Ką daryti, jei po perkėlimo matau didelį srauto kritimą?
Pirmiausia nenervinkite, trumpalaikis (1-2 savaičių) 10-20 % srauto sumažėjimas yra normalus. Jei kritimas didesnis arba trunka ilgiau nei mėnesį, tikrinkite šiuos dalykus eilės tvarka: (1) ar 301 peradresavimai veikia visiems URL, (2) ar sitemap.xml turi HTTPS URL, (3) ar nėra canonical žymų konfliktų, (4) ar robots.txt neblokuoja HTTPS puslapių, (5) ar Google Search Console nerodo indeksavimo klaidų.
Ar galiu grįžti atgal į HTTP, jei kas nors nepavyks?
Techniškai taip, galite pašalinti peradresavimus ir grąžinti svetainę į HTTP. Tačiau tai nerekomenduojama: (1) Google jau galėjo pradėti indeksuoti HTTPS versiją, ir grįžimas sukels papildomą painiavą; (2) HSTS antraštė (jei aktyvuota) naršyklių talpykloje gali trukti ilgai, ir lankytojai vis tiek bus nukreipiami į HTTPS. Geriau ištaisyti problemas HTTPS versijoje nei grįžti atgal.
Ar turiu atnaujinti visas backlinks (išorines nuorodas)?
Idealiu atveju taip, bet praktiškai tai beveik neįmanoma. Svarbiausia, kad 301 peradresavimas veikia, nes jis perduoda SEO vertę iš HTTP nuorodos į HTTPS puslapį. Tačiau verta atnaujinti nuorodas tose svetainėse, kurias galite kontroliuoti: partnerių svetainės, katalogai, socialiniai profiliai, Google Business Profile.
Apibendrinimas
HTTP → HTTPS perkėlimas yra vienkartinis procesas, kurio teisingas atlikimas apsaugo jūsų investicijas į SEO, lankytojų pasitikėjimą ir duomenų saugumą. Skubotai atliktas perkėlimas gali kainuoti mėnesių SEO darbo rezultatus. Kruopščiai suplanuotas perkėlimas pereina be jokių pastebimų nuostolių.
Trijų sakinių veiksmų planas:
Pradėkite nuo atsarginės kopijos ir dabartinių SEO rodiklių fiksavimo. Įdiekite SSL, atnaujinkite vidines nuorodas, nustatykite 301 peradresavimą ir patikrinkite mixed content. Atnaujinkite Google Search Console, sitemap.xml ir visas trečiųjų šalių integracijų nuorodas, tada stebėkite rezultatus tris mėnesius.
Naudokite šio straipsnio kontrolinį sąrašą kaip atmintinę, ir kiekvienas žingsnis bus aiškus ir atskaitingas.
