HTTPS: teljes útmutató

A HTTPS a HTTP titkosított változata: a böngésző és a szerver közötti forgalmat TLS-kapcsolat védi, így harmadik fél nem tudja elolvasni vagy észrevétlenül módosítani. SEO szempontból a Google könnyű rangsorolási jelzésként kezeli, a böngészők a HTTP-oldalakat nem biztonságosként jelölik, a sikeres átálláshoz pedig tanúsítvány, 301-es átirányítás, frissített belső linkek és canonical címek kellenek.

Alapfogalmak

A HTTPS nem külön protokoll a szó szoros értelmében, hanem a megszokott HTTP, amely egy titkosított csatornán halad. A csatornát a TLS (Transport Layer Security) biztosítja, amelyet a köznyelv sokszor még mindig SSL-nek hív, pedig az SSL régi, elavult elődje. Amikor egy címben https:// szerepel, a böngésző először felépíti a titkosított kapcsolatot a szerverrel, és csak utána küldi el a tényleges kérést. Az alapértelmezett port a 443, szemben a titkosítatlan HTTP 80-as portjával.

A HTTPS három dolgot ad. Az első a titkosítás: a hálózaton utazó adatokat, például űrlapok tartalmát, sütiket vagy a lekért oldal szövegét, kívülről nem lehet elolvasni. A második az integritás: a forgalmat útközben nem lehet észrevétlenül megváltoztatni, így egy nyilvános wifi vagy egy szolgáltató sem tud reklámot vagy kártékony kódot illeszteni az oldalba. A harmadik a hitelesítés: a tanúsítvány igazolja, hogy a böngésző valóban azzal a domainnel beszél, amelyet a címsorban lát.

A legfontosabb fogalmak egy helyen

Fogalom	Jelentés	Miért fontos SEO szempontból
TLS	A titkosított csatornát biztosító protokoll	Nélküle nincs HTTPS, és a modern protokollok, például a HTTP/2 a böngészőkben, sem érhetők el
Tanúsítvány	Hitelesítésszolgáltató által aláírt igazolás, amely a domainhez köti a nyilvános kulcsot	Lejárt vagy hibás tanúsítványnál a böngésző figyelmeztető oldalt mutat, a látogató elakad
Hitelesítésszolgáltató (CA)	Az a szervezet, amely a tanúsítványt kiállítja	A böngészők csak a megbízhatónak tekintett szolgáltatók tanúsítványát fogadják el
Vegyes tartalom	HTTPS-oldalon HTTP-n betöltött erőforrás	A böngésző blokkolhatja, az oldal hiányosan jelenhet meg
HSTS	Fejléc, amely előírja a böngészőnek, hogy a domaint csak HTTPS-en érje el	Megszünteti a HTTP-ről induló első lépést, és véd a visszaminősítéses támadás ellen
301-es átirányítás	Végleges átirányítás a HTTP-címről a HTTPS-címre	Ezzel tudja meg a kereső, hogy a HTTPS-változat az új, elsődleges cím

Tanúsítványtípusok

A tanúsítványokat az ellenőrzés mélysége szerint szokás csoportosítani. A domainellenőrzött (DV) tanúsítvány csak azt igazolja, hogy a kérelmező rendelkezik a domain felett. A szervezetellenőrzött (OV) és a kiterjesztett ellenőrzésű (EV) tanúsítványnál a hitelesítésszolgáltató a céget is ellenőrzi. A titkosítás erőssége mindhárom típusnál ugyanaz lehet, a különbség a mögöttes ellenőrzésben van. A keresőoptimalizálás szempontjából a típus nem számít: a Google nem kezeli előnyben az OV vagy EV tanúsítványt, a lényeg, hogy érvényes legyen, és a böngészők elfogadják.

