FIREMNÍ BLOG

Jaké jsou výhody a nevýhody převedení webu na zabezpečené HTTPS?

27.03.2018

Také přemýšlíte nad tím, jestli dává smysl přesunout vaši webovou stránku z doposud používané HTTP adresy na její bezpečnější verzi HTTPS? A rádi byste se předem dozvěděli, co vás čeká a nemine?

Přechod na HTTPS rozhodně nepatří mezi jednoduché záležitosti a je tak třeba již na začátku zvážit všechna pro a proti. Tento článek přináší souhrn všech možných úskalí, která vás při přechodu na HTTPS mohou potkat a výčet hlavních důvodů, proč se vlastně (ne)pouštět do zavádění HTTPS na váš web.

Nejdřív si však pojďme připomenout, co to je HTTPS.

Co to je HTTPS?

HTTPS (Hypertext Transfer Protocol Secure) představuje, stejně jako HTTP (Hypertext Transfer Protocol) internetový komunikační protokol, který se využívá k přenášení dat na internetu.

S HTTPS jste se už nejspíše setkali. Pouze o tom jen asi nevíte. Nejsnazší způsob, jak poznat stránky zabezpečené pomocí HTTPS protokolu, je podívat se do adresního řádku, zda tam náhodou nevidíte obrázek zaklapnutého zeleného zámku.

Obrázek č. 1 – ukázka adresního řádku s HTTPS protokolem

Jak se od sebe liší HTTP a HTTPS?

HTTPS se liší pouze tím, že data, které se přenáší mezi serverem (webová stránka, kterou si chcete prohlédnout) a klientem (váš internetový prohlížeč), jsou šifrovaná. A je tedy obtížnější je odposlouchávat, sledovat nebo modifikovat.

Protokol HTTPS zároveň ověřuje protistranu (kdo data skutečně posílá). Uživatelé tak vědí, s kým komunikují a že se je nesnaží nikdo podvést.

Nicméně ani využití HTTPS neznamená, že komunikace nemůže být odposlouchávána či pozměněna. Pomocí metody MITM to samozřejmě jde, jen je to už trochu složitější.

Pozn. MiTM (man-in-the-middle, volně přeloženo do češtiny – muž uprostřed) je metoda spočívající v tom, že mezi dvěma komunikujícími uživateli se nachází prostředník (zpravidla útočník), který všechen provoz odposlouchává a odesílá oběma subjektům vlastní šfrovací klíče, čímž může získat přístup k obsahu šifrovaných zpráv a ty pak následně také měnit. Ani jeden z uživatelů tak o existenci tohoto prostředníka nemusí mít vůbec ponětí.

Jak funguje HTTPS?

Systém zabezpečení u HTTPS probíhá prostřednictvím SSL protokolu, který je založen na důvěryhodných certifikačních autoritách. Tyto certifikační autority představují společnosti, od kterých si pak následně kupujete důvěryhodný SSL certifikát. Problémům spojeným s celým procesem obstarávání certifikátu od různých certifikačních autorit se budu věnovat později.

Každý, kdo používá SSL, musí mít ve svém systému “nainstalovaný” seznam důvěryhodných certifikátů, tzn. “seznam protistran”, kterým věří a je ochoten s nimi komunikovat (tzn. důvěřuje jim).

Ve výchozím stavu již operační systém každého obyčejného uživatele obsahuje nějaké důvěryhodné kořenové certifikační autority (například Verisign nebo Comodo). Webové servery, se kterými komunikujete, mají certifikáty podepsané těmito důvěryhodnými certifikačními autoritami.

Tolik asi ve zkratce.

Certifikační autority

Jsou důvěryhodné společnosti, do kterých si můžete pořídit certifikát. Cena tohoto certifikátu se odvíjí od toho, na jakém stupni “v celém potravním řetězci” se nachází společnost, od které certifikát kupujete.

Certifikační společnosti totiž mohou udělit oprávnění i dalším firmám a učinit z nich tak další certifikační autority, které mohou prodávat tyto certifikáty (zpravidla za nižší cenu) také a ty mohou opět toto oprávnění zase přeprodávat dále atd.

Obrázek 2 – schéma certifikační autority – slouží jen pro ilustraci, jak fungují certifikační autority. V praxi jsou většinou certifikační autority 1.-2. úrovně.

Cena certifikátu se tak bude lišit tím, od jakého subjektu kupujete certifikát. Obecně platí, že čím déle certifikační autorita, od které certifikát nakupujete, existuje, tím dražší bývá kupovaný certifikát.

