HSTS: HTTP Strict Transport Security dla SEO

TL;DR — HSTS to krótka instrukcja, którą Twój serwer wysyła przeglądarkom, mówiąca “zawsze używaj HTTPS dla mojej witryny — nigdy zwykłego HTTP.” Zamyka ona małą lukę w zabezpieczeniach, którą pozostawia normalne przekierowanie HTTP→HTTPS, i nie szkodzi SEO. Ale jest celowo rygorystyczna: gdy już jest włączona, uszkodzony certyfikat powoduje awarię witryny bez możliwości ominięcia ostrzeżenia przez odwiedzających. Włącz ją tylko wtedy, gdy Twoja konfiguracja HTTPS jest naprawdę solidna.

Czym jest HSTS

Wiesz już, że powinieneś korzystać z HTTPS — zaszyfrowanej, wersji Twojej witryny z kłódką. Normalnym sposobem wymuszenia tego jest przekierowanie: gdy ktoś wpisze http://yoursite.com, Twój serwer wysyła mu przekierowanie 301 na https://yoursite.com. To działa, ale jest niewielka luka. To pierwsze żądanie — to przed uruchomieniem przekierowania — nadal jest wysyłane przez niezabezpieczony HTTP. Atakujący w tej samej sieci Wi-Fi może zaatakować w tym oknie.

HSTS — HTTP Strict Transport Security — zamyka tę lukę. To krótka instrukcja (nagłówek), którą Twój serwer dodaje do swoich odpowiedzi — ale tylko tych obsługiwanych przez naprawdę bezpieczne połączenie; ten sam nagłówek wysłany przez zwykły HTTP jest ignorowany, ponieważ atakujący mógłby go w przeciwnym razie wstrzyknąć lub usunąć — która mówi tej jednej przeglądarce: przez następne ileś miesięcy nawet nie próbuj HTTP dla tej witryny — przejdź od razu do HTTPS. To polityka, której każda przeglądarka uczy się i przechowuje dla siebie, a nie coś, co zmienia Twój serwer. Gdy przeglądarka już to zobaczy, automatycznie ulepsza linki http:// do https://, zanim cokolwiek opuści urządzenie. Dowód potwierdzający to twierdzenie After receiving HSTS, a browser upgrades future HTTP attempts to HTTPS before sending the request. Zakres: MDN documents user-agent enforcement after the header has been learned; first-visit protection requires preload or a prior secure visit. Poziom ufności: wysoki · Zweryfikowano: 2026-07-14 MDN: Strict-Transport-Security header

Czy HSTS pomaga czy szkodzi SEO?

Ani jedno, ani drugie, bezpośrednio. HSTS to funkcja bezpieczeństwa i zaufania, a nie dźwignia rankingowa. Nie przesunie Cię wyżej w wynikach — ale zrobione dobrze nie zaszkodzi Ci też. Jedyną rzeczą, którą należy zrozumieć, jest to, że HSTS nie zastępuje Twoich przekierowań. Nadal potrzebujesz prawdziwych przekierowań 301 po stronie serwera z HTTP na HTTPS, ponieważ to właśnie to widzą i używają Google i Bing. HSTS działa wewnątrz przeglądarki dla prawdziwych ludzkich odwiedzających; roboty indeksujące nie polegają na nim. Zachowaj oba.

Jedno duże ostrzeżenie

HSTS jest celowo bezlitosny. Gdy przeglądarka “nauczy się”, że Twoja witryna jest tylko HTTPS, odmówi załadowania witryny w ogóle, jeśli Twój certyfikat kiedykolwiek wygaśnie lub zostanie źle skonfigurowany — bez przycisku “kontynuuj mimo to”. To jest cały sens (zapobiega oszustom nakłaniającym ludzi do fałszywej wersji HTTP), ale oznacza, że wygasły certyfikat zmienia się z “irytującego ostrzeżenia” na “witryna niedostępna dla każdego, kto odwiedził ją wcześniej.”

Istnieje również wersja z dodatkowymi funkcjami o nazwie preload, która wbudowuje Twoją domenę w samą przeglądarkę. To świetne, ale późniejsze zejście z listy preload jest powolne i bolesne — pomyśl o miesiącach. Więc preload to drzwi w jedną stronę: przejdź przez nie tylko wtedy, gdy jesteś pewien. Dowód potwierdzający to twierdzenie HSTS preload requires at least a one-year max-age, includeSubDomains, and preload; removal can take months to reach users. Zakres: The Chromium preload service documents submission and removal behavior; requirements can change and should be rechecked before submission. Poziom ufności: wysoki · Zweryfikowano: 2026-07-17 Chromium: HSTS Preload List Submission

Chcesz składnię nagłówka, wewnętrzne przekierowanie przeglądarki, którego roboty indeksujące nigdy nie widzą, wymagania preload i prawdziwe scenariusze blokady? Przełącz się na kartę Zaawansowane.

TL;DR — HSTS to nagłówek odpowiedzi Strict-Transport-Security, honorowany tylko wtedy, gdy przeglądarka otrzyma go przez bezpieczne połączenie, i przechowywany per-klient jako przyszła polityka dla tego hosta. Zamyka on „problem pierwszego żądania”, który sam 301 pozostawia otwarty: początkowe żądanie HTTP od nowego odwiedzającego jest niebezpieczne, dopóki przekierowanie nie zadziała, a to jest okno, którego chce atakujący przeprowadzający SSL-stripping. Trzy dyrektywy: max-age (wymagana, sekundy), includeSubDomains, preload. Gdy przeglądarka egzekwuje HSTS, przepisuje URI na HTTPS wewnętrznie, zanim jakiekolwiek żądanie dotrze do serwera — RFC 6797 nie nakazuje konkretnego kodu statusu dla tego przepisania, chociaż narzędzia często pokazują go jako 307 — więc Twoje 301 po stronie serwera są nadal obowiązkowe dla wyszukiwarek i przekazywania link equity; HSTS jest na nich, nie zamiast nich. Preload wbudowuje Twoją domenę w przeglądarkę przez hstspreload.org (wymaga max-age ≥ 31536000, includeSubDomains i preload) i jest prawie nieodwracalny — usunięcie to osobne zgłoszenie, które dociera do użytkowników po miesiącach. A HSTS jest zaprojektowany tak, aby twardo kończyć się błędem przy każdym problemie z certyfikatem, więc włączaj go tylko wtedy, gdy HTTPS jest solidne na każdym subdomenie.

Centrum HTTPS przedstawia HSTS jako ochronę na poziomie przeglądarki, która leży na Twoich 301. Ta strona to szczegółowe omówienie: dokładna składnia nagłówka, wewnętrzne przekierowanie, które myli specjalistów SEO, prawie nieodwracalność listy preload, oraz rzeczywiste sposoby, w jakie HSTS blokuje użytkownikom dostęp.

Problem, który HSTS faktycznie rozwiązuje: pierwsze żądanie

Wyobraź sobie poprawnie zmigrowaną witrynę. Każdy adres URL http:// przekierowuje 301 na swój odpowiednik https://, certyfikat jest ważny, kanoniki wskazują na HTTPS. Wygląda na szczelne. Nie jest, całkiem.

Gdy zupełnie nowy odwiedzający wpisze yoursite.com (bez schematu) lub kliknie stary link http://yoursite.com, pierwsze żądanie przeglądarki wychodzi przez zwykły HTTP. Twój serwer odpowiada 301, a każde kolejne żądanie jest już bezpieczne. Ale ta jedna początkowa wymiana danych odbyła się jawnie — i to jest dokładnie okno, którego chce atakujący SSL-stripping w tej samej sieci. Przechwytuje żądanie HTTP, utrzymuje ofiarę na HTTP, podczas gdy sam pośredniczy w HTTPS do Twojego serwera, i czyta lub przepisuje wszystko.