Formájuk szerint is különböznek a tanúsítványok. Egy tanúsítvány szólhat egyetlen gépnévre, több felsorolt névre, vagy helyettesítő karakterrel egy domain összes első szintű aldomainjére. Ez utóbbi kényelmes, de nem fedi le a főnév alatti mélyebb szinteket, és a gyökérdomaint sem minden esetben. Átállás előtt ezért érdemes összeírni, mely gépnevek szolgálnak ki tartalmat, például a www és a www nélküli változat, a statikus fájlok aldomainje vagy egy külön blog.

Mit jelent a HTTPS a keresőnek?

A Google nyilvánosan közölte, hogy a HTTPS rangsorolási jelzés, de könnyű súlyú. Önmagában ritkán dönt el egy helyezést, ezért nem érdemes csodát várni tőle. A közvetett hatásai fontosabbak. A böngészők a HTTP-oldalakat nem biztonságosként jelölik, ami bizalomvesztést és lemorzsolódást okozhat, különösen űrlapoknál és pénztáraknál. A HTTP/2 és a HTTP/3 a gyakorlatban csak titkosított kapcsolaton érhető el a böngészőkben, így a gyorsabb protokollok előfeltétele is a HTTPS. Ha pedig egy HTTPS-oldalról a látogató egy HTTP-oldalra kattint, a böngésző alapértelmezés szerint nem adja át a hivatkozó oldal címét, ami a céloldal analitikájában torzítást okoz.

Hogyan működik?

A HTTPS-kapcsolat felépítése néhány lépésből áll, amelyet a böngésző és a szerver a felhasználó számára észrevétlenül bonyolít le. A folyamat neve TLS-kézfogás. Ennek során a két fél megállapodik a használt protokollverzióban és titkosítási eljárásban, a szerver bemutatja a tanúsítványát, a böngésző ellenőrzi azt, majd a felek közös munkamenetkulcsot állítanak elő. Ettől kezdve minden adat ezzel a kulccsal titkosítva utazik.

A kapcsolat lépései

Névfeloldás. A böngésző a DNS segítségével megtudja a domainhez tartozó IP-címet.
TCP-kapcsolat. A böngésző kapcsolatot nyit a szerver 443-as portjára.
TLS-kézfogás. A felek egyeztetik a protokollverziót, a szerver elküldi a tanúsítványt, a böngésző pedig ellenőrzi, hogy érvényes-e, a megfelelő domainre szól-e, és megbízható hitelesítésszolgáltató írta-e alá.
Kulcscsere. A felek egy közös, csak erre a munkamenetre érvényes kulcsot állítanak elő.
HTTP-forgalom. A tényleges kérések és válaszok már a titkosított csatornán haladnak.

A TLS 1.3 a kézfogást rövidebbre fogta a korábbi verziókhoz képest, ezért kevesebb oda-vissza üzenetváltásra van szükség a kapcsolat felépítéséhez. Ez különösen nagy késleltetésű, például mobilhálózaton érezhető. A régebbi TLS-verziókat és az SSL-t a modern böngészők már nem támogatják, ezért a szerver beállításainál érdemes a régi verziókat kikapcsolni.

A tanúsítványlánc ellenőrzése

A böngésző nem közvetlenül a szerver tanúsítványában bízik meg, hanem egy láncban. A szerver tanúsítványát egy köztes tanúsítvány írta alá, azt pedig egy gyökértanúsítvány, amely a böngészőben vagy az operációs rendszerben eleve megbízhatóként szerepel. Ha a szerver nem küldi el a köztes tanúsítványt, egyes böngészők és eszközök nem tudják felépíteni a láncot, és hibát jeleznek, miközben más kliensek hibátlanul működnek. Ez a hiba azért alattomos, mert a fejlesztő saját gépén gyakran nem jelentkezik.

Az átirányítás és a HSTS szerepe

