Przejście z HTTP na HTTPS: jak wdrożyć certyfikat bez utraty widoczności

Co zmienia przejście na HTTPS i dlaczego to więcej niż instalacja certyfikatu

Przejście na HTTPS zmienia sposób przesyłania danych między przeglądarką a serwerem na szyfrowany, a przy okazji zmienia początek każdego adresu w serwisie. Dla wyszukiwarki strona pod adresem zaczynającym się od http i ta sama strona pod adresem zaczynającym się od https to dwa osobne adresy z tą samą treścią, spośród których trzeba wybrać jeden.

Google opisuje to w dokumentacji o wyborze adresu kanonicznego: jego systemy wolą jako kanoniczne strony HTTPS niż równoważne strony HTTP, ale z wyjątkami. Pierwszeństwo przepada, gdy strona HTTPS ma nieprawidłowy certyfikat, gdy wczytuje niezabezpieczone zależności inne niż obrazy, gdy przekierowuje do strony HTTP albo gdy jej znacznik rel="canonical" prowadzi do wersji HTTP. Te cztery sytuacje to gotowa lista rzeczy, których należy uniknąć.

Jest też powód niezwiązany z wyszukiwarką. Przeglądarka Chrome, zgodnie z pomocą Google, oznacza połączenia symbolami w pasku adresu i przy stronach bez poprawnego szyfrowania pokazuje określenie „Niezabezpieczona”. Dla sklepu z Poznania czy kancelarii z Krakowa, która zbiera dane w formularzu kontaktowym, taki komunikat bywa droższy niż sama zmiana.

Co do wpływu na pozycje warto zachować spokój. Google ogłosiło, że HTTPS jest sygnałem rankingowym, ale w tym samym komunikacie zaznaczyło, że ma on niewielką wagę i znaczy mniej niż na przykład jakość treści. Szyfrowanie wdraża się więc dla bezpieczeństwa i zaufania, a celem prac nad SEO jest to, by przy tej okazji niczego nie stracić.

Jak przygotować serwis do zmiany protokołu

Przygotowanie polega na zapisaniu stanu wyjściowego: pełnej listy adresów, które mają dziś ruch i linki, oraz danych, z którymi będzie można porównać wyniki po zmianie. Bez tego po kilku tygodniach nie da się uczciwie odpowiedzieć na pytanie, czy coś zginęło.

Listę adresów najprościej zbudować z trzech miejsc. Pierwszym jest obecna mapa witryny. Drugim jest raport Skuteczność w Search Console, w którym na karcie Strony widać adresy mające wyświetlenia i kliknięcia, a przycisk eksportu pozwala zapisać je do pliku. Trzecim jest raport Linki w tym samym narzędziu, pokazujący podstrony, do których najczęściej prowadzą odnośniki z innych witryn. Te są szczególnie ważne, bo linków na cudzych stronach nikt nie poprawi i to przekierowanie musi przenieść ich wartość.

Warto przy tym spisać wszystkie warianty, pod którymi strona odpowiada. Serwis hydraulika z Łodzi potrafi otwierać się pod czterema adresami: z www i bez www, każdy w wersji http i https. Docelowy ma być jeden i tę decyzję trzeba podjąć przed zamówieniem certyfikatu. Jeśli przy okazji planowana jest zmiana domeny, serwera albo systemu, lepiej rozdzielić te prace w czasie albo potraktować całość jako pełną migrację strony z osobnym planem, bo przy kilku zmianach naraz trudno ustalić przyczynę ewentualnego spadku.

Pozostaje wybór terminu. Z naszej praktyki wynika, że zmianę najlepiej zaplanować na okres mniejszego ruchu i na dzień, w którym osoba odpowiedzialna za serwer jest dostępna także nazajutrz.

Instalacja certyfikatu: od czego zacząć i co sprawdzić przed przekierowaniem