Pozn. Váš certifikát může být důvěryhodný i v případě, že není přímo podepsán důvěryhodnou certifikační autoritou. Toho lze dosáhnout pomocí prostředníka – další certifikační autority. Pokud tedy například existuje obecně uznávaná certifikační autorita A, která podepíše důvěryhodný kořenový certifikát certifikační autoritě B, můžete pak používat certifikát i od certifikační autority B jako důvěryhodný.

Tento “trust-path” lze v podstatě neomezeně řetězit, takže k vašemu certifikátu můžete dostat klidně ještě další 3 certifikáty, které sestavují cestu důvěryhodnosti k vašemu certifikátu, který jste si právě koupili.

Toto může způsobovat problémy, když zprostředkované certifikáty, které jsou potřeba k ověření vašeho certifikátu, nejsou uvedeny ve správném pořadí, nebo když dojde k zneplatnění některého z těchto certifikátů v tomto řetězení.

Obrázek 3 – schéma certifikační autority

Z toho důvodu je dobré snažit se mít trust-path co možná nejkratší – to má obvykle bohužel zásadní vliv na cenu certifikátu.

Správnost nasazení SSL certifikátu si můžete ověřit např. zde: https://www.ssllabs.com/ssltest/analyze.html

Co se může stát, když nepoužíváte HTTPS protokol?

Představte si, že se přihlašujete na nezabezpečeném webu a vaše heslo po cestě někdo odchytne a bude tak mít vaše přihlašovací údaje k danému účtu. Asi každý z vás si umí představit, jaký velkého strašáka může tato situace představovat pro banky a pro její uživatele, kteří se například přihlašují do elektronického bankovnictví.

To však není jediná riziková situace, která by mohla nastat. Představte si, že svým uživatelům posíláte nějaká data a útočník je po cestě změní. Zákazníkovi kupříkladu po vyplnění objednávky podsune jinou adresu platební brány a nic netušící zákazník tak pošle peníze někomu zcela jinému. A obdobných rizik je u nezabezpečených přenosů více.

Na nezabezpečený web lze vkládat jakýkoliv vlastní obsah (viry, bannery aj.). Vaše konkurence by tak čistě hypoteticky mohla na váš web vkládat nevhodný obsah či vám škodit jakkoliv jinak dle libosti. A to samé můžete dělat i vy s svým konkurentům, pokud ještě nemají svůj web zabezpečený :-).

V jakých situacích by se měl využívat HTTPS protokol?

V podstatě u jakýchkoliv webů, kde by zcizení či pozměnění dat mohlo způsobit nenapravitelnou škodu, tzn. v podstatě u všech webů :-). Jen ne pro každého je ochrana dat jeho uživatelů tak zásadní jako například u:

  • E-shopů, kde lze vyplnit online objednávky a platit pomocí kreditní karty a je třeba zamezit zneužití či zcizení důležitých osobních či platebních údajů.
  • Bank a u finančních institucí, které pracují s platebními údaji a osobními údaji zákazníků.
  • Ve státní správě, na úřadech, jelikož tyto instituce velice často pracují s citlivými údaji (datum narození, adresa, rodné číslo aj.) a stejně tak jako všechny ostatní subjekty musí vaše tato data náležitě chránit.
  • U ostatních webů, které jakýmkoliv způsobem zpracovávají data zákazníků online (maily, adresy, telefony, platební údaje).

Právě pro tyto segmenty je ochrana dat prioritou číslo jedna.

Asi byste také nesvěřili příště bance své peníze, kdybyste vinou jejího špatně zabezpečeného internet bankingu přišli o peníze. Anebo kdyby se ukázalo, že aplikace banky je děravá a někdo vám tak mohl do počítače nainstalovat vir a vy museli na vlastní náklady sjednávat opravu…

Jak to všechno začalo – hysterie kolem HTTPS?

HTTPS začalo být horké téma přibližně před dvěma lety , kdy Google vydal prohlášení, ve kterém upozornil, že weby využívající HTTPS (= SSL certifikáty) budou z pohledu SEO mírně upřednostňovány a budou se tak pravděpodobně zobrazovat výše ve výsledcích vyhledávání.

Jen pro zajímavost – Google dokonce tuto změnu podporoval už v roce 2012, tzn. dva roky předtím, než se začal pojem HTTPS skloňovat ve všech pádech hlavně kvůli SEO.

