HTTPS w SEO

TL;DR — HTTPS to bezpieczna, szyfrowana wersja HTTP — symbol kłódki w przeglądarce. Google historycznie dawało stronom HTTPS minimalną przewagę rankingową, lecz prawdziwe powody migracji są inne: Chrome oznacza zwykłe witryny HTTP jako „Niezabezpieczone”, a HTTPS jest dziś standardem oczekiwanym w sieci. Prawidłowo wykonana zmiana jest bezpieczna: przekieruj każdy stary URL http:// do jego wersji https:// i niczego po drodze nie zepsuj.

Czym jest HTTPS

Gdy wczytujesz witrynę, przeglądarka rozmawia z serwerem. Przy zwykłym HTTP ta rozmowa odbywa się otwartym tekstem — każdy pośrednik w sieci (dostawca internetu, Wi-Fi w kawiarni, atakujący) może ją odczytać lub zmodyfikować. HTTPS szyfruje tę samą komunikację. Litera „S” oznacza „Secure”, czyli bezpieczeństwo. Włącza się je przez instalację certyfikatu TLS na serwerze (nadal często nazywanego „certyfikatem SSL”).

Sposób połączenia widać na pasku adresu: URL zaczynający się od https:// zwykle ma ikonę kłódki. Zwykła strona http:// otrzymuje w Chrome oznaczenie „Niezabezpieczona”.

HTTPS chroni wyłącznie samo połączenie — nie potwierdza jakości zawartości strony. Kłódka oznacza szyfrowanie danych podczas przesyłania; nie mówi nic o wiarygodności treści, prawdziwości formularza ani rzetelności firmy. Witryny phishingowe również mogą korzystać z ważnych certyfikatów HTTPS.

Czy HTTPS pomaga w SEO?

Historycznie — nieznacznie. W 2014 roku Google potwierdziło wykorzystywanie HTTPS jako sygnału rankingowego, ale był on bardzo słaby; zespół Google opisywał go wtedy jako rozstrzygnięcie remisu: jeśli dwie strony były poza tym równe, bezpieczna mogła uzyskać przewagę. Nie wyniesie słabej strony ponad mocną, a dzisiejsze wskazówki Google nie powtarzają już tezy o bezpośrednim wzroście pozycji dzięki HTTPS. Obietnice dużych zysków „tylko po dodaniu SSL” są przesadzone.

Powody, które naprawdę mają znaczenie:

• Chrome mówi „Niezabezpieczona”. Od 2018 roku ostrzeżenie otrzymuje każda strona HTTP. Odstrasza to użytkowników niezależnie od opinii Google.
• To dzisiejsza podstawa. Szacunkowo 9 na 10 witryn korzysta już z HTTPS (W3Techs, 2026). Pozostanie wyjątkiem wygląda jak usterka.
• Nowoczesne funkcje go wymagają. Wiele możliwości przeglądarki — oraz szybsze połączenia przez HTTP/2 — po prostu nie działa bez HTTPS.

Czy migracja zaszkodzi moim pozycjom?

Nie, jeśli wykonasz ją ostrożnie. Przejście z HTTP na HTTPS jest rodzajem migracji witryny, a złota zasada pozostaje ta sama: przekieruj każdy stary URL do jego nowej bezpiecznej wersji przekierowaniem 301. Poprawna migracja zachowuje pozycje. Niedbała — z brakującymi przekierowaniami albo uszkodzonymi linkami do obrazów i skryptów — może kosztować ruch. Sama zmiana jest bezpieczna; szkodzą błędy wokół niej.

Chcesz poznać pełny obraz — rzeczywistą wagę sygnału, migrację krok po kroku, mieszaną zawartość i HSTS? Przejdź do karty Zaawansowane.

TL;DR — Aktualne wytyczne Google dotyczące jakości strony mówią, że aspekty poza Core Web Vitals „nie pomagają bezpośrednio uzyskiwać wyższych pozycji”, więc nie obiecuj dzisiejszego wzrostu rankingu dzięki HTTPS. Potwierdzona jest historia: w sierpniu 2014 roku Google nazwało HTTPS „bardzo lekkim” sygnałem (mniej niż 1% zapytań), a Gary Illyes w 2015 roku — rozstrzygnięciem remisu. To wypowiedzi historyczne, nie udokumentowany obecny mechanizm. Osobno aktualne wytyczne kanonikalizacji Google preferują strony HTTPS nad odpowiednikami HTTP, lecz warunkowo: nieważny certyfikat, niezabezpieczone zależności, przekierowanie HTTPS→HTTP albo przypadkowy canonical HTTP mogą odwrócić preferencję, a HSTS tego nie naprawi. Najważniejsze argumenty za HTTPS to oznaczenie „Niezabezpieczona” w Chrome, HTTP/2 we wszystkich głównych przeglądarkach, nowoczesne API i status podstawowego standardu — nie dźwignia wzrostu. Migracja to migracja witryny: ustaw 301 dla każdego URL-a (301 nie traci PageRank), napraw aktywną i pasywną mieszaną zawartość, zaktualizuj canonicale, mapy witryn i linki wewnętrzne oraz ponownie zweryfikuj Search Console. Zmiana protokołu nie wymaga narzędzia Change of Address. HSTS i jego wewnętrzne przekierowanie 307 stanowią warstwę ochrony przeglądarki nad serwerowymi 301, nie ich zamiennik.

