preloader

"*" oznacza pola wymagane

Wypełnij formularz. Przygotujemy dla Ciebie bezpłatną wycenę!

*pole wymagane

agree*

Czy warto przejść na protokół HTTPS i jak zrobić to poprawnie?

Czy warto przejść na protokół HTTPS i jak zrobić to poprawnie?

Całe zamieszanie z protokołem HTTPS w świecie SEO rozpoczęło się ponad pół roku temu, 6 sierpnia 2014 roku. Właśnie tego dnia na oficjalnym blogu Google pojawiła się nietypowa informacja, mówiąca o tym, że protokół HTTPS będzie czynnikiem rankingowym. Informacja zaskakująca, bo Google zwykle nie kwapi się podawać do publicznej wiadomości, co jest czynnikiem rankingowym w wyszukiwarce, a co nie. Tu jednak sytuacja wygląda nieco inaczej niż w przypadku pozostałych czynników rankingowych. Google takim działaniem chce skłonić właścicieli stron internetowych do przeniesienia na protokół HTTPS całych witryn. Dotychczas poprzez HTTPS dostępne były tylko wybrane podstrony serwisu, na których użytkownicy podają dane wrażliwe, takie jak np. dane do płatności.

Google chce rozpowszechnienia protokołu HTTPS, bo zapewnia on użytkownikom serwisów nieporównywalnie większe bezpieczeństwo, niż standardowy protokół HTTP. Dlaczego zatem nie jest on powszechny? Głównym powodem są koszty certyfikatu oraz obawa przed obniżeniem wydajności i prędkości działania serwisu po jego przeniesieniu na HTTPS. Czy słusznie? Na te i inne pytania postaram się odpowiedzieć w dalszej części artykułu. Spróbuję wskazać zalety i wady korzystania z HTTPS, a także najważniejsze kwestie, o których nie należy zapominać przy przenoszeniu serwisu na HTTPS.

Co można zyskać przenosząc serwis na HTTPS?

Przede wszystkim zwiększone bezpieczeństwo dla użytkowników odwiedzających serwis. Ta korzyść jest oczywista, bo przecież zapewnienie bezpieczeństwa jest głównym celem protokołu HTTPS. Na czym to polega? HTTPS czyli Hypertext Transfer Protocol Secure jest szyfrowaną wersją protokołu HTTP, z którego korzystamy, przeglądając strony internetowe. Oparto go o standard TLS (Transport Layer Security), będący rozwinięciem protokołu SSL (Secure Socket Layer). Poprzez szyfrowanie i mechanizmy infrastruktury klucza publicznego (PKI, Public Key Infrastructure) protokół ten pozwala zabezpieczyć międzyprocesowy kanał komunikacyjny. Dzięki temu HTTPS zapewnia bezpieczeństwo w następujący sposób:

  • Dzięki mechanizmowi certyfikacji potwierdza, że serwer, z którym się komunikujemy, jest właśnie tym, z jakim chcieliśmy się komunikować.
  • Szyfrując całą komunikację pomiędzy klientem a serwerem HTTPS, uniemożliwia się „podglądanie” tego, co robimy i kradzież przesyłanych danych.

W praktyce w HTTPS (a raczej w TLS) istnieją poważne luki we wszystkich wspomnianych wyżej zabezpieczeniach, co bardzo szczegółowo opisane zostało w artykule o SSL. Jednak pomimo tych wad, pod względem bezpieczeństwa jest on znacznie lepszym rozwiązaniem niż zwykły HTTP. W HTTP wszystko przesyłane jest otwartym tekstem, co pozwala łatwo podejrzeć przesyłane informacje.

