HTTPS: mi ez és miért fontos

Mi az a HTTPS?

A HTTPS a HTTP és a Transport Layer Security (TLS) kombinációja. Titkosítást (adatbizalmasság), integritásellenőrzést és szerver-hitelesítést biztosít, így a böngésző (vagy más kliens) és a webkiszolgáló közötti adatcsere védett a lehallgatás és a manipuláció ellen. Gyakorlatban egy HTTPS-t használó oldal HTTP-forgalmat szolgál ki TLS-sel védett csatornán, és egy megbízható Certificate Authority (CA) által kiadott tanúsítványt mutat be.

Miért fontos a HTTPS a SEO szempontjából

A HTTPS ma már alapelvárás a felhasználók és a böngészők részéről egyaránt. SEO szempontból gyakorlati hatásai közé tartozik a felhasználói bizalom növekedése és a böngészői biztonsági figyelmeztetések csökkenése, a referral adatok megőrzése secure→secure átmeneteknél, valamint a biztonságos környezetet igénylő funkciókkal való kompatibilitás (például sok modern web API és a progresszív webapp-funkciók). A Google korábban a HTTPS-t könnyű rangsorolási jelként kezelte; ennél fontosabb, hogy egy hibás vagy rosszul konfigurált HTTPS-bevezetés feltérképezési vagy indexelési hibákat okozhat, amelyek közvetetten rontják a láthatóságot. Ne feledje: crawling, indexing and ranking külön szakaszok — a HTTPS befolyásolja, hogyan töltődnek le az oldalak és hogyan veszik őket figyelembe indexelésre, de a rangsorolási döntések sok egyéb jel kombinációján alapulnak a transport security mellett.

Hogyan működik a HTTPS

Magas szinten a HTTPS a TLS-t használja biztonságos csatorna létrehozására, mielőtt az HTTP payloadok kicserélődnének. A TLS kézfogás tipikus lépései: a kliens elküldi a ClientHello-t, a szerver válaszként elküldi a tanúsítványát és a kiválasztott paramétereket, a kliens érvényesíti a tanúsítványláncot és kulcsokat tárgyal, majd mindkét fél szimmetrikus kulcsokat származtat a munkamenethez. A modern telepítések TLS 1.3-at használnak, ahol támogatott; a régebbi TLS verziók fokozatosan elavulnak. További fontos elemek: a tanúsítványlánc (leaf, intermediate, root), az OCSP/OCSP stapling a visszavonás-ellenőrzéshez, valamint a HTTP/2 vagy HTTP/3 támogatása, amelyek TLS fölött futva megfelelő konfiguráció esetén javíthatják a teljesítményt.

A HTTPS-tanúsítványok típusai

Gyakori tanúsítványtípusok és kompromisszumok:

• Domain-validated (DV) — a domain feletti birtoklás igazolása után kerül kiadásra. Előnyök: gyors és általában ingyenes (pl. Let's Encrypt); hátrányok: csak domain-szintű identitást nyújt.
• Organization-validated (OV) — vállalati azonosítási ellenőrzést ad hozzá; előnyök: szervezeti adatok megjelenítése a tanúsítvány metaadataiban; hátrányok: magasabb költség és hosszabb kiadási idő.
• Extended Validation (EV) — korábban szigorúbb ellenőrzések és egyes kliensekben külön UI; előnyök: erősebb identitásellenőrzés; hátrányok: sok böngésző már nem jelenít meg speciális UI-t az EV-hez.
• Wildcard és SAN (multi-domain) tanúsítványok — több aldomainre vagy hosztnévre érvényesek; előnyök: egyszerűbb kezelés sok hosztnév esetén; hátrányok: a wildcard kulcsok növelik a kockázatot, ha a privát kulcs kompromittálódik.
• Self-signed — a böngészők nem bíznak meg bennük, és nem alkalmasak nyilvános oldalakhoz.

Hogyan kezdjen hozzá a HTTPS-hez

Alaplépések egy nyilvános weboldal HTTPS-re való átállásához:

1) Szerezzen tanúsítványt egy megbízható CA-tól (beleértve ingyenes CA-kat, mint a Let's Encrypt) vagy a hosting/CDN szolgáltatójától. 2) Telepítse a tanúsítványt és a kapcsolódó intermediate láncot az origin vagy edge szervereire. 3) Konfigurálja a biztonságos TLS-beállításokat (részesítse előnyben a modern verziókat és az erős cipher suite-okat) és engedélyezze az OCSP staplinget. 4) Valósítson meg szerveroldali 301 átirányításokat HTTP-ről HTTPS-re, és győződjön meg róla, hogy a canonical tagek a preferált HTTPS URL-re mutatnak. 5) Frissítse a belső linkeket, sitemaps-et, hreflang bejegyzéseket és minden keménykódolt hivatkozást. 6) Teszteljen kevert tartalomra és javítsa a nem biztonságos asset URL-eket. 7) Opcionálisan engedélyezze a HSTS-t a tesztelés után (alaposan mérlegelje a preload opciót).

Gyakori HTTPS-hibák

Figyeljen ezekre a gyakori hibákra, amelyek mind a UX-et, mind a keresési láthatóságot érintik:

• Hiányzó vagy törött átirányítási láncok — egyes oldalak elérhetők maradnak HTTP-n, miközben a canonical és a sitemap bejegyzések HTTPS-re mutatnak.
• Kevert tartalom — HTTPS-en szolgáltatott oldalak olyan al-erőforrásokat töltenek be HTTP-n, amelyeket a böngészők blokkolnak vagy figyelmeztetnek rá.
• Lejárt vagy hiányos tanúsítványlánc — a böngészők vagy feltérképezők elutasíthatják a kapcsolatot.
• HSTS hibás konfigurációja — a preload engedélyezése minden variáns (www, non-www, IPv6) ellenőrzése nélkül zárolást okozhat.
• Feltérképezők TLS szintű blokkolása — szigorú tűzfal/TLS szabályok, amelyek blokkolják a Googlebotot vagy más keresőfeltérképezőket, megakadályozhatják az indexelést.
• Harmadik féltől származó szolgáltatások elfelejtése — frissítse a CDN-t, analytics-et, tag managert és az API végpontokat, hogy HTTPS-t használjanak.

HTTPS ellenőrzés: technikai ellenőrzőlista

**Certificate validity** — ellenőrzés helye: böngésző lakat ikonja > tanúsítvány részletei, SSL Labs vagy openssl — megfelelő, ha a tanúsítványt megbízható CA adta ki, a lánc teljes és a dátumok érvényesek.

**Redirects to HTTPS** — ellenőrzés helye: curl -I -L https://example.com (cserélje le a saját hostjára) — megfelelő, ha a HTTP kérések 301/308 átirányítást adnak vissza, amelyek a kanonikus HTTPS URL-re végződnek.

**Mixed content** — ellenőrzés helye: böngésző DevTools Console vagy automatizált scanner — megfelelő, ha nincs aktív kevert tartalom (script-ek, iframe-ek) blokkolva és minden kritikus asset HTTPS-ről töltődik.

**TLS protocol and cipher support** — ellenőrzés helye: SSL Labs vagy openssl s_client -connect example.com:443 -servername example.com — megfelelő, ha modern TLS verziók (TLS 1.2/TLS 1.3) engedélyezve vannak és a nem biztonságos cipher-ek ki vannak kapcsolva.

**HSTS header** — ellenőrzés helye: curl -I https://example.com — megfelelő, ha a Strict-Transport-Security fejléc jelen van a kívánt direktívákkal (tesztelje a preload előtt).

**Search engine access** — ellenőrzés helye: szerverlogok és Google Search Console (a tulajdonolt oldalakhoz) — megfelelő, ha a Googlebot és más jelentős feltérképezők TLS-hiba nélkül képesek lekérni a HTTPS-válaszokat.

Gyakorlati parancsok és eszközök

Hasznos ellenőrzések, amelyeket a munkaállomásáról vagy CI-pipelineről futtathat:

• Fejlécek és átirányítások megtekintése: curl -I -L https://example.com (használja a -I-t csak a fejlécek lekéréséhez; a -L követi az átirányításokat).
• TLS tanúsítványlánc vizsgálata: openssl s_client -connect example.com:443 -servername example.com (ellenőrizze a megjelenített tanúsítványadatokat).
• Gyors böngészős ellenőrzés: nyissa meg az oldalt, kattintson a lakatra és nézze meg a tanúsítvány-információt.
• Automatizált értékelés: futtassa az SSL Labs (Qualys SSL Labs) vagy a CI TLS scannerét, hogy jelentést kapjon a protokolltámogatásról, a cipher suite-okról és láncproblémákról.
• Saját tulajdonban lévő webhelyekhez: használja a Google Search Console URL Inspectiont annak megerősítésére, hogy a Google képes-e lekérni és indexelni a HTTPS-oldalt; ne feledje, az URL Inspection csak a saját tulajdonában lévő webhelyekre tekinthető irányadónak.

Megjegyzés a feltérképezőkről: a Google alapértelmezés szerint a Googlebot Smartphone-mal feltérképezi az oldalakat; győződjön meg róla, hogy a TLS-stackje, SNI és tűzfalszabályai lehetővé teszik a fontos crawler user-agentek hozzáférését úgy, hogy crawling and indexing ne szakadjanak meg.

Olvassa el a Technical SEO Guide

Gyakran ismételt kérdések

K: Javítja közvetlenül a HTTPS a rangsorolást?
V: A HTTPS-t könnyű rangsorolási jelként kezelték, de csak az egyik a sok rangsorolási tényező közül. Sokkal fontosabb, hogy egy hibás HTTPS bevezetés lekérési vagy indexelési problémákat okozhat, amelyek közvetetten rontják a láthatóságot.

K: Elégségesek-e az ingyenes tanúsítványok (Let's Encrypt)?
V: Igen — a megbízható CA-k által kiadott ingyenes DV tanúsítványok széles körben elfogadottak nyilvános webhelyekhez. Válasszon kiadási és megújítási folyamatot, amely illeszkedik az üzemeltetési modelljéhez; a kezelt vagy kereskedelmi tanúsítványok további funkciókat adhatnak, például hosszabb érvényességi időket, jótállást vagy további ellenőrzéseket.

K: Mi az a HSTS és engedélyeznem kell-e?
V: A HSTS (Strict-Transport-Security) azt mondja a böngészőknek, hogy egy hosztnál mindig HTTPS-t használjanak. Növeli a biztonságot, de alapos tesztelést igényel a preload listára való jelentkezés előtt, mert hibás konfiguráció esetén nehezebb lehet a helyreállítás.

K: Hogyan észlelhetem a kevert tartalmat?
V: Nyissa meg az oldalt a böngészőben, ellenőrizze a DevTools Console-t kevert tartalom figyelmeztetésekért, vagy használjon automatizált szkennert. Javítsa a nem biztonságos asset URL-eket, hogy az oldalak teljesen biztonságosak legyenek.

K: Ha egy oldal elérhető HTTPS-en, de nincs indexelve, a HTTPS okolható?
V: Nem feltétlenül. Az indexelés sok tényezőtől függ (canonical tagek, noindex, feltérképezhetőség, tartalom minősége). A helyes HTTPS beállítás eltávolít egy gyakori indexelési hibaforrást, de az indexelési döntések többtényezősek maradnak.