HTTPS protokolo ir SSL sertifikato įtaka SEO

Autorius /

HTTPS pats vienas „stebuklingai“ nepakels pozicijų, bet yra oficialus Google reitingavimo signalas ir praktiškai dažnai duoda apčiuopiamos netiesioginės naudos SEO per pasitikėjimą, konversijas, analitikos tikslumą ir techninę svetainės kokybę.

Kas yra HTTPS ir kuo jis skiriasi nuo HTTP?

HTTP yra bazinis žiniatinklio protokolas, kuriuo naršyklė ir serveris apsikeičia užklausomis ir atsakymais (HTML, CSS, JS, paveikslėliais ir t. t.), tačiau pats protokolas iš prigimties nenumato šifravimo, todėl duomenys gali būti perimami ar modifikuojami kelyje. Plačiau apie pačią HTTP logiką ir pranešimų modelį aiškiai aprašo MDN HTTP apžvalga.

HTTPS iš esmės yra tas pats HTTP, tik vykstantis per TLS (transporto sluoksnio šifravimą): ryšys užmezgamas taip, kad trečiosios šalys negalėtų lengvai perskaityti turinio, nepastebimai jo pakeisti ar apsimesti jūsų svetaine. Praktikoje HTTPS sprendžia tris kritines rizikas: konfidencialumą (kad niekas „neklausytų“), vientisumą (kad duomenys nebūtų pakoreguoti) ir autentifikavimą (kad tikrai jungiatės prie to domeno, kurį matote adreso juostoje).

Kaip veikia šifravimas?

TLS šifravimo esmė paprasta: naršyklė ir serveris susitaria dėl saugaus „tunelio“, kuriame duomenys keliauja užkoduoti, o bandymai juos pakeisti atpažįstami. Šį susitarimą sudaro kelios dalys: serveris pateikia sertifikatą, naršyklė patikrina, ar jis patikimas, ir tuomet abi pusės apsikeičia informacija taip, kad galėtų apskaičiuoti bendrą sesijos raktą, kuriuo vėliau greitai šifruojamas srautas.

Moderniame TLS (pvz., 1.3 versijoje) didelė dalis senų, lėtų ir pažeidžiamų algoritmų atsisakyta, o protokolas suprojektuotas taip, kad būtų atsparus pasiklausymui, klastojimui ir žinučių modifikacijai. Formalius TLS 1.3 tikslus ir saugumo savybes apibrėžia TLS 1.3 specifikacija.

Kasdienėje kalboje vis dar sakoma „SSL“, bet technologiškai teisingiau – „TLS“, nes SSL kaip protokolas yra istoriškai senesnis, o realiame žiniatinklyje dominuoja TLS šeima. Šį terminų niuansą ir tai, kodėl „SSL“ dažnai vartojamas iš įpročio, glaustai paaiškina MDN apie TLS.

  • Šifravimas saugo duomenis kelyje tarp naršyklės ir serverio, bet neapsaugo nuo blogo turinio pačioje svetainėje (pvz., kenkėjiško JS).
  • Sertifikatas patvirtina, kam priklauso domenas ir koks viešasis raktas naudojamas, bet jis nėra „antivirusas“ ar „SEO booster“.
  • Saugumas priklauso ne tik nuo HTTPS, bet ir nuo konfigūracijos (protokolų versijų, raktų, tarpinės grandinės).

Kas yra SSL sertifikatas ir kokie būna jų tipai?

SSL/TLS sertifikatas yra skaitmeninis dokumentas (X.509), kuris susieja domeno vardą su viešuoju raktu ir leidžia naršyklei patikrinti, ar serveris tikrai yra tas, kuo prisistato. Sertifikatų išdavimo ir patikimumo ekosistema remiasi viešai patikimomis sertifikavimo institucijomis (CA), kurioms taikomi vienodi minimalūs standartai, apibrėžti CA/Browser Forum baziniuose reikalavimuose.