Abych to uvedl na pravou míru – Google sice oznámil, že weby na HTTPS bude preferovat, ale sám Google tvrdí, že HTTPS má velmi malou váhu a ovlivňuje to asi procento dotazů. Přecházet na HTTPS “jen” kvůli vyhledávači proto nedává v podstatě žádný smysl.

Protože podobných signálů, které vyhledávač vyhodnocuje, jsou stovky. A kdyby mělo využití HTTPS třeba byť jen jednoprocentní podíl na výsledném hodnocení pozic na Googlu, tak se vám to zkrátka nejspíš stejně nevyplatí. Už jen proto, že je s tím spojeno obrovské množství práce. Ostatně tomu, jaké martyrium vás pak čeká, se věnuji podrobněji níže.

Nemusíte se ani bát toho, že se vám propadne web o desítky pozic. I tento názor se dá s přehledem dementovat. Stejně tak vám nehrozí penalizace za to, že váš web běží stále na nezabezpečeném HTTP. Je to prostě něco, co můžete udělat a získáte malou výhodu navíc. Ale když to neuděláte, nic hrozného se nestane. Vlastně skoro nic, jak ukazují výsledky většinu uživatelů, kteří se nechali zlákat přechodem na HTTPS „kvůli SEO”.

Na HTTPS byste měli přecházet kvůli samotným uživatelům, abyste chránili jejich soukromí. Protože asi nic nevypadá hůře, než když se provalí nějaký bezpečnostní problém a data uživatelů pak běhají nezadržitelně po internetu a všichni ví, že za to můžete právě VY! O to horší to pak může být problém, pokud jste třeba firma, která poskytuje hosting, vyrábí webové stránky anebo provozujete například internetovou peněženku…

A teď – co vás tedy skutečně čeká, když se rozhodnete přejít na HTTPS a jaké výhody a nevýhody to přináší?

Nevýhody:

Cena certifikátu – při přechodu na HTTPS si musíte chtě nechtě pořídit SSL certifikát, který si musíte každoročně obnovit.

Lze si ale samozřejmě pořídit SSL certifikát i na několik let dopředu. Není nutné jej tedy ručně obnovovat každý rok, pokud nechcete, celý tento proces se dá automatizovat, jen vás to bude stát opět nějaký čas navíc, než přijdete na to, jak. Tak jako tak – musíte za certifikát vždy platit.

Nejedná se o nějaké závratné částky, pokud nepotřebujete zrovna takto zabezpečit stovky webů (a pokud ano, tak asi částky v řádů tisíců pro vás nepředstavují výrazný problém, protože jste minimálně středně velká firma, pro kterou částky v řádu pár (desítek) tisíc nebudou likvidační).

Zde bych ještě doplni, že hodně záleží na certifikační autoritě, tzn. ceny, které najdete níže, se mohou (výrazně) lišit. Uvádím je pouze pro představu – abyste zkrátka věděli, kolik to asi stojí.

