HTTPS a SEO: ako prepnúť web na zabezpečené pripojenie bez straty pozícií

Autor: Peter Weidinger · Publikované 1. 10. 2026

Certifikát dnes vydá väčšina hostingov na pár kliknutí, lenže tým sa prechod na HTTPS ani nezačína, ani nekončí. Google prepnutie protokolu uvádza medzi presunmi webu so zmenou adries, čiže vedľa zmeny domény, a to znamená, že sa plánuje, robí v jednom kroku a potom sa sleduje. Tento článok prechádza celý postup od voľby certifikátu cez presmerovania a kanonické adresy až po zmiešaný obsah, hlavičku HSTS a nastavenie Search Console. Každé pravidlo je prevzaté z dokumentácie Google Search Central alebo MDN, nie z domnienok o tom, čo vyhľadávač urobí.

1. Čo prepnutie na HTTPS znamená pre vyhľadávanie

Google v auguste 2014 oznámil, že zabezpečené pripojenie začal používať ako signál vo svojich hodnotiacich algoritmoch, a v tom istom texte to zasadil do proporcií, keďže podľa neho ide o veľmi slabý signál, ktorý ovplyvňuje menej než jedno percento celosvetových dopytov a nesie menšiu váhu než iné signály, napríklad kvalitný obsah (HTTPS as a ranking signal). Očakávanie preto treba nastaviť triezvo, lebo prepnutie protokolu samo nikoho na prvú stranu nevytlačí, aj keď Google už vtedy dodal, že váhu tohto signálu môže v čase zvýšiť.

Podstatnejšia než hodnotenie je iná vec, na ktorú sa prichádza až pri problémoch. Verzia webu na HTTP a verzia na HTTPS sú pre vyhľadávač dve rôzne adresy s tým istým obsahom, čo dokumentácia ku kanonizácii uvádza priamo medzi dôvodmi duplicitného obsahu pod názvom variant protokolu (What is canonicalization). Ak teda po prepnutí zostane starý protokol dostupný, web si konkuruje sám so sebou a širšie dôsledky takého stavu rozoberá článok o duplicitnom obsahu.

Medzi faktormi, ktoré do výberu kanonickej adresy vstupujú, tá istá dokumentácia vymenúva, či je stránka doručená cez HTTP alebo HTTPS, presmerovania, prítomnosť adresy v sitemape a značku rel="canonical", no vzápätí dodáva, že uvedenie preferencie je pre Google nápoveda, nie pravidlo. Prakticky z toho vyplýva, že jeden signál nestačí a všetky štyri majú po prepnutí ukazovať rovnakým smerom.

Google navyše prechod z HTTP na HTTPS neberie ako drobnú úpravu servera, keďže ho v dokumentácii uvádza ako prvý príklad presunu webu so zmenou adries, hneď vedľa zmeny domény a zmeny ciest (How to move a site). S presunom prichádza aj dokumentovaná daň, pretože tá istá stránka upozorňuje, že pri každej väčšej zmene webu môžu nastať výkyvy v hodnotení a že pri stredne veľkých weboch môže postupné nahradenie starých adries novými trvať niekoľko týždňov aj viac.

2. Certifikát: čo si vybrať a kde ho na serveri uložiť

Prvé rozhodnutie je typ certifikátu a oznámenie z roku 2014 ho zhrnulo do troch možností, keďže Google odporúča rozhodnúť sa medzi certifikátom pre jednu doménu, pre viac domén alebo zástupným certifikátom a používať certifikáty s 2048-bitovým kľúčom. Voľba nie je kozmetická, pretože zástupný certifikát v tvare *.example.com podľa príručky na zapnutie HTTPS pokrýva len jednu úroveň mena, takže na adresu a.b.example.com už neplatí (Enable HTTPS on your servers).