Sertifikatas turi galiojimo laiką, dažnai apima kelis vardus (SAN), o jo patikimumas naršyklėje priklauso nuo to, ar sertifikatą pasirašiusi grandinė veda iki šakninių sertifikatų, kurie yra įtraukti į naršyklių ir OS patikimų šaknų sąrašus. Praktinis skirtumas SEO kontekste dažniausiai atsiremia ne į „kokio tipo sertifikatas“, o į tai, ar jis teisingai įdiegtas, ar nėra klaidų, ir ar visa svetainė realiai aptarnaujama per HTTPS.

DV, OV, EV – kuo skiriasi ir kam kuris tinka?

Visi trys tipai (DV, OV, EV) suteikia tokį patį šifravimą, tačiau skiriasi tuo, ką CA patikrina prieš išduodama sertifikatą: DV patvirtina domeno kontrolę, OV papildomai tikrina organizacijos duomenis, o EV reikalauja griežtesnio identiteto patvirtinimo proceso. Trumpą, praktišką šių lygių palyginimą pateikia paaiškinimas apie DV, OV ir EV skirtumus.

Renkantis tipą verta mąstyti apie riziką ir vartotojo lūkestį: DV dažniausiai pakanka turinio svetainėms, portfeliams, paprastiems B2B puslapiams, o OV/EV logiškesni ten, kur svarbus aiškus juridinio subjekto atpažįstamumas (finansai, didelės apimties e. komercija, prekės ženklai, kuriuos dažnai bandoma klonuoti). Vis dėlto verta žinoti, kad vien „brangesnis sertifikatas“ pats savaime neišsprendžia phishing rizikos, jei vartotojai nemato aiškių signalų ar jei viduje vis tiek yra nesaugių procesų.

EV sertifikatų išdavimo minimumą aprašo atskiras standartas, kuriame detalizuojami papildomi patikrinimai ir dokumentų reikalavimai. Jei reikia suprasti, kuo EV „formaliai“ griežtesnis, atsiremkite į CA/Browser Forum EV gaires.

Nemokami (pvz., Let’s Encrypt) vs mokami sertifikatai – kada verta mokėti?

Nemokami sertifikatai šiandien yra pilnavertis sprendimas didelei daliai svetainių, nes jie suteikia tą patį TLS šifravimą ir yra plačiai pripažįstami naršyklių. Pavyzdys – Let’s Encrypt sertifikavimo institucija, kuri išduoda sertifikatus nemokamai ir automatizuotai, todėl smarkiai sumažina įėjimo barjerą pereiti prie HTTPS.

Mokėti dažniausiai verta ne „dėl SEO“, o dėl procesų ir verslo poreikių: kai reikia OV/EV identiteto patvirtinimo, kai norite formalios garantijos (warranty), kai svarbus tiekėjo palaikymas 24/7, kai turite sudėtingą infrastruktūrą (daug domenų, daug komandų, centralizuotas raktų valdymas), arba kai organizacijoje reikalaujama konkretaus tiekėjo dėl atitikties ir audito.

  • Jei turite paprastą svetainę ar blogą – nemokamas DV dažniausiai yra optimalus.
  • Jei renkate klientų duomenis ir norite papildomo patikimumo sluoksnio dokumentuose – verta svarstyti OV.
  • Jei esate didelis prekės ženklas, kurį dažnai imituoja sukčiai – EV kartais pasirenkamas dėl formalumo ir vidinių politikų.

Ar HTTPS/SSL daro įtaką SEO reitingams?

Taip, daro, bet tiesioginis efektas dažniausiai nėra didelis, palyginti su turinio kokybe, nuorodomis ar ketinimo atitikimu. Google oficialiai paskelbė, kad pradeda naudoti HTTPS kaip reitingavimo signalą dar 2014 m., ir tai užfiksuota Google įraše apie HTTPS kaip reitingavimo signalą.

HTTPS kaip reitingavimo signalas: nuo 2014 m. iki dabar

2014 m. signalas buvo apibūdintas kaip „lengvas“, bet per laiką pasikeitė svarbi detalė: kai svetainė turi ir HTTP, ir HTTPS versijas su tuo pačiu turiniu, Google vis labiau linkęs pasirinkti HTTPS kaip pirminę indeksuojamą versiją, jei techniniai signalai tvarkingi. Šią kryptį aiškiai aprašė Google sprendimas indeksuoti HTTPS puslapius pagal nutylėjimą.