Kolejną, mniej oczywistą korzyścią płynącą z przejścia na HTTPS, jest otrzymywanie pełniejszych danych o tym, skąd użytkownicy trafili na naszą stronę. Mam tu na myśli dane dotyczące witryn odsyłających (referral), czyli takich, na których użytkownicy kliknęli w odnośnik do naszej strony. „Jak to?!” – mógłby ktoś spytać – korzystając z niezabezpieczonego HTTP nie otrzymuję pełnych danych o użytkownikach?”. Tak, zgadza się. Dzieje się tak w przypadku, gdy strona, na której znajduje się odnośnik do naszej witryny, jest dostępna poprzez HTTPS, a nasza witryna – nie. W takiej sytuacji informacje o witrynie odsyłającej są czyszczone, a połączenie nie różni się niczym od wejścia bezpośredniego i jako takie zostanie przedstawione w Google Analytics. Jeżeli natomiast nasz serwis jest dostępny poprzez HTTPS, informacje nie są czyszczone i otrzymujemy pełne dane o witrynach odsyłających.

Trzecią korzyścią płynącą z przejścia na HTTPS (i w moim odczuciu także dopiero trzecią pod względem jej ważności) jest ogłoszony przez Google wpływ HTTPS’a na ranking witryny w wynikach wyszukiwania. Moim zdaniem to czynnik mało istotny, bo według oficjalnych informacji Google dotyczy mniej niż 1% światowych zapytań kierowanych właśnie do tej wyszukiwarki.

Na dodatek i z uwagi na to, że HTTPS wymaga zaawansowanych obliczeń, spowalnia szybkość działania strony, będącej również czynnikiem rankingowym Google. Wszystko to powoduje, że wpływ HTTPS’a na pozycje serwisu jest naprawdę znikomy. Nie oznacza to jednak, że możemy go ignorować, ponieważ nie mamy pewności, czy w przyszłości nie będzie miał większego znaczenia.

Kończąc rozważania dotyczące plusów przejścia na HTTPS’a, nie należy zapominać o tym, że poprawnie zaimplementowany HTTPS wzbudza zaufanie użytkowników, co może się przekładać na korzyści biznesowe.

Jakie są najważniejsze minusy przejścia na HTTPS?

Pierwszym z nich jest wspomniany już wyżej spadek prędkości działania strony i wzrost obciążenia serwera. To o tyle problematyczne, że szybkość działania strony jest czynnikiem branym pod uwagę przy ocenie serwisu przez Google i mającym wpływ na jego pozycje w wynikach wyszukiwania. Szczególnie dotyczy to urządzeń mobilnych, dla których szybkość działania strony jest często jednym z kluczowych czynników. W świetle komunikatu ogłoszonego przez Google 26 lutego, o którym więcej można przeczytać w artykule o  Stronach Mobile Friendly, nabiera on jeszcze większego znaczenia. W skrócie: dostosowanie serwisu do urządzeń mobilnych stanie się czynnikiem rankingowym w mobilnych wynikach wyszukiwania. Możemy zatem oczekiwać, że wzrośnie znaczenie szybkości działania strony (ale oczywiście mogę się mylić).

O spadku prędkości działania strony można jednak powiedzieć, że nie taki diabeł straszny, jak go malują. W dzisiejszych czasach, gdy mamy znacznie wydajniejsze komputery niż kiedyś, ilość koniecznych do wykonania obliczeń stała się mniejszym problemem. Oprócz wydajności procesorów, przychodzą nam z pomocą inne czynniki. Jednym z nich jest protokół SPDY, zaproponowany przez Google i będący rozszerzeniem TCP-IP protokołu, na którym zbudowany jest cały Internet.

SPDY, nie bez powodu należy czytać jako „SPeeDY”. Głównym celem przyświecającym jego powstaniu jest przyspieszenie działania protokołu TCP-IP, czyli de facto niemal wszystkich połączeń w internecie. SPDY jest przyjazny HTTPS’owi i potrafi znacznie przyspieszyć stronę. Warto zauważyć, że nie jest to technologia, która dopiero wejdzie do użycia – SPDY już działa: obsługuje go przeglądarka Google Chrome, Mozilla Firefox od wersji 11 (przy czym domyślnie włączony jest od wersji 13), Opera od wersji 12.10 oraz Internet Explorer 11, ale dopiero od Windows 8.1. W Windows 8.1 SPDY dostępne jest w całym systemie, co sprawia, że także inne aplikacje mogą go używać.