Czy Google obecnie obiecuje wzrost pozycji dzięki HTTPS?

Zacznij od tego, co Google mówi dzisiaj, a nie od 2014 roku. Aktualna dokumentacja jakości strony wymienia HTTPS wśród aspektów poza Core Web Vitals, które “don’t directly help your website rank higher in search results.” (tłumaczenie) „nie pomagają bezpośrednio witrynie uzyskiwać wyższych pozycji w wynikach wyszukiwania”. To najbardziej aktualna i bezpośrednia wskazówka; nie uzasadnia obiecywania współczesnego wzrostu pozycji tylko dzięki HTTPS.

Sygnał z 2014 roku i „rozstrzygnięcie remisu” — historia, nie dzisiejszy mechanizm

Historia jest dobrze potwierdzona: 6 sierpnia 2014 roku Google ogłosiło HTTPS jako sygnał rankingowy i wyjątkowo otwarcie opisało jego małą wagę. Był to „bardzo lekki sygnał”, obejmujący mniej niż 1% zapytań globalnych i słabszy od innych sygnałów, takich jak treść wysokiej jakości. Google dodało, że z czasem może go wzmocnić, aby zachęcić właścicieli witryn do wdrożenia HTTPS. Mowa była o „wzmocnieniu”, nie o „wzroście”, jak często parafrazowała to prasa SEO.

Rok później, we wrześniu 2015, Gary Illyes opisał sygnał jako rozstrzygnięcie remisu: jeśli wszystkie sygnały jakości dwóch wyników były równe, HTTPS mógł dać jednemu z nich niewielką przewagę. W tym samym roku jasno stwierdził, że na HTTPS należy przejść dla użytkowników, nie dla sygnału rankingowego. John Mueller również ostrzegał wtedy, aby nie oczekiwać widocznej zmiany pozycji od samej migracji.

Traktuj „rozstrzygnięcie remisu” jako historyczny komentarz Illyesa z lat 2015–2016, a nie mechanizm, który Google obecnie dokumentuje jako aktywny. Dzisiejsze sformułowanie dotyczące jakości strony jest ostrożniejszym źródłem. Uczciwa odpowiedź z datami na pytanie „czy HTTPS pomaga SEO?” brzmi więc: Google potwierdziło słaby sygnał w 2014 roku, jego przedstawiciel nazwał go rozstrzygnięciem remisu w 2015, a aktualne wytyczne nie powtarzają tego mechanizmu. HTTPS to higiena, nie dźwignia wzrostu, niezależnie od dzisiejszej wagi historycznego sygnału.

Preferencja kanoniczna HTTPS Google — warunkowa, nie oparta wyłącznie na schemacie

Niezależnie od sygnału rankingowego z 2014 roku Google obecnie dokumentuje preferencję kanonikalizacji: zwykle wybiera stronę HTTPS zamiast równoważnej strony HTTP, chyba że występują problemy lub sprzeczne sygnały — na przykład nieważny certyfikat SSL, niezabezpieczone zależności (inne niż obrazy), przekierowanie użytkownika ze strony HTTPS do strony HTTP lub przez nią albo rel="canonical" strony HTTPS wskazujący wersję HTTP.

Ten niuans umyka niemal wszystkim poradnikom i przeczy popularnemu uproszczeniu — także słowom Illyesa z 2016 roku, że sygnał rankingowy zasadniczo sprawdza pierwszych pięć znaków URL-a. Ten skrót opisywał sygnał z 2014 roku, nie decyzję kanonikalizacyjną. Google mówi wprost, że zły certyfikat lub przekierowanie obniżające HTTPS do HTTP bardzo mocno przechyla preferencję w stronę HTTP. HSTS nie może jej nadpisać.

Praktyczny skutek: wygasły lub źle skonfigurowany certyfikat to nie tylko problem UX — może również skłonić Google do zindeksowania strony HTTP zamiast HTTPS, której pozycję chcesz budować. Rodzaje awarii certyfikatów i ich diagnozę opisuje artykuł Certyfikaty SSL/TLS; sposób czytania osobnego raportu Search Console o tej decyzji — Raport HTTPS.

Dlaczego HTTPS naprawdę ma znaczenie