Ak certifikát vydáva a obnovuje administrácia hostingu, nasledujúci odsek preskočte a pokračujte presmerovaniami. Na vlastnom serveri opisuje tá istá príručka postup v štyroch krokoch: vytvorenie 2048-bitového páru kľúčov RSA, vygenerovanie žiadosti o certifikát, ktorá obsahuje verejný kľúč, odoslanie žiadosti certifikačnej autorite a napokon inštalácia výsledného certifikátu na miesto neprístupné z webu, napríklad do priečinka /etc/ssl na Linuxe a na Unixe.

Práve posledný krok sa pri rýchlom nasadení odkladá a potom sa naň zabudne, hoci na ňom celé zabezpečenie stojí. Certifikát je verejný a môže si ho prečítať každý, kým privátny kľúč je to jediné, čo spojenie chráni, a preto nesmie skončiť v priečinku, ktorý server vydáva návštevníkom.

3. Presmerovania, kanonické adresy a sitemapa v jednom kroku

Presun sa začína tým, že server odpovie na každú starú adresu trvalým presmerovaním na jej nový tvar, teda nielen na domovskej stránke, ale na úrovni celého webu. Dokumentácia k presunu webu žiada pripraviť si najprv mapovanie starých adries na nové a až potom nastaviť presmerovanie, pričom najčastejšiu obavu rieši jednou vetou, keď uvádza, že presmerovania 301 ani ďalšie trvalé presmerovania nespôsobujú stratu hodnoty PageRank.

Druhá polovica práce je v samotnom kóde webu a robot ju vidí skôr než vy. Interné odkazy, kanonické značky, adresy v sitemape aj odkazy v šablónach majú viesť priamo na HTTPS, lebo spoliehať sa na to, že presmerovanie opraví každý odkaz, znamená posielať návštevníka aj Googlebota cez zbytočný krok navyše. Sitemapa má pri presune ešte jednu úlohu, keďže podľa dokumentácie jej odoslanie pomáha zrýchliť objavovanie nových adries.

Celý presun má preto vlastný poriadok krokov a vyplatí sa ho dodržať aj na malom webe. Podrobnejšie ho prechádza článok o migrácii webu bez straty SEO, kým technickú stránku samotných odpovedí servera rozoberajú presmerovania 301.

4. Zmiešaný obsah: prečo zámok zmizne aj na HTTPS stránke

Zmiešaný obsah je pojem pre bezpečne načítanú stránku, ktorá si zdroje ťahá cez HTTP alebo iný nezabezpečený protokol, ako to definuje dokumentácia MDN, a je to najčastejší dôvod, prečo web po prepnutí stále nepôsobí zabezpečene (Mixed content). Riziko nie je teoretické, lebo nezabezpečene poslaný zdroj vie útočník prečítať aj zmeniť a pri skriptoch je to najhoršie, keďže skript dokáže zmeniť ľubovoľnú časť stránky.

Prehliadače pritom nereagujú na všetky typy zdrojov rovnako, čo je pri hľadaní chyby dôležité. Podľa MDN automaticky povyšujú požiadavky na obrázky, video a zvuk z HTTP na HTTPS a požiadavky na všetky ostatné typy zdrojov blokujú, takže chýbajúci štýl alebo nefunkčný formulár si všimnete okamžite, kým pri obrázku sa problém prejaví len varovaním v konzole.

Samotná oprava je nudná a nedá sa obísť, pričom MDN za najjednoduchší postup označuje výmenu všetkých odkazov http:// za https:// a následné overenie, či všetky odkazy fungujú. Prejsť treba šablóny, súbory CSS aj obsah uložený v databáze, pretože staré články majú obrázky často vložené absolútnou adresou na HTTP a v šablóne ich nenájdete.

Na kontrolu stačí prechádzať web a sledovať vývojársku konzolu prehliadača, ktorá podľa MDN vypisuje varovania vždy, keď sa zmiešaný obsah povýši alebo zablokuje. Prehliadnuť sa nemajú ani súbory na stiahnutie, lebo odkaz na súbor cez HTTP z bezpečnej stránky je takzvané zmiešané stiahnutie, ktoré majú prehliadače blokovať rovnako ako blokovaný obsah.