Należy także zwrócić uwagę na fakt, że SPDY stał się podstawą nowej wersji protokołu HTTP (HTTP 2.0) oficjalnie opublikowanej 17 lutego, która wg szacunków zastąpi obecną wersję HTTP 1.1 do końca roku. To jeszcze nie wszystkie dobre wiadomości. Stosując się do zaleceń opublikowanych na stronie istlsfastyet.com, można jeszcze bardziej przyspieszyć strony dostępne przez HTTPS.

Kolejnym problemem dotykającym szczególnie małe firmy i klientów indywidualnych są koszty certyfikatu, które mogą wynieść od kilkudziesięciu do nawet kilkuset złotych. Nie każdemu wiadome jest, że istnieje możliwość przejścia na HTTPS zupełnie za darmo (niestety opcja ta nie jest dostępna dla każdego klienta).

Dużą bolączkę mają serwisy zarabiające na reklamach AdSense, ponieważ po przejściu na HTTPS zarobki z programu AdSense mogą drastycznie spaść. Problem został opisany w tym artykule, polega na tym, że wyświetlane będą tylko te reklamy, które są dostosowane do HTTPS.

Jednym z największych problemów związanych z przejściem na HTTPS mogą być różne błędy związane z samym przenoszeniem witryny na HTTPS oraz występujące po nim. Przede wszystkim należy zadbać o to, aby:

  • Nie tworzyć duplikatów treści – tych samych stron dostępnych zarówno poprzez HTTPS, jak i HTTP, gdyż mogło by to zaszkodzić pozycjom serwisu.
  • Poprawić wszystkie odnośniki, ścieżki źródłowe zasobów takich jak np. pliki graficzne, dokumenty PDF, arkusze stylów, skrypty JavaScript i inne oraz linki kanoniczne, aby nie odwoływały się do starego protokołu HTTP.
  • Zadbać o to, aby serwis był dostępny dokładnie pod takim adresem, dla jakiego został podpisany certyfikat, dotyczy to także wersji domeny z „www” lub bez. Jest to bardzo ważne, ponieważ jeśli tego nie dopilnujemy, użytkownik przy próbie wejścia na stronę otrzyma komunikat z ostrzeżeniem o błędnym certyfikacie, co może go odstraszyć od wejścia na stronę, a na pewno wywoła negatywne wrażenie. Z tego samego powodu należy bezwzględnie pilnować daty ważności certyfikatu, aby nie dopuścić do sytuacji, gdy posiadany przez nas certyfikat wygaśnie.

niezaufane połączenie

Gdy strona będzie już działała poprzez HTTPS, warto przetestować poziom jej zabezpieczeń oraz konfigurację za pomocą polecanego przez Google narzędzia Qualys Lab.

O co należy zadbać przy przenoszeniu strony na HTTPS?

W pierwszej kolejności powinniśmy zdecydować jakiego rodzaju certyfikatu potrzebujemy. Mamy do wyboru certyfikaty dla jednej domeny, dla kilku domen oraz z symbolem wieloznacznym, pozwalającym na zastosowanie do dowolnej subdomeny naszej domeny głównej, np. subdomena.domena.pl, subdomena2.domena.pl itd. Do wyboru mamy także dwa rodzaje „jakości” certyfikatów: standardowe oraz o zwiększonym poziomie uprawomocnienia.