Po odłożeniu pytania o ranking argumenty za HTTPS są przytłaczające — z jednym ważnym zastrzeżeniem: HTTPS zabezpiecza kanał transportowy między przeglądarką a serwerem. Nie audytuje kodu aplikacji, nie gwarantuje bezpieczeństwa endpointów ani intencji użytkownika. Zhakowana witryna HTTPS, formularz phishingowy podawany przez HTTPS i wyciek danych po odszyfrowaniu nadal są możliwe. HTTPS to konieczna higiena, a nie gwarancja bezpieczeństwa wszystkiego za połączeniem.

Po takim określeniu zakresu praktyczne argumenty wyglądają następująco:

• Ostrzeżenie Chrome „Niezabezpieczona”. Od wersji Chrome 68 (lipiec 2018) wszystkie strony HTTP są oznaczane jako niezabezpieczone. Etykietę widzą prawdziwi użytkownicy na pasku adresu — to znacznie większy problem konwersji niż jakakolwiek przewaga rankingowa.
• W praktyce jest warunkiem HTTP/2 (i HTTP/3). Żadna główna przeglądarka nie udostępnia HTTP/2 przez zwykłe HTTP — wszystkie negocjują je tylko przez TLS, choć sama specyfikacja HTTP/2 nie wymaga szyfrowania. Dokumentacja Google stwierdza: “in some cases, TLS can improve performance, mostly as a result of making HTTP/2 possible.” (tłumaczenie) „w niektórych przypadkach TLS może poprawić wydajność, głównie dzięki umożliwieniu HTTP/2”. To warunkowe „może”, nie gwarancja; narzut TLS, konfiguracja serwera i ponowne użycie połączenia nadal mają znaczenie. Multipleksowanie i kompresja nagłówków HTTP/2 często sprawiają jednak, że HTTPS+HTTP/2 jest szybsze niż zwykłe HTTP/1.1 — odwrotnie niż w dawnym lęku przed opóźnieniem TLS.
• Nowoczesne funkcje przeglądarki go wymagają. Service workers, API geolokalizacji, kamery i mikrofonu oraz progresywne aplikacje internetowe zwykle wymagają bezpiecznego kontekstu (sprawdź wyjątki danej funkcji i przeglądarki, takie jak localhost). Google stwierdza: “HTTPS is required for many new browser features, especially those required for progressive web apps.” (tłumaczenie) „HTTPS jest wymagany przez wiele nowych funkcji przeglądarki, szczególnie tych potrzebnych progresywnym aplikacjom”.
• Dane o odesłaniach i „dark traffic” — domyślnie, nie zawsze. Przeglądarki z nowoczesną domyślną polityką Referrer-Policy (strict-origin-when-cross-origin) całkowicie usuwają nagłówek Referer, gdy link prowadzi ze strony HTTPS do celu HTTP. Nawigacja w tym samym schemacie lub z podniesieniem bezpieczeństwa nadal wysyła co najmniej origin. Jeśli pozostajesz na HTTP, ruch wychodzący — i jego atrybucja przychodząca — może domyślnie trafić do kategorii „direct”. Własny nagłówek Referrer-Policy witryny może jednak zmienić to zachowanie w obie strony, więc przy audycie cudzej luki analitycznej nie traktuj go jako reguły absolutnej.
• To standard wejścia. Szacunkowo około 89% witryn używa HTTPS (W3Techs, 2026 — traktuj wartość kierunkowo, nie jako dokładny bieżący pomiar). Historia SEO dotyczy dziś ryzyka widocznego pozostania w tyle, nie korzyści z samego przełączenia.

Migracja HTTP → HTTPS

Przejście HTTP→HTTPS jest migracją witryny i wymaga takiej samej dyscypliny. Dobra wiadomość pochodzi wprost z wytycznych Google o przenoszeniu witryn: przekierowania 301 i inne stałe przekierowania nie powodują utraty PageRank. Dawny lęk przed utratą wartości linków podczas migracji jest mitem — ryzyko kryje się wyłącznie w wykonaniu: brakujących 301, mieszanej zawartości, nieaktualnych canonicalach i niezweryfikowanej usłudze HTTPS w Search Console.

Najważniejsza dyscyplina w jednym akapicie: najpierw zapisz stan działającej witryny HTTP (skanowanie, pozycje, eksport Search Console, profil linków), zdobądź certyfikat TLS (bezpłatny DV Let’s Encrypt przekazuje taki sam sygnał jak płatny OV/EV), przekieruj 301 każdy URL HTTP do jego odpowiednika HTTPS jeden do jednego, ustaw HTTPS jako kanoniczny wszędzie (linki wewnętrzne, mapa witryny, hreflang — nie zakrywaj nieaktualnych linków wewnętrznych przekierowaniami), napraw mieszaną zawartość przed przełączeniem, ponownie zweryfikuj wszystkie cztery usługi Search Console (zmiana protokołu nie wymaga Change of Address) i utrzymuj przekierowania co najmniej rok. Oczekuj tymczasowych wahań pozycji: spadek, który się odbudowuje, oznacza stabilizację migracji; trwały — usterkę.