Amikor valaki a címsorba csak a domain nevét írja be, a böngésző hagyományosan HTTP-n indul. A szerver ilyenkor 301-es kóddal a HTTPS-címre irányítja. Ez az első kérés azonban titkosítatlan, ezért elvileg lehallgatható vagy eltéríthető. A HSTS ezt a rést zárja be. A szerver a Strict-Transport-Security fejléccel közli, hogy a domaint egy megadott ideig csak HTTPS-en szabad elérni. A böngésző ezt megjegyzi, és a következő látogatásoknál a HTTP-címet már magától HTTPS-re cseréli, átirányítás nélkül. A fejléc kiterjeszthető az aldomainekre is, és a domain felvehető a böngészők beépített előtöltési listájára, így már az első látogatás is HTTPS-en indul.

A HSTS erős eszköz, és éppen ezért óvatosan kell bevezetni. Ha egy aldomain még nem működik HTTPS-en, és a fejléc az aldomainekre is kiterjed, az aldomain elérhetetlenné válik a böngésző számára. Az előtöltési listáról való lekerülés lassú folyamat. A biztonságos sorrend: először rövid érvényességi idővel indítani, ellenőrizni minden aldomaint, és csak utána növelni az időtartamot, illetve kérni az előtöltést.

Mit lát ebből a Googlebot?

A Googlebot HTTPS-címeket is feltérképez, és ha egy oldal HTTP- és HTTPS-változata is elérhető, azonos tartalommal, a kereső általában a HTTPS-változatot választja kanonikusnak. Ez azonban nem garantált: ha a belső linkek, a sitemap vagy a canonical elem a HTTP-címre mutat, a jelzések ellentmondanak egymásnak. A HTTPS-átállás SEO-oldalról ezért arról szól, hogy minden jelzés egybehangzóan a HTTPS-címet mutassa elsődlegesnek.

Fő módszerek

A HTTPS bevezetése két részből áll: a technikai beállításból, amely a titkosított kapcsolatot biztosítja, és a SEO-oldali átállásból, amely a keresőnek jelzi, hogy a címek megváltoztak. Az első a szerver, a második a tartalom és a jelzések rendbetétele. A sikertelen átállások többsége a második részen csúszik el.

1. Tanúsítvány beszerzése és automatikus megújítása

Ma már számos hitelesítésszolgáltató kínál ingyenes, automatizálható domainellenőrzött tanúsítványt, és a legtöbb tárhelyszolgáltató és CDN beépítve kezeli ezt. A tanúsítványoknak lejárati idejük van, ezért a legfontosabb szabály az automatikus megújítás. A lejárt tanúsítvány miatt a böngésző teljes oldalas figyelmeztetést mutat, amelyen a legtöbb látogató nem megy tovább. A megújítás sikerességét érdemes külön figyelni, mert a megújító folyamat csendben is elhasalhat.

2. Oldalszintű 301-es átirányítás

Minden HTTP-cím a neki megfelelő HTTPS-címre mutasson, egyetlen lépésben, 301-es kóddal. Nem elég a főoldalra irányítani mindent: a http://pelda.hu/termek/cipo címnek a https://pelda.hu/termek/cipo címre kell vezetnie. Ha a webhelynek www és www nélküli változata is van, érdemes egyszerre dönteni, és a HTTP www nélküli címet közvetlenül a végleges HTTPS-változatra küldeni, nem két lépcsőben. Az átirányítások részleteiről a 301-es átirányítás útmutató ad bővebb képet.

3. Belső linkek, canonical, hreflang és sitemap frissítése

A belső linkek közvetlenül a HTTPS-címre mutassanak. Ha átirányításon keresztül vezetnek, a webhely minden oldalletöltésnél felesleges lépést ad hozzá, és a kereső vegyes jelzést kap. A canonical elemek, a hreflang-hivatkozások, a strukturált adatokban szereplő URL-ek és az Open Graph címek mind HTTPS-re frissüljenek. Az XML sitemap csak HTTPS-címeket tartalmazzon. A robots.txt-t is érdemes átnézni, mert a HTTPS-változatnak saját robots.txt-je van, és annak ugyanazt kell engednie, amit korábban a HTTP-változat engedett.