„Iki dabar“ dalis SEO prasme labiausiai matoma per praktinius įrankius ir diagnostiką: Search Console turi ataskaitas, kurios tiesiogiai padeda identifikuoti HTTPS įgyvendinimo problemas ir jų mastą. HTTPS būsenos stebėsenos logiką ir tai, ką ataskaita parodo, paaiškina Google pranešimas apie HTTPS ataskaitą Search Console.

Realiame gyvenime daugeliui projektų didžiausia SEO nauda atsiranda ne iš „+X pozicijų“, o iš to, kad HTTPS sumažina technines kliūtis: mažiau klaidų naršyklėje, mažiau turinio blokavimo, mažiau netikslumų analitikoje, daugiau pasitikėjimo, o tai dažnai pagerina elgsenos rodiklius ir verslo rezultatą.

Kaip HTTPS netiesiogiai pagerina SEO

Vartotojų pasitikėjimas ir „Not secure“ įspėjimų poveikis elgsenai

Net jei žmogus nėra „techninis“, naršyklės signalai veikia elgseną: perspėjimai mažina pasitikėjimą, didina atšokimus, trumpina sesijas ir mažina tikimybę užpildyti formą ar atlikti pirkimą. Kad tai nėra teorija, rodo ir tai, jog Chrome planuoja dar labiau eskaluoti įspėjimus svetainėms be HTTPS nuo 2026 m. balandžio, kaip aprašyta naujienoje apie Chrome griežtesnius HTTP perspėjimus.

Pasitikėjimas yra SEO „ne tiesiogiai“, bet labai realiai: jei jūsų snippet’ą paspaudę žmonės dažniau grįžta atgal į paiešką, rečiau konvertuoja ir labiau abejoja svetaine, jūs prarandate verslo vertę net ir turėdami gerą poziciją. HTTPS čia veikia kaip bazinis „higienos“ signalas: net jei jis neduoda didelio ranking boost, jis dažnai panaikina psichologinę kliūtį.

Konversijos ir lead’ų formos: kodėl saugumas = mažiau trinties

Formos, prisijungimai, registracijos ir apmokėjimai yra vietos, kur vartotojas labiausiai jautrus rizikai. Jei forma siunčiama per HTTP, reali rizika yra ne tik „duomenų nutekėjimas“, bet ir tai, kad kelyje esantis užpuolikas gali pakeisti formos veiksmą (action) ir nukreipti duomenis į neteisingą vietą, todėl autentifikavimo srautai turi būti aptarnaujami tik per TLS. Šią praktiką aiškiai įvardija OWASP autentifikavimo rekomendacijos.

SEO ryšys čia paprastas: geresnės konversijos leidžia daugiau investuoti į turinį, UX ir rinkodarą, o mažesnė trintis formose mažina „nutrūkstančių“ sesijų skaičių. Net jei organinis srautas išlieka toks pats, svetainė tampa efektyvesnė, o tai ilgainiui dažnai koreliuoja su geresniais elgsenos signalais ir stipresniu prekės ženklu.

Analitika ir referral duomenys: kodėl HTTPS padeda tiksliau matyti srautą

Klasikinis atvejis: kai žmogus ateina į jūsų HTTP puslapį iš HTTPS šaltinio, dalis naršyklių pagal referrer politiką „nenuleidžia“ pilnos refererio informacijos, todėl analitikoje tokios sesijos gali atrodyti kaip „Direct“. Referrer elgseną ir politiką, įskaitant „downgrade“ scenarijus, aprašo MDN Referrer-Policy dokumentacija.

Kai referral informacija dingsta, jūs prarandate ne tik „grožį ataskaitose“, bet ir sprendimų kokybę: sunkiau vertinti kampanijas, partnerystes, turinio sklaidą, net sunkiau suprasti, ar organinis srautas realiai auga. Google Analytics savo ruožtu „Direct“ priskiria sesijoms, kai nėra referral informacijos, ir tai aprašyta Google Analytics srautų šaltinių paaiškinime.

Greitis, HTTP/2 ir našumas: kada HTTPS gali padėti, o kada – ne