To mapa ryzyka, nie instrukcja wykonawcza. Sekwencję krok po kroku, próbę na środowisku testowym, masowe mapowanie przekierowań, plan wycofania i pełną listę kontrolną opisuje Migracja HTTP do HTTPS. Ta strona pozostaje zwięzłym przeglądem, aby nie rozminąć się z bardziej szczegółowym poradnikiem.

Mieszana zawartość

Mieszana zawartość występuje, gdy strona HTTPS ładuje podzasób przez HTTP. Ma dwie odmiany, a ich rozróżnienie wyznacza priorytety:

• Aktywna mieszana zawartość — skrypty, arkusze stylów, ramki iframe i XMLHttpRequest. Przeglądarki blokują je całkowicie, ponieważ zmodyfikowany skrypt może przepisać całą stronę. To właśnie psuje witrynę po migracji, więc napraw tę kategorię jako pierwszą.
• Pasywna mieszana zawartość — obrazy, dźwięk, wideo. Przeglądarki zwykle nadal ją wyświetlają, ale obniżają wskaźnik bezpieczeństwa i ostrzegają.

Znajdziesz ją przez skanowanie witryny HTTPS (Ahrefs Site Audit, Screaming Frog), obserwowanie konsoli Chrome DevTools lub zbieranie raportów CSP. Najczystszym rozwiązaniem wyprzedzającym problem jest nagłówek Content-Security-Policy: upgrade-insecure-requests, który nakazuje przeglądarce po cichu zamieniać żądania podzasobów http:// na https:// przed ich wysłaniem. To użyteczna siatka bezpieczeństwa w trakcie i po migracji. Zwykłe linki do stron HTTP nie są mieszaną zawartością — po prostu prowadzą do innej strony.

HSTS — i dlaczego nie zastępuje przekierowań 301

HSTS — HTTP Strict Transport Security — to nagłówek odpowiedzi (Strict-Transport-Security), który każe przeglądarkom zawsze używać HTTPS dla domeny, nawet jeśli użytkownik wpisze lub kliknie link http://. Rozwiązuje „problem pierwszego żądania”: przy samym 301 pierwsze żądanie nowego użytkownika nadal wychodzi przez HTTP, zanim zadziała przekierowanie, co tworzy okno dla ataku SSL stripping. Według Google HSTS pozwala “avoid the cost of the 301 redirect” (tłumaczenie) „uniknąć kosztu przekierowania 301” dla powracających użytkowników oraz “defeats attacks like SSL Stripping.” (tłumaczenie) „udaremnia ataki takie jak SSL Stripping”.

Specjaliści SEO powinni rozróżniać dwie rzeczy:

• HSTS nie zastępuje serwerowych 301. Gdy przeglądarka respektuje HSTS, wykonuje wewnętrzne przekierowanie 307 do HTTPS — ale dzieje się to w przeglądarce i roboty go nie widzą. Wyszukiwarki nadal potrzebują prawdziwego serwerowego 301, aby zrozumieć migrację i przenieść wartość linków. Potrzebujesz obu warstw.
• HSTS preload jest prawie trwały. Możesz zgłosić domenę do wbudowanej w przeglądarki listy preload (wymagane max-age co najmniej rok, includeSubDomains i preload), co zamyka lukę nawet dla nowych użytkowników. Usunięcie z listy jest jednak powolne i bolesne. Google ostrzega, aby nie włączać HSTS, dopóki nie masz pewności, że działanie witryny jest wystarczająco niezawodne, by nigdy nie wdrożyć HTTPS z błędami walidacji certyfikatu. Traktuj preload jak drzwi w jedną stronę.

Popularne mity

• „HTTPS daje dziś duży wzrost pozycji”. Nie — „bardzo lekki” sygnał z 2014 roku obejmujący mniej niż 1% zapytań i opis „rozstrzygnięcia remisu” z 2015 są komentarzami historycznymi; aktualne wytyczne mówią, że aspekty jakości strony poza Core Web Vitals nie pomagają bezpośrednio uzyskiwać wyższych pozycji.
• „Migracja pogrąży moje pozycje”. Nie przy prawidłowych przekierowaniach; 301 nie traci PageRank. Szkodzi źle wykonana migracja, nie zmiana protokołu.
• „Potrzebujesz narzędzia Change of Address”. Nie dla HTTP→HTTPS — tylko przy zmianie domeny.
• „Wygasły certyfikat psuje tylko UX, nie SEO”. Nie — zły certyfikat jest jednym z warunków, które mogą odwrócić preferencję kanoniczną Google z HTTPS na HTTP, a ponadto blokuje stronę użytkownikom.
• „HTTPS ma znaczenie tylko na stronach płatności”. Nie — Chrome oznacza każdą stronę HTTP, a nowoczesne API zwykle wymagają bezpiecznego kontekstu.
• „TLS spowalnia witryny”. W praktyce zwykle jest odwrotnie, ponieważ HTTPS umożliwia HTTP/2, choć TLS jedynie „może” pomóc wydajności, a jej nie gwarantuje.