4. Vegyes tartalom felszámolása

A HTTPS-oldalon minden erőforrás, kép, szkript, stíluslap, betűkészlet és beágyazott elem HTTPS-en töltődjön be. A böngészők a szkripteket és más aktív tartalmat HTTP-n blokkolják, a képeket pedig vagy automatikusan HTTPS-re próbálják cserélni, vagy figyelmeztetést adnak. A hibás tartalom forrása sokszor a szerkesztőben rögzített, abszolút HTTP-hivatkozás. Ezeket az adatbázisban kell cserélni, nem csak a sablonban.

5. HSTS bevezetése fokozatosan

Amikor minden HTTPS-en működik, jöhet a HSTS. Rövid időtartammal kezdve, ellenőrzés után növelve. Az aldomainekre csak akkor érdemes kiterjeszteni, ha azok mindegyike biztosan működik HTTPS-en.

6. Search Console és analitika

Ha a Search Console-ban URL-előtag típusú tulajdon van, a HTTPS-változatot külön tulajdonként kell felvenni. A domaintulajdon minden protokollt és aldomaint lefed, ezért átálláskor kényelmesebb. Az analitikai eszközben a webhely alapcímét is érdemes frissíteni.

Döntési szabály: mit csinálj, ha...

Helyzet	Teendő
A webhely még HTTP-n fut	Tanúsítvány, oldalszintű 301, belső linkek és jelzések frissítése egy tervezett átállásban
HTTPS van, de a HTTP-változat is 200-as kóddal válaszol	A HTTP-változat minden címe 301-gyel mutasson a HTTPS-párjára
Egy harmadik fél erőforrása csak HTTP-n érhető el	Saját tárhelyre költöztetés, HTTPS-es alternatíva vagy eltávolítás
Minden működik HTTPS-en, aldomainekkel együtt	HSTS rövid időtartammal, majd fokozatos növelés
Egy aldomain nem tud HTTPS-t	A HSTS ne terjedjen ki az aldomainekre, amíg ez nem rendeződik

Kidolgozott példa: egy közepes webáruház átállása

Egy webáruház évek óta HTTP-n működött, a pénztár egy külön, HTTPS-es aldomainen futott. A csapat úgy döntött, hogy a teljes webhelyet HTTPS-re állítja. Első lépésként egy tesztkörnyezetben bekapcsolták a tanúsítványt, és egy feltérképező eszközzel lefuttatták a teljes webhelyet. A feltérképezés kimutatta, hogy a termékleírásokban több ezer kép abszolút HTTP-hivatkozással szerepelt, a menüben pedig néhány link régi, HTTP-s címre mutatott. Ezeket az adatbázisban cserélték. Második lépésként elkészítették az átirányítási szabályt, amely minden HTTP-címet a HTTPS-párjára küldött, és egy mintalistán ellenőrizték, hogy a paraméteres címek is helyesen, egy lépésben érkeznek. A canonical elemeket és a sitemapot a sablonban HTTPS-re állították. Az élesítés után a Search Console-ban felvették a domaintulajdont, beküldték az új sitemapot, és a következő hetekben figyelték az indexelt oldalak alakulását mindkét változatnál. A HSTS csak néhány héttel később került be, amikor minden aldomain ellenőrzötten működött.

Kidolgozott példa: blog egy tárhelyszolgáltatói kapcsolóval

Egy kisebb szakmai blog tulajdonosa a tárhely vezérlőpultján egy kapcsolóval bekapcsolta a HTTPS-t. A webhely betöltött, a lakat megjelent, ezért késznek tekintette a munkát. Néhány héttel később észrevette, hogy a Search Console-ban a HTTP-címek is indexelve maradtak. Kiderült, hogy a kapcsoló csak a tanúsítványt telepítette, átirányítást nem állított be, így mindkét változat 200-as kóddal válaszolt. A tartalomkezelő beállításaiban a webhely címe is HTTP maradt, ezért a canonical elemek a régi címre mutattak. A javítás két lépés volt: a webhely alapcímének átírása HTTPS-re, és a kiszolgáló szintű 301-es átirányítás bekapcsolása. A tanulság, hogy a lakat megjelenése a titkosításról szól, nem az átállásról.