HSTS eliminuje to okno dla każdego, kto odwiedził witrynę wcześniej. web.dev mówi wprost o mechanizmie: “use Strict Transport Security to tell clients they should always connect to your server using HTTPS, even when following an http:// reference. This defeats attacks like SSL Stripping, and avoids the round-trip cost of the 301 redirect.” (tłumaczenie) „użyj Strict Transport Security, aby poinformować klientów, że powinni zawsze łączyć się z serwerem przez HTTPS, nawet gdy korzystają z odnośnika http://. Udaremnia to ataki SSL Stripping i pozwala uniknąć dodatkowego przebiegu przekierowania 301”. (tłumaczenie) „użyj Strict Transport Security, aby powiedzieć klientom, że powinni zawsze łączyć się z Twoim serwerem przez HTTPS, nawet gdy podążają za odwołaniem http://. To pokonuje ataki takie jak SSL Stripping i unika kosztu dodatkowej podróży w obie strony związanego z przekierowaniem 301.” (web.dev). To ostatnie zdanie ma znaczenie również dla wydajności: powracająca przeglądarka pomija całkowicie podróż HTTP→HTTPS w obie strony. Dowód potwierdzający to twierdzenie After receiving HSTS, a browser upgrades future HTTP attempts to HTTPS before sending the request. Zakres: MDN documents user-agent enforcement after the header has been learned; first-visit protection requires preload or a prior secure visit. Poziom ufności: wysoki · Zweryfikowano: 2026-07-14 MDN: Strict-Transport-Security header

Warto precyzyjnie określić dwa warunki brzegowe. Po pierwsze, HSTS to przechowywana, per-klient polityka — żyje w stanie tej jednej przeglądarki dla tego hosta, poznana z nagłówka dostarczonego przez bezpieczne połączenie; ten sam nagłówek wysłany w odpowiedzi HTTP jest całkowicie ignorowany (atakujący, który mógłby wstrzykiwać lub usuwać nagłówki na zwykłym HTTP, mógłby w przeciwnym razie go zneutralizować), a klient, który nigdy go nie otrzymał — świeża instalacja, inna przeglądarka, robot indeksujący — nie ma polityki do egzekwowania. Po drugie, przepisanie jest świadome schematu i portu: niejawne żądanie na porcie 80 staje się niejawnym żądaniem na porcie 443, ale jeśli oryginalny URI wskazywał jawny port inny niż domyślny, przeglądarka zachowuje ten sam numer portu i po prostu kontaktuje się z nim przez HTTPS.

Składnia nagłówka

HSTS to jeden nagłówek odpowiedzi z maksymalnie trzema dyrektywami. Według MDN, formy są następujące:

Strict-Transport-Security: max-age=31536000
Strict-Transport-Security: max-age=31536000; includeSubDomains
Strict-Transport-Security: max-age=63072000; includeSubDomains; preload

• max-age=<seconds> — wymagane. “Czas, w sekundach, przez który przeglądarka powinna pamiętać, że host może być dostępny tylko przez HTTPS” (MDN). 31536000 to jeden rok; 63072000 to dwa. Zegar resetuje się przy każdej odpowiedzi zawierającej nagłówek, więc aktywna witryna stale odnawia swoją politykę. Jest to stan względny, per-klient: samo usunięcie nagłówka nie powoduje natychmiastowego wyczyszczenia — przeglądarka, która już poznała politykę, nadal ją egzekwuje, dopóki jej zapisany max-age nie wygaśnie. Aby wyłączyć HSTS dla klientów, którzy już ją poznali, musisz aktywnie serwować max-age=0 w bezpiecznej odpowiedzi; przeglądarka wtedy zapomina politykę przy następnej bezpiecznej wizycie. (max-age=0 czyści nauczoną politykę tylko — nie usuwa domeny z osobnej listy preload.)
• includeSubDomains — opcjonalne. “Jeśli ta dyrektywa jest określona, polityka HSTS stosuje się również do wszystkich subdomen domeny hosta” (MDN). Potężne i niebezpieczne w równym stopniu — patrz scenariusze blokady poniżej.
• preload — opcjonalne. Flaga sygnalizująca Twoją intencję umieszczenia na liście preload przeglądarki. Sama w sobie nic nie robi; jest warunkiem wstępnym do zgłoszenia na hstspreload.org. Dowód potwierdzający to twierdzenie HSTS preload requires at least a one-year max-age, includeSubDomains, and preload; removal can take months to reach users. Zakres: The Chromium preload service documents submission and removal behavior; requirements can change and should be rechecked before submission. Poziom ufności: wysoki · Zweryfikowano: 2026-07-17 Chromium: HSTS Preload List Submission

Zachowanie, ponownie z MDN: “Przed załadowaniem adresu URL http przeglądarka sprawdza nazwę domeny na swojej liście hostów HSTS. Jeśli nazwa domeny jest dopasowaniem bez rozróżniania wielkości liter do hosta HSTS lub jest subdomeną takiego, który określił includeSubDomains, przeglądarka zastępuje schemat URL na https.”

Wewnętrzne ulepszenie, którego crawlerzy nigdy nie widzą (to jest sedno SEO)

Oto najczęściej źle rozumiana rzecz dotycząca HSTS i powód, dla którego nie może ona zastąpić Twoich przekierowań.

Gdy przeglądarka ulepsza żądanie http:// w ramach HSTS, przepisuje URI na HTTPS wewnętrznie, przed wykonaniem jakiegokolwiek żądania sieciowego — RFC 6797 wymaga samej substytucji schematu, ale nie nakazuje konkretnego kodu statusu dla niej (RFC 6797 §8.3), więc dana przeglądarka lub narzędzie do crawlowania może reprezentować ten wewnętrzny krok, jak chce — wiele wyświetla go jako wewnętrzne 307, ale to specyficzne dla klienta/narzędzia, a nie gwarancja protokołu. To, co ma znaczenie dla SEO, jest prostsze i obowiązuje niezależnie od etykiety: żaden serwer nie jest kontaktowany dla wersji HTTP, więc żaden crawler nigdy jej nie widzi. Googlebot i Bingbot nie noszą nauczonej polityki HSTS tak, jak robi to wracający człowiek w Chrome — uderzają na Twój serwer na świeżo, a to, co muszą tam zobaczyć, to prawdziwe, serwerowe 301. Dowód potwierdzający to twierdzenie RFC 6797 requires the user agent to rewrite a known-HSTS-host HTTP URI to HTTPS internally, but does not mandate any specific redirect status code for that internal rewrite; how a given browser or crawling tool represents that step (e.g., as an internal 307) is a client/tool implementation detail, not a protocol requirement. Zakres: RFC 6797 Section 8.3 ("URI Loading and Port Mapping") specifies the UA MUST replace the URI scheme with https; it does not prescribe an HTTP status code for that internal substitution, since no HTTP exchange occurs for it. Section 7.2's suggestion of status code 301 addresses ordinary server-side redirect behavior, not this internal client-side rewrite. Poziom ufności: wysoki · Zweryfikowano: 2026-07-17 RFC 6797 §8.3 — URI Loading and Port Mapping