Migracja HTTP→HTTPS należy do szerszej dyscypliny migracji witryn. Jeśli jednocześnie zmieniasz domenę lub platformę, najpierw przeczytaj ten materiał, ponieważ nałożone migracje zwielokrotniają ryzyko.

Podsumowanie AI

Skrócona wersja karty Zaawansowane:

• Aktualne wytyczne Google nie obiecują wzrostu pozycji. Dokument o jakości strony mówi, że aspekty poza Core Web Vitals “don’t directly help your website rank higher” (tłumaczenie) „nie pomagają bezpośrednio witrynie uzyskiwać wyższych pozycji”; HTTPS jest wśród nich wymieniony.
• Sygnał z 2014 roku i „rozstrzygnięcie remisu” z 2015 są historyczne. „Bardzo lekki”, mniej niż 1% zapytań (2014); słowa Illyesa o remisie (2015) — to wypowiedzi z datą, nie ponowne potwierdzenie dzisiejszego mechanizmu. Niezależnie od tego nie traktuj HTTPS jak dźwigni wzrostu.
• Preferencja kanoniczna HTTPS Google jest osobna — i warunkowa. Google obecnie preferuje HTTPS, chyba że występuje nieważny certyfikat, niezabezpieczona zależność inna niż obraz, przekierowanie HTTPS→HTTP albo błędny canonical HTTP. HSTS tego nie nadpisze. Zły certyfikat to nie tylko problem UX, ale też ryzyko kanonikalizacji.
• HTTPS zabezpiecza tylko transport — nie logikę aplikacji, endpointy ani zamiar użytkownika; strona phishingowa może działać na ważnym HTTPS.
• Prawdziwe powody HTTPS: oznaczenie „Niezabezpieczona” na wszystkich stronach HTTP w Chrome (od lipca 2018), HTTP/2 w każdej głównej przeglądarce (często szybsze od HTTP/1.1, choć TLS może pomóc, a nie gwarantuje poprawy), funkcje wymagające bezpiecznego kontekstu i PWA, domyślne — ale konfigurowalne — zachowanie danych o odesłaniach oraz szacunkowo 89-procentowy standard sieci.
• Migracja = migracja witryny, tutaj w zarysie. Przekieruj 301 każdy URL jeden do jednego (301 nie traci PageRank), ustaw HTTPS jako kanoniczny, zaktualizuj linki wewnętrzne, mapy witryn i hreflang, napraw mieszaną zawartość, ponownie zweryfikuj GSC (HTTP i HTTPS są osobnymi usługami), utrzymuj przekierowania co najmniej rok i nie używaj Change of Address przy zmianie protokołu. Pełne kroki wykonawcze są na osobnej stronie migracji.
• Mieszana zawartość: aktywna (skrypty/iframe) jest blokowana — napraw ją najpierw; pasywna (obrazy) wywołuje ostrzeżenia. CSP upgrade-insecure-requests stanowi zabezpieczenie.
• HSTS zamyka lukę pierwszego żądania, ale używa widocznego tylko przeglądarce 307, którego roboty nie widzą. Jest warstwą nad serwerowymi 301, nie ich zamiennikiem. Preload jest prawie trwały — nie wdrażaj go pochopnie.

Oficjalna dokumentacja

Źródła pierwotne od wyszukiwarek i zespołów przeglądarek.

Google

• HTTPS jako sygnał rankingowy (ogłoszenie z 2014) — pierwotny wpis o „bardzo lekkim sygnale”.
• Włączanie HTTPS na serwerach (web.dev) — certyfikaty, 301, canonicale, HSTS i pliki cookie.
• Dlaczego HTTPS ma znaczenie (web.dev) — argumenty dotyczące bezpieczeństwa i funkcji przeglądarki.
• Naprawianie mieszanej zawartości (web.dev) — aktywna i pasywna mieszana zawartość oraz upgrade-insecure-requests.
• Przenoszenie witryn ze zmianą adresów URL — podręcznik migracji (przekierowania, bez Change of Address dla HTTPS).
• Jak rozumieć jakość strony — miejsce HTTPS w jakości strony; aktualne źródło zalecenia, by nie oczekiwać bezpośredniego wzrostu pozycji.
• Jak wskazać kanoniczny URL — obecna, warunkowa preferencja kanoniczna HTTPS wobec HTTP i wyjątki, które ją odwracają: złe certyfikaty, niezabezpieczone zależności i przekierowania obniżające bezpieczeństwo.

Chrome / Chromium

• W stronę bezpieczniejszej sieci (2016) — początek wdrażania oznaczenia „Niezabezpieczona”.
• Bezpieczna sieć zostaje z nami (2018) — oznaczanie wszystkich stron HTTP jako niezabezpieczonych od Chrome 68.

Bing / Microsoft

• Wytyczne Bing dla webmasterów — ogólne wytyczne; aktualne sformułowanie dotyczące HTTPS należy potwierdzić w przeglądarce.