Gyakori hibák

A HTTPS-átállás hibái ritkán látványosak. Az oldal betölt, a lakat ott van, közben a kereső vegyes jelzéseket kap, a látogatók egy része figyelmeztetést lát, vagy egy láncolt átirányítás lassítja az első betöltést. A hibák nagy része egy alapos feltérképezéssel és néhány kézi ellenőrzéssel megelőzhető.

Tipikus hibák listája

Csak a főoldal irányít át. A HTTP-aloldalak mind a HTTPS-főoldalra mutatnak, így a kereső az aloldalakat nem tudja párosítani, és az oldalak értéke elveszhet.
302-es átirányítás 301 helyett. Az ideiglenes átirányítás rossz jelzés egy végleges változásnál, és lassíthatja, hogy a kereső az új címet tekintse kanonikusnak.
Átirányítási lánc. HTTP www nélkül, onnan HTTP www-vel, onnan HTTPS www-vel. Minden plusz lépés késleltetés és plusz kérés a keresőnek. Erről a redirect chain útmutató ír részletesen.
Canonical a HTTP-címre. A sablon a régi alapcímet használja, így minden oldal a saját HTTP-változatát jelöli elsődlegesnek.
Vegyes tartalom. Blokkolt szkriptek miatt hiányzó funkciók, törött menük, nem működő űrlapok.
Hiányzó köztes tanúsítvány. Egyes eszközökön hibaoldal jelenik meg, a fejlesztő gépén minden rendben van.
Elfelejtett megújítás. A tanúsítvány lejár, a webhely egyik napról a másikra figyelmeztető oldalt mutat.
A robots.txt HTTPS-változata tilt. A tesztkörnyezetből átmásolt, mindent tiltó robots.txt kerül élesbe az új protokollon.
Túl korán, túl szélesen bevezetett HSTS. Egy HTTPS-t nem támogató aldomain elérhetetlenné válik.

Tévhit: a HTTPS lassítja a webhelyet

Ez a félelem a titkosítás korai éveiből maradt meg. A mai szervereken a titkosítás számítási költsége kicsi, a TLS 1.3 rövidebb kézfogása és a munkamenetek újrafelhasználása pedig tovább csökkenti a többletet. Emellett a HTTPS teszi lehetővé a böngészőkben a HTTP/2 és a HTTP/3 használatát, amelyek sok kis erőforrásnál kifejezetten gyorsíthatnak. A lassulás oka átállás után szinte mindig egy átirányítási lánc vagy egy rosszul beállított szerver, nem maga a titkosítás.

Tévhit: a HTTPS önmagában jobb helyezést hoz

A HTTPS könnyű jelzés, amely inkább egyforma tartalmak között billenthet. Aki az átállástól látványos forgalomnövekedést vár, csalódni fog. A valódi érték a bizalom, a biztonság és a modern protokollok elérhetősége. Az is előfordul, hogy az átállás után átmeneti ingadozás látszik, amíg a kereső az új címeket feldolgozza. Ez egy jól megcsinált átállásnál rendszerint rendeződik, egy hibás átállásnál viszont tartós veszteség is lehet belőle.

Ellenpélda: minden rendben, mégis HTTP-címek az indexben