Więc zasada jest prosta: HSTS nie zastępuje Twoich serwerowych 301. 301 jest tym, czego wyszukiwarki używają do zrozumienia zmiany protokołu i do konsolidacji sygnałów (“301 and other permanent redirects don’t cause a loss in PageRank.” (tłumaczenie) „301 i inne trwałe przekierowania nie powodują utraty PageRank”, według Google). Wewnętrzne ulepszenie tylko w przeglądarce to warstwa doświadczenia użytkownika i bezpieczeństwa na wierzchu. Potrzebujesz obu, wykonujących różne zadania:

• 301 (serwerowe): dla crawlerów, indeksowania i kapitału linków.
• Wewnętrzne ulepszenie w stylu 307 (po stronie przeglądarki, z HSTS): dla wracających ludzi i ochrony przed SSL-stripping — dokładna reprezentacja statusu różni się w zależności od klienta/narzędzia.

Każdy przewodnik, który mówi, że HSTS “obsługuje przekierowanie, więc możesz porzucić swoje 301”, jest błędny w sposób, który będzie Cię po cichu kosztować.

HSTS preload: wersja prawie permanentna

max-age chroni powracających odwiedzających, ale ma problem z uruchamianiem: pierwszy odwiedzający, który nigdy nie otrzymał Twojego nagłówka, jest nadal narażony na to początkowe żądanie. Preload rozwiązuje to, wpisując Twoją domenę bezpośrednio do źródła przeglądarki, dzięki czemu przeglądarka wie, że jesteś HTTPS-only, zanim jeszcze się połączy.

Zgłaszasz się na hstspreload.org. Wymagania są dokładne:

1. “Serve a valid certificate.” (tłumaczenie) „Udostępniaj prawidłowy certyfikat”.
2. “Redirect from HTTP to HTTPS on the same host, if you are listening on port 80.” (tłumaczenie) „Przekierowuj połączenia nieszyfrowane do szyfrowanych w tej samej domenie, jeśli nasłuchujesz na porcie 80”.
3. “Serve all subdomains over HTTPS.” (tłumaczenie) „Obsługuj wszystkie subdomeny przez szyfrowane połączenie” — w tym w szczególności subdomenę www, jeśli istnieje rekord DNS.
4. W odpowiedzi HTTPS domeny głównej nagłówek HSTS, gdzie “the max-age must be at least 31536000 seconds (1 year),” (tłumaczenie) „wartość max-age musi wynosić co najmniej 31536000 sekund (1 rok)”, “the includeSubDomains directive must be specified,” (tłumaczenie) „dyrektywa includeSubDomains musi być określona” oraz “the preload directive must be specified.” (tłumaczenie) „dyrektywa preload musi być określona”. (hstspreload.org)

Dlatego powyższy dwuletni przykład (max-age=63072000; includeSubDomains; preload) ma kształt, który ludzie zgłaszają — zauważ, że są to dokładne wymagania zgłoszeniowe opublikowane przez hstspreload.org; traktuj je jako aktualny próg, a nie stałą stałą, i sprawdź ponownie stronę na żywo przed zgłoszeniem.

Pomaga rozróżnić cztery różne stany, ponieważ ludzie ciągle je mylą:

Usunięcie przebiega przez te same cztery stany w odwrotnej kolejności i równie wolno: usunięcie dyrektywy preload z nagłówka czyni Cię kwalifikującym się do formularza usunięcia, następnie zgłoszenie jest oczekujące, a domena pozostaje egzekwowana dla każdego użytkownika na kompilacji przeglądarki, która nadal ją zawiera — dopóki ta kompilacja nie wygaśnie.

Teraz część, która zamienia preload w drzwi jednokierunkowe. Ze strony zgłoszeniowej samej w sobie: “Be aware that inclusion in the preload list cannot easily be undone. Domains can be removed, but it takes months for a change to reach users with a Chrome update and we cannot make guarantees about other browsers.” (tłumaczenie) „Pamiętaj, że wpisu na liście preload nie można łatwo cofnąć. Domenę można usunąć, ale dotarcie zmiany do użytkowników wraz z aktualizacją Chrome trwa miesiące, a w przypadku innych przeglądarek nie możemy niczego zagwarantować”. (hstspreload.org). I jej własna rada: “Don’t request inclusion unless you’re sure that you can support HTTPS for your entire site and all its subdomains in the long term.” (tłumaczenie) „Nie proś o dodanie do listy, dopóki nie masz pewności, że możesz długoterminowo obsługiwać HTTPS w całej witrynie i we wszystkich jej subdomenach”.

Praktyczne tłumaczenie: preload to naprawdę świetna postawa bezpieczeństwa, ale jeśli kiedykolwiek będziesz musiał serwować cokolwiek — starszą subdomenę, przejętą markę, wewnętrzne narzędzie — ponownie przez zwykły HTTP, utkniesz czekając na cykle wydań przeglądarki, aby dotarły do każdego użytkownika. Przewodnik Kinsty przedstawia rzeczywistość operacyjną wprost: może to być trudny i czasochłonny proces usunięcia Twojej domeny. Traktuj preload jako trwały.

Dlaczego HSTS jest zaprojektowany tak, aby boleć, gdy coś się psuje

Surowość HSTS nie jest błędem — to cała gwarancja bezpieczeństwa. web.dev wyjaśnia ten kompromis: “Clients that have listed your site as a known HSTS Host are likely to hard-fail if your site ever has an error in its TLS configuration, (such as an expired certificate). HSTS is explicitly designed this way to ensure that network attackers can’t trick clients into accessing the site without HTTPS.” (tłumaczenie) „Klienci, którzy zapisali Twoją witrynę jako znany host HSTS, prawdopodobnie zakończą połączenie twardym błędem, jeśli w konfiguracji TLS witryny kiedykolwiek pojawi się błąd, taki jak wygasły certyfikat. HSTS jest celowo zaprojektowany w ten sposób, aby atakujący w sieci nie mogli nakłonić klientów do wejścia na stronę bez HTTPS”. (web.dev).

Wniosek, do którego dochodzi Google, to zdanie, które wyryłbym każdemu, kto ma zamiar to włączyć: “Don’t enable HSTS until you’re certain your site operation is robust enough to avoid ever deploying HTTPS with certificate validation errors.” (tłumaczenie) „Nie włączaj HSTS, dopóki nie masz pewności, że działanie Twojej witryny jest na tyle solidne, aby nigdy nie wdrożyć HTTPS z błędami walidacji certyfikatu.” (web.dev).

„Twarda awaria” oznacza dokładnie to: brak linku „kontynuuj mimo to”, brak możliwości przejścia dalej. Na zwykłej stronie HTTPS wygasły certyfikat wyświetla przerażający ekran pośredni, który zdeterminowany użytkownik może ominąć. Na hoście z HSTS przeglądarka po prostu odmawia. Tak więc sposób awarii w przypadku przeoczonego odnowienia certyfikatu zmienia kategorię — z „spadku ruchu, ponieważ ludzie są odstraszani” na „witryna jest niedostępna dla każdego powracającego odwiedzającego”.

Scenariusze blokady w realnym świecie

Sposoby, w jakie HSTS gryzie w praktyce, prawie zawsze sprowadzają się do includeSubDomains lub preloadu wyprzedzającego rzeczywiste pokrycie HTTPS:

• Zapomniana subdomena. Ustawiasz includeSubDomains na example.com, ale legacy.example.com (stara aplikacja, strona statusu, narzędzie dostawcy) obsługuje tylko HTTP lub ma certyfikat, który jej nie obejmuje. Każda przeglądarka, która widziała nagłówek, teraz odmawia załadowania tej subdomeny. Nic się nie zmieniło na tym serwerze — polityka sięgnęła w dół i ją zepsuła.
• Luka w certyfikacie wildcard. Wildcard *.example.com obejmuje foo.example.com, ale nie obejmuje foo.bar.example.com (wildcard jest głęboki na jeden poziom DNS). Jeśli głębsza subdomena polega na HTTP lub niepasującym certyfikacie, includeSubDomains ją blokuje.
• Wygasły certyfikat na hoście z HSTS. Automatyzacja odnawiania zawodzi, certyfikat wygasa, i zamiast ostrzeżenia, które można ominąć, dostajesz witrynę, która jest niedostępna dla wszystkich, których przeglądarka pamięta Twoją politykę — dopóki nie przywrócisz ważnego certyfikatu i oni nie połączą się ponownie i nie otrzymają świeżej, bezpiecznej odpowiedzi. Nie ma szybszego obejścia.
• Żal po preloadzie. Wykonałeś preload, a potem potrzeba biznesowa wymusza usługę tylko-HTTP w ramach domeny. Cofnięcie tego to dwa osobne, nie natychmiastowe zadania, nie jedno: serwowanie max-age=0 przez HTTPS czyści tylko wyuczoną politykę dla klientów, którzy połączą się ponownie, zanim ich stary max-age i tak by wygasł, podczas gdy usunięcie domeny z listy preload to osobne zgłoszenie, które i tak zajmuje cykle wydań przeglądarek — miesiące — zanim dotrze do użytkowników, niezależnie od tego, co zmienisz na swoim serwerze.
• Kolizje lokalnego dev / staging. Preloadowanie example.com z includeSubDomains może sprawić, że dev.example.com lub host wewnętrzny w stylu localhost pod tym samym apexem odmówi HTTP, psując lokalne przepływy pracy w zaskakujący sposób.

Żaden z tych powodów nie jest powodem, aby unikać HSTS. To powody, aby go wdrożyć etapami: najpierw krótki max-age, dodaj includeSubDomains dopiero po audycie każdej subdomeny, a preload zarezerwuj na moment, gdy będziesz pewien.

HSTS to nie gra o pozycje (i nie wpływa na kanonikalizację)

Dla jasności w kwestii SEO: HSTS nie jest sygnałem rankingowym. Sam HTTPS jest celowo minimalnym sygnałem — Google nazwał go “bardzo lekkim sygnałem” wpływającym na mniej niż 1 % zapytań — a HSTS to warstwa na HTTPS, nie osobny czynnik rankingowy. Nie wpływa też bezpośrednio na kanonikalizację ani indeksowanie. Dokumentacja Google jest jednak bardziej szczegółowa niż płaskie “to nie ma znaczenia”: Google preferuje HTTPS jako kanon względem równoważnej strony HTTP z wyjątkiem sytuacji, gdy występuje nieprawidłowy certyfikat, niezabezpieczone zależności strony, strona HTTPS przekierowująca na HTTP lub tag rel="canonical" HTTP (Google: konsolidacja zduplikowanych adresów URL). HSTS nie może tego naprawić ani nadpisać. To polityka po stronie przeglądarki, która nie ma wpływu na logikę kanonikalizacji Google — zły certyfikat lub zerwany łańcuch przekierowań może nadal skłaniać Google ku kanonowi HTTP niezależnie od tego, co mówi Twój nagłówek HSTS. Kanonikalizacja jest sterowana przez Twoje przekierowania 301, certyfikat, tag rel="canonical" i linki wewnętrzne — HSTS zasługuje na swoje miejsce ze względu na bezpieczeństwo, zaufanie użytkowników i zamknięcie luki związanej ze strippingiem SSL — rób to z tych powodów, utrzymuj przekierowania 301 i certyfikat naprawdę solidne, a nigdy nie zobaczysz HSTS na raporcie rankingowym w żadną stronę.

Jeśli przeprowadzasz szerszą migrację HTTP→HTTPS, HSTS włączasz na końcu, nie na początku — powinno to nastąpić po ustabilizowaniu się migracji, w ramach szerszej dyscypliny migracji strony.

Podsumowanie AI

Skrócona wersja wersji zaawansowanej:

• HSTS = nagłówek odpowiedzi Strict-Transport-Security. Mówi przeglądarkom, aby zawsze używały HTTPS dla Twojej domeny, zamykając “problem pierwszego żądania”, który pozostawia samo przekierowanie 301 — początkowe żądanie HTTP od nowego odwiedzającego jest niezabezpieczone, dopóki nie zadziała przekierowanie, co stanowi okno na stripping SSL.
• Trzy dyrektywy: max-age (wymagana, w sekundach; resetuje się przy każdej odpowiedzi; usunięcie nagłówka nie czyści zapamiętanej polityki — musisz serwować max-age=0 przez HTTPS), includeSubDomains (dotyczy wszystkich subdomen) oraz preload (flaga zgody na listę preload w przeglądarkach — obecność tokena, kwalifikowalność, złożenie i faktyczne umieszczenie na liście to cztery osobne stany).
• Kluczowa kwestia wewnętrznego ulepszania: gdy przeglądarka egzekwuje HSTS, przepisuje URI na HTTPS wewnętrznie, zanim jakiekolwiek żądanie dotrze do serwera — RFC 6797 nie nakazuje konkretnego kodu statusu dla tego przepisania, choć narzędzia często pokazują je jako 307 — więc żaden serwer tego nie widzi i crawlerzy nigdy tego nie widzą. Twoje przekierowania 301 po stronie serwera są nadal obowiązkowe dla wyszukiwarek i przekazywania mocy linków. HSTS działa na bazie Twoich przekierowań 301, nigdy zamiast nich.
• Preload trwale zapisuje Twoją domenę w przeglądarce przez hstspreload.org (wymaga max-age ≥ 31536000, includeSubDomains i preload). To niemal nieodwracalne — usunięcie to osobne zgłoszenie, które dociera do użytkowników miesiącami, przeglądarka po przeglądarce.
• Zaprojektowany do twardej awarii: host HSTS z uszkodzonym/wygasłym certyfikatem odmawia ładowania, bez możliwości kliknięcia dalej. Google: “Don’t enable HSTS until you’re certain your site operation is robust enough to avoid ever deploying HTTPS with certificate validation errors.” (tłumaczenie) „Nie włączaj HSTS, dopóki nie masz pewności, że Twoja strona działa na tyle stabilnie, by nigdy nie wdrażać HTTPS z błędami walidacji certyfikatu.”
• Scenariusze blokady koncentrują się wokół includeSubDomains i preload wyprzedzającego Twoje pokrycie HTTPS: zapomniane subdomeny HTTP, luki w głębokości certyfikatów wildcard, wygasłe certyfikaty, żal po preload i kolizje środowisk stagingowych.
• To nie sygnał rankingowy — i nie może nadpisać kanonikalizacji. Google preferuje HTTPS jako kanon z wyjątkiem sytuacji, gdy certyfikat jest nieprawidłowy, zależności są niezabezpieczone, strona HTTPS przekierowuje na HTTP lub tag kanoniczny wskazuje HTTP — a HSTS nie ma mocy, by cokolwiek z tego naprawić lub nadpisać. Pozostaw przekierowania 301, certyfikat i tagi kanoniczne do wykonywania pracy SEO.

Oficjalna dokumentacja

Dokumentacja źródłowa zespołów przeglądarek i standardów.