Ceny certifikátů se liší podle typu:

  • Automatizovaný důvěryhodný SSL certifikát od Let’s Encrypt. Nejlevnější (bezplatná) varianta, která ale neumí Wildcard a SAN (viz níže). Druhým problém je, že tento certifikát vydají každému, kdo si o něj požádá. Stačí odeslat žádost a máte certifikát. Problém je tak v tom, že web, na který se díváme, je sice zabezpečený, ale kromě podvrženého obsahu má podvržený i SSL certifikát. Za zmínku určitě stojí i fakt, že některé české hostingy již nabízejí funkci auto-SSL. Tzn. všechny hostované weby u daného hostera mají k dispozici SSL certifikát (Let’s Encrypt), který je buď zdarma anebo z nějaký symbolický poplatek. Jejich seznam sestavil Dušan Janovský ze Seznamu.
  • Základní SSL – lze certifikát pořídit od cca 139 Kč za rok a vztahuje se nejčastěji na jednu doménu.
  • SAN/UC (Subject Alternative Name/Unified Communications) – tyto certifikáty umožňují chránit jedním SSL certifikátem více domén.
  • Cena těchto certifikátů může začínat u těch nejlevnějších na 329 Kč za rok a s tímto „levným“ certifikátem lze zabezpečit až 3 domény najednou. Vyskytují se pak samozřejmě i varianty, které umožňují jedním certifikátem zabezpečit i 10 a více domén. Počítejte však, že vás takový certifikát může stát kolem 1 890 Kč za rok.
  • SSL Wildcard certifikáty (taktéž označovány jako hvězdičkové certifikáty) – představují univerzální typ SSL certifikátu, který umožňuje zabezpečit všechny subdomény pod jednou hlavní doménou. Wildcard certifikát obsahuje před názvem hlavní domény hvězdičku (např. *.seznam.cz) a jeho použití šetří finanční náklady na nákup dalších SSL certifikátů a v neposlední řadě i čas potřebný pro jejich instalaci a správu.
  • Cena těchto certifikátů začíná na 990 Kč za rok. Stejně jako SAN/UC je možné je pořídit také ve verzi, která umožňuje zabezpečit jedním certifikátem více wildcard domén. SSL Wildcard certifikáty umožňující zabezpečit až 9 hlavních domén včetně jejich  subdomén pak stojí klidně 18 000 Kč za rok.
  • IDN SSL (Internationalised Domain Names) – jsou certifikáty využívající se k zabezpečí domény, které používají znaky mimo standardní abecedu latinky (a-z). IDN SSL certifikátem můžete zabezpečit například weby mající v názvu ruské či čínské znaky. Nejlevnější verze IDN SSL pořídíte klidně od 189 Kč, IDN SSL certifikáte pro zabezpečení až 100 domén vás pak může přijít na bezmála 41 000 Kč za rok.
  • Samotné certifikáty se pak liší nejenom cenou, množstvím domén, které lze jedním certifikátem zabezpečit, ale také typem ověření:
  • DV SSL (Domain Validation) – cenově nejdostupnější SSL certifikáty, které pro svoje ověření používají pouze základní ověření na úrovni domény, kdy je zasílán verifikační e-mail. Obrovskou výhodou DV certifikátů je jejich rychlé vystavení, které může být provedeno během několika minut.
  • OV SSL (Organization Validation) – SSL certifikáty nabízí vyšší stupeň důvěryhodnosti oproti certifikátům DV díky kompletní identifikaci společnosti, pro kterou je SSL certifikát vystaven. Ověření společnosti zdůrazňuje důvěryhodnost provozovatele www projektu, návštěvník má možnost kdykoliv si provozovatele stránek ověřit.
  • EV SSL (Extended Validation certifikáty) – tento certifikát zbarví zeleně adresní řádek prohlížeče S EV SSL certifikátem se navíc vedle www adresy zobrazí i název společnosti.

Jak sami vidíte, certifikátů je docela velké množství a to jsem se ještě nerozepsal také o tom, že se liší ještě šifrováním a třeba metodou výměny klíčů.

Poznámka: Certifikáty se mohou lišit také typem šfrování. Nejběžnější a nejpoužívanější je RSA.

RSA šifrování (pojmenováno iniciály autorů Rivest, Shamir, Adleman) – jedná se v podstatě o nejběžnější formu zabezpečení, která se používá i dnes, přičemž při dostatečné délce klíče je považován RSA ověření za bezpečný.

Za zmínku stojí určitě zajímavost, že do budoucna to nemusí platit. Kvůli rozmachu kvantových počítačů americký Národní institut standardů a technologie (NIST) hledá kvantově odolné šifry. V jejich zprávě se můžeme dočíst, že RSA, DSA ani eliptické ECDSA a ECDH nejsou spolehlivé, pokud budou dostupné velké kvantové počítače.

ECC (Elliptic Curve Cryptography) šifrování – je zhruba 10 000 krát silnější varianta než nejrozšířenější RSA 2048-bit. Navíc tento výrazně kratší 256-bit ECC klíč vyžaduje mnohem méně výpočetní kapacity (procesoru i paměti) serveru než 2048-bit RSA. Ale tento typ šifrování se moc nepoužívá.

Čas – Asi největší překážka, která vás bude odrazovat od přechodu na HTTPS. S přechodem na HTTPS muset začít počítat také s tím, že vám určitý čas zabere nejenom samotné načítání si informací (jaké certifikáty existují, který z nich si vybrat a kde jej koupit), ale je třeba připočíst i čas strávený se samotnou implementací (zkrátka musíte vědět, co kam vložit a jak to zkontrolovat, případně zajistit bezproblémový chod HTTPS). K tomu připočtěte čas strávený bug fixingem, kterému se tak jako tak nevyhnete. Ostatně, co vše vás při přechodu na HTTPS čeká, si můžete udělat představu z následujících řádků.

Kompletní přesměrování – web budete muset kompletně celý přesměrovat na nové URL adresy, které budou nově místo HTTP využívat HTTPS. Což u rozsáhlejších webů může být práce i na několik dnů, ne-li týdnů. U korporátních webů, pak počítejte spíše s měsíci usilovné práce a desítkami bezesných nocí.