5. HSTS: ako protokol zamknúť a kedy s tým počkať

Presmerovanie na serveri rieši len tú požiadavku, ktorá sa na HTTP už dostala, kým hlavička HSTS posúva rozhodnutie do prehliadača. Podľa dokumentácie MDN hlavička Strict-Transport-Security oznámi prehliadaču, že k hostiteľovi sa má pristupovať iba cez HTTPS a že každý budúci pokus o prístup cez HTTP sa má automaticky povýšiť na HTTPS (Strict-Transport-Security header). Návštevník, ktorý si adresu napíše bez protokolu, tak na verziu HTTP vôbec nepríde.

Zápis má tri časti a každá znamená iný záväzok. Smernica max-age udáva v sekundách, ako dlho si má prehliadač pamätať, že hostiteľ je dostupný len cez HTTPS, smernica includeSubDomains rozšíri pravidlo na všetky subdomény danej domény a preload je určená pre zoznam prednahraných domén, pričom pri ňom musí byť max-age aspoň 31536000 sekúnd, teda jeden rok, a musí byť prítomná aj smernica pre subdomény.

Presne tu sa oplatí nezhltnúť to naraz, lebo HSTS nemá poistku pre prípad chyby. Ak pri spojení nastane varovanie alebo chyba TLS, napríklad pri neplatnom certifikáte, prehliadač podľa MDN návštevníkovi neponúkne možnosť pokračovať a chybu nemôže preklikať, takže subdoména s neplatným certifikátom sa pri zapnutej smernici pre subdomény stane nedostupnou. Hlavičku preto zapínajte až vtedy, keď HTTPS funguje na celej doméne a na všetkých subdoménach, ktoré používate.

Vypnutie je možné, lenže nie okamžité, keďže hodnota max-age=0 sa uplatní až vtedy, keď prehliadač urobí zabezpečenú požiadavku a dostane túto hlavičku v odpovedi, pričom cez nezabezpečené HTTP sa HSTS podľa návrhu vypnúť nedá. MDN k tomu dodáva, že hlavičku treba posielať iba cez HTTPS, lebo poslanú cez HTTP prehliadače ignorujú, aby ju útočník v strede spojenia nemohol upraviť. Pri prvom nastavení má preto zmysel začať s krátkym max-age a predĺžiť ho až po pár týždňoch bez problémov, pretože každá ďalšia odpoveď s touto hlavičkou posúva platnosť dopredu.

6. Search Console po prepnutí: čo nastaviť a čo sledovať

Najčastejšia chyba tohto kroku je siahnuť po nástroji na zmenu adresy, ktorý pri prechode na HTTPS nemá čo robiť. Pomocník Search Console ho vymenúva medzi prípadmi, keď nástroj nepoužiť, a k zmene z HTTP na HTTPS uvádza, že sa treba držať pokynov na presun webu so zmenou adries, no tento nástroj nepoužiť, pretože Google si zmenu odvodí sám (Change of Address tool).

Namiesto toho treba vyriešiť property, teda to, čo vlastne Search Console meria. Podľa pomocníka property typu doména zahŕňa všetky subdomény a viac protokolov vrátane HTTP a HTTPS, kým property s predponou adresy obsahuje iba adresy so zadanou predponou vrátane protokolu (Add a website or platform property to Search Console). Property typu doména sa navyše overuje výlučne záznamom DNS, s čím treba počítať vopred, ak k nastaveniam domény nemáte prístup.

Pre samotný presun je užitočné mať oboje, nielen jednu z nich. Dokumentácia k presunu webu žiada overiť všetky varianty starého aj nového webu, teda verziu s www aj bez www a variant HTTP aj HTTPS, lebo len tak vidíte, ako sa zobrazenia a kliky prelievajú z jednej strany na druhú. Ktoré prehľady pri tom čítať a čo v nich hľadať, prechádza článok o Google Search Console.