Cytaty ze źródeł

Publiczne wypowiedzi Google. Każdy odsyłacz prowadzi bezpośrednio do cytowanego fragmentu strony źródłowej.

Google — ogłoszenie sygnału rankingowego z 2014 roku

• “We’re starting to use HTTPS as a ranking signal. For now it’s only a very lightweight signal—affecting fewer than 1% of global queries, and carrying less weight than other signals such as high-quality content.” (tłumaczenie) „Zaczynamy używać HTTPS jako sygnału rankingowego. Na razie jest to tylko bardzo lekki sygnał — obejmuje mniej niż 1% zapytań globalnych i ma mniejszą wagę niż inne sygnały, takie jak treść wysokiej jakości”. — Zineb Ait Bahajji i Gary Illyes, Google. Przejdź do cytatu
• “But over time, we may decide to strengthen it, because we’d like to encourage all website owners to switch from HTTP to HTTPS.” (tłumaczenie) „Z czasem możemy jednak postanowić go wzmocnić, ponieważ chcielibyśmy zachęcić wszystkich właścicieli witryn do przejścia z HTTP na HTTPS”. — ten sam wpis. Przejdź do cytatu

Gary Illyes — HTTPS jako rozstrzygnięcie remisu

• “With the HTTPS ranking boost, it acts more like a tiebreaker. For example, if all quality signals are equal for two results, then the one that is on HTTPS would get … or may get … the extra boost that is needed to trump the other result.” (tłumaczenie) „Wzrost związany z HTTPS działa raczej jak rozstrzygnięcie remisu. Jeśli wszystkie sygnały jakości dwóch wyników są równe, ten na HTTPS otrzyma — lub może otrzymać — dodatkową przewagę potrzebną do wyprzedzenia drugiego”. — Gary Illyes, Google (za Search Engine Land). Przeczytaj omówienie
• “You should switch to HTTPS for users, not as a ranking signal.” (tłumaczenie) „Na HTTPS należy przejść dla użytkowników, nie ze względu na sygnał rankingowy”. — Gary Illyes, SMX East 2015 (za Search Engine Land). Przeczytaj omówienie
• “Basically looking at the first five characters in front of the URL, and if it’s HTTPS … it will get a minimal boost.” (tłumaczenie) „Zasadniczo sprawdza pierwszych pięć znaków przed adresem URL i jeśli jest to HTTPS, otrzyma on minimalną przewagę”. — Gary Illyes, 2016 (za Search Engine Land). Przeczytaj omówienie

Google — preferencja kanoniczna HTTPS (aktualne wytyczne)

• “Google prefers HTTPS pages over equivalent HTTP pages as canonical, except when there are issues or conflicting signals such as the following.” (tłumaczenie) „Google preferuje strony HTTPS jako kanoniczne względem równoważnych stron HTTP, chyba że występują problemy lub sprzeczne sygnały, takie jak poniższe”. — Google Search Central. Przejdź do cytatu
• “Avoid bad TLS/SSL certificates and HTTPS-to-HTTP redirects because they cause Google to prefer HTTP very strongly.” (tłumaczenie) „Unikaj wadliwych certyfikatów TLS/SSL i przekierowań z HTTPS do HTTP, ponieważ sprawiają one, że Google bardzo silnie preferuje HTTP”. — Google Search Central. Przejdź do cytatu
• “Implementing HSTS cannot override this strong preference.” (tłumaczenie) „Wdrożenie HSTS nie może nadpisać tej silnej preferencji”. — Google Search Central. Przejdź do cytatu

Google — wytyczne dotyczące migracji i HSTS

• “301 and other permanent redirects don’t cause a loss in PageRank.” (tłumaczenie) „301 i inne stałe przekierowania nie powodują utraty PageRank”. — Google Search Central. Przejdź do cytatu
• “If you’re moving your site from HTTP to HTTPS, you don’t need to use the Change of Address tool.” (tłumaczenie) „Jeśli przenosisz witrynę z HTTP do HTTPS, nie musisz używać narzędzia Change of Address”. — Google Search Central. 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 masz pewności, że działanie witryny jest wystarczająco niezawodne, aby nigdy nie wdrożyć HTTPS z błędami walidacji certyfikatu”. — web.dev (Google). Przejdź do cytatu
• “In some cases, TLS can improve performance, mostly as a result of making HTTP/2 possible.” (tłumaczenie) „W niektórych przypadkach TLS może poprawić wydajność, głównie dzięki umożliwieniu HTTP/2”. — web.dev (Google). Przejdź do cytatu

Chrome — wdrożenie oznaczenia „Niezabezpieczona”

• “Beginning in July 2018 with the release of Chrome 68, Chrome will mark all HTTP sites as ‘not secure’.” (tłumaczenie) „Od lipca 2018 roku, wraz z wydaniem Chrome 68, Chrome będzie oznaczać wszystkie witryny HTTP jako ‘niezabezpieczone’”. — Emily Schechter, Chrome Security (Chromium Blog). Przejdź do cytatu