HTTPS pats savaime nebūtinai pagreitina svetainę, bet jis dažnai yra būtina sąlyga moderniems transporto optimizavimams ir geresnei protokolų ekosistemai. HTTP/2 įveda headerių suspaudimą ir multiplexing’ą (kelios užklausos per vieną ryšį), kas mažina vėlavimą ir efektyviau naudoja tinklo resursus, kaip aprašyta HTTP/2 standarte.

Kada HTTPS gali padėti: jei iki šiol turėjote daug smulkių resursų, daug paralelinių užklausų ir prastą „krovimo“ elgseną mobiliajame tinkle, perėjimas prie HTTPS kartu su HTTP/2 (ar net HTTP/3) ir tvarkingu caching’u dažnai duoda realių laimėjimų. Kada gali „nepadėti“: jei serveris silpnas, TLS konfigūracija bloga, arba jei didžiausia problema yra sunkūs vaizdai, prasti skriptai ir nenaudojamas caching’as.

  • HTTPS nauda greičiui dažniausiai atsiskleidžia tik kartu su našumo optimizacijomis (caching, suspaudimas, resursų prioritetai).
  • Vien TLS „rankos paspaudimas“ dažniausiai nėra pagrindinis stabdys, bet blogai sukonfigūruotas serveris gali pridėti nereikalingų vėlavimų.
  • Didžiausi našumo laimėjimai dažniausiai ateina iš kritinių resursų optimizavimo, o ne iš „sertifikato pakeitimo“.

Kada HTTPS yra „privalomas“, o kada – tiesiog gera praktika?

El. parduotuvės, mokėjimai, prisijungimai, formos ir asmens duomenys

Jei svetainė priima prisijungimus, renka kontaktus, siunčia lead’us, turi registraciją ar bet kokį srautą su asmens duomenimis, HTTPS praktiškai yra privalomas, nes be šifravimo rizikuojate duomenų perėmimu ir formų klastojimu. Pridėkite e. prekybą ir mokėjimus – tuomet HTTPS jau tampa ne „pasirinkimu“, o minimaliu saugumo standartu, kurį tikisi matyti tiek vartotojai, tiek partneriai, tiek mokėjimo ekosistemos.

Dar vienas praktinis „privalomumo“ aspektas: vis daugiau naršyklių funkcijų ir Web API yra ribojamos „saugiuose kontekstuose“, todėl be HTTPS galite netekti dalies funkcionalumo ar gauti prastesnę vartotojo patirtį. Kas laikoma saugiu kontekstu ir kodėl tai svarbu, paaiškina MDN apie saugius kontekstus.

Turinio svetainės / blogai: kodėl vis tiek verta pereiti

Net jei „nieko nerenkate“, turinio svetainėse HTTPS vis tiek yra gera praktika dėl trijų priežasčių: pasitikėjimo (naršyklės indikatoriai), duomenų tikslumo (referral praradimai) ir techninės ateities (saugūs kontekstai, modernūs protokolai). Be to, jei turite reklamos tinklus, komentarus, embed’us ar trečiųjų šalių skriptus, HTTPS padeda sumažinti riziką, kad kelyje kas nors įterps papildomų reklamų ar pakeis turinį.

SEO prasme tai dažnai reiškia mažiau „triukšmo“: mažiau mišraus turinio blokavimo, mažiau techninių klaidų, mažiau dublikatų tarp HTTP ir HTTPS versijų, aiškesnė kanoninė versija ir paprastesnis svetainės priežiūros procesas.

Migracija iš HTTP į HTTPS be SEO nuostolių

Prieš migraciją: inventorizacija (URL sąrašas), backup, testinė aplinka

Saugiausia migracija prasideda ne nuo sertifikato, o nuo inventorizacijos: turite žinoti visus indeksuojamus URL, svarbiausius landing’us, šablonus, parametrus, subdomenus ir kritinius srautus (checkout, login, API). Google rekomenduoja pasiruošti URL susiejimo planą (senas → naujas) ir testuoti pakeitimus prieš paleidžiant, kaip aprašyta Google gairėse apie migracijas ir URL susiejimą.