Prace zaczyna się od uruchomienia wersji https obok starej, jeszcze bez przekierowań. Taką kolejność zaleca opracowanie web.dev o włączaniu protokołu HTTPS na serwerach: najpierw serwer ma poprawnie obsługiwać szyfrowane połączenia, a przekierowanie ruchu przychodzi w późniejszej fazie. Dzięki temu serwis można obejrzeć pod nowym adresem, zanim trafią tam użytkownicy i roboty.

Certyfikat wydaje urząd certyfikacji, a w większości firm hostingowych wystarczy włączyć go w panelu zarządzania domeną. Urzędy pobierają za to różne opłaty, istnieją też certyfikaty wydawane bez opłat. Dla widoczności w Google cena nie ma znaczenia, liczy się poprawność. Trzy rzeczy wymagają uwagi.

Pierwszą jest zakres nazw. Certyfikat musi pasować do pełnej nazwy hosta, pod którą działa witryna. Google wymienia jako błąd sytuację, w której witryna podaje certyfikat wystawiony dla innego wariantu hosta, na przykład dla subdomeny zamiast domeny głównej. Jeśli serwis ma odpowiadać z www i bez www, certyfikat powinien obejmować obie nazwy. Certyfikat wieloznaczny, zapisywany z gwiazdką, obejmuje subdomeny tylko jednego poziomu: według web.dev działa dla nazwy sklep.example.com, ale już nie dla nazwy test.sklep.example.com.

Drugą jest kompletność instalacji. Każda subdomena, pod którą firma coś publikuje, potrzebuje właściwego certyfikatu, także ta z blogiem, panelem klienta czy plikami graficznymi. Trzecią jest odnawianie. Certyfikat ma termin ważności i po jego upływie przeglądarka pokaże ostrzeżenie zamiast strony, dlatego automatyczne odnawianie należy włączyć od razu.

Przed włączeniem przekierowań warto ręcznie otworzyć pod adresem https stronę główną, kilka podstron ofertowych, wpis blogowy, formularz, koszyk i panel logowania. Jeśli przeglądarka pokazuje bezpieczne połączenie na każdej z nich, a formularze i płatności działają, można przejść dalej.

Przekierowania wszystkich adresów z HTTP na HTTPS

Każdy adres starej wersji powinien odpowiadać trwałym przekierowaniem 301 do tego samego adresu z https. To najważniejsza czynność całego wdrożenia. Google w dokumentacji o przekierowaniach wyjaśnia, że trwałe przekierowanie po stronie serwera jest dla procesu indeksowania sygnałem, iż to strona docelowa ma być kanoniczna i to ona ma pokazywać się w wynikach. Przekierowanie tymczasowe takiego sygnału nie daje, więc w wynikach może pozostać stary adres.

W tej samej dokumentacji kody 301 i 308 opisano jako stałe przeniesienie, a kody 302, 303 i 307 jako tymczasowe. Przekierowania oparte na znaczniku meta refresh lub skrypcie JavaScript Google zaleca tylko wtedy, gdy nie da się ustawić przekierowania na serwerze. Szerzej różnice między kodami omawiamy we wpisie o tym, kiedy użyć przekierowania 301, a kiedy 302.

Jedna reguła zamiast setek wpisów

Zmiana protokołu nie wymaga tabeli ze starymi i nowymi adresami, ponieważ ścieżki zostają takie same. Wystarczy jedna reguła na serwerze, która każde zapytanie przychodzące bez szyfrowania odsyła pod ten sam adres z https. Na serwerze Apache regułę umieszcza się w pliku .htaccess, na serwerze NGINX w konfiguracji hosta, a w wielu panelach hostingowych służy do tego osobny przełącznik wymuszający szyfrowanie.

RewriteEngine On
RewriteCond %{HTTPS} off [OR]
RewriteCond %{HTTP_HOST} !^www\. [NC]
RewriteRule ^(.*)$ https://www.example.com/$1 [R=301,L]

