Jak sprawdzić przekierowanie HTTP do HTTPS?

Poprawna konfiguracja HTTPS nie kończy się na wyświetleniu kłódki. Trzeba sprawdzić certyfikat, każdy wariant hosta, status przekierowania, końcowy adres, zasoby strony i spójność sygnałów SEO.

Dlaczego przekierowanie HTTP do HTTPS jest ważne?

Bez przekierowania ta sama treść może być dostępna pod wersją HTTP i HTTPS. Użytkownicy korzystający ze starych linków mogą trafić na niezabezpieczone połączenie, a wyszukiwarka otrzymuje kilka wersji adresu. Stałe przekierowanie kieruje ruch do preferowanego URL-a i ogranicza duplikację.

HTTPS szyfruje transmisję, ale nie gwarantuje bezpieczeństwa całej aplikacji. Nie wykrywa luk w kodzie, słabych haseł, błędnych uprawnień ani złośliwych wtyczek.

Sprawdź wszystkie warianty domeny

Nie testuj wyłącznie strony głównej wpisanej w przeglądarce. Dla każdego ważnego adresu sprawdź co najmniej:

http://example.pl/
http://www.example.pl/
https://example.pl/
https://www.example.pl/

Wybierz jedną końcową wersję hosta. Pozostałe powinny prowadzić bezpośrednio do niej. Certyfikat musi obejmować także wariant, który przyjmuje połączenie przed przekierowaniem.

Jaki status powinno zwracać przekierowanie?

Dla stałego przejścia z HTTP na HTTPS użyj serwerowego kodu 301 albo 308. Google traktuje oba jako stałe przekierowania. Kod 302 lub 307 zostaw dla rzeczywiście tymczasowej sytuacji.

Status	Znaczenie	Zastosowanie
301	Trwałe przeniesienie	Najczęstszy wybór dla HTTP → HTTPS.
308	Trwałe przeniesienie z zachowaniem metody	Możliwy odpowiednik 301.
302 / 307	Przeniesienie tymczasowe	Tylko gdy stary URL ma wrócić.
200	Treść dostępna bezpośrednio	Końcowy adres HTTPS.

Google zaleca stałe przekierowania serwerowe dla trwałych zmian adresów. Zobacz dokumentację przekierowań i Google Search.

Jak wykonać test?

Przeglądarka

Wpisz pełny adres zaczynający się od http://, a następnie sprawdź końcowy URL. Sama zmiana paska adresu nie pokazuje jednak liczby kroków ani statusów.

curl

Nagłówki pierwszej odpowiedzi sprawdzisz poleceniem:

curl -I http://example.pl/podstrona

Pełny łańcuch można zobaczyć przez:

curl -IL http://example.pl/podstrona

Oczekiwany przebieg to pojedynczy status 301/308 i końcowa odpowiedź 200 pod właściwym adresem HTTPS.

Narzędzia deweloperskie

W zakładce Network sprawdź dokument główny i wszystkie zasoby. Wyczyść cache albo użyj trybu prywatnego, ponieważ przeglądarka może pamiętać wcześniejsze przekierowanie lub HSTS.

Łańcuchy i pętle przekierowań

Każdy dodatkowy krok zwiększa czas dotarcia do treści i komplikuje diagnozę. Zamiast:

http://example.pl → http://www.example.pl → https://www.example.pl → https://example.pl

ustaw bezpośrednie przejście każdego wariantu do https://example.pl. Pętla występuje, gdy reguły odsyłają adresy między sobą i użytkownik nigdy nie otrzymuje strony 200.

Nie zapomnij o podstronach i metodach

Reguła powinna zachować ścieżkę i parametry, np. http://example.pl/oferta?a=1 ma prowadzić do https://example.pl/oferta?a=1, o ile parametry są potrzebne. Sprawdź kilka głębokich URL-i, obrazy i pliki PDF. Formularze oraz endpointy płatności wymagają dodatkowej ostrożności, ponieważ błędna zmiana metody może przerwać żądanie.

Mixed content

Strona HTTPS może nadal odwoływać się do skryptów, stylów, fontów, obrazów lub ramek przez HTTP. To mixed content. Część zasobów przeglądarka zablokuje, a część może automatycznie próbować podnieść do HTTPS. Popraw źródłowe adresy zamiast polegać wyłącznie na zachowaniu przeglądarki.

Przeszukaj HTML, CSS i bazę treści pod kątem http://.
Sprawdź konsolę przeglądarki.
Zweryfikuj zewnętrzne fonty, analitykę, mapy i widgety.
Nie zmieniaj adresu na HTTPS, jeżeli zewnętrzny host go nie obsługuje — zastąp zasób.

Ryzyko opisuje dokumentacja MDN dotycząca mixed content.

HSTS — dopiero po poprawnym HTTPS

Nagłówek Strict-Transport-Security informuje przeglądarkę, aby kolejne połączenia wykonywała bezpośrednio przez HTTPS. Włącz go dopiero po potwierdzeniu działania certyfikatu i HTTPS na całej domenie. Parametr includeSubDomains obejmuje wszystkie subdomeny, a preload jest decyzją trudniejszą do cofnięcia.

Przed długim max-age rozpocznij od krótszego okresu i sprawdź wszystkie usługi. Szczegóły mechanizmu opisuje dokumentacja TLS i HSTS.

Spójność sygnałów SEO po migracji

Canonical wskazuje adres HTTPS.
Sitemap zawiera wyłącznie URL-e HTTPS.
Linki wewnętrzne nie przechodzą przez HTTP.
Open Graph i dane strukturalne używają HTTPS.
Robots.txt i jego dyrektywa Sitemap działają pod HTTPS.
Stare adresy HTTP nie zwracają treści 200.

Najczęstsze błędy

Błąd	Naprawa
HTTP odpowiada 200	Dodaj stałe przekierowanie serwerowe.
HTTPS przekierowuje z powrotem do HTTP	Popraw kolejność i warunki reguł.
Certyfikat nie obejmuje www	Rozszerz certyfikat przed przekierowaniem wariantu.
Wiele kroków do adresu końcowego	Kieruj każdy wariant bezpośrednio do preferowanego URL-a.
Zasoby HTTP na stronie HTTPS	Zmień adresy źródłowe i wyczyść cache.
HSTS włączony zbyt wcześnie	Najpierw napraw i przetestuj cały zakres HTTPS.

Końcowa checklista HTTP → HTTPS

Certyfikat jest ważny i obejmuje wszystkie przyjmowane hosty.
Każdy wariant HTTP wykonuje jeden 301/308 do wersji docelowej.
Końcowy adres odpowiada 200.
Ścieżki oraz potrzebne parametry są zachowane.
Nie występują pętle ani przekierowanie HTTPS do HTTP.
Brak mixed content.
Canonical, sitemap i linki wskazują HTTPS.
HSTS został włączony świadomie po testach.
Sprawdzono stronę główną, podstrony, formularze i płatności.
Test powtórzono po publikacji i wyczyszczeniu cache.

Źródła i dalsza lektura

Poradnik opiera się na praktyce technicznej analizatora oraz oficjalnej dokumentacji Google Search Central wskazanej w treści.