Praktinė taisyklė: prieš bet kokius peradresavimus pasidarykite pilną backup (failai + DB), turėkite „roll-back“ scenarijų, o pakeitimus pirmiausia paleiskite staging/test aplinkoje su tais pačiais šablonais ir tais pačiais resursais (CDN, analytics, tag manager, payment integracijos). Taip pat prieš migraciją verta pasižymėti bazinę būseną: organinio srauto lygį, svarbiausių užklausų pozicijas, indeksuotų URL apimtį ir crawl klaidas.

  • Susikurkite dabartinių URL sąrašą (crawl įrankiu arba iš sitemap/GSC), pažymėkite status kodus ir kanonikalus.
  • Užfiksuokite „prieš“ rodiklius: GSC Performance, Pages/Coverage, top landing’ai, top query.
  • Pasiruoškite testinę aplinką su identiška konfiguracija ir SSL įdiegimu.

Sertifikato įdiegimas ir patikra (galiojimas, tarpiniai sertifikatai)

Įdiegus sertifikatą, svarbiausia yra ne „kad užsidėtų spynelė“, o kad nebūtų grandinės klaidų: serveris turi pateikti teisingą sertifikatą ir tarpinį (intermediate) sertifikatą, kad naršyklė galėtų patikrinti grandinę iki patikimos šaknies. Taip pat įsitikinkite, kad sertifikatas apima visus reikalingus vardus (www ir non-www, subdomenus, jei reikia), o galiojimo atnaujinimas yra automatizuotas ir stebimas.

TLS konfigūraciją verta vertinti kaip saugumo „sistemą“, o ne vienkartinį įvykį: uždrauskite pasenusias TLS versijas, naudokite modernias šifrų suites, įjunkite OCSP stapling, ir periodiškai patikrinkite rezultatą. Praktines TLS diegimo ir kietinimo gaires pateikia OWASP TLS rekomendacijos.

301 nukreipimai: taisyklės, www/non-www, vienas „kanoninis“ variantas

SEO požiūriu svarbiausia – kad kiekvienas HTTP URL 301 peradresuotų į tikslų atitinkamą HTTPS URL (vienas su vienu), be tarpinių šuolių ir be kilpų. Google peradresavimus traktuoja kaip kanonikalumo signalą, o skirtingi redirect tipai nėra lygiaverčiai, todėl verta remtis Google paaiškinimu apie 301/302 ir peradresavimų interpretaciją.