Reguła z przykładu załatwia jednocześnie dwie sprawy: protokół i wariant z www. To ważne, bo najczęstszą wadą wdrożeń jest łańcuch, w którym adres http bez www najpierw odsyła do http z www, a dopiero potem do https z www. Każdy dodatkowy przystanek wydłuża wczytywanie strony i mnoży miejsca, w których coś może się zepsuć. Docelowo każdy stary adres ma trafiać do właściwego jednym skokiem.

Jak sprawdzić, co naprawdę odpowiada serwer

Samo to, że przeglądarka pokazuje właściwą stronę, niczego nie dowodzi, bo nie widać w niej kodu odpowiedzi ani liczby skoków. Odpowiedź serwera można odczytać w narzędziach deweloperskich Chrome, na karcie Network, po wpisaniu starego adresu, albo jednym poleceniem w wierszu poleceń.

curl -I http://example.com/oferta/

HTTP/1.1 301 Moved Permanently
Location: https://www.example.com/oferta/

Kontrolę warto powtórzyć dla kilku typów adresów: strony głównej, podstrony oferty, wpisu, kategorii sklepu, adresu z parametrami po znaku zapytania, pliku PDF i obrazu. Częsty błąd polega na tym, że reguła działa dla stron, a pomija pliki albo gubi parametry. Drugi to odsyłanie wszystkich starych adresów na stronę główną: użytkownik, który kliknął link do konkretnej usługi, ląduje w innym miejscu, a wyszukiwarka nie dostaje informacji, który nowy adres zastępuje który stary.

Poprawa linków wewnętrznych i zasobów wczytywanych przez stronę

Po włączeniu przekierowań wszystkie odnośniki i pliki w obrębie serwisu powinny od razu wskazywać adresy z https, tak aby przekierowanie było potrzebne tylko gościom z zewnątrz. Google zaleca, by linki w witrynie prowadziły do adresu kanonicznego, a nie do duplikatu, bo spójne wskazywanie jednego adresu pomaga wyszukiwarce odczytać preferencje właściciela. Menu, stopka, okruszki i linki w treści wpisów nie mogą więc przechodzić przez stary protokół.

Web.dev podpowiada zapis, który uniezależnia serwis od protokołu: ścieżki względne zaczynające się od ukośnika. Zwraca też uwagę, że adresy trzeba poprawić nie tylko w treści stron, ale również w szablonach, kodzie JavaScript, regułach przekierowań i znacznikach link. W praktyce oznacza to przegląd czterech miejsc: ustawień systemu, bazy danych z treścią, plików motywu oraz skryptów zewnętrznych, takich jak czat czy mapa.

W WordPressie adres serwisu zapisany jest w kokpicie, w menu Ustawienia, na ekranie Ogólne, w polach „Adres WordPressa (URL)” i „Adres witryny (URL)”. Oba powinny zaczynać się od https. Dokumentacja WordPressa opisuje ponadto stałą FORCE_SSL_ADMIN w pliku wp-config.php, która wymusza szyfrowanie logowania i panelu, oraz przypadek serwisu działającego za serwerem pośredniczącym, w którym bez dodatkowej konfiguracji powstaje pętla przekierowań. Starsze wpisy często mają obrazy i linki wstawione z pełnym adresem http, dlatego potrzebna jest zamiana w bazie danych, wykonana po zrobieniu kopii zapasowej. W WooCommerce, PrestaShop i innych systemach sklepowych zasada jest ta sama.

Treść mieszana, czyli stare adresy ukryte w kodzie

Treść mieszana to sytuacja, w której strona otwarta przez https wczytuje część plików przez http. Według opracowania web.dev o naprawianiu treści mieszanej Chrome zgłasza takie zasoby w konsoli narzędzi deweloperskich: bierne przeglądarka próbuje sama pobrać przez https, a aktywne, takie jak skrypty, blokuje. Zablokowany skrypt oznacza na przykład niedziałający formularz, mapę albo galerię.

Konsola pokazuje ostrzeżenia tylko dla aktualnie otwartej strony, więc każdy typ podstrony trzeba otworzyć osobno. Drugim sposobem jest wyszukanie ciągu http:// w kodzie źródłowym i w szablonach. Zwykły odnośnik do innej strony zapisany z http nie jest treścią mieszaną, bo przeglądarka po prostu przechodzi pod inny adres. Jeśli zewnętrzny plik nie jest dostępny przez https, web.dev podaje trzy wyjścia: pobrać go z innego hosta, umieścić na własnym serwerze, o ile pozwala na to licencja, albo z niego zrezygnować.

Jeśli chcą Państwo zamówić SEO techniczne, zachęcamy do kontaktu: tel. 222 500 844 lub mailowo: biuro@pozycjonowaniestron.pl

Adresy kanoniczne, mapa witryny i pozostałe sygnały dla wyszukiwarki

Wszystkie miejsca, w których serwis sam deklaruje swoje adresy, muszą po zmianie podawać wersję https. Google zestawia metody wskazywania adresu kanonicznego według siły: przekierowania i adnotacje rel="canonical" są sygnałami wyraźnymi, obecność adresu w mapie witryny sygnałem słabszym, a wszystkie się sumują. Zaleca też, by nie wskazywać różnych adresów różnymi metodami. Serwis, w którym przekierowanie prowadzi na https, a znacznik kanoniczny nadal podaje http, wysyła dwie sprzeczne informacje naraz.

Znacznik rel="canonical"

Znacznik kanoniczny każdej podstrony powinien zawierać jej pełny adres z https. Systemy zarządzania treścią zwykle budują go z adresu zapisanego w ustawieniach, więc poprawia się sam, ale warto to potwierdzić w kodzie źródłowym, bo adres bywa wpisany na stałe w szablonie albo w ustawieniach wtyczki. Zasady działania tego znacznika opisujemy we wpisie o poprawnym wdrożeniu adresu kanonicznego.

<link rel="canonical" href="https://www.example.com/oferta/" />

Mapa witryny

Mapa witryny powinna zawierać wyłącznie adresy z https. Dokumentacja Google o przygotowywaniu i przesyłaniu mapy witryny wymaga pełnych, bezwzględnych adresów i przypomina, że Google próbuje indeksować dokładnie te adresy, które w mapie podano. Podawanie w mapie lub w adnotacjach hreflang wersji HTTP Google wymienia wśród praktyk, które mogą doprowadzić do błędnego uznania strony HTTP za kanoniczną. O zawartości takiego pliku piszemy we wpisie o mapie witryny XML.

Plik robots.txt, hreflang i dane strukturalne

Plik robots.txt wersji https musi być dostępny i nie może blokować robotów. Google już przy ogłaszaniu sygnału HTTPS prosiło, by nie blokować indeksowania witryny HTTPS w tym pliku. Wiersz Sitemap w pliku robots.txt powinien podawać nowy adres mapy. Przegląd obejmuje także adnotacje hreflang w serwisach wielojęzycznych, adresy w danych strukturalnych oraz adres strony w Profilu Firmy w Google, w kampaniach Google Ads i w profilach społecznościowych.

Search Console po zmianie: nowa usługa, mapa witryny i raporty

W Search Console potrzebna jest usługa obejmująca adresy z https, bo to w niej pojawią się dane po zmianie. Narzędzie zna dwa rodzaje usług. Usługa domeny, zapisywana samą nazwą domeny, zawiera według pomocy Search Console dane wszystkich protokołów i subdomen. Usługa z prefiksem adresu URL obejmuje tylko adresy zaczynające się dokładnie od wpisanego ciągu, więc wersja z http i wersja z https to dwie różne usługi.

Jeśli firma ma już usługę domeny, niczego nie trzeba dodawać: w raporcie Skuteczność będzie widać, jak adresy z https zastępują stare. Jeśli do tej pory istniała tylko usługa z prefiksem http, należy rozwinąć listę usług w lewym górnym rogu, wybrać polecenie dodania usługi i wpisać pełny adres z https w polu prefiksu albo samą domenę w polu domeny. Starej usługi nie należy usuwać, ponieważ zawiera historię potrzebną do porównań.

Usługę domeny można zweryfikować wyłącznie przez dodanie rekordu DNS u dostawcy domeny. Usługę z prefiksem da się potwierdzić także plikiem HTML lub znacznikiem w kodzie strony. Pomoc Google zaznacza, że przy weryfikacji plikiem Search Console podąża za przekierowaniami w obrębie tej samej domeny, w tym za przekierowaniem do nowego protokołu.

Przesłanie mapy i kontrola pojedynczych adresów

Nową mapę przesyła się w raporcie Mapy witryn, w sekcji Indeksowanie w menu po lewej stronie: w polu dodawania nowej mapy wpisuje się jej adres i zatwierdza przyciskiem przesyłania. Następnie warto wkleić kilka najważniejszych adresów z https w pole sprawdzania adresu URL u góry ekranu. Wynik pokazuje, czy strona jest w indeksie, jaki adres kanoniczny zadeklarował właściciel i jaki wybrał Google.

Raport HTTPS i raport Strony

Google udostępnia w Search Console raport HTTPS, do którego odsyła w dokumentacji o jakości strony jako do miejsca, gdzie można sprawdzić, czy witryna wyświetla bezpieczne strony i co poprawić, jeśli tak nie jest. Drugim miejscem jest raport Strony w sekcji Indeksowanie. Stare adresy powinny w nim stopniowo trafiać do grupy stron z przekierowaniem, co jest stanem prawidłowym, a nie błędem. Niepokoić powinien wzrost liczby błędów serwera albo adresów nieznalezionych. Statusy tego raportu omawiamy we wpisie o tym, dlaczego Google nie indeksuje strony.

Czego spodziewać się po zmianie protokołu

Po poprawnie wykonanym przejściu należy spodziewać się okresu przejściowego, w którym Google stopniowo odwiedza stare adresy, odczytuje przekierowania i podmienia je w indeksie na wersje z https. Nie dzieje się to jednego dnia, ponieważ robot wraca do poszczególnych podstron w różnym tempie. Przez pewien czas w wynikach mogą więc występować obok siebie adresy obu wersji.

Z naszej praktyki wynika, że w tym okresie zdarzają się niewielkie wahania pozycji i liczby wyświetleń, które uspokajają się wraz z postępem ponownego indeksowania. Nie podajemy tu liczby dni, bo zależy ona od wielkości serwisu i częstotliwości odwiedzin robota. Mały serwis usługowy przechodzi tę zmianę szybciej niż sklep z dziesiątkami tysięcy produktów.

Warto też wiedzieć, czego nie należy oczekiwać. Samo szyfrowanie nie podniesie wyraźnie pozycji, bo Google od początku opisywało ten sygnał jako słaby. Korzyść jest inna: znika ostrzeżenie w przeglądarce, a formularze i płatności są chronione.

Zmiana wpływa także na pomiar ruchu. W Search Console dane starej i nowej wersji rozdzielą się między dwie usługi z prefiksem, dlatego porównania najlepiej prowadzić w usłudze domeny albo sumować obie. Datę wdrożenia dobrze jest zapisać w notatkach, żeby po kwartale nie zastanawiać się, skąd wziął się uskok na wykresie. Przy większych serwisach pomaga w tym uporządkowana analityka i raportowanie SEO.

Jak sprawdzić, czy nic nie zostało po starej wersji

Kontrola po wdrożeniu polega na przejściu po wszystkich miejscach, w których mógł przetrwać adres z http, i potwierdzeniu, że żadna strona nie odpowiada już bez szyfrowania kodem 200. Najlepiej wykonać ją dwa razy: w dniu zmiany oraz po kilku tygodniach, gdy w Search Console pojawią się dane z ponownego indeksowania.

• Cztery warianty strony głównej (z www i bez, z http i https) kończą się pod jednym adresem, a trzy pozostałe odpowiadają kodem 301 w jednym skoku.
• Losowo wybrane podstrony, pliki PDF, obrazy i adresy z parametrami przekierowują do swoich odpowiedników, a nie na stronę główną.
• W kodzie źródłowym kilku typów podstron nie występuje ciąg http:// z własną domeną.
• Konsola w narzędziach Chrome nie pokazuje ostrzeżeń o treści mieszanej na stronie głównej, w ofercie, we wpisie, w koszyku i w formularzu.
• Znaczniki kanoniczne, adnotacje hreflang i dane strukturalne zawierają adresy z https.
• Mapa witryny zawiera wyłącznie adresy z https i została przesłana w Search Console.
• Plik robots.txt w wersji https otwiera się, nie blokuje serwisu i podaje nowy adres mapy.
• Formularze, logowanie, koszyk i płatności działają pod nowym adresem.
• Certyfikat obejmuje wszystkie używane nazwy hosta i ma włączone automatyczne odnawianie.

Przy większej liczbie podstron ręczne przeglądanie nie wystarczy. Stosuje się wtedy program, który przechodzi po serwisie tak jak robot i wypisuje każdy odnośnik, obraz i skrypt prowadzący do adresu z http oraz każdy łańcuch przekierowań.

HSTS jako ostatnia czynność, nie pierwsza

HSTS (HTTP Strict Transport Security) to nagłówek odpowiedzi, którym serwer informuje przeglądarkę, że z tą witryną należy zawsze łączyć się przez https, także wtedy, gdy ktoś wpisze adres z http. Google wymienia wdrożenie HSTS obok przekierowań i znacznika kanonicznego jako sposób na to, by jego systemy zawsze wybierały wersję HTTPS. Web.dev zaleca jednak ostrożność: przeglądarka, która zapamiętała tę zasadę, nie połączy się z witryną, gdy w konfiguracji pojawi się błąd, na przykład wygaśnie certyfikat. Dlatego nagłówek włącza się dopiero wtedy, gdy serwis działa stabilnie, zaczynając od krótkiego czasu obowiązywania, podawanego w sekundach w parametrze max-age, i wydłużając go stopniowo.

Strict-Transport-Security: max-age=300

Typowe pomyłki i sytuacje, w których warto poprosić o pomoc

Najczęściej spotykamy pięć błędów. Certyfikat obejmuje tylko jeden wariant nazwy, przez co adres bez www kończy się ostrzeżeniem przeglądarki, zanim przekierowanie zdąży zadziałać. Przekierowanie ma kod 302, bo tak domyślnie ustawiła je wtyczka lub panel. Stara mapa witryny z adresami http pozostaje zgłoszona w Search Console. Na wersji produkcyjnej zostaje blokada robotów z okresu testów. Wreszcie po kilku miesiącach certyfikat wygasa, ponieważ odnawianie nie było automatyczne.

Samodzielne wdrożenie jest realne w małym serwisie firmowym na popularnym systemie. Pomoc specjalisty przydaje się, gdy serwis ma tysiące adresów, kilka subdomen lub wersji językowych, niestandardowe reguły na serwerze albo gdy zmiana protokołu zbiega się ze zmianą domeny czy serwera, co opisujemy przy usłudze migracji domeny i hostingu. Pomoc jest też potrzebna wtedy, gdy po kilku tygodniach ruch nie wraca do poziomu sprzed zmiany. Punktem wyjścia jest wówczas audyt SEO, a dalsze prace prowadzimy w ramach SEO technicznego.

Jeśli chcą Państwo zamówić SEO techniczne, zachęcamy do kontaktu: tel. 222 500 844 lub mailowo: biuro@pozycjonowaniestron.pl