W przypadku przyznawania tych drugich, dokonuje się bardziej skrupulatnej weryfikacji, obejmującej przedstawienie odpowiednich dokumentów, które potwierdzają, że firma jest właścicielem domeny oraz np. upoważnienia do reprezentowania firmy przez pracownika. W nagrodę otrzymujemy certyfikat, dzięki któremu obok adresu naszej strony w przeglądarce internetowej pojawi się nie tylko ikona kłódki, ale również zielony pasek z nazwą firmy, dla której wystawiono certyfikat. Takie oznaczenia często możemy zaobserwować na stronach banków lub systemów płatności, czyli serwisów, którym szczególnie zależy na jak największym bezpieczeństwie danych przesyłanych pomiędzy nimi a użytkownikami.

zwykły certyfikat bezpieczeństwa
certyfikat zwiększonego bezpieczeństwa danych

Według informacji pracownika Google Johna Muellera, rodzaj certyfikatu obecnie nie ma znaczenia dla rankingu w wynikach wyszukiwania. Nie oznacza to jednak, że w przyszłości to, jakiego rodzaju certyfikatu używamy, nie będzie w różny sposób wpływało na pozycje w wynikach wyszukiwania.

Podczas wyboru certyfikatu mamy do dyspozycji certyfikaty o różnej długości klucza szyfrującego. Im dłuższy klucz, tym mocniejszy szyfr, którym zabezpieczone są przesyłane dane, ale też sam proces szyfrowania oraz deszyfrowania wymaga więcej mocy obliczeniowej. Nie wpływa to jednak znacząco na szybkość działania serwisu, dlatego najrozsądniej zdecydować się na najdłuższy 2048 bitowy klucz – taki, jaki jest zalecany przez Google.

Gdy już mamy odpowiedni certyfikat i przenosimy naszą witrynę na HTTPS należy przede wszystkim:

  • Zadbać o to, aby wszystkie adresy witryny zostały przekierowane na ich nowe odpowiedniki z protokołem HTTPS za pomocą przekierowania 301.

  • Poprawić wszystkie adresy zasobów znajdujących się w tej samej domenie na adresy względne, czyli np. /grafiki/obrazek.jpg zamiast https://domena.pl/grafiki/obrazek.jpg. Dzięki temu mamy pewność, że wszystkie zasoby będą pobierane poprzez HTTPS. Ważne jest aby nie mieszać ze sobą protokołów HTTP i HTTPS, ze względów bezpieczeństwa. Dodatkową korzyścią jest zmniejszenie liczby błędów podczas tworzenia serwisu, w momencie gdy znajduje się on jeszcze w środowisku produkcyjnym lub na lokalnym komputerze.

  • Koniecznie trzeba zadbać również o to, aby poprawić wszystkie odnośniki wewnętrzne w serwisie, w taki sposób, by nawigacja nie działała tylko dzięki przekierowaniom 301 ze starych adresów z protokołem HTTP. Nie można zapominać o linkach kanonicznych. Jeśli są w nich adresy bezwzględne z protokołem HTTP, należy je poprawić na HTTPS.

  • Google zaleca, aby w adresach URL z innych domen, używać względnego protokołu, czyli np. //domena.pl/dalsza-czesc-adresu.html albo tak poprawić linki, żeby bezpośrednio wskazywały zasoby w HTTPS.

  • Powinniśmy sprawdzić, czy roboty Google mają dostęp do serwisu działającego przez HTTPS oraz czy pozwalamy im indeksować te strony.

  • Pamiętajmy, że serwis działający poprzez HTTPS należy na nowo zweryfikować w Narzędziach dla Webmasterów, bo jest on w nich traktowany jako inny serwis niż ten, który był dostępny poprzez HTTP. Z tego samego powodu musimy na nowo przesłać plik zgłoszony wcześniej w narzędziu Disavow Tool.

  • Jeśli korzystamy ze starego kodu Google Analytics, powinniśmy sprawdzić, czy nie ma potrzeby jego aktualizacji, ponieważ może on działać błędnie poprzez HTTPS.

  • Jeżeli mamy możliwość, powinniśmy korzystać z mechanizmu HSTS (HTTP Strict Transport Security). Dzięki niemu w nagłówku HTTP przesyłana jest informacja dla przeglądarki, mówiąca o tym, że przez pewien czas, np. przez najbliższy rok, przy otwieraniu stron z naszej domeny, ma ona automatycznie używać protokołu HTTPS. Warto zwrócić uwagę na fakt, że protokół HTTPS zostanie użyty nawet wtedy, gdy użytkownik jawnie wpisze w pasku adresu protokół HTTP. Oprócz zwiększenia bezpieczeństwa serwisu, HSTS potrafi także przyspieszyć działanie strony, eliminując zbędne przekierowania z HTTP na HTTPS. Jest to także informacja dla Google, że w wynikach wyszukiwania ma podawać adresy z HTTPS.