Egy webhelyen az átirányítás, a canonical és a sitemap is hibátlan volt, a HTTP-címek mégis sokáig indexben maradtak. Az ok egy régi, külső oldalakon sok helyen hivatkozott partnerlista volt, amelyet a kereső gyakran újra feltérképezett, és amelyből HTTP-linkek vezettek a webhelyre. A kereső ezeket követte, az átirányításon keresztül végül a HTTPS-címhez jutott, de a HTTP-címek feldolgozása időbe telt. Ilyenkor nincs teendő a türelmen túl: a jelzések rendben vannak, a kereső idővel követi őket. Hiba lenne ebben a helyzetben a HTTP-címeket robots.txt-vel tiltani, mert akkor a kereső az átirányítást sem látná.

Mérés

A HTTPS mérése két kérdésre felel: a titkosított kapcsolat technikailag rendben van-e, és a kereső átvette-e a HTTPS-címeket elsődlegesnek. Az első a szerver és a böngésző oldala, a második a Search Console és a feltérképező eszközök terepe.

Technikai ellenőrzések

A böngésző fejlesztői eszközeinek biztonsági és hálózati nézete megmutatja a használt protokollt, a tanúsítvány adatait és a vegyes tartalom figyelmeztetéseit. Parancssorból a curl -I kéréssel a HTTP-címre ellenőrizhető, hogy egyetlen 301-es válasz érkezik-e, és a Location fejléc a pontos HTTPS-párra mutat-e. Nyilvános TLS-tesztelő szolgáltatásokkal a tanúsítványlánc, a támogatott protokollverziók és a HSTS beállítása is átnézhető. A tanúsítvány lejárati dátumát érdemes monitorozó eszközbe felvenni.

Keresőoldali ellenőrzések

A Search Console oldal-indexelési jelentése mutatja, hogy a HTTP-címek átirányított oldalként jelennek-e meg, és hogy a HTTPS-címek indexelődnek-e. Az URL-vizsgáló eszköz egy konkrét oldalnál megmondja, melyik URL-t választotta a Google kanonikusnak. Egy teljes webhelyes feltérképezés kimutatja a HTTP-re mutató belső linkeket, a HTTP-canonicalt, a láncolt átirányításokat és a vegyes tartalmat. A szervernaplóban látszik, hogy a Googlebot kérései idővel a HTTPS-címekre tolódnak-e.

Ellenőrzőlista az átállás után

Ellenőrzés	Eszköz	Jó eredmény
HTTP-cím válasza	curl vagy feltérképező	Egyetlen 301 a pontos HTTPS-párra
Tanúsítványlánc	TLS-tesztelő	Teljes lánc, érvényes, a megfelelő nevekre szól
Vegyes tartalom	Böngészőkonzol, feltérképező	Nincs HTTP-n betöltött erőforrás
Belső linkek	Feltérképező	Mind HTTPS-re mutat, átirányítás nélkül
Canonical és hreflang	Feltérképező	Mind HTTPS-címet jelöl
XML sitemap	Kézi ellenőrzés, Search Console	Csak HTTPS-címek
robots.txt	A HTTPS-cím kézi lekérése	Nem tilt semmit, amit korábban engedett
Kanonikus választás	URL-vizsgáló	A Google a HTTPS-címet választja
Tanúsítvány lejárata	Monitorozó eszköz	Riasztás a lejárat előtt, automatikus megújítás

Mérési ritmus

Az átállás napján és az azt követő napokban a technikai ellenőrzések a legfontosabbak, mert a hibás átirányítás vagy a vegyes tartalom azonnal rontja a felhasználói élményt. Az ezt követő hetekben a keresőoldali mutatókat érdemes figyelni: hogyan fogynak a HTTP-címek az indexből, és hogyan nő a HTTPS-címek száma. Egy stabil webhelyen elég negyedévente egy teljes feltérképezés a visszaszivárgó HTTP-hivatkozások kiszűrésére, és folyamatos monitorozás a tanúsítvány lejáratára. Az átirányítást hosszú távon, gyakorlatilag véglegesen érdemes megtartani, mert külső linkek és könyvjelzők még sokáig a HTTP-címekre mutathatnak.