Lista kontrolna migracji HTTP → HTTPS

Skrócona wersja przed wdrożeniem. Pełna lista wykonawcza, próba na środowisku testowym i plan wycofania znajdują się w materiale Migracja HTTP do HTTPS.

Przed zmianą

• Zapisano pełne skanowanie działającej witryny HTTP (każde 200 i wszystkie istniejące przekierowania).
• Zarchiwizowano stan pozycji, eksport Search Console i profil linków zwrotnych.
• Uzyskano i przetestowano certyfikat TLS (bezpłatny certyfikat DV wystarczy dla sygnału).

Przełączenie

• Każdy URL HTTP jest przekierowany 301 po stronie serwera, jeden do jednego, do odpowiednika HTTPS.
• Brak łańcuchów przekierowań (stary URL prowadzi bezpośrednio do docelowego HTTPS).
• Brak masowego przekierowania niedopasowanych adresów na stronę główną.
• Każda strona wskazuje własny URL HTTPS w rel="canonical".
• Linki wewnętrzne, mapy XML i hreflang zaktualizowano do HTTPS — nie pozostawiono ich przekierowaniom.
• Naprawiono aktywną mieszaną zawartość (skrypty, style, iframe), ponieważ jest blokowana.
• Naprawiono pasywną mieszaną zawartość (obrazy, multimedia) i ustawiono CSP upgrade-insecure-requests.

Search Console i działania po zmianie

• Zweryfikowano usługę HTTPS w GSC (lub usługę domenową obejmującą wszystkie warianty).
• Przesłano nową mapę witryny HTTPS.
• Nie użyto narzędzia Change of Address (służy tylko zmianom domeny).
• Przejrzano plik disavow, jeśli istnieje, pod kątem adresów HTTP.
• Przekierowania utrzymano co najmniej rok — najlepiej przez cały okres działania witryny.
• Monitoruje się indeksowanie i Crawl Stats; spadek, który się nie odbudowuje, oznacza usterkę.

Modele myślowe

1. HTTPS to higiena, nie dźwignia wzrostu. „Bardzo lekki”, mniej niż 1% zapytań, rozstrzygnięcie remisu. Wysiłek rankingowy przeznacz na treść i linki; wdroż HTTPS, bo wymaga go współczesna sieć, a następnie przejdź dalej.

2. Oddziel sygnał rankingowy z 2014 roku od obecnej preferencji kanonicznej. Historyczny sygnał rankingowy opierał się na schemacie — zdanie Illyesa o „pierwszych pięciu znakach” go opisuje, ale jest komentarzem z datą, nie obecnie udokumentowanym mechanizmem. Dzisiejsza preferencja kanoniczna HTTPS Google jest inna i warunkowa: zły certyfikat, niezabezpieczone zależności lub przekierowanie obniżające bezpieczeństwo mogą skierować Google do zindeksowania strony HTTP. Uszkodzony certyfikat to zatem nie tylko awaria UX — może też kosztować canonical HTTPS.

3. Migrację niosą przekierowania 301 — wszystko inne jest sygnałem wspierającym. Przekierowania, które nie tracą PageRank, wykonują właściwą pracę przenoszenia pozycji. Canonicale, mapy witryn, aktualizacja linków wewnętrznych i ponowna weryfikacja GSC jedynie pomagają Google przetworzyć zmianę szybciej i czyściej.

4. Dwie warstwy „wymuszania HTTPS” — potrzebujesz obu. Serwerowe 301 służy robotom i wartości linków. HSTS (widoczne tylko przeglądarce 307) chroni powracających użytkowników i zabezpiecza przed SSL stripping. Rozwiązują różne problemy; HSTS nigdy nie zastępuje 301.

5. Mieszana zawartość: ustal priorytet według zachowania przeglądarki. Aktywna (skrypty/style/iframe) jest blokowana → jej naprawa przywraca działanie, więc zrób ją najpierw. Pasywna (obrazy/multimedia) tylko ostrzega → napraw ją jako następną. upgrade-insecure-requests stanowi siatkę bezpieczeństwa dla pominiętych elementów.

HTTPS w SEO — ściągawka

Rzeczywisty wpływ na pozycje

Fakty o przekierowaniach i migracji

Mieszana zawartość i HSTS

Wymuś HTTPS i ustaw HSTS

Przykłady dla dwóch najpopularniejszych stosów. Najpierw przetestuj je na środowisku testowym — nagłówek HSTS jest trwały, a źle skonfigurowana pętla przekierowań odcina użytkowników.

Apache (plik .htaccess)

# 301 every HTTP request to HTTPS
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

# HSTS — only add once you're confident HTTPS is solid
<IfModule mod_headers.c>
  Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"
</IfModule>

Nginx — konfiguracja