Sledovanie po prepnutí má dve otázky: či sa nové adresy indexujú a či tie staré z indexu ubúdajú. Dokumentácia zároveň hovorí, že presun prebieha po jednotlivých adresách a za dokončený sa dá považovať až vtedy, keď Googlebot navštívi každú adresu starého aj nového webu aspoň raz, pričom rýchlosť závisí od veľkosti webu a od toho, ako rýchlo sa dá prehľadávať. Presmerovanie z HTTP na HTTPS preto nie je dočasné opatrenie na pár mesiacov, ale trvalé nastavenie servera, ktoré nemá dôvod vypnúť.

Časté otázky

Zvýši prechod na HTTPS pozície vo vyhľadávaní?

Sám o sebe takmer nie. Google pri oznámení z augusta 2014 uviedol, že ide o veľmi slabý signál, ktorý ovplyvňuje menej než jedno percento celosvetových dopytov a nesie menšiu váhu než iné signály, napríklad kvalitný obsah, no zároveň dodal, že jeho váhu môže v čase zvýšiť. Praktický prínos je inde: bez HTTPS vzniká druhá verzia webu s tým istým obsahom a prehliadače blokujú alebo povyšujú nezabezpečené zdroje.

Mám pri prechode z HTTP na HTTPS použiť nástroj na zmenu adresy?

Nie. Pomocník Search Console tento prípad vymenúva medzi situáciami, keď nástroj nepoužívať, a odkazuje na pokyny na presun webu so zmenou adries s tým, že Google si zmenu z HTTP na HTTPS odvodí sám. Nástroj je určený na presun z jednej domény alebo subdomény na inú, nie na zmenu protokolu.

Prečo prehliadač píše, že stránka nie je zabezpečená, keď certifikát mám?

Takmer vždy ide o zmiešaný obsah, čiže o bezpečne načítanú stránku, ktorá si niektoré zdroje ťahá cez HTTP. Prehliadače podľa dokumentácie MDN požiadavky na obrázky, video a zvuk automaticky povýšia na HTTPS a požiadavky na všetky ostatné typy zdrojov zablokujú, pričom varovania vypisuje vývojárska konzola. Opravou je výmena všetkých odkazov http:// za https:// v šablónach, v súboroch CSS aj v obsahu uloženom v databáze.

Akú property v Search Console si mám po prepnutí vytvoriť?

Pre celkový pohľad property typu doména, ktorá podľa pomocníka zahŕňa všetky subdomény a viac protokolov vrátane HTTP a HTTPS a overuje sa výlučne záznamom DNS. Ak chcete sledovať, ako dáta prechádzajú zo starého protokolu na nový, nechajte si k tomu aj property s predponou adresy pre HTTP aj HTTPS, keďže tá zahŕňa iba adresy so zadanou predponou vrátane protokolu. Dokumentácia k presunu webu odporúča overiť všetky varianty starého aj nového webu.

Stratím presmerovaním silu spätných odkazov?

Nie. Dokumentácia Googlu k presunu webu uvádza priamo, že presmerovania 301 ani ďalšie trvalé presmerovania nespôsobujú stratu hodnoty PageRank. Počítajte však s dočasnými výkyvmi v hodnotení, lebo podľa tej istej stránky môže pri stredne veľkých weboch trvať niekoľko týždňov aj viac, kým Google začne postupne zobrazovať nové adresy namiesto starých.

Kedy zapnúť hlavičku HSTS?

Až keď HTTPS spoľahlivo funguje na celej doméne aj na všetkých subdoménach, ktoré používate. Pri chybe alebo varovaní TLS totiž prehliadač podľa MDN návštevníkovi neponúkne možnosť pokračovať a chybu nemôže preklikať, takže subdoména s neplatným certifikátom sa pri zapnutej smernici includeSubDomains stane nedostupnou. Vypnutie navyše nie je okamžité, keďže max-age=0 sa uplatní až po zabezpečenej požiadavke a cez nezabezpečené HTTP sa HSTS vypnúť nedá.