Jeżeli korzystamy z HSTS, musimy bezwzględnie zadbać o poprawność i aktualność posiadanego certyfikatu. Jeżeli będzie on niepoprawny, użytkownik przy próbie wejścia na stronę nie otrzyma (tak, jak to zwykle ma miejsce) informacji o problemie i ryzyku związanym z wejściem na stronę oraz możliwości wejścia na nią, pomimo błędnego certyfikatu. Gdy korzystamy z HSTS otrzyma on informacje o błędzie i nie będzie miał możliwości wejścia na stronę. Stracimy zatem nawet tych nielicznych użytkowników, którzy zdecydowaliby się wejść na stronę pomimo ostrzeżenia, a w konsekwencji ruch spadnie do zera.

Warto zatem utworzyć nową mapę witryny dla adresów z HTTPS i wgrać ją w GWT, natomiast starą mapę pozostawić jeszcze przez około miesiąc, aż zaindeksują się przekierowania ze starych adresów na nowe. Dobrym pomysłem jest skorzystanie z dostępnej w Narzędziach dla Webmasterów Google opcji „pobierz i zrenderuj”. W ten sposób możemy sprawdzić, czy po przeniesieniu serwisu na HTTPS Google potrafi poprawnie zrenderować naszą stronę, czy może w wyniku braku dostępu do niektórych zasobów jest to niemożliwe.

zdjęcie: Marquinhos Schnaider

12
Komentarze
Dodaj własny
  1. 1

    Napisalbym jeszcze o not provided bo czy masz http czy https udział tego parametru jest bardzo duży. I nie da się odczytać słów kluczowych

  2. 2

    Dzięki za artykuł. Wydaje mi się, że w moim przypadku przejście na https to gra nie warta świeczki. (koszty, sporo pracy) a wynik pozycjonujący – niejasny (https a szybkość strony) Pozdrawiam.

  3. 3

    Bardzo dobry artykuł, wyczerpujący tematykę chyba w 100% 🙂

    Uzupełniłbym w części dotyczącej testowania/poprawności o narzędzia typu:
    https://www.ssllabs.com/ssltest
    http://rehmann.co/projects/heartbeat/
    https://pentest-tools.com/network-vulnerability-scanning/ssl-poodle-scanner

    Wspominałeś o darmowych certyfikatach, w artykule jest link do artykułu, w którym pojawia się
    https://startssl.com/ – może już zakładałeś darmowy certyfikat z tego serwisu?

  4. 4

    Fajne :-:-) 🙂 🙂 🙂 B-) :-)’

  5. 5

    Jak na dzisiaj wygląda sprawa z: „Dużą bolączkę mają serwisy zarabiające na reklamach AdSense, ponieważ po przejściu na HTTPS zarobki z programu AdSense mogą drastycznie spaść.” Nadal są odczuwalne spadki ??

    • 6
      Grzegorz Strzelczyk

      Niestety nie wiem jak to obecnie wygląda. Raczej rzadko zajmuję się reklamami AdSense, więc nie mam podglądu na to jak to się z czasem zmieniło. Mogę tylko podejrzewać, że wraz ze wzrostem ilości serwisów korzystających z https’a sytuacja powinna się poprawiać.

  6. 7

    Dziękuję za pomocny artykuł, właśnie odczułam ujemne skutki przejścia na https i szukam pomocnych rozwiązań. A co zrobić w przypadku, gdy po przejściu włączeniu SSL grafiki odwołują się do do adresów http?

    • 8
      Grzegorz Strzelczyk

      Należy poprawić ich adresy źródłowe tak, aby były pobierane przez https. Nie ma innego rozwiązania. Wszystkie zasoby wykorzystywane przez stronę muszą być ładowane przez https w przeciwnym razie pojawią się błędy. Zasoby statyczne, jak grafiki, będą wczytane ale przeglądarka wyświetli ostrzeżenie, że połączenie nie jest bezpieczne ponieważ nie wszystkie zasoby są wczytywane poprzez https. Gorzej z zasobami dynamicznymi jak skrypty JavaScript – te zostaną zablokowane i przeglądarka ich nie wczyta przez co część funkcjonalności strony nie będzie działać. Co gorsza nawet nie zostanie wyświetlone ostrzeżenie o takiej blokadzie, znajdziemy je dopiero w konsoli przeglądarki.
      Najlepiej skorzystać z narzędzi dla programistów oferowanych przez większość współczesnych przeglądarek (uruchamianych klawiszem F12). Tam w zakładce „sieć” znajdziemy wszystkie zasoby wczytywane przez stronę, trzeba odnaleźć te, które są wczytywane poprzez http i poprawić na https. W zakładce „konsola” znajdziemy natomiast informację o zablokowanych zasobach dynamicznych (ponieważ zostały zablokowane i przeglądarka ich przez to nie wczytała, nie będzie ich w zakładce „sieć”).

  7. 9

    czy przy wdrażaniu ssl dawać pobierz jako google i niech się dzieje / po tych wszystkich zaleceniach powyżej ? czy lepiej czekać 🙂 ?

    • 10
      Grzegorz Strzelczyk

      Jeżeli zrobiłeś poprawnie przekierowania 301 z http na https oraz podmieniłeś wszystkie odnośniki tak aby kierowały na https to Google ładnie sam sobie to wszystko szybko ogarnie. Jednak nie zaszkodzi pobrać jako Google w GSC i przesłać do indeksu aby jeszcze to przyspieszyć, nie jest to jednak konieczne. Konieczne jest zrobienie przekierowań i poprawienie odnośników wewnętrznych.

  8. 11

    To jest chore. Mam na stronie opis mojego pensjonatu i kilka zdjęć. Niech mi ktoś powie jak może mi zaszkodzić haker czy kto kolwiek inny? dlaczego zmusza się mnie i szykanuje azebym zapłacił i przeszedł na HTTTPS? Jkiez to dane może mi wykraść? Myśle że kluczową sprawą jest konieczność zapłaty za to co zawsze było za darmo. dla mnie to wałek i piramidalny skandal.

    • 12
      Grzegorz Strzelczyk

      To Google dyktuje zasady działania swojej wyszukiwarki a to nie Google’owi płacimy za certyfikaty SSL więc myślę, że to, że trzeba za nie zapłacić jest w tym wypadku bez znaczenia. Swoją drogą istnieje możliwość użycia darmowego certyfikatu SSL.

+
Napisz komentarz
Współadministratorami danych osobowych są: Semergy sp. z o.o. sp. k., Artefakt sp. z o.o. sp. k., Semahead sp. z o.o. sp. k., Grupa Tense Polska sp. z o.o. sp. k., Widzialni.pl sp. z o.o. sp. k. Sprzeciw wobec przetwarzania danych możesz złożyć w każdym momencie poprzez kontakt z Administratorem lub Doradcą Klienta, który skontaktował się z Tobą w celu przedstawienia zamówionej wyceny. Więcej informacji dotyczących przetwarzania danych osobowych znajduje się w polityce prywatności.
Pełna treść polityki prywatnościRegulamin strony