# Redirect HTTP → HTTPS
server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://$host$request_uri;
}

# On the HTTPS server block, add HSTS
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;

Dodaj ; preload do nagłówka HSTS tylko wtedy, gdy zamierzasz zgłosić domenę do hstspreload.org — ta decyzja jest niemal nieodwracalna.

Znajdź mieszaną zawartość z wiersza poleceń

Przeskanuj strony HTTPS i wyszukaj w HTML wszystkie pozostałe podzasoby http://.

macOS / Linux — polecenie

# Pull a page and flag insecure script/img/link/iframe sources
curl -s https://example.com/ \
  | grep -Eo '(src|href)="http://[^"]+"' \
  | sort -u

Windows (PowerShell) — polecenie

# Same idea in PowerShell
(Invoke-WebRequest -Uri "https://example.com/").Content `
  | Select-String -Pattern '(src|href)="http://[^"]+"' -AllMatches `
  | ForEach-Object { $_.Matches.Value } | Sort-Object -Unique

Do sprawdzenia całej witryny szybszy od skryptowego przeglądania każdej strony będzie crawler (Ahrefs Site Audit, Screaming Frog) albo konsola Chrome DevTools.

Zasoby warte czasu

Moje wystąpienia

• Lepiej dmuchać na zimne z HTTPS — SMX East 2016 (SlideShare) — moje szczegółowe omówienie TLS, typowych błędów we wdrożeniach HTTPS i pułapek migracji. (Obowiązuje stałe zastrzeżenie: to moje rozumienie tych systemów, a statystyki wdrożeń pochodzą z 2016 roku.)

Moje powiązane artykuły

• Poradnik technicznego SEO dla początkujących — miejsce HTTPS w szerszym obrazie.

Od innych autorów (oficjalne)

• Materiały Google Włączanie HTTPS na serwerach i Naprawianie mieszanej zawartości — najbardziej użyteczny, skondensowany zestaw dokumentów wdrożeniowych.
• hstspreload.org — sprawdź, czy domena spełnia wymagania, zanim zobowiążesz się do preload.
• SSL Labs Server Test — oceń konfigurację TLS.

Z branży

• HTTPS jako czynnik rankingowy — Search Engine Journal — analiza sygnału, jego rzeczywistej wagi i tego, dlaczego pozostaje raczej rozstrzygnięciem remisu niż dźwignią wzrostu.
• Gary Illyes z Google: HTTPS może rozstrzygać remis między dwoma równymi wynikami wyszukiwania (Search Engine Land) — pierwotna relacja z ujęcia Illyesa jako „rozstrzygnięcia remisu”.
• Google zaczyna przyznawać bezpiecznym witrynom HTTPS/SSL przewagę rankingową (Search Engine Land) — omówienie ogłoszenia z 2014 roku i pierwszych reakcji branży.
• HSTS — czym jest i jak go używać (Kinsta) — praktyczny poradnik wdrożeniowy obejmujący ryzyko listy preload i ostrzeżenia przed uzależnieniem od tej konfiguracji.
• Let’s Encrypt — bezpłatny, zautomatyzowany urząd certyfikacji DV, szeroko wykorzystywany przez witryny, które potrzebują schematu https:// bez płacenia za OV/EV.
• HTTPS jest proste (Troy Hunt) — krótka seria filmów wyjaśniająca konfigurację TLS osobom zaczynającym od podstaw.

Statystyki warte cytowania

• “HTTPS is a very lightweight signal—affecting fewer than 1% of global queries.” (tłumaczenie) „HTTPS to bardzo lekki sygnał, obejmujący mniej niż 1% zapytań globalnych”. Tak Google opisywało wagę sygnału w chwili jego uruchomienia w 2014 roku — to liczba historyczna, nadal najlepsza do korygowania oczekiwań, ale nie ponowne stwierdzenie obecnego mechanizmu. Źródło
• “Chrome will mark all HTTP sites as not secure.” (tłumaczenie) „Chrome będzie oznaczać wszystkie witryny HTTP jako niezabezpieczone”; dotyczy to wszystkich stron HTTP od Chrome 68, czyli od lipca 2018 roku. Najbardziej widoczny praktyczny powód migracji. Źródło
• Około 89% witryn korzysta obecnie z HTTPS. To podstawowy standard — ryzyko SEO polega na pozostaniu wyjątkiem, nie na wielkości zysku po przełączeniu (W3Techs, 2026; potwierdź aktualną wartość).
• “301 and other permanent redirects don’t cause a loss in PageRank.” (tłumaczenie) „Przekierowania 301 i inne stałe przekierowania nie powodują utraty PageRank”. Jednoznaczne stwierdzenie Google, które obala mit o utracie wartości linków przy migracji. Źródło

Sprawdź się: HTTPS w SEO

Pięć krótkich pytań o HTTPS w SEO. Wybierz odpowiedź na każde z nich, a następnie sprawdź wynik.

Dziennik zmian