A proč je vlastně přesměrování potřeba? Webové stránky běžící na HTTPS představují samostatný web, než ten, který doposud běžel na protokolu HTTP. Z pohledu vyhledávače tak máte vlastně dvě totožné webové stránky.

Pokud chcete zamezit tomu, abyste váš web neduplikovali (což z pohledu SEO není žádoucí stav), budete muset starý HTTP web přesměrovat na jeho novou HTTPS verzi.

Jednu URL adresu po druhé tak budete muset pomocí stavového kódu 301 (Moved Permanently), což znamená, že se jedná o trvalý (a ne jen dočasný) stav. A teď si představte, že celý tento proces budete muset vyřešit například pro web, který dennnodenně využívají tisíce lidí a vše tak musí proběhnout hladce, ideálně tak, aby koncový uživatel nic nepoznal…

Další starosti s přesměrováním

  • Následně pak musíte ověřit, že přesměrování funguje i na všech subdoménách webu.
  • Dále pak je nutné, abyste si přenastavili všechny URL adresy exportů (např. feedy pro heureka.cz nebo zboží.cz, kde musíte změnit URL adresu feedu na https).
  • To samé vás čeká u obrázků, JavaScriptů, CSS, multimédií, PDF souborů atd.
  • Budete muset upravit všechny URL na webu tak, aby vedly na HTTPS stránky (použijte buď absolutní URL s HTTPS, relativní URL, nebo protocol relative URL „://“)
  • Budete také muset upravit canonical URL, aby nevznikalo zacyklení (zkrátka by uživatel mohl být přesměrován na jinou URL a zase zpět a tak pořád dokola).
  • Měli byste upravit tzv. hardcoded URL (natvrdo zapsané odkazy s http:// například v článcích, JavaScriptech, CSS souborech, atd.).
  • Měli byste upravit hreflang URL, pokud jej používáte.
  • Měli byste upravit URL v RSS, pokud používáte RSS feed pro čtečky.
  • Měli byste upravit URL v Facebook, Twitter a jiných interaktivních tlačítkách, to samé se týká i meta tagů OG:URL.
  • Měli byste vytvořit nový robots.txt.
  • Měli byste změnit umístění souborů sitemap.xml na https:// a upravit odkaz na sitemapu v robots.txt.
  • Měli byste změnit URL v souborech sitemap.xml na https://.
  • U velkých webů musíte, u menších webů (do pár desítek stránek) byste měli zachovat původní tzv. řetězení přesměrování („redirect chain“). Pokud už máte na stránce nějaká přesměrování, tak needitujte aktuální přesměrování, ale přidejte nová pravidla pro přesměrování z HTTP na HTTPS.Pro robota Seznamu je to velmi důležité. K existujícímu přesměrování HTTP://s.cz/stara-url -> 301 -> HTTP://s.cz/nova-url jen přidejte (před, nebo za) další 301 přesměrování 301 -> HTTPS://s.cz/nova-url. Nezkracujte řetězení přesměrování.
  • Musíte přesměrovat URL s _escaped_fragment_= na jejich alternativy 1:1 (tzn. z http://www.s.cz/?_escaped_fragment_= -> 301 -> https://www.s.cz/?_escaped_fragment_=),
  • Měli byste zajistit, že HTTPS funguje i na subdoménách a externích zdrojích, ze kterých budete linkovat soubory – CSS, JS, obrázky, CDN, atd.
  • Měli byste předchozí body otestovat ještě před nasazením (například pomocí nástrojů Screaming Frog, nebo Xenu´s Link Sleuth)

Změny v Google Analytics, Adwords, Sklik a v dalších kampaních – dalším nutným krokem je pro přechodu na HTTPS přenastavit URL adresy v Google Analytics. Pokud to neuděláte, Google Analytics vám nebudou měřit.

Obrázek 4 – Google Analytics

Měli byste přidat HTTPS verzi webu do Google Webmaster Tools (kvůli statistikám HTTPS webu).

  • Měli byste změnit URL webu všude, kde je používáte, např.: PPC kampaně (Sklik, Adwords, Facebook aj.), bannerové a jiné kampaně, affiliate odkazy, opensearch.xml.
  • Pak byste nejspíše měli změnit i URL v emailových podpisech, v automatických emailech atd. To už však není must have, ale spíše nice to have.

Stále ještě máte chuť přejít na HTTPS?

A aby toho nebylo málo, tak ještě donedávna měl zejména Seznam problém s indexací takto převedených webů, což mělo za následek znatelný propad návštěvnosti (tento stav trval bezmála rok a Seznamu se jej podařilo v dubnu (údajně) vyřešit.

I když Seznam tvrdí, že je již vše v pořádku, přesto je třeba mít na paměti, že vám bezproblémový přechod na HTTPS v Seznamu nikdo negarantuje: „V individuálních případech se krátkodobé propady bohužel stále můžou vyskytnout (čím větší web, tím náchylnější k problému je).“

To však ostatně ale platí pro jakékoliv masivní zmeny adres. Zkrátka nikdy nevíte, jak to s webem nakonec zahýbe.

Další povinnosti

U HTTPS budete muset jako provozovatel dávat pozor také na vypršení platnosti certifikátu a zavčas vygenerovat a nasadit nový certifikát. Jinak na návštěvníky čeká nepěkné červené upozornění informující o tom, že web nemá platný certifikát. Samozřejmě i obnovení SSL certifikátu (tzv. renewal) se dá automatizovat, ale opět – bude vás to stát čas navíc, než přijdete, jak na to. A čas jsou peníze…

Připočtěte k tomu nutnost testování během migrace na HTTPS a chyby, které se při přechodu na HTTPS nejspíše vyskytnou a které budete muset řešit.

Na něco určitě zapomenete anebo špatně nastavíte. A v neposlední řadě počítejte také s tím, že vyhledávačům může chvilku trvat, než zaznamenají, že nějaká změna spojená s převodem na HTTPS proběhla, což může resultovat v dočasný (ale i trvalý propad) pozic (zejména u Seznamu) a z toho plynoucí nižší návštěvnost.

Výhody:

  • Bezpečnost – v podstatě tohle by měl být ten hlavní důvod, proč přejít na HTTPS. Odesílaná data nebude tak snadné odchytávat a výrazněji tak eliminujete riziko možného problému s únikem dat.
  • Rychlost – použití HTTPS je sice značně komplikovanější než HTTP, znatelně zvýšit rychlost načítání webu díky spojování požadavků na jednotlivé soubory může použití SPDY protokolu. Pokud stránka načítá velké množství objektů (typicky obrázky, které není možné spojit do jednoho) u HTTP trvá značnou dobu samotná režie s vytvořením požadavku. SPDY si požadavky na soubory dokáže seskupovat a tak dosáhnout znatelného nárůstu zrychlení webu při načítání.
  • Ušetříte si čas v budoucnu – nebudete muset tuto změnu provádět později. Protože dříve nebo později bude HTTPS protokol nejspíše standardem. Takže můžete získat menší náskok a tuto změnu provést teď.Jak píše expert na bezpečnost Michal Špaček: „Další verze HTTP počítá už jen s šifrovaným provozem, zjednodušeně řečeno HTTP 2.0 už bude jen HTTPS. Google sice možná jednou přestane znevýhodňovat HTTPS weby, ale to bude signál, že takových webů je majorita. Možná je toto zvýhodnění také způsob, jak to urychlit.“
  • Získáte ten jeden bodík v SEO navíc teď, dokud ještě Google weby, které přešly na HTTPS, oficiálně zvýhodňuje :-).
  • Spravujete citlivá data uživatelů a chcete zvýšit důvěryhodnost svého webu i úroveň zabezpečení dat.
  • Spouštíte nový web / eshop (a pak se v podstatě tvoříte vše od začátku a žádnou migraci z HTTP na HTTPS dělat nemusíte)

Kdy tedy pro vás dává smysl řešit HTTPS?

  • Nechcete řešit přechod na HTTPS později, až budete muset (HTTPS bude standardem u majority webů).
  • Jenom kvůli SEO tedy nedává migrace smysl, což potvrzuje i Dušan Janovský ze Seznamu: “Množí se dotazy, jestli je dobrý nápad přesouvat weby na https: protokol. Že prý Google to chce. Já říkám, že měnit zbůhdarma URL je blbost.”

Zdroje:

Michal Krčmář
Michal Krčmář
CEO
CEO at Onlineandweb. Over 12 years in the online business. Helping clients to achieve higher profits, being more successful in the digital environment and in online marketing. In digital I went through essentially everything I could (copywriting, PPC, social, web analytics and development). That is why I sometimes feel that I know a lot about the digital environment :-)

Napsat komentář

Vaše e-mailová adresa nebude zveřejněna. Vyžadované informace jsou označeny *