Google / web.dev

• Włącz HTTPS na swoich serwerach (web.dev) — sekcja HSTS: nagłówek, SSL-stripping, ostrzeżenie o twardym błędzie oraz „nie włączaj HSTS, dopóki nie będziesz pewien”.
• Przenoszenie witryny ze zmianami adresów URL — dlaczego przekierowanie 301 po stronie serwera jest nadal obowiązkowe (przekierowania nie tracą PageRank).
• Zrozumienie doświadczenia strony — gdzie HTTPS (a przez to HSTS) znajduje się w ujęciu Google.

Standardy i referencje przeglądarek

• MDN — Strict-Transport-Security — pełna składnia nagłówka, trzy dyrektywy oraz sposób, w jaki przeglądarka ulepsza schemat.
• RFC 6797 — HTTP Strict Transport Security (HSTS) — oryginalna specyfikacja.
• Lista preload HSTS — zgłoszenia (hstspreload.org) — dokładne wymagania preload i zastrzeżenia dotyczące usuwania, utrzymywane przez projekt Chromium.

Cytaty ze źródła

Oficjalne wypowiedzi Google/web.dev oraz usługi preload Chromium. Każdy link przenosi do (lub wskazuje) cytowany fragment na stronie źródłowej.

web.dev (Google) — co robi HSTS i ostrzeżenia

• “Use HTTP Strict Transport Security (HSTS) to avoid the cost of the 301 redirect.” (tłumaczenie) „Użyj HTTP Strict Transport Security (HSTS), aby uniknąć kosztu przekierowania 301.” Przejdź do cytatu
• “First, use Strict Transport Security to tell clients they should always connect to your server using HTTPS, even when following an http:// reference. This defeats attacks like SSL Stripping, and avoids the round-trip cost of the 301 redirect.” (tłumaczenie) „Najpierw użyj Strict Transport Security, aby poinformować klientów, że powinni zawsze łączyć się z Twoim serwerem przez HTTPS, nawet gdy podążają za odnośnikiem http://. To udaremnia ataki takie jak SSL Stripping i unika kosztu przekierowania 301 w obie strony.” Przejdź do cytatu
• “Clients that have listed your site as a known HSTS Host are likely to hard-fail if your site ever has an error in its TLS configuration, (such as an expired certificate). HSTS is explicitly designed this way to ensure that network attackers can’t trick clients into accessing the site without HTTPS.” (tłumaczenie) „Klienci, którzy umieścili Twoją witrynę na liście znanych hostów HSTS, prawdopodobnie twardo zakończą połączenie, jeśli Twoja witryna kiedykolwiek będzie miała błąd w konfiguracji TLS (na przykład wygasły certyfikat). HSTS jest celowo zaprojektowany w ten sposób, aby atakujący w sieci nie mogli oszukać klientów, aby uzyskali dostęp do witryny bez HTTPS.” Przejdź do cytatu
• “Don’t enable HSTS until you’re certain your site operation is robust enough to avoid ever deploying HTTPS with certificate validation errors.” (tłumaczenie) „Nie włączaj HSTS, dopóki nie będziesz pewien, że działanie Twojej witryny jest wystarczająco solidne, aby nigdy nie wdrażać HTTPS z błędami walidacji certyfikatu.” Przejdź do cytatu

Usługa preload Chromium — hstspreload.org

• “Be aware that inclusion in the preload list cannot easily be undone. Domains can be removed, but it takes months for a change to reach users with a Chrome update and we cannot make guarantees about other browsers.” (tłumaczenie) „Miej świadomość, że umieszczenie na liście preload nie może być łatwo cofnięte. Domeny można usunąć, ale dotarcie zmiany do użytkowników wraz z aktualizacją Chrome zajmuje miesiące, a my nie możemy zagwarantować tego w przypadku innych przeglądarek.” Źródło
• “Don’t request inclusion unless you’re sure that you can support HTTPS for your entire site and all its subdomains in the long term.” (tłumaczenie) „Nie zgłaszaj prośby o umieszczenie, dopóki nie będziesz pewien, że możesz długoterminowo obsługiwać HTTPS dla całej swojej witryny i wszystkich jej subdomen.” Źródło

MDN — zachowanie nagłówka

• “Before loading an http URL, the browser checks the domain name against its HSTS hosts list. If the domain name is a case insensitive match for an HSTS host or is a subdomain of one that specified includeSubDomains, then the browser replaces the URL scheme with https.” (tłumaczenie) „Przed załadowaniem adresu URL http przeglądarka sprawdza nazwę domeny na swojej liście hostów HSTS. Jeśli nazwa domeny jest dopasowaniem bez uwzględniania wielkości liter do hosta HSTS lub jest subdomeną takiego, który określił includeSubDomains, przeglądarka zastępuje schemat adresu URL na https.” Źródło

Czy powinienem włączyć HSTS — i jak daleko?

Przejdź przez to od góry do dołu. Każde „nie” to znak stopu, a nie „może”. Jedno rozróżnienie na początek: dokładne wartości max-age poniżej (kilka minut dla canary, rok dla stanu spoczynkowego) to operacyjne zalecenia Patricka dotyczące etapów, a nie wymagania protokołu — jedynym twardym wymogiem liczbowym jest minimalny próg preloadu w hstspreload.org (max-age ≥ 31536000), który jest wyraźnie wskazany na tym etapie. Dostosuj czasy trwania etapów do własnej tolerancji ryzyka i tempa wdrażania.

1. Czy cała Twoja witryna jest już na HTTPS z ważnym certyfikatem, a migracja się ustabilizowała?

• Nie → Nie ruszaj HSTS na razie. Najpierw ukończ migrację na HTTPS: przekieruj 301 każdy URL, napraw mieszaną treść, zweryfikuj w Search Console. HSTS to ostatni przełącznik, nie pierwszy.
• Tak → kontynuuj.

2. Czy odnawianie certyfikatu jest zautomatyzowane i monitorowane (aby wygaśnięcie nie mogło Cię zaskoczyć)?

• Nie → Najpierw to napraw. Na hoście z HSTS wygasły certyfikat to twarda awaria, a nie ostrzeżenie. Skonfiguruj automatyczne odnawianie + alerty o wygaśnięciu, a potem kontynuuj.
• Tak → kontynuuj. Włącz krótki max-age (np. od kilku minut do dnia) bez includeSubDomains na razie i potwierdź, że nic się nie psuje.

3. Czy przeprowadziłeś audyt każdej poddomeny — w tym www, starszych aplikacji, stron statusu i hostów dostawców — i potwierdziłeś, że każda obsługuje ważny HTTPS?

• Nie → Trzymaj includeSubDomains wyłączone. Dodanie go teraz sięgnęłoby w dół i zepsuło każdą poddomenę tylko-HTTP lub z niedopasowanym certyfikatem.
• Tak → Podnieś max-age w kierunku roku i dodaj includeSubDomains. To bezpieczny, mocny stan spoczynkowy dla większości witryn.

4. Czy chcesz też zamknąć lukę pierwszej wizyty i jesteś pewien, że nigdy nie będziesz musiał serwować niczego pod tą domeną przez zwykły HTTP?

• Nie / nie jestem pewien → Zatrzymaj się tutaj. max-age=31536000; includeSubDomains (bez preloadu) to doskonała postawa. Marginalny zysk preloadu nie jest wart jego nieodwracalności, jeśli nie jesteś pewien.
• Tak, jestem pewien → Dodaj flagę preload i zgłoś na hstspreload.org. Traktuj to jako trwałe — usunięcie zajmuje miesiące, zanim dotrze do użytkowników.