Praktinė „vieno kanono“ taisyklė: išsirinkite vieną versiją (pvz., https://www.), ir į ją suveskite visus variantus (http, https be www, su/ be trailing slash, su/ be default index). Jei šito nepadarysite, labai lengva prisigaminti dublikatų, redirect chain’ų ir signalų konflikto.

Jei keičiate ir www/non-www, ir protokolą vienu metu, būkite itin atsargūs su taisyklių eiliškumu. Idealus tikslas – maksimaliai trumpas kelias: vienas 301, viena galutinė versija, be tarpinių žingsnių.

Vidinės nuorodos, canonical’ai, hreflang, struktūriniai duomenys – ką atnaujinti

Po 301 peradresavimų antras svarbiausias darbas – atnaujinti visus vidinius signalus taip, kad jie rodytų į HTTPS, o ne „pasikliautų redirect’u“. Canonical’ų atveju tai kritiška, nes prieštaringi signalai (pvz., canonical į HTTP, bet puslapis kraunasi HTTPS) gali sukelti indeksavimo chaosą, todėl naudinga remtis Google gidu apie kanonikalų nustatymą.

Atnaujinimo sąrašas praktiškai visada apima: navigacijos ir turinio vidines nuorodas, canonical žymas, hreflang alternatyvas, Open Graph/Twitter meta, struktūrinius duomenis (schema.org su URL), RSS feed’us, sitemap’us, ir bet kokius kietai įrašytus absolute URL šablonuose. Kuo mažiau paliksite „senų“ HTTP pėdsakų, tuo greičiau paieškos sistema susidėlios vieningą kanoną.

Sitemap, robots.txt ir „crawl“ signalai po perėjimo

Po migracijos sugeneruokite naują sitemap su HTTPS URL ir pateikite jį per Search Console, nes tai padeda greičiau atrasti naujus adresus ir pamatyti apdorojimo klaidas. Kaip tiksliai kurti ir pateikti sitemap, įskaitant pateikimą per GSC ir nuorodą robots.txt faile, aprašo Google instrukcija apie sitemap kūrimą ir pateikimą.

robots.txt migracijos metu dažnai „netyčia“ sugadinamas: staging aplinkoje būna Disallow: /, o tada failas perkeliamas į produkciją ir staiga krenta indeksavimas. Taip pat svarbu suprasti, kad robots taisyklės taikomos konkrečiam protokolui ir host’ui, todėl HTTP ir HTTPS robots.txt yra skirtingi resursai, kaip paaiškinta Google dokumentacijoje apie robots.txt.

Google Search Console: HTTPS property, HTTPS report’as, sitemap pateikimas

Search Console valdyme praktinis principas paprastas: turėkite aiškiai matomą HTTPS versijos būseną ir pateikite HTTPS sitemap’ą. Ypač naudinga yra HTTPS ataskaita, kuri parodo, kiek indeksuotų URL yra HTTPS ir kokios problemos trukdo aptarnauti puslapius saugiai, kaip aprašyta Search Console HTTPS ataskaitos paaiškinime.

Jei turite kelių host’ų architektūrą (www, be www, subdomenai), „Domain property“ dažniausiai supaprastina stebėseną, bet vis tiek svarbiausia yra signalų nuoseklumas: sitemap, canonical, peradresavimai ir vidinės nuorodos turi sutapti su jūsų pasirinktu kanonu.

Google Analytics / kitos sistemos: nustatymų atnaujinimas

Analitikoje patikrinkite: ar pagrindinis URL, numatytasis domenas, referral exclusions, cross-domain nustatymai ir checkout srautai atnaujinti į HTTPS. Taip pat įsitikinkite, kad „self-referral“ neatsirado dėl netvarkingų peradresavimų (pvz., dalis puslapių dar HTTP, dalis HTTPS), o kampanijų žymėjimas (UTM) nenulūžta dėl netikėtų redirect chain’ų.

Jei naudojate trečiųjų šalių sistemas (chat widget’ai, A/B testai, payment iframe, CDN), patikrinkite, ar jos palaiko HTTPS visuose resursuose. Dažnai „SEO nuostoliai“ po migracijos būna ne dėl paieškos sistemos, o dėl to, kad dalis funkcionalumo neveikia, prastėja UX ir keičiasi elgsena.

Mixed content: kaip rasti ir sutvarkyti

Mixed content reiškia, kad HTTPS puslapis krauna dalį resursų per HTTP (pvz., paveikslą, skriptą ar CSS), todėl naršyklė gali blokuoti resursus arba rodyti perspėjimus, o kartais tai „nuima“ spynelę ir mažina pasitikėjimą. Kas yra mixed content, kokie scenarijai dažniausi ir kaip juos taisyti, detalizuoja MDN mixed content gidas.

Paieškai ir SEO čia svarbu tai, kad mixed content dažnai sukelia realius puslapio „lūžius“: neveikia pagrindiniai skriptai, neįsikrauna stiliai, krenta Core Web Vitals, didėja bounce. Todėl mixed content taisymas yra ne kosmetika, o stabilumo darbas.

Po migracijos: monitoring planas

Pirmos 2–6 savaitės po migracijos yra stebėsenos fazė: sekite indeksavimo apimtį, crawl klaidas, 301 atitikimą, mixed content, svarbiausių landing’ų būseną ir konversijų stabilumą. Taip pat apsvarstykite HSTS, kuris nurodo naršyklei visada jungtis per HTTPS ir sumažina riziką, kad vartotojas pateks į HTTP, kaip aprašyta MDN apie Strict-Transport-Security (HSTS).

  • Kasdien 1–2 savaites: stebėkite GSC klaidas, indeksavimo pokyčius, svarbiausių URL statusus.
  • Kas savaitę 4–8 savaites: palyginkite organinį srautą, konversijas, top query ir top landing’us su „prieš“ periodu.
  • Nuolat: stebėkite sertifikato galiojimą, atnaujinimų automatizaciją ir serverio konfigūracijos pokyčius.

Dažniausios HTTPS migracijos klaidos, kurios „numuša“ pozicijas

302 vietoje 301, redirect chains, kilpos

Dažniausias „klasikinis“ SEO praradimų scenarijus – neteisingi peradresavimai: 302 vietoje 301, kelių šuolių redirect chain’ai (HTTP → HTTPS → www → trailing slash), arba kilpos (A → B → A). Tai sulėtina crawl’ą, švaisto biudžetą, kelia klaidų tikimybę ir lėtina signalų konsolidaciją.

Praktinis testas: atsitiktinai paimkite 50–100 svarbiausių URL ir patikrinkite, kad kelias iki galutinio 200 būtų vienas šuolis, o galutinė versija sutaptų su pasirinktu kanonu.

Canonical konfliktai (HTTP kanonikalas, HTTPS puslapis)

Jei canonical žyma rodo į HTTP, bet puslapis aptarnaujamas per HTTPS, paieškos sistemai siunčiate prieštaringą signalą: „indeksuok HTTP“, nors jūs realiai migruojate į HTTPS. Tokie konfliktai ypač skaudūs didelėse svetainėse, kur canonical generuojamas šablonuose ir klaida automatiškai išsiplečia per tūkstančius puslapių.

Analoginė problema atsiranda su hreflang: jei alternatyvos nurodo HTTP, o kanonai – HTTPS (arba atvirkščiai), atsiranda tarpusavio neatitikimai ir „neaišku“, kuri versija turi būti laikoma pagrindine.

Neatnaujinti sitemap’ai / vidinės nuorodos / asset’ai

Palikti HTTP sitemap’ai ir vidinės nuorodos reiškia, kad jūs patys toliau maitinate crawl’ą senais URL, o paieškos sistema pirmiausia pamato peradresavimus, o tik tada pasiekia galutinį turinį. Tai dažnai sulėtina perėjimą, didina crawl apimtį ir gali ilgiau išlaikyti „dvigubą“ indeksavimo būseną.

Asset’ų (JS/CSS/vaizdų) neatnaujinimas dažnai baigiasi mixed content, o tai jau tampa ne tik SEO, bet ir funkcionalumo problema, kai naršyklė blokuoja kritinius skriptus.

Blokuotas crawl’as (robots/noindex) ir netikėtai dingę puslapiai

Migracijos metu dažnai „paveldimos“ staging apsaugos: robots.txt su Disallow, meta noindex, arba apskritai Basic Auth, dėl kurio Googlebot nepasiekia turinio. Rezultatas – staigus indeksuotų puslapių kritimas ir organinio srauto duobė, kuri atrodo kaip „HTTPS sugadino SEO“, nors reali priežastis yra blokavimas.

Dar vienas pavojus – netikėtai dingę puslapiai dėl neteisingo redirect mapping’o: jei dalis senų URL nukreipiami į homepage ar į bendrą kategoriją vietoje tikslių atitikmenų, signalai išsiskaido, o svarbūs landing’ai praranda relevantiškumą.

Kaip pamatuoti realią HTTPS/SSL įtaką SEO

Ką stebėti GSC (coverage, HTTPS report, crawl errors, query pokyčiai)

GSC stebėkite tris sluoksnius: (1) indeksavimo būseną (kiek URL yra „Indexed“, kiek „Excluded“ ir kodėl), (2) crawl klaidas (5xx, soft 404, redirect error), (3) Performance (impressions/clicks/avg position) pagal užklausas ir landing’us. Jei turite HTTPS ataskaitą, ji ypač patogi kaip „sanity check“: ar Google realiai mato jūsų puslapius kaip HTTPS, ar vis dar aptinka HTTP pėdsakų.

Vertinant pokyčius, lyginkite laikotarpius su tuo pačiu sezoniškumu (pvz., 28 dienos prieš ir 28 po) ir būtinai žiūrėkite pagal landing’us: bendras vidurkis gali slėpti tai, kad keli svarbiausi puslapiai nukentėjo dėl konkrečios klaidos (canonical, redirect, blocked crawl).

Ką stebėti analitikoje (organinis srautas, konversijos, referral tikslumas)

Analitikoje svarbiausias „SEO realybės“ rinkinys: organinių sesijų stabilumas, konversijų stabilumas, top landing’ų našumas, ir srauto šaltinių pasiskirstymas (ar nemažėja referral, ar nedidėja direct dėl tracking problemų). Jei po migracijos staiga šoka „Direct“, patikrinkite, ar nėra HTTP↔HTTPS maišymosi, cross-domain problemų, neteisingų UTM, ar sugedusio tracking kodo dalyje šablonų.

Labai verta stebėti ir mikro-konversijas (formos pradžia, scroll depth, add-to-cart), nes jos greičiau parodo UX lūžius (pvz., mixed content blokuoja JS), negu galutinės konversijos, kurios gali būti retesnės ir „triukšmingesnės“.

Kada tikėtis svyravimų ir kas yra „normalu“ po migracijos

Nedideli svyravimai po migracijos yra normalūs, nes paieškos sistema turi iš naujo per-crawl’inti URL, perkelti signalus ir perskaičiuoti kanoną. Dažniausiai didesnėse svetainėse tai trunka ilgiau, ypač jei crawl biudžetas ribotas, o signalai nėra nuoseklūs (dalies vidinių nuorodų neperrašėte, sitemap dar senas, redirect’ai sudėtingi).

Kas nėra „normalu“: ilgai trunkantis indeksuotų puslapių kritimas, staigus 404/5xx padidėjimas, masinis „Duplicate, Google chose different canonical“ tipo simptomų augimas, arba nuolatinis konversijų smukimas. Tokiais atvejais beveik visada yra konkreti techninė priežastis, kurią galima rasti per logus, crawl’ą, GSC ir naršyklės konsolę.

DUK apie HTTPS, SSL ir SEO

Ar SSL sertifikatas vienas pats pakels pozicijas?

Paprastai – ne „vienas pats“: sertifikatas tik įgalina HTTPS, o Google reitingavimas remiasi daugybe signalų, kuriuose turinys, naudingumas ir autoritetas dažniausiai turi didesnį svorį. Tačiau HTTPS dažnai pašalina techninius minusus (įspėjimus, mixed content, dublikatų riziką), todėl kai kuriuose projektuose realus rezultatas gali būti teigiamas net ir be papildomų turinio pokyčių.

Ar EV sertifikatas suteikia SEO pranašumą prieš DV?

SEO prasme svarbiausia, kad svetainė būtų patikimai pasiekiama per HTTPS, o ne tai, koks validacijos lygis pasirinktas. EV istorinis privalumas dažnai buvo vizualinis „pasitikėjimo“ indikatorius naršyklėje, bet šie indikatoriai per laiką buvo perkelti į gilesnius UI sluoksnius, todėl dauguma vartotojų jų net nepastebi. Firefox pokyčius dėl EV indikatoriaus vietos ir logiką paaiškina Mozilla įrašas apie saugumo indikatorius Firefox 70.

Ką daryti, jei dalis puslapių vis dar indeksuojami kaip HTTP?

Pirmiausia patikrinkite, ar tikrai kiekvienas HTTP URL daro 301 į tikslų HTTPS atitikmenį ir ar nėra redirect chain’ų. Tada įsitikinkite, kad canonical, vidinės nuorodos, hreflang ir sitemap rodo į HTTPS, o ne į HTTP. Galiausiai patikrinkite, ar nepalikote HTTP resursų (mixed content), nes kartais tai signalizuoja, kad šablonuose vis dar yra kietai įrašytų HTTP URL.

Jei problema užsitęsia, naudinga peržiūrėti serverio logus (ar Googlebot iš tiesų gauna 301 ir pasiekia galutinį 200), taip pat GSC URL Inspection, kad matytumėte, kokius kanoninius signalus Google pasirenka ir ką deklaruojate jūs.

Ar HTTPS reikalingas, jei svetainė neturi formų ir nerenka duomenų?

Dažniausiai – taip, nes net ir „be formų“ HTTPS duoda pasitikėjimo ir techninės ekosistemos naudą: naršyklės įspėjimai veikia elgseną, referral duomenys gali būti prarandami, o dalis funkcijų reikalauja saugaus konteksto. Be to, net turinio svetainė gali turėti trečiųjų šalių skriptų, embed’ų ar reklamos, kurių saugumas ir stabilumas praktikoje tampa svarbus.

Parašykite komentarą

Į viršų