Hogyan lehet váltani a https-re: lépésről lépésre. Hogyan működik a https

2014 júliusában a Google bejelentette, hogy előnyt jelent a webhelyek rangsorolásában megfelelően telepítve SSL tanúsítványok. A konvertált és SSL-védett webhelyek HTTPS (hypertext transfer protocol secure) néven kezdtek megjelenni, ellentétben a korai HTTP szabvánnyal. Így megjelent egy további biztonsági szint, amely megakadályozza a tárolt adatokhoz való nem kívánt hozzáférést.

Ma a Google, a Safari, a Firefox és a legtöbb más népszerű böngésző megköveteli ezt a protokollt a jobb rangsoroláshoz, a földrajzi helymeghatározáshoz, a hitelkártya-adatok beviteléhez és még sok máshoz. A HTTPS biztonsági protokoll megvédi a weboldalt a nem kívánt hirdetésektől is, amelyek tolakodó, csúnya információkkal bosszantják a látogatókat, néha rosszindulatú programokat tartalmaznak. 2018 októbere óta a Google piros figyelmeztetést kezdett megjeleníteni a veszélyről, amikor a felhasználók adatokat adnak meg a HTTP-oldalakon, vagy egy zöld zárat a címsorba, amikor a biztonság normális a HTTPS-en.

Rövid meghatározás

A HTTPS és az SSL látható a webhely URL-jén, amely a böngésző panelen tükröződik. A közelben észreveheti a kastély szimbólumát is. Tehát a modern böngészők azt mutatják, hogy a Felhasználó olyan webhelyen van, amely SSL titkosítást használ. Bizonyos esetekben az URL tartalmazza a vállalat nevét. Ezek a jelek azt jelzik, hogy a látogató olyan webhelyen tartózkodik, amely komolyan veszi a magánélet védelmét. Ez a HTTPS Secure hypertext transport protokollt jelenti. A" testvére " HTTP ugyanazt jelenti, a végén "titoktartás" nélkül, és egy kommunikációs protokoll, amelyet általában a webes forgalom megkönnyítésére használnak.

A biztonságos verzió SSL tanúsítványt (Secure Socket Layer) használ a böngésző és a szerver közötti kapcsolat létrehozásához. Ezért világossá válik, hogyan működik a HTTPS - minden kicserélt információ titkosítva lesz. A Titkosítás az egyszerű szöveges információk, például a felhasználónevek és jelszavak véletlenszerű számokkal és betűkkel történő helyettesítésének folyamata. Így az emberek már nem tudják olvasni, és nehezebb megérteni a lehallgatás során.

Egy kis pontosítás: technikailag az SSL valójában nem a megfelelő kifejezés, a 90-es évek végén TLS-re (transport layer security)változott. Azonban még mindig gyakran használják a HTTPS folyamatok leírásakor.

Első, amire szüksége van ahhoz, hogy váltani A HTTPS information security technologies a megfelelő SSL tanúsítvány megvásárlása, amely titkosított áthatolhatatlan kapcsolatot hoz létre a böngészőablak és a webszerver között. . Különböző típusú tanúsítványok állnak rendelkezésre, amelyek költségükben különböznek. A lényeg az, hogy alapvetően mindannyian ugyanazon az elven működnek, így a felhasználó nem kap "nagyobb biztonságot" csak azért, mert többet fizet.

Különböző funkciók vannak:

1. Belépő szintű SSL Domain szolgáltatások. Azonnal kiadják őket, mielőtt a HTTPS-re váltanának, csak e-mailben történő megerősítést igényelnek, HTTPS-megtekintést kínálnak zárral, nincs mély elemzési folyamat, csak a domain tulajdonjogának ellenőrzése. Ideális a korlátozott költségvetéssel rendelkező kisvállalkozások számára, amelyek nem fogadják el az online fizetéseket.
2. Szervezeti SSL tanúsítványok, a vállalati tulajdonjog magasabb fokú ellenőrzését igénylik. Ilyen típusú tanúsítvány esetén a cégnév és a domain név megjelenik a böngésző panelen.
3. SSL fejlett ellenőrzéssel lehetővé teszi a "zöld böngésző panel" használatát. Ezek drágábbak, mint a korábbi tanúsítványok, és jogi, működési és fizikai ellenőrzést tartalmaznak.
4. Az SSL tanúsítvány megvásárlása után jóvá kell hagyni. A tanúsítvány kiadása előtt különböző szintű ellenőrzések vannak, például a domain SSL esetében, azonnal kiadható, amint a domain tulajdonosa megerősíti e-mail címét. Ha a webhely tulajdonosa virtuális tárhelyet használ, akkor a HTTPS-re való áttérés előtt a szolgáltatóhoz fordulnak segítségért a szerver adminisztrációjában, jóváhagyott tanúsítvánnyal.

A HTTPS-re való váltás algoritmusa:

1. Végezze el a webhely teljes biztonsági mentését. Ha a tárhelyet a cPanel kezeli, használhatja a beépített cPanel biztonsági mentési funkciót. Ellenkező esetben vegye fel a kapcsolatot a tárhelyszolgáltatóval, hogy megtudja, kínál-e felügyelt biztonsági mentési szolgáltatást.
2. Módosítsa a HTTP linkeket HTTPS-re a webhelyen. Az eljárás a webhely méretétől függ, amely meghatározza a HTTPS működését. Ha csak néhány oldal van a webhelyen, akkor kézi folyamatot használhat. Ha vannak több száz vagy akár több ezer oldal, olyan eszközöket használnak, amelyek automatizálják a folyamatot, különösen, ha a WordPress motoron tárolják.
3. A HTTPS-re váltás előtt ellenőrizze a kódkönyvtárakat. Ez egy opcionális lépés, és alkalmazható bonyolultabb webhelyekre, amelyek további szoftvereket használnak, mint például a JavaScript és az Ajax.
4. Frissítse a webhelyre mutató összes külső linket a közösségi médiafiókokból és a jó hírű könyvtárakban található listákból.
5. Hozzon létre egy átirányítást a HTTPS 301-re. Bonyolultnak hangzik, bár valójában nem. A 301 egy módszer a forgalom átirányítására egy weboldalról egy másik URL-re. Ez egy fontos pont, mert ha egy webhely több tucat, száz vagy akár több ezer backlinks mutat rá más webhelyekről, akkor a HTTP-oldalakra mutatnak, és a keresőmotorok rangsorolása a backlinkek számától és minőségétől függ. A 301-es átirányítási beállítás a használt webkiszolgáló típusától függ. A legnépszerűbb webszerverek az Apache, az NGinx, a LiteSpeed és a Windows. Mielőtt HTTPS-re váltana az Apache és a LiteSpeed használatával, frissítenie kell a htaccess fájlt, az NGinx-az NGinx konfigurációs fájlt, a Windows-ban pedig a web.konfigurációs fájl.
6. Ha tartalomszolgáltató hálózatot (CDN), például CloudFlare-t használ, akkor az SSL-t is szinkronizálnia kell ezzel a rendszerrel. A CDN egy globálisan elosztott szerverhálózat, amely a weboldalak másolatait tárolja a szerverükön. Ez nemcsak a sebesség, hanem a biztonság szempontjából is előnyökkel jár, mivel felismeri a különböző rosszindulatú programokat és megakadályozza a webhely hackelését.
7. Frissítse az egyéb eszközöket és tranzakciós e-maileket, például az e-mail marketinget, az automatizálást és a céloldal generátorokat. El kell készítenie ezeknek a programoknak a listáját, meg kell keresnie a HTTP-re hivatkozó weboldalak megemlítését, majd frissítenie kell őket HTTPS-re.
8. Végül, de nem utolsósorban, a HTTPS-re való váltásra vonatkozó utasítások követéséhez frissítenie kell Google Analytics és Search Console-fiókjait. Az Analytics szolgáltatásban meg kell változtatnia az alapértelmezett URL-címet HTTPS-re. A search console-ban új webhelyet kell hozzáadnia HTTPS-sel.

A SEO csapdák megelőzése

A Chrome figyelmezteti a felhasználókat, hogy a webhely nem biztonságos, amikor kitöltenek egy űrlapot, például keresőmezőt vagy e-mailes regisztrációt. Ez a legújabb figyelmeztetés, a Google SEO előnyeivel kombinálva, sok webhely számára felgyorsította az új szabványra való áttérést.

Számos részlet és ellenőrző lista létezik a mérnöki oldalon, de néha a SEO sajátosságai figyelmen kívül hagyhatók az átmenet során. Egy HTTP-HTTPS ellenőrzőlista, amely csak a SEO problémákra összpontosít: tervezés, áttelepítés és áttelepítés utáni megfigyelés.

A Keylime Toolbox Query Analytics használatával összekapcsolhatja a Google Search Console HTTP és HTTP Secure query adatait, és nyomon követheti a kattintások számának, rangsorolásának, megjelenítésének időbeli és összesített tendenciáit, az egyes lekérdezések szintjén és kategóriákban. A Keylime Toolbox Crawl Analytics napi naplóelemzést biztosít a Googlebot-vizsgálatok nyomon követéséhez, a teljes vizsgálat és újraindexelés időtartamának becsléséhez, valamint a problémák azonosításához. Ha a webhely nagy és a normál szkennelés hatástalan, fontolja meg a szkennelés hatékonyságának speciális elemeinek bevezetését az áttelepítés megkezdése előtt.

Átmeneti funkciók beállítása

Az Átirányításokra való váltáskor konfigurálja a következő paramétereket. Útmutató a HTTP-ről HTTPS-re való váltáshoz:

1. 301 átirányítja a HTTP-címeket HTTPS URL-ekre. A lehető legnagyobb mértékben tartalmazza az összes meglévő szabályt. A Google csak legfeljebb 5 átirányítást fog beolvasni egy láncban.
2. Frissítse az összes belső linket a HTTPS URL-ekre.
3. Metaadatok frissítése és strukturált jelölés.
4. Győződjön meg arról, hogy az összes erőforrás átkerül a HTTPS-re, és a hivatkozások frissülnek az oldal forráskódjában.
5. Ellenőrizze a HTTPS tulajdonságot a Google Search console - ban.
6. Hozzon létre egy olyan tulajdonságkészletet, amely egyesíti a HTTP-t és a HTTPS-t megfigyelési célokra.
7. Konfigurálja a tartomány HTTPS verziójának paramétereinek feldolgozását a Google Search Console-ban a HTTPS telepítési beállításainak megfelelően.
8. Nemzetközi célzás létrehozása.
9. Állítsa be a szkennelési sebességet.
10. Győződjön meg arról, hogy a fájl HTTPS robotok.a TXT-nek ugyanaz a tartalma, mint amit korábban megadtunk a HTTP-hez, és nem tilt meg mindent.
11. Győződjön meg arról, hogy a HTTPS oldalak nem rendelkeznek "meta noindex" attribútumokkal.
12. Győződjön meg arról, hogy a webanalitika és más külső címkék telepítve vannak.
13. Küldje el az URL-ek XML-Webhelytérképét a HTTPS-re, és ne blokkolja a HTTP-URL-eket robotok segítségével.txt.
14. Nyomon követik a szokásos keresési forgalmat a webes elemzésben, hogy megbizonyosodjanak arról, hogy stabil-e.
15. Rangsorok és más SEO-orientált adatok nyomon követése a Google Search Console-ban.
16. Manuálisan ellenőrizze a keresési eredmények megjelenítését, hogy megbizonyosodjon arról, hogy minden rendben van-e, mivel a HTTPS URL-ek indexelve vannak.

Google robot által szkennelt

A folyamatkövetési adatok, a Google robot HTTP és HTTPS szkennelésének módja, a beolvasott URL-ek és a kapott válaszkódok csak akkor érhetők el, ha Crawl Analytics-et használnak, amely letölti a szerver naplófájljait feldolgozásra. Ehhez töltse le a Google által biztosított szkennelési hibák teljes listáját, mind a HTTP, mind a HTTPS esetében, valamint az egyes hibák linkforrási adatait.

Az összesített rangsorolás és a HTTP-és HTTPS-forgalom idővel nyomon követhető a márkás és nem márkás lekérdezésekhez, valamint más SEO-adatokhoz, például az egyéni és összesített kattintási értékelésekhez és azok teljes számához, amelyre a webhely megjelenik

Ha a webhely nagy, és a szkennelés nem hatékony, a folyamat felgyorsítása érdekében a Google időbe telhet az összes HTTP-URL újbóli beolvasása, majd az indexben lévő HTTPS-verziókkal való helyettesítése. A naplófájlok nagyszerű forrást jelentenek a teljesítményproblémák azonosításához. Bár a Google azt állítja, hogy a PageRank adatfolyamot ugyanúgy kezeli, mint a 301. és a 302., de ezeket az átirányításokat mégis másképp kezelik. Mivel a 302 technikailag "ideiglenes", a Google továbbra is indexeli a 302 cél URL-jét. A 301-es átirányításakor a Google eltávolítja az átirányítási URL-t az indexből, és csak a 301-es cél URL-t indexeli.

Az átirányítási szabályok konszolidálása

A Googlebot robot legfeljebb 5 átirányítást hajt végre, és mivel az URL-ek idővel változnak, és a kanonizációs szabályok hozzáadódnak, az átirányítási láncok általánossá válnak. Azonban lassítják az oldal betöltését, különösen a mobil eszközökön.

Sok esetben a HTTP / HTTPS és a www/nem www átirányításokat szerver szinten hajtják végre, a többit pedig a. Ebben az esetben az ideális forgatókönyv az, ha egyetlen 301-et használunk szerver szinten a könyveléshez, például a HTTP/HTTPS-hez.

A HTTPS-re történő legutóbbi átirányítás a következő szabályokat tartalmazza:

1. A régi URL-sablonoktól az aktuálisakig győződjön meg arról, hogy az összes régi szabály frissül az aktuális végcélokkal. Az eset normalizálása például a példából.com / Page1 to példa.com / page1 és egy záró perjel, például a példából.com / page1 to példa.com / page1/. Ebben a példában példa.a com / Page1 alkalmazás szintje átirányítja a 301-et közvetlenül a példára.com / page1 / egy HTTPS és www ciklussal.
2. A régi szabályok felülvizsgálatakor, frissítésekor és konszolidálásakor győződjön meg arról, hogy mindegyik értéke 301, nem pedig 302. A 302-t átirányító URL-ek indexelve maradhatnak, ami kiszámíthatatlan elemekhez vezet a keresési eredmények megjelenítésében. Nem csak a rossz URL jelenhet meg bennük, hanem más nemkívánatos viselkedés is. Ha például metaadatok, például webhelyhivatkozások kapcsolódnak az aktuális URL-hez, és a régi megjelenik a keresési eredmények között, akkor a további hivatkozások nem jelennek meg.
3. Frissítse az összes belső linket a kanonikus URL-ekre, ami hasznos, mivel az átirányítások növelik az oldal betöltési idejét, különösen a mobil eszközökön. Ideális esetben a belső linkeknek abszolútnak, nem relatívnak kell lenniük, és frissíteniük kell őket HTTPS URL-ekre.
4. Használjon relatív, nem pedig abszolút hivatkozásokat, amelyek kiküszöbölik a frissítés szükségessége belső. Ez normális, , de nem ideális, mivel a belső kapcsolatok erős kanonikus jel a keresőmotorok, , ezért, ha bármely URL helytelenül van beállítva, hogy ne irányítsa át, akkor a webhely véletlenül megismétlődik egy aldomainen, vagy törlődik. Az ezeken az oldalakon található összes link nem kanonikus verziókon lesz.

A legtöbb esetben a belső linkek frissítése nem igényel sok munkát. Gyakran frissíthetők konfigurációs paraméterekkel, programozottan vagy egyszerre egy szkript segítségével.

Metaadatok és strukturált jelölések frissítése

A kanonikus attribútumértékek HTTPS URL-ekre történő frissítésekor, ha a 301-et átirányítja a HTTP-ről a HTTPS-re, de a HTTPS URL-ek kanonikus attribútumokkal rendelkeznek a HTTP-hez, a Google végtelen ciklust fog látni, ami kiszámíthatatlan indexelési eredményeket eredményez. A hiba kijavításához szüksége lesz:

1. A webhely HTTP-ről HTTPS-re váltásához frissítse az értékeket az oldalszámozási attribútum HTTPS URL-ek.
2. Frissítse a hreflang attribútum értékeit HTTPS URL-ekre.
3. Frissítse a rel alternatív értékeket, ha azokat egyedi mobil URL-ekhez használják a HTTPS URL-eken.
4. Frissítse a strukturált jelöléseket, például videókat, körhintákat és a webhely linkkeresési mezőjét HTTPS URL-ek alapján.
5. Győződjön meg arról, hogy az összes erőforrás átkerül a HTTPS-re. A HTTPS oldalak által használt összes erőforrást HTTPS-ről kell kiszolgálni. Ez olyan elemeket tartalmaz, mint a képek, a JavaScript és a CSS fájlok.
6. Frissítik a közösségi beépülő modulokat, hirdetési hívások, stb.
7. A Google eszközök segítségével keresse meg a" vegyes tartalmat " a webhelyen.

A Search Console konfigurálása

A search console konfigurálásához hozzon létre egy olyan tulajdonságkészletet, amely a tartomány HTTP-és HTTPS-verzióját egyaránt tartalmazza a figyeléshez. Szekvenciális művelet algoritmus:

1. A tartomány HTTPS-verziójának paraméterfeldolgozási konfigurációjának konfigurálása a Google Search Console-ban.
2. Állítsa be a nemzetközi célzást, ha alkalmazható, hogy megfeleljen a HTTP-hez beállított értéknek.
3. Frissítse a beolvasási frekvenciát, ha a HTTP-re van beállítva.
4. Töltse fel a HTTP-re feltöltött összes elutasított fájlt.
5. Az előnyben részesített tartomány beállítása.
6. Létrehoznak egy protokollt a HTTP és HTTPS robotok kizárására.
7. Győződjön meg arról, hogy a HTTP robots fájl.txt átirányítások vagy 404s.
8. Győződjön meg arról, hogy a fájl HTTPS robotok.a txt tartalma megegyezik az előző HTTP-vel, kivéve a webhelytérkép-fájlokra mutató linket.
9. Győződjön meg arról, hogy a HTTPS oldalak nem rendelkeznek meta noindex attribútummal.
10. Győződjön meg arról, hogy a webanalitikai címkék (és mások) továbbra is a helyükön vannak

Sok esetben a webhely továbbra is ugyanazokat a webanalitikai címkéket használja, például a Google Analytics tulajdonának azonosítóját. De ha ez megváltozik, ellenőrizze, hogy a webhely oldalai frissülnek-e. Ezenkívül győződjön meg arról, hogy a címkéket tartalmazó forráskód nem kerül eltávolításra az oldalakról az áttelepítési folyamat során. Használhat egy harmadik féltől származó eszközt, amely ellenőrzi a címkéket, vagy beállíthat egy szkennert, például a Screaming Frog alkalmazást.

Ha XML-webhelytérképeket ad hozzá a Google Search Console-hoz, jelentések segítségével nyomon követheti az indexelés csökkenését. Indítsa el a Google botok szkennelését HTTPS URL-ekkel, amikor XML Webhelytérkép-fájlokban vannak. Az indexelés növekedését XML fájlindexelési jelentések segítségével követheti nyomon. Mindig hozzon létre átfogó és kanonikus XML webhelytérképeket, nem csak a HTTP-ről HTTPS-re való váltás céljából.

Search Console Monitor

Az URL-ek XML-Webhelytérképét el kell küldeni a HTTPS-re, a meglévő XML-webhelytérképet pedig a HTTP-re kell hagyni. Ez lehetővé teszi a HTTP tulajdonság indexelésének csökkenését, valamint a HTTPS tulajdonság indexelésének növekedését.

A HTTP-webhelytérkép minden URL-jének 301-es állapotkóddal kell rendelkeznie, az indexelésnek pedig idővel csökkennie kell. A HTTPS webhelytérképben szereplő összes URL-nek 200-as állapotkóddal kell rendelkeznie, és indexelnie kell kell növekedés az idő múlásával. Ez a folyamat eltarthat egy ideig, és előfordulhat, hogy néhány HTTP URL-t még hónapokkal később indexelnek.

A legtöbb gyakori okok mert ez:

1. A HTTP URL-eket blokkolják a robotok.txt, így a Googlebot robot nem tudja beolvasni az átirányítást, és részben indexelve van.
2. A HTTP URL-ek "nem kanonikusak" , és nem túl gyakran szkennelik őket.
3. A HTTP URL-ek nem 301-et adnak vissza, hanem 302-et vagy hibát adnak vissza.

Hibaelhárítási Tippek

Sajnos a lépésenkénti utasítások követése és a HTTPS-re való váltás meglehetősen bonyolult folyamat, és a felhasználónak meg kell értenie, hogy mit foglalkozik.

A fő típusai átmeneti hibák: az

1. a webhely HTTPS-re váltása után felmerülő leggyakoribb problémák a vegyes tartalomra vonatkozó figyelmeztetések. Ez akkor történik, ha a böngésző nem biztonságos linkeket talál egy másik védett oldalon. Ez általában a jQuery könyvtárakra mutató linkek frissítésének kérdése, egyedi betűtípusok , vagy hasonló HTTPS verziói. A felhasználónak gondoskodnia kell erről a webhelyének beolvasásakor, mielőtt közzétenné, és ha ilyen figyelmeztetések jelennek meg, ellenőrizze az őket okozó forrásokat.
2. A HTTP-ről HTTPS-re váltás negatívan befolyásolhatja a minősítést, bár ez általában csak ideiglenes. Ha 301 átirányítást állít be, az csak a referenciatömeg 90-99% - át dolgozza fel. Ezért csökkenhet a minősítés az elején. Idővel azonban növekedniük kell, és hosszú távon előnyösek.
3. Ha kiderül, hogy egyes URL-eket hónapokkal később is indexelnek, de a Google Search Console Search Analytics jelentései nem mutatnak kattintásokat a HTTP tulajdonságra, akkor talán nem érdemes megvizsgálni ezt a problémát. Az URL-eket nem rangsorolják lekérdezések szerint, és nem okoznak problémát. Ha azonban kattintások vannak a HTTP tulajdonságra, akkor az URL-eket lekérdezések szerint rangsorolják.
4. A vizsgálat megkezdésének legegyszerűbb módja a szervernaplók áttekintése, hogy megtudja, pontosan mit kap a Google robot a szkennelés során. Az Excelben a Keylime Toolbox Crawl Analytics részletes naplófájljai tartalmaznak egy lapot, amely felsorolja az összes URL-t 200 válaszkóddal, az összes URL-t 302 válaszkóddal stb.
5. Lehetőség van egy webhely beolvasására egy olyan eszköz segítségével, mint a Screaming Frog, hogy megkapja a robotok által blokkolt 200-at visszaadó URL-ek listáját.txt. Megnézheti a Google Search Console-t is> Szkennelés> robotok.txt tesztelő A HTTP tulajdonsághoz, hogy megnézze, látja-e a Google a robots fájlt.txt, és ha igen, blokkolja az URL-eket.

Egyéb buktatók, amelyek nem kapcsolódnak a SEO-hoz

Más lehetséges problémák is vannak a HTTPS-re váltó webhelyek számára:

1. Az AdSense bevételeinek potenciális csökkenése. A múltban az Adsense bevételeinek csökkenését a HTTPS-szel összeegyeztethetetlen hirdetések nagy száma okozta. Fontos megjegyezni, hogy ha a felhasználó HTTP-ről HTTPS-re vált, frissítenie kell az AdSense kódot, különben megkapja a fent leírt tartalmi problémákat.
2. Nem ritka, hogy egy webhely elveszíti az összes részesedését a közösségi hálózatokban, amikor HTTPS-re vált. Még egy fantasztikus cikk is, amely több tízezer lájkot gyűjtött össze a Facebook-on, visszaállítható az átmenet után. A Facebook dokumentációja elmagyarázza ennek a megkerülését, amely magában foglalja az og:url metacímkék beállítását a régi http URL megadásához. Azt mondja azonban, hogy csak akkor működik, ha a régi URL 200 választ ad vissza. Ha átirányítja a http oldalakat https oldalakra, akkor a "régi" oldalak 301-et adnak vissza, nem pedig 200-at.
3. A HTTPS-re való váltás miatt a Google túlbecsülheti a webhelyet a minőség szempontjából. Ez a legnagyobb probléma az átmenet során azt jelentheti, hogy a webhely összes oldala új minőségi minősítést kap. Lehetséges, hogy a korábban használt technikák és kiskapuk a HTTPS eltolás után már nem fognak ugyanúgy működni, aminek következtében a forgalom a HTTPS-re való váltás után csökken.
4. A webhelytérkép fájlokat frissíteni kell. Váltás előtt győződjön meg arról, hogy egy új webhelytérkép is létrejött.
5. A Disavow fájlt fel kell tölteni a HTTPS-re.
6. A Google továbbra is különböző webhelyekként kezeli a webhely HTTPS és HTTP verzióit, és ha a Google Search console-t használja, akkor létre kell hoznia egy új tulajdonságot a HTTPS verzióhoz. Ha a felhasználónak van egy leállítási fájlja, akkor fel kell töltenie a HTTPS verzióra.
7. Győződjön meg arról, hogy a tanúsítvány nem járt le. Ha a webhely HTTPS-en keresztül működik, és a biztonsági tanúsítvány lejár, akkor amikor a Google megpróbálja elküldeni a látogatókat a webhelyre, nagy teljes képernyős figyelmeztetést kapnak, amely minden bizonnyal elidegeníti az embereket.

A forgalom biztonságának biztosítása az egyik legfontosabb kérdés minden webhelytulajdonos számára. A bizalom átadása mellett a folyamat a megnövekedett sebesség és a jobb SEO előnyeit is élvezi. Ez nagy befektetés a jövőbe, mivel a hálózat ebbe az irányba halad. Mint már említettük, a Google az SSL használatát pozitív rangsorolási tényezőnek tekinti, tehát ha egy felhasználó webhelyét HTTPS-re helyezi át, az valójában vonzóbbá teszi. Úgy tűnik, ez után ilyen súlyos érvekkel a felhasználónak már nem lesz kérdése a HTTPS-re való váltásról, és miért "keríteni a kertet".