Osobna, zawsze prawdziwa gałąź: czy włączenie HSTS oznacza, że mogę zrezygnować z przekierowań 301?

• Nigdy. Crawlery nie widzą wewnętrznego ulepszenia HSTS tylko w przeglądarce. Zachowaj swoje przekierowania 301 po stronie serwera niezależnie od tego, jak głęboko zejdziesz w tym drzewie.

Lista kontrolna wdrażania HSTS

Pracuj od góry do dołu — każdy etap bramkuje następny. Podane tu czasy trwania etapów to zalecenia operacyjne, a nie wymagania protokołu — jedyną twardą liczbą jest minimum preloadu max-age ≥ 31536000 w etapie 3.

Zanim cokolwiek włączysz

• Cała witryna (apex + www + wszystkie poddomeny) obsługuje HTTPS z ważnym certyfikatem.
• Przekierowania HTTP→HTTPS 301 są skonfigurowane po stronie serwera, jeden do jednego.
• Automatyczne odnawianie certyfikatu jest skonfigurowane oraz istnieje monitorowanie/alerty wygaśnięcia.
• Migracja HTTP→HTTPS się ustabilizowała (Search Console czyste, bez spadku rankingów).

Etap 1 — udowodnij, że to bezpieczne

• Dodaj Strict-Transport-Security z krótkim max-age (od minut do dnia).
• Bez includeSubDomains na razie. Bez preload na razie.
• Potwierdź, że witryna ładuje się normalnie w różnych przeglądarkach i że nic się nie zepsuło.

Etap 2 — zobowiązanie

• Podnieś max-age do co najmniej 31536000 (jednego roku).
• Przeprowadź audyt każdej poddomeny (w tym www, starszych, statusu, dostawców) pod kątem ważnego HTTPS.
• Dopiero po przejściu tego audytu dodaj includeSubDomains.
• Przetestuj ponownie, czy każda poddomena ładuje się przez HTTPS.

Etap 3 — preload (opcjonalny, prawie trwały)

• Jesteś pewien, że nigdy nie będziesz potrzebować HTTP pod tą domeną.
• Nagłówek to max-age=31536000 (lub więcej) ; includeSubDomains; preload.
• HTTP na porcie 80 przekierowuje na HTTPS na tym samym hoście.
• Zgłoś i potwierdź status na hstspreload.org.

Zawsze prawda — nie pomijaj

• 301 po stronie serwera pozostają na miejscu (crawlerzy nigdy nie widzą wewnętrznego ulepszenia tylko w przeglądarce).
• Masz udokumentowany plan wycofania: max-age=0 serwowane przez HTTPS czyści wyuczoną (niepreloadowaną) politykę dla klientów, którzy połączą się ponownie, zanim i tak by wygasła. Dla domen preloadowanych wymagany jest osobny, wolniejszy proces usuwania z listy.

Modele mentalne

1. HSTS to warstwa, nie zamiennik. 301 po stronie serwera = dla crawlerów i przekazywania link equity. Wewnętrzne ulepszenie po stronie przeglądarki (z HSTS, często pokazywane jako 307, choć RFC nie wymaga dokładnie tego kodu) = dla powracających ludzi i ochrony przed SSL-strippingiem. Różni odbiorcy, różne zadania. Zawsze potrzebujesz obu; HSTS nigdy nie zastępuje 301.

2. HSTS zamyka lukę, której 301 nie może. 301 chroni drugie żądanie i kolejne. Pierwsze żądanie — zanim przekierowanie zadziała — nadal jest HTTP. HSTS (dla powracających odwiedzających) i preload (dla pierwszych odwiedzin) to jedyne rzeczy, które zamykają to konkretne okno.

3. Zwiększaj stopniowo, nigdy nie skacz. max-age krótkie → długie. Nagi nagłówek → includeSubDomains (po audycie subdomen) → preload (tylko jeśli jesteś pewien). Każdy szczebel jest odwracalny, z wyjątkiem ostatniego. Nie pomijaj szczebli, aby zaoszczędzić czas.

4. Surowość to funkcja, która działa w obie strony. Ten sam twardy błąd, który zatrzymuje atakującego, zatrzymuje również ciebie, gdy certyfikat się zepsuje. Więc warunkiem wstępnym nie jest „czy chcesz bezpieczeństwa?” — każdy chce — ale „czy Twoja operacja certyfikatowa jest na tyle solidna, aby nigdy nie zawieść?”

5. Preload to drzwi w jedną stronę. Niepreloadowane HSTS można rozluźnić dla klienta przy następnym bezpiecznym żądaniu, gdy otrzyma max-age=0 — nie szybciej i tylko dla klientów, którzy się ponownie połączą. Preload idzie o krok dalej: usunięcie to osobne zgłoszenie, które dociera do użytkowników miesiącami, przeglądarka po przeglądarce. Umieść to w kategorii „decyzje, których nie możemy łatwo cofnąć” i traktuj odpowiednio.

6. HSTS jest ortogonalne do rankingów — ale też nie uratuje złego sygnału kanonicznego. To nie jest sygnał rankingowy i nie kontroluje bezpośrednio kanonizacji ani indeksowania. Oceń to pod kątem bezpieczeństwa i zaufania, nie pod kątem korzyści SEO — żadnych nie ma. Ale to też nie jest siatka bezpieczeństwa: preferencja Google dotycząca kanonizacji HTTPS nadal ustępuje w przypadku złego certyfikatu, niebezpiecznych zależności, przekierowania HTTPS→HTTP lub kanonicznego tagu HTTP, a HSTS nie ma mocy, aby to nadpisać.

HSTS — ściągawka

Dyrektywy nagłówka

Typowe wartości nagłówka (poniższe wartości testowe to sugestie operacyjne, nie wymagania protokołu — twarde minimum to wiersz preload)

Przekierowania: które, kto je widzi

Szybkie fakty

• Preload wymaga max-age ≥ 31536000 + includeSubDomains + preload — zweryfikowane względem aktualnych opublikowanych wymagań hstspreload.org.
• Usunięcie preload to osobne zgłoszenie, które zajmuje miesiące, zanim dotrze do użytkowników, przeglądarka po przeglądarce — traktuj to jako trwałe.
• Na hoście z HSTS uszkodzony certyfikat = twarda awaria, brak możliwości kliknięcia dalej.
• HSTS nie jest sygnałem rankingowym i nie zastępuje Twoich przekierowań 301.

Ustaw nagłówek HSTS

Dodaj nagłówek tylko w bloku serwera HTTPS i zacznij od krótkiego max-age, dopóki nie potwierdzisz, że nic się nie psuje. Dodaj ; preload tylko, gdy planujesz zgłoszenie do hstspreload.org — to prawie nieodwracalne.

Apache (.htaccess)

<IfModule mod_headers.c>
  # Start short (300s) to prove it's safe; raise to 31536000 once confident.
  Header always set Strict-Transport-Security "max-age=300"
  # Full posture once every subdomain is verified HTTPS:
  # Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"
  # Only add ; preload when submitting to hstspreload.org:
  # Header always set Strict-Transport-Security "max-age=63072000; includeSubDomains; preload"
</IfModule>

Nginx

# On the HTTPS (listen 443) server block:
add_header Strict-Transport-Security "max-age=300" always;
# Full posture once subdomains are verified:
# add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
# Preload shape (near-irreversible):
# add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" always;

Sprawdź, czy HSTS jest ustawione (i odczytaj je)

macOS / Linux

# Print only the Strict-Transport-Security response header
curl -sI https://example.com/ | grep -i strict-transport-security
# → strict-transport-security: max-age=31536000; includeSubDomains

Windows (PowerShell)

# Same check in PowerShell
(Invoke-WebRequest -Uri "https://example.com/" -Method Head).Headers["Strict-Transport-Security"]

Sprawdź i wyczyść wpis HSTS w Chrome (DevTools / net-internals)

Jeśli testujesz i przeglądarka “nauczyła się” polityki HSTS, którą musisz wyczyścić:

1. Open a new tab and visit:  chrome://net-internals/#hsts
2. Under "Query HSTS/PKP domain", enter your host to see the stored policy.
3. Under "Delete domain security policies", enter the host and Delete.
   (This clears the *learned* policy — it does NOT remove a *preloaded* domain,
   which lives in the browser binary and can't be cleared this way.)

Użyj tego, aby potwierdzić, że Twój nagłówek jest faktycznie przechowywany, oraz aby zresetować host testowy — nie jako naprawa w produkcji, gdzie odpowiedzią jest aktywne serwowanie max-age=0 przez HTTPS (samo usunięcie nagłówka nie czyści polityki, której klient już się nauczył; zadziała to dopiero, gdy ten klient ponownie się połączy i otrzyma odpowiedź z max-age=0).

Błędy HSTS, które bolą

1. Porzucanie przekierowań 301s, bo „HSTS to załatwia”. Klasyka. Przekierowanie HSTS to wewnętrzne uaktualnienie tylko w przeglądarce, którego crawlery nigdy nie widzą. Usuń swoje przekierowania 301s po stronie serwera, a wyszukiwarki stracą sygnał konsolidujący Twoje przeniesienie. Zawsze zachowuj oba.

2. Włączanie includeSubDomains przed audytem subdomen. Najczęstszy sposób na wyłączenie subdomeny. Jeśli jakakolwiek subdomena — starsza aplikacja, strona statusu, host dostawcy, samo www — nie ma ważnego HTTPS, polityka sięga w dół i psuje ją dla każdej przeglądarki, która zobaczyła nagłówek.

3. Skakanie od razu do rocznego max-age (lub preload) pierwszego dnia. Brak siatki bezpieczeństwa. Zacznij od krótkiego (max-age=300), potwierdź, że nic się nie psuje, potem zwiększaj. Długi max-age ustawiony na źle skonfigurowanej stronie to samookaleczająca się awaria, która utrzymuje się w przeglądarkach przez rok.

4. Preloading przed HTTPS jest naprawdę nie do przebicia. Preload jest prawie nieodwracalny — usunięcie zajmuje miesiące. Własne stanowisko Google: nie włączaj HSTS, dopóki nie masz pewności, że Twoja witryna działa wystarczająco stabilnie. Preload mnoży tę stawkę.

5. Traktowanie wygasłego certyfikatu jako drobnego problemu. Na stronie bez HSTS wygasły certyfikat to ostrzeżenie, które można ominąć. Na hoście z HSTS to twarda awaria bez możliwości kliknięcia dalej. Jeśli włączasz HSTS, automatyzacja odnawiania certyfikatów i alertowanie o wygaśnięciu przestają być opcjonalnymi udogodnieniami.

6. Ustawianie nagłówka w odpowiedzi HTTP. Przeglądarki ignorują HSTS dostarczane przez HTTP (celowo — atakujący mógłby je wstrzyknąć lub usunąć). Aby się liczyło, musi być wysyłane w odpowiedzi HTTPS.

7. Zapominanie o limicie głębokości certyfikatu wildcard. Wildcard *.example.com nie obejmuje foo.bar.example.com. Włącz includeSubDomains, a każda głębsza subdomena polegająca na tym certyfikacie zostanie zablokowana.

Playbook incydentów: host z HSTS jest zablokowany

1. Potwierdź awarię z czystej sieci i w więcej niż jednej przeglądarce. Zapisz dotknięte hostname’y i dokładny błąd certyfikatu. Zapamiętana polityka HSTS może sprawić, że objawy będą się różnić między powracającymi a nowymi odwiedzającymi.
2. Najpierw przywróć prawidłowe HTTPS. Jeśli certyfikat wygasł, nie pasuje lub brakuje w nim certyfikatu pośredniego, odnów go lub wymień i wdróż pełny łańcuch. Przeglądarka z HSTS nie zaoferuje bezpiecznego obejścia przez HTTP.
3. Zmapuj zakres polityki. Sprawdź aktywny nagłówek Strict-Transport-Security i ustal, czy includeSubDomains lub preload rozszerzają awarię poza hostname, który ją wysłał.
4. Sporządź inwentaryzację każdej dotkniętej subdomeny. W przypadku zapomnianego hosta tylko-HTTP umieść przed nim prawidłowy certyfikat i punkt końcowy HTTPS, zanim zdecydujesz, czy zachować, przenieść, czy przekierować usługę.
5. Popraw politykę dopiero po przywróceniu dostępu. Jeśli zakres jest niebezpieczny, zmniejsz lub usuń nagłówek w odpowiedziach HTTPS. To nie czyści natychmiast polityki już zapisanej w pamięci przeglądarek, a usunięcie preloadu to osobny, powolny proces.
6. Zweryfikuj odzyskanie. Przetestuj domenę główną, www i każdą dotkniętą subdomenę pod kątem prawidłowego łańcucha, poprawnego hostname, jednoprzeskokowego przekierowania HTTP→HTTPS i zamierzonego nagłówka HSTS. Utrzymuj monitorowanie wygaśnięcia certyfikatów w tej samej inwentaryzacji.

Nie usuwaj przekierowania HTTP ani nie mów użytkownikom, aby omijali ostrzeżenie. Trwałym rozwiązaniem jest prawidłowy punkt końcowy HTTPS wszędzie tam, gdzie sięga aktywna polityka HSTS.

Audyt aktywnej polityki HSTS

Act as a security-minded technical SEO. Review this Strict-Transport-Security
header, the HTTP redirect response, and the supplied subdomain inventory.

For the header, parse max-age, includeSubDomains, and preload. Explain the effective
scope, identify subdomains whose HTTPS or certificate coverage is unproven, and
separate browser-side HSTS behavior from the server-side 301 search engines need. Use
GET requests (HEAD can behave differently on some servers/clients), and record which
client or tool produced each observation and its version, since internal-redirect
representation is client/tool-specific rather than a fixed protocol value.

Recommend the next rollout stage: keep a short max-age canary, lengthen max-age,
add includeSubDomains, or consider preload. Do not recommend preload unless the
evidence shows a valid certificate, same-host HTTP→HTTPS redirects, HTTPS on every
subdomain, max-age of at least 31536000, includeSubDomains, and the preload token.

Return: observed configuration, risks, blocking evidence, next action, rollback
constraint, and exact validation checks.

Triage blokady HSTS

Given the affected hostnames, browser error, certificate details, DNS/CDN layout,
and live response headers, identify whether this is an expired certificate, hostname
mismatch, incomplete chain, includeSubDomains spillover, or preload issue. Prioritize
restoring valid HTTPS. Explain why removing a header does not immediately erase a
cached browser policy, then provide recovery and verification steps.

Zestaw narzędzi do inspekcji HSTS

• HTTP Header Checker — sprawdź aktywny nagłówek Strict-Transport-Security i potwierdź, że pojawia się w odpowiedziach HTTPS.
• curl -I — porównaj przekierowanie HTTP z nagłówkiem HTTPS bez polegania na zapamiętanym stanie HSTS w przeglądarce.
• DevTools przeglądarki — potwierdź końcowe nagłówki odpowiedzi i błąd certyfikatu widziany przez prawdziwego klienta.
• Status preloadu HSTS — sprawdź wymagania dotyczące zgłoszenia i czy domena jest już reprezentowana w procesie preloadu.

Użyj co najmniej dwóch perspektyw: dane z wiersza poleceń pokazują odpowiedź serwera, a przeglądarka ujawnia również egzekwowanie po stronie klienta i twarde błędy certyfikatów. Preferuj GET nad HEAD przy porównywaniu narzędzi — niektóre serwery i klienci reprezentują te dwa inaczej — i zanotuj dokładnego klienta/narzędzie/wersję stojące za każdym odczytem.

Testy etapowego wdrażania HSTS

Test 0: macierz stanów (uruchom przed wprowadzaniem zmian etapowych)

Status HSTS to nie jeden fakt — to kilka niezależnych stanów, które mogą być ze sobą sprzeczne. Śledź je osobno, dla każdego hostname:

Zapisuj klienta, narzędzie i wersję dla każdej obserwacji — reprezentacja wewnętrznych przekierowań i szczegóły egzekwowania HSTS różnią się między przeglądarkami, crawlerami i narzędziami wiersza poleceń, a nieaktualny odczyt z jednego klienta może wyglądać na sprzeczność, która w rzeczywistości nie istnieje.

Test 1: krótki kanarek max-age

• Cel: Udowodnij, że nagłówek jest emitowany tylko z zdrowych odpowiedzi HTTPS, zanim zobowiążesz klientów do długiej polityki.
• Metoda: Sprawdź reprezentatywne szablony i hosty za pomocą HTTP Header Checker i curl -I; porównaj wdrożoną wartość z zatwierdzoną konfiguracją kanarka.
• Oczekiwany wynik: Odpowiedzi HTTPS niosą zamierzony krótki max-age; HTTP nadal zwraca trwałe przekierowanie po stronie serwera na HTTPS.
• Wyzwalacz błędu: Brakujące lub zduplikowane nagłówki, nieoczekiwany długi czas trwania, błędy certyfikatu lub jakakolwiek pętla przekierowań.
• Następne działanie: Napraw nagłówek lub punkt końcowy HTTPS i utrzymaj wdrożenie na etapie kanarka.

Test 2: gotowość includeSubDomains

• Cel: Zapobiegaj zablokowaniu zapomnianej nazwy hosta przez politykę nadrzędną.
• Metoda: Przetestuj każdą nazwę DNS w utrzymywanym inwentarzu subdomen pod kątem ważnej odpowiedzi HTTPS, poprawnej nazwy certyfikatu i kompletnego łańcucha.
• Oczekiwany wynik: Każda subdomena w zakresie działa przez HTTPS, w tym starsze, dostawcy, deweloperskie i głębsze hosty.
• Wyzwalacz błędu: Jakakolwiek usługa tylko HTTP, wygasły lub niepasujący certyfikat lub nazwa hosta nieobecna w inwentarzu.
• Następne działanie: Napraw lub przenieś host przed dodaniem includeSubDomains.

Test 3: gotowość preload

• Cel: Zweryfikuj, że polityka prawie stała spełnia udokumentowane wymagania zgłoszeniowe.
• Metoda: Potwierdź ważny certyfikat, przekierowania HTTP→HTTPS na tym samym hoście, HTTPS na wszystkich subdomenach oraz nagłówek domeny głównej z max-age co najmniej 31536000, includeSubDomains i preload.
• Oczekiwany wynik: Każde wymaganie jest spełnione, a organizacja akceptuje powolną ścieżkę usuwania.
• Wyzwalacz błędu: Jakiekolwiek nieudane wymaganie techniczne lub nierozwiązana potrzeba subdomeny tylko HTTP.
• Następne działanie: Nie zgłaszaj; pozostań przy odwracalnej, etapowej polityce.

Zasoby warte Twojego czasu

Moje wystąpienie

• Lepiej dmuchać na zimne z HTTPS — SMX East 2016 (SlideShare) — moje szczegółowe omówienie TLS, typowych błędów w implementacji HTTPS oraz pułapek migracyjnych, które HSTS zarówno zamyka, jak i może wzmacniać. (Stałe zastrzeżenie ma zastosowanie: to moje rozumienie tych systemów, a statystyki adopcji w nim pochodzą z 2016 r.)

Moje powiązane artykuły

• The Beginner’s Guide to Technical SEO — gdzie HTTPS i HSTS wpisują się w szerszy obraz.

Z branży

• Włącz HTTPS na swoich serwerach (web.dev) — własne wytyczne Google dotyczące HSTS: nagłówek, stripping SSL i ostrzeżenie o twardym błędzie.
• MDN — Strict-Transport-Security — autorytatywna referencja nagłówka: składnia, dyrektywy i zachowanie przy ulepszaniu schematu.
• Zgłoszenie do listy HSTS Preload (hstspreload.org) — wymagania projektu Chromium dotyczące preload i ostrzeżenia o niemal nieodwracalności.
• RFC 6797 — HTTP Strict Transport Security — oryginalna specyfikacja, gdy potrzebujesz dokładnego sformułowania dyrektywy.
• HSTS — What It Is and How to Use It (Kinsta) — praktyczny przewodnik wdrożeniowy obejmujący wewnętrzne przekierowanie na poziomie przeglądarki, listę preload i ryzyko związane z blokadą.
• SSL Labs Server Test (Qualys) — oceń swoją konfigurację TLS i potwierdź, że HSTS jest poprawnie serwowany.

Statystyki i twarde fakty, które warto cytować

• Preload wymaga max-age ≥ 31536000 (1 rok), includeSubDomains i preload. Dokładny, niepodlegający negocjacjom próg zgłoszenia dla listy wbudowanej w przeglądarkę. Źródło
• Usunięcie z preload zajmuje miesiące, zanim dotrze do użytkowników. Z serwisu zgłoszeniowego: “inclusion in the preload list cannot easily be undone… it takes months for a change to reach users with a Chrome update.” (tłumaczenie) „Włączenie do listy preload nie może być łatwo cofnięte… zmiana dociera do użytkowników z aktualizacją Chrome dopiero po miesiącach.” To liczba, która czyni preload drzwiami jednokierunkowymi. Źródło
• Hosty HSTS twardo kończą się błędem przy każdym błędzie TLS. web.dev: klienci, którzy znają Twoją witrynę jako host HSTS, “are likely to hard-fail if your site ever has an error in its TLS configuration.” (tłumaczenie) „prawdopodobnie twardo zakończą się błędem, jeśli Twoja witryna kiedykolwiek będzie miała błąd w konfiguracji TLS.” Bez możliwości kliknięcia — wygasły certyfikat staje się awarią. Źródło
• Sam HTTPS to „a very lightweight signal—affecting fewer than 1% of global queries.” (tłumaczenie) „bardzo lekki sygnał — wpływający na mniej niż 1% globalnych zapytań.” Własne sformułowanie Google — a HSTS to warstwa na HTTPS, a nie osobny czynnik rankingowy, więc jego waga SEO jest praktycznie zerowa. Dostosuj oczekiwania odpowiednio. Źródło

Sprawdź się: HSTS

Pięć szybkich pytań o HSTS. Wybierz odpowiedź na każde, a następnie sprawdź.

Dziennik zmian