Raport HTTPS

TL;DR — Raport HTTPS w Google Search Console informuje, ile Twoich stron Google pokazuje w bezpiecznej wersji HTTPS, a ile w starej, niezabezpieczonej wersji HTTP — oraz dlaczego w przypadku tych HTTP. Google woli wersję HTTPS, więc zdrowa witryna powinna mieć tutaj wynik bliski 100% HTTPS.

Czym jest raport HTTPS

Jeśli stronę można otworzyć zarówno pod http://example.com/page, jak i pod https://example.com/page, Google zasadniczo chce pokazywać w wynikach wersję HTTPS (bezpieczną). Raport HTTPS to karta wyników pokazująca, jak dobrze dzieje się to w Twojej witrynie: zlicza, ile zindeksowanych stron korzysta z HTTPS, a ile nadal tkwi na HTTP.

Kilka rzeczy warto wiedzieć przed lekturą:

• Obejmuje tylko strony, które Google zindeksował — nie każdą stronę w witrynie.
• Pokazuje próbkę, a nie kompletną listę. Nie traktuj tej liczby jak dokładnego inwentarza.

Dlaczego pojawia się strona HTTP

Gdy strona pojawia się jako HTTP, zwykle nie oznacza to, że zabezpieczenia są zepsute. Może to oznaczać kilka różnych rzeczy: coś w witrynie mówi Google, aby preferował HTTP, wersji HTTPS brakuje albo zwraca błąd, Google przestał sprawdzać witrynę po błędach obejmujących całą witrynę albo URL jest po prostu nowy i nie został jeszcze oceniony. Zacznij od typowych przyczyn poniżej — każda jest sygnałem, który możesz znaleźć i przełączyć:

• Tag „canonical” na stronie wskazuje adres HTTP.
• Mapa witryny zawiera wersję HTTP URL-u.
• Wersja HTTPS przekierowuje z powrotem do HTTP (zły kierunek).
• Wersja HTTPS jest zablokowana w robots.txt.
• Certyfikat SSL jest rzeczywiście uszkodzony.

Co z tym zrobić

Wybierz odpowiadającą przyczynę i przełącz sygnał tak, aby wskazywał HTTPS — napraw tag canonical, zaktualizuj mapę witryny, popraw przekierowanie tak, aby HTTP prowadził do HTTPS (nigdy odwrotnie) albo uporządkuj certyfikat. Następnie poproś Google o ponowne sprawdzenie strony (URL Inspection pozwala poprosić o ponowne crawlowanie). Z czasem liczba HTTPS powinna rosnąć w kierunku 100%.

Co większość ludzi rozumie błędnie

HTTPS nie jest dużym czynnikiem rankingowym. To prawdziwy, ale bardzo lekki sygnał. Przejdź na HTTPS dla bezpieczeństwa, zaufania odwiedzających oraz czystych danych analitycznych i URL-i canonical — nie dlatego, że przesunie Cię wyżej w wynikach. Jeśli widzisz “HTTPS not evaluated,”, nie zakładaj, że to nieszkodliwe — może to oznaczać brak wersji HTTPS, wycofanie się Google po błędach całej witryny, wybór HTTP jako canonical albo (jedyny przypadek naprawdę niskiego ryzyka) URL, który jest po prostu nowy i nie został jeszcze crawlowany. Sprawdź, która sytuacja zachodzi, zanim zdecydujesz, czy coś naprawiać, czy tylko czekać.

Chcesz poznać pełne omówienie każdego wiersza błędu oraz związek z kanonikalizacją i raportem Page Indexing? Przejdź do karty Advanced.

TL;DR — Raport HTTPS pokazuje, ile Twoich zindeksowanych URL-i Google obsługuje przez HTTPS, a ile przez HTTP — to próbka, nie kompletna lista. Google preferuje indeksowanie wersji HTTPS każdej strony dostępnej w obu protokołach, ale wiersz HTTP nie musi oznaczać, że sprzeczny sygnał pokonał tę domyślną preferencję — może również wskazywać brak odpowiednika HTTPS, błąd przetwarzania całej witryny albo naprawdę nowy/nieprzecrawlowany URL. Preferencja HTTPS jest jednym z wielu sygnałów ważonych przez Google przy wyborze canonical; raport HTTPS, raport Page Indexing i URL Inspection są powiązane, ale nie są zamienne. HTTPS to lekki sygnał rankingowy — napraw te problemy dla zaufania i czystej kanonikalizacji, a nie dla wzrostu pozycji.

Co raport rzeczywiście mierzy

Wprost z dokumentacji: “The HTTPS report shows how many indexed URLs on your site are HTTP vs HTTPS.” (tłumaczenie) „Raport HTTPS pokazuje, ile zindeksowanych URL-i w witrynie korzysta z HTTP, a ile z HTTPS”. Dwa zastrzeżenia wykonują tu dużą część pracy, a większość osób pomija oba.

Po pierwsze, zindeksowane — raport obejmuje URL-e, które Google już zindeksował, a nie cały zbiór URL-i. Po drugie, jest to próbka: “The report isn’t a comprehensive list of all detected items.” (tłumaczenie) „Raport nie jest kompletną listą wszystkich wykrytych elementów”. To narzędzie diagnostyczne, a nie inwentarz. Jeśli próbujesz uzgodnić tę liczbę z całkowitą liczbą stron, przestań — dotyczą innej populacji. Raport jest dostępny dla właściwości domenowych i właściwości z prefiksem URL HTTPS.

Search Console dopasowuje każdy URL HTTP do jego odpowiednika HTTPS, ignorując parametry — dlatego ciągi zapytania takie jak ?utm_source= nie psują dopasowania. Nie traktuje jednak URL-u HTTPS o innej strukturze jako bezpiecznej wersji URL-u HTTP. Jeśli migracja zmieniła ścieżki, a nie tylko protokół, ta strona HTTPS nie zarejestruje się tutaj jako odpowiednik, nawet jeśli działa poprawnie. Ponieważ jest to próbka zindeksowanej populacji, a nie bieżący crawl każdego posiadanego URL-u, brak URL-u w raporcie nie musi oznaczać, że wszystko jest w porządku — URL może być po prostu jeszcze niezindeksowany albo nie trafić do próbki. Używaj raportu do wykrywania wzorców, a nie jako kompletnego audytu URL po URL-u.

Dlaczego w ogóle pojawiają się wiersze HTTP

Oto model mentalny, dzięki któremu raport staje się zrozumiały: “If your site has a page with both an HTTP and HTTPS address, Google prefers to index the HTTPS version.” (tłumaczenie) „Jeśli witryna ma stronę zarówno pod adresem HTTP, jak i HTTPS, Google woli indeksować wersję HTTPS”. Preferencja HTTPS jest domyślna — ale wiersz HTTP nie zawsze oznacza, że silniejszy sygnał ją nadpisał. Przeanalizuj przyczyny w tej kolejności:

1. Brakujący albo błędny HTTPS. Nie ma jeszcze działającego odpowiednika HTTPS albo zwraca on błąd.
2. Sprzeczny sygnał. Coś w witrynie jawnie głosuje za HTTP — tag canonical, wpis w mapie witryny, przekierowanie w złym kierunku albo blokada robots. To obejmuje pięć nazwanych poniżej powodów.
3. Błąd przetwarzania całej witryny. Google napotkał tyle błędów, że wycofał się z przetwarzania URL-i w kolejce, albo problem obejmujący całą witrynę (np. uszkodzony certyfikat) blokuje ocenę wszędzie.
4. Naprawdę nowy albo nieprzecrawlowany URL. Google go nie widział albo widział, ale jeszcze go nie craw­lował — to jedyny przypadek, w którym własne wskazówki Google mówią o krótkim oczekiwaniu (około doby) przed ponownym sprawdzeniem.

HTTPS względem HTTP jest jednym z wielu sygnałów ważonych przez Google przy wyborze kanonicznego URL-u — nie jest stałą liczbą i nie będę powtarzać dokładnej wartości bez źródła, które mogę zweryfikować. Każdy nazwany wiersz błędu poniżej pasuje do przyczyny nr 2; „HTTPS not evaluated” obejmuje przyczyny nr 1, 3 i 4.

Wiersze błędów — „dlaczego strony HTTP nie są obsługiwane przez HTTPS”

To wiersze statusu raportu. Każdy jest konkretnym sprzecznym sygnałem i każdy ma konkretną naprawę.

• HTTP oznaczony tagiem canonical — “The HTTP page has a <link rel="canonical"> tag, indicating that the HTTP version is canonical.” (tłumaczenie) „Strona HTTP ma tag <link rel="canonical"> wskazujący, że wersja HTTP jest kanoniczna”. Jawnie poinformowałeś Google, że preferowany jest URL HTTP. Naprawa: wskaż jako canonical URL HTTPS.
• HTTPS ma nieważny certyfikat — “The HTTPS URL has an invalid SSL certificate.” (tłumaczenie) „URL HTTPS ma nieważny certyfikat SSL”. Google nie sprawdzi URL-u HTTPS, jeśli certyfikat nie jest ważny, a problem zwykle dotyczy całej witryny, a nie jednej strony. Napraw certyfikat.
• Mapa witryny wskazuje HTTP — “A sitemap on your site is pointing to an HTTP URL that was indexed as canonical.” (tłumaczenie) „Mapa witryny wskazuje URL HTTP, który został zindeksowany jako kanoniczny”. Mapa witryny głosuje za HTTP. Naprawa: zaktualizuj mapę witryny, aby wymieniała URL-e HTTPS.
• HTTPS ma przekierowanie — “The HTTPS URL exists, but redirects to an HTTP URL.” (tłumaczenie) „URL HTTPS istnieje, ale przekierowuje do URL-u HTTP”. To przekierowanie w złym kierunku. Prawidłowy kierunek to zawsze HTTP → HTTPS, nigdy odwrotnie. W technicznym badaniu SEO Ahrefs obejmującym ponad milion domen istotna część witryn robi to dokładnie odwrotnie.
• URL HTTPS jest zablokowany przez robots — “The HTTPS URL is present, but is blocked from crawling by a robots.txt rule.” (tłumaczenie) „URL HTTPS istnieje, ale reguła robots.txt blokuje jego crawlowanie”. Google nie może craw­lować wersji HTTPS, aby ją potwierdzić, więc wraca do HTTP. Naprawa: odblokuj URL HTTPS w robots.txt.
• HTTPS not evaluated — status zbiorczy, a nie pojedyncza awaria. Dokumentacja mówi, że “This error can be caused by any of the following conditions” (tłumaczenie) „Ten błąd może być spowodowany dowolnym z poniższych warunków”: URL HTTP nie ma odpowiednika HTTPS; oba istnieją, ale z jakiegoś powodu Google wybrał HTTP jako canonical; Google napotkał tyle błędów dowolnego typu, że przerwał przetwarzanie URL-i w kolejce; istnieje błąd całej witryny (np. zły certyfikat SSL); albo Google nigdy nie widział URL-u lub go widział, ale jeszcze nie craw­lował. Nie uznawaj domyślnie tego statusu za nieszkodliwy — przeprowadź triage według przyczyny. Naprawdę nowy lub nieprzecrawlowany URL to jedyny przypadek, dla którego Google daje warunkową wskazówkę (odczekaj około doby po crawlu przed ponownym sprawdzeniem); brakujący odpowiednik HTTPS, wybór HTTP jako canonical albo błąd całej witryny to realne problemy wymagające naprawy, a nie przeczekania.
• Inne problemy — “Another error occurred that is not covered in the list of errors.” (tłumaczenie) „Wystąpił inny błąd, którego nie obejmuje lista błędów”.

Ważna korekta popularnego mitu: aktualna strona pomocy nie wymienia wiersza „noindex” ani wiersza „HSTS”. To pojęcia powiązane, które warto rozumieć — noindex na stronie HTTPS rzeczywiście może uniemożliwić jej zindeksowanie i wyświetlanie, a HSTS wymusza HTTPS na poziomie przeglądarki i wspiera prawidłowe przekierowania — ale nie są kategoriami tego raportu. Nie szukaj wierszy, których tam nie ma.

Jak łączą się preferencja HTTPS, kanonikalizacja i raport Page Indexing

Raport HTTPS nie jest samodzielnym narzędziem, ale nie jest też wymienny z narzędziami pokrewnymi. Trzy różne powierzchnie Search Console mogą dotyczyć tego samego URL-u, a każda mówi coś innego:

Mogą mieć wspólną przyczynę — konflikt canonical może pojawić się tutaj jako wiersz HTTP, a w Page Indexing jako „Duplicate, Google chose a different canonical” — ale to hipoteza do zweryfikowania dla każdego URL-u, a nie gwarantowane odwzorowanie jeden do jednego. Sprawdź URL Inspection dla konkretnej strony, zanim założysz, że oba raporty opisują ten sam problem.

Treść mieszana i niezabezpieczone zależności

Treść mieszana — strona HTTPS, która ładuje zasoby HTTP (obrazy, skrypty, arkusze stylów) — nie jest nazwanym wierszem w tym raporcie, a aktualna dokumentacja Google nie wymienia jej jako przyczyny raportu HTTPS. Nadal warto ją naprawić dla niej samej: przeglądarki ostrzegają przed nią albo ją blokują, a to realna luka bezpieczeństwa. Nie diagnozuj jej przez ten raport — jeśli strona nadal pokazuje się tu jako HTTP po wykluczeniu pięciu nazwanych powodów, potraktuj treść mieszaną jako osobną kontrolę (Chrome DevTools albo crawler witryny), a nie jako wyjaśnienie raportu. To samo dotyczy HSTS: jest użytecznym mechanizmem na poziomie przeglądarki, ale również nie jest wierszem raportu.

HTTPS jako sygnał rankingowy — uczciwa wersja

HTTPS jest przedstawiany jako czynnik rankingowy od 2014 roku, gdy ogłosił to zespół webmasterów Google (Zineb Ait Bahajji i Gary Illyes) — wówczas relacjonowano go jako lekki sygnał o mniejszej wadze niż takie elementy jak jakość treści. Nie udało mi się ponownie potwierdzić dokładnego brzmienia wpisu z 2014 roku na podstawie aktualnej kopii, więc traktuj precyzyjną liczbę jako relację, a nie dosłowną gwarancję; trwały wniosek pozostaje prawdziwy niezależnie od dokładnej wartości — HTTPS nigdy nie był przedstawiany jako silna dźwignia rankingowa. HTTPS jest również częścią szerszych wskazówek dotyczących page experience. I żeby było jasne, nic z tego nie pochodzi z samego raportu HTTPS: raport nie pokazuje wpływu na ranking, kliknięć ani ruchu — jest wyłącznie diagnostyką implementacji protokołu. Uczciwe ujęcie brzmi więc: napraw problemy HTTPS dla bezpieczeństwa, zaufania użytkowników, czystych danych odesłań w analityce i uporządkowanej kanonikalizacji — nie dla wzrostu pozycji. To warunek podstawowy, nie dźwignia wzrostu.

Naprawa i potwierdzenie

Przepływ pracy jest taki sam niezależnie od tego, który wiersz śledzisz — i zaczyna się od przyczyny, a nie etykiety wiersza:

1. Zidentyfikuj przyczynę. Raport daje próbkowany punkt wyjścia — potwierdź, co rzeczywiście się dzieje: brak HTTPS, sprzeczny sygnał, błąd całej witryny czy naprawdę nowy URL.
2. Napraw to u źródła. Popraw canonical, wpis w mapie witryny, kierunek przekierowania, regułę robots albo certyfikat. Usunięcie linków do objętego problemem URL-u nie jest naprawą — ukrywa objaw bez rozwiązania przyczyny.
3. Potwierdź przez URL Inspection, sprawdzając osobno bieżący test i stan zindeksowania — tuż po naprawie mogą się nie zgadzać.
4. Obserwuj próbkowaną kohortę, a nie tylko jeden URL. Raport HTTPS przeklasyfikowuje URL-e według własnego harmonogramu; nie ma tu uniwersalnego SLA, które można obiecać. Jedyny przypadek z warunkową wskazówką to naprawdę nowy, nieprzecrawlowany URL — odczekaj mniej więcej dobę przed ponownym sprawdzeniem.

Przeprowadziłem migracje wielu witryn między protokołami (moja prelekcja SMX East 2016 Bezpieczniej dmuchać na zimne z HTTPS jest dłuższą wersją), a powtarzająca się lekcja jest taka sama: sama obecność wersji HTTPS nie wystarczy. Jeśli tagi canonical, mapy witryn albo przekierowania nadal wskazują HTTP, Google z przyjemnością będzie dalej indeksować HTTP. Spraw, by wszystkie sygnały były zgodne, a ten raport sam się uporządkuje.

Podsumowanie AI

Skrócona wersja karty Advanced:

• Co mierzy: ile Twoich zindeksowanych URL-i Google obsługuje przez HTTPS, a ile przez HTTP. To próbka, nie kompletna lista, dostępna dla właściwości domenowych i właściwości z prefiksem URL HTTPS. Dopasowanie ignoruje parametry URL, ale nie zmienioną strukturę URL-u.
• Domyślna preferencja: Google woli indeksować wersję HTTPS każdej strony istniejącej w obu protokołach — ale wiersz HTTP nie zawsze oznacza, że pokonał ją sprzeczny sygnał. Sprawdzaj kolejno: brakujący/błędny HTTPS, sprzeczny sygnał (pięć nazwanych wierszy poniżej), błąd przetwarzania całej witryny albo naprawdę nowy/nieprzecrawlowany URL.
• Siedem wierszy: HTTP oznaczony tagiem canonical · nieważny certyfikat HTTPS · mapa witryny wskazuje HTTP · przekierowanie HTTPS (błędne HTTPS→HTTP) · URL HTTPS zablokowany przez robots · HTTPS not evaluated (status zbiorczy — triage według przyczyny, nie zakładaj nieszkodliwości) · inne problemy.
• Obalanie mitów: aktualna strona pomocy nie ma wiersza „noindex”, wiersza „HSTS” ani wiersza „mixed content” — to pojęcia powiązane, nie kategorie raportu.
• Trzy powiązane powierzchnie: raport HTTPS (próbkowany widok protokołu), raport Page Indexing (stan indeksowania i wybrany canonical) oraz URL Inspection (stan zindeksowania a stan bieżący). Mogą mieć wspólną przyczynę, ale to hipoteza do sprawdzenia dla każdego URL-u, a nie gwarantowane dopasowanie.
• Ranking: HTTPS to lekki sygnał (wprowadzony w 2014 roku) i część page experience — ale sam raport nie pokazuje żadnych danych o rankingu, kliknięciach ani ruchu. Naprawiaj dla zaufania i czystej kanonikalizacji, nie dla wzrostu pozycji.
• Pętla naprawy: zidentyfikuj konkretną przyczynę → napraw ją u źródła (nie usuwaj tylko linków) → potwierdź przez bieżący test URL Inspection i osobno stan zindeksowania → obserwuj kohortę, aż trend zbliży się do 100% HTTPS, bez obiecywania terminu.

Dokumentacja oficjalna

Dokumentacja źródłowa Google.

Google

• Raport HTTPS — pomoc Search Console — co pokazuje raport, wiersze błędów i przyczyny statusu „HTTPS not evaluated”.
• Nowy raport HTTPS w Search Console (wrzesień 2022) — ogłoszenie uruchomienia raportu.
• HTTPS jako sygnał rankingowy (sierpień 2014) — pierwotne ogłoszenie dotyczące sygnału rankingowego.
• Domyślne indeksowanie stron HTTPS (grudzień 2015) — tło domyślnego indeksowania HTTPS przez Google.
• Kanonikalizacja URL-i — miejsce preferencji HTTPS wśród sygnałów canonical Google.
• Konsolidowanie zduplikowanych URL-i (rel=canonical) — deklarowanie URL-u HTTPS jako canonical.
• Zrozumienie page experience — miejsce HTTPS w page experience.

Cytaty ze źródła

Wypowiedzi Google z przypisaniem autorstwa. Każdy link jest deep linkiem prowadzącym do cytowanego fragmentu na stronie źródłowej.

Google — co pokazuje raport

• “The HTTPS report shows how many indexed URLs on your site are HTTP vs HTTPS.” (tłumaczenie) „Raport HTTPS pokazuje, ile zindeksowanych URL-i w witrynie korzysta z HTTP, a ile z HTTPS”. — pomoc Search Console. Przejdź do cytatu
• “The report isn’t a comprehensive list of all detected items.” (tłumaczenie) „Raport nie jest kompletną listą wszystkich wykrytych elementów”. — pomoc Search Console. Przejdź do cytatu
• “If your site has a page with both an HTTP and HTTPS address, Google prefers to index the HTTPS version.” (tłumaczenie) „Jeśli witryna ma stronę zarówno pod adresem HTTP, jak i HTTPS, Google woli indeksować wersję HTTPS”. — pomoc Search Console. Przejdź do cytatu

Google — wiersze błędów

• “The HTTP page has a <link rel="canonical"> tag, indicating that the HTTP version is canonical.” (tłumaczenie) „Strona HTTP ma tag <link rel="canonical"> wskazujący, że wersja HTTP jest kanoniczna”. — pomoc Search Console. Przejdź do cytatu
• “The HTTPS URL has an invalid SSL certificate.” (tłumaczenie) „URL HTTPS ma nieważny certyfikat SSL”. — pomoc Search Console. Przejdź do cytatu
• “A sitemap on your site is pointing to an HTTP URL that was indexed as canonical.” (tłumaczenie) „Mapa witryny wskazuje URL HTTP, który został zindeksowany jako kanoniczny”. — pomoc Search Console. Przejdź do cytatu
• “The HTTPS URL exists, but redirects to an HTTP URL.” (tłumaczenie) „URL HTTPS istnieje, ale przekierowuje do URL-u HTTP”. — pomoc Search Console. Przejdź do cytatu
• “The HTTPS URL is present, but is blocked from crawling by a robots.txt rule.” (tłumaczenie) „URL HTTPS istnieje, ale reguła robots.txt blokuje jego crawlowanie”. — pomoc Search Console. Przejdź do cytatu
• “Another error occurred that is not covered in the list of errors.” (tłumaczenie) „Wystąpił inny błąd, którego nie obejmuje lista błędów”. — pomoc Search Console. Przejdź do cytatu

Google — HTTPS jako sygnał rankingowy (sierpień 2014)

• “very lightweight signal — affecting fewer than 1% of global queries, and carrying less weight than other signals such as high-quality content.” (tłumaczenie) „Bardzo lekki sygnał — wpływający na mniej niż 1% globalnych zapytań i mający mniejszą wagę niż inne sygnały, takie jak treści wysokiej jakości”. — Zineb Ait Bahajji i Gary Illyes, Google Webmaster Central Blog, 2014. Przeczytaj ogłoszenie

Wiersze błędów — ściąga

Znaczenie każdego wiersza i naprawa. (Pamiętaj: raport obejmuje próbkę zindeksowanych URL-i. Wiersz HTTP może oznaczać, że sprzeczny sygnał pokonał domyślną preferencję HTTPS Google — ale może też oznaczać brakujący odpowiednik HTTPS, błąd przetwarzania całej witryny albo URL, który jest po prostu nowy i nie został oceniony. Sprawdź konkretny wiersz.)

Nie w tym raporcie (popularny mit): aktualna strona pomocy nie ma wiersza „noindex”, wiersza „HSTS” ani wiersza „mixed content”. To pojęcia powiązane, a nie kategorie raportu.

Szybkie fakty

• Zakres: tylko zindeksowane URL-e i próbka — nie pełny inwentarz.
• Dostępność: właściwości domenowe i z prefiksem URL HTTPS.
• Domyślna preferencja: Google woli indeksować wersję HTTPS, gdy istnieją obie — ale wiersz HTTP nie oznacza automatycznie, że „sygnał pokonał HTTPS”; sprawdź, czy HTTPS nie brakuje, ocena nie utknęła albo URL nie jest po prostu nowy.
• Właściwy kierunek przekierowania: HTTP → HTTPS (nigdy HTTPS → HTTP).
• Waga rankingowa: lekka, w 2014 roku opisywana jako dotycząca mniej niż 1% zapytań — a sam raport w ogóle nie pokazuje danych rankingowych.

Lista kontrolna triage wiersza HTTP

Gdy URL pojawia się jako HTTP, przejdź przez tę listę, aby znaleźć sprzeczny sygnał:

• Tag canonical — czy rel="canonical" strony HTTP wskazuje HTTP? Przekieruj go na URL HTTPS.
• Mapa witryny — czy któraś mapa wymienia wersję HTTP? Zastąp ją URL-ami HTTPS.
• Przekierowania — czy URL HTTPS przekierowuje z powrotem do HTTP? Odwróć je, aby działały HTTP → HTTPS.
• robots.txt — czy URL HTTPS jest zablokowany przed crawlowaniem? Odblokuj go.
• Certyfikat SSL — czy certyfikat jest ważny dla całej witryny? Google nie sprawdzi HTTPS, dopóki taki nie będzie.
• Treść mieszana — czy strona HTTPS ładuje zasoby HTTP (niezabezpieczone zależności)? Przełącz je na HTTPS.
• „HTTPS not evaluated”? — nie zakładaj, że „wszystko jest w porządku”. Sprawdź, która przyczyna zachodzi: brak HTTPS, wybór HTTP jako canonical, błąd całej witryny albo (jedyny przypadek niskiego ryzyka) naprawdę nowy/nieprzecrawlowany URL.
• Sprawdź ponownie — uruchom URL Inspection, poproś o indeksowanie i zaczekaj na ponowną ocenę.
• Porównaj — zestaw z decyzją canonical w raporcie Page Indexing dla tego samego URL-u.

Modele myślowe

1. Preferencja HTTPS jest domyślna — ale wiersz HTTP może mieć więcej niż jedną przyczynę. Google woli indeksować wersję HTTPS każdego URL-u istniejącego w obu protokołach. Gdy URL pokazuje się jako HTTP, zapytaj kolejno: czy HTTPS jest brakujący albo błędny? Czy coś jawnie głosuje za HTTP (nazwane wiersze powodów)? Czy Google wycofał się po błędach całej witryny? Czy to po prostu nowy URL, do którego Google jeszcze nie dotarł?

2. Każdy wiersz odwzorowuje jeden sprzeczny sygnał. Tag canonical · wpis w mapie witryny · kierunek przekierowania · reguła robots · certyfikat. Znajdź ten, który ma zastosowanie, przełącz go na HTTPS i gotowe. To cała pętla naprawy.

3. „Not evaluated” wymaga triage, a nie domyślnego założenia. Ten status zbiorczy obejmuje realne problemy (brak HTTPS, wybór HTTP jako canonical, błąd całej witryny) oraz jeden naprawdę niskiego ryzyka przypadek (nowy URL, którego Google jeszcze nie craw­lował). Ustal, z czym masz do czynienia, zanim zdecydujesz, czy coś naprawić, czy czekać.

4. Ten raport, Page Indexing i URL Inspection są powiązane, ale nie zamienne. HTTPS względem HTTP jest jednym z wielu sygnałów ważonych przez Google przy wyborze canonical. Raport HTTPS, raport Page Indexing i URL Inspection mogą mieć wspólną przyczynę, ale traktuj to jako hipotezę do potwierdzenia dla każdego URL-u — nie jako gwarantowane odwzorowanie jeden do jednego.

5. Napraw HTTPS dla zaufania, nie dla rankingów. To lekki sygnał rankingowy i część page experience. Prawdziwe korzyści to bezpieczeństwo, zaufanie użytkowników, czyste dane odesłań i jednoznaczna kanonikalizacja.

Udowodnij, że naprawa HTTPS zadziałała

Potwierdź przekierowanie i certyfikat

Test do wykonania — poproś o URL HTTP i prześledź łańcuch przekierowań przez curl -I albo panel sieciowy przeglądarki, a następnie załaduj końcowy URL HTTPS. Oczekiwany wynik — HTTP przekierowuje bezpośrednio w stronę HTTPS, końcowa odpowiedź jest poprawna, a przeglądarka zgłasza ważny certyfikat. Interpretacja niepowodzenia — przekierowanie w złym kierunku, pętla przekierowań albo problem z certyfikatem nadal uniemożliwia czyste miejsce docelowe HTTPS. Okno monitorowania — natychmiast. Wyzwalacz wycofania — wycofaj zmianę przekierowania, jeśli tworzy pętlę, prowadzi do HTTP albo sprawia, że produkcyjny URL jest niedostępny.

Potwierdź zgodność każdego sygnału canonical

Test do wykonania — sprawdź żywą stronę HTTPS i jej wpis w mapie witryny, a następnie sprawdź URL w URL Inspection Search Console. Oczekiwany wynik — canonical strony wskazuje HTTPS, mapa witryny wymienia HTTPS, a sprawdzony URL udostępnia zamierzony canonical HTTPS bez blokady robots. Interpretacja niepowodzenia — co najmniej jeden sygnał na poziomie witryny nadal głosuje za HTTP albo uniemożliwia Google ocenę HTTPS. Okno monitorowania — sygnały witryny są natychmiastowe; wybrany przez Google canonical może wymagać ponownego crawla. Wyzwalacz wycofania — zatrzymaj wdrożenie, jeśli zmiana kieruje canonicale na niewłaściwy zestaw URL-i albo usuwa zamierzone strony z mapy witryny.

Potwierdź brak niezabezpieczonych zależności strony

Test do wykonania — załaduj stronę HTTPS z otwartymi panelami Console i Network w przeglądarce, a następnie przecrawl­uj reprezentatywny zestaw szablonów pod kątem zasobów http://. Oczekiwany wynik — brak aktywnych błędów treści mieszanej i brak wymaganego zasobu żądanego przez HTTP. Interpretacja niepowodzenia — szablony, hosty zasobów albo zapisana treść nadal emitują niezabezpieczone zależności. Okno monitorowania — natychmiast po wdrożeniu. Wyzwalacz wycofania — wycofaj zmianę, jeśli konwersja HTTPS psuje wymagane skrypty, style, obrazy albo ścieżki płatności.

Potwierdź, że Search Console przeklasyfikował URL

Test do wykonania — po ponownym crawlu sprawdź URL Inspection i wiersz kohorty w raporcie HTTPS. Oczekiwany wynik — Google widzi wersję HTTPS, a kohorta błędów HTTP maleje bez odpowiadającej utraty zamierzonych zindeksowanych stron. Interpretacja niepowodzenia — Google jeszcze nie przecrawlow­ał URL-u albo nadal istnieje inny sprzeczny sygnał. Okno monitorowania — poczekaj, aż Google ponownie przecrawluje witrynę i odświeży próbkowany raport; nie traktuj natychmiastowego statusu „not evaluated” jako awarii. Wyzwalacz wycofania — zbadaj albo odwróć zmianę, jeśli zamierzone zindeksowane URL-e spadają, a błędy HTTPS trwają.

Narzędzia do pracy z raportem HTTPS

• Google Search Console — raport HTTPS — sam raport: liczba HTTPS względem HTTP i wiersze “why HTTP isn’t served over HTTPS” (tłumaczenie) „dlaczego HTTP nie jest obsługiwany przez HTTPS”.
• URL Inspection (GSC) — sprawdź, jak pojedynczy URL został crawlowany, wyrenderowany i zindeksowany, zobacz wybrany canonical i poproś o ponowny crawl po naprawie.
• Raport Page Indexing (GSC) — raport pokrewny; potwierdza, czy URL jest zindeksowany i jaki canonical wybrał Google.
• Browser DevTools — panele Security/Console bezpośrednio wskazują treść mieszaną i problemy z certyfikatem.
• Crawlery audytu witryn — Ahrefs Site Audit i Screaming Frog SEO Spider pokazują canonicale wskazujące HTTP, przekierowania w złym kierunku, wpisy HTTP w mapach witryny, blokady robots i treść mieszaną na dużą skalę.
• Ahrefs Webmaster Tools — bezpłatny crawl i audyt dla zweryfikowanych witryn.

Zasoby warte uwagi

Moje wystąpienia

• Bezpieczniej dmuchać na zimne z HTTPS (SMX East 2016, SlideShare) — moja prelekcja o migracji HTTPS, rozszerzona wersja lekcji „spraw, aby każdy sygnał był zgodny”.

Moje powiązane teksty

• Google wykorzystuje około 40 sygnałów kanonikalizacji — miejsce preferencji HTTPS wśród sygnałów canonical.
• 11 typów przekierowań i ich wpływ na SEO — dlaczego kierunek przekierowania zawsze powinien być HTTP → HTTPS.
• Badanie technicznego SEO Ahrefs (ponad milion domen) — rzeczywiste dane o witrynach przekierowujących w złym kierunku i innych problemach protokołu.
• Migracja witryny: kompletny przewodnik — dla odbiorców zajmujących się migracją HTTP→HTTPS.

Od innych autorów

• Raport HTTPS — pomoc Search Console — źródło podstawowe.
• Google uruchamia nowy raport HTTPS w Search Console — relacja Barry’ego Schwartza z uruchomienia w Search Engine Land.
• Nieporozumienia wokół statusu „HTTPS is invalid” w Google Search Console — Search Engine Roundtable dokumentuje rzeczywiste nieporozumienia społeczności wokół tego statusu.
• Dlaczego HTTPS ma znaczenie — wprowadzenie web.dev do znaczenia HTTPS dla bezpieczeństwa, zaufania i wydajności, nie tylko SEO.
• Naprawianie treści mieszanej — poradnik web.dev dotyczący znajdowania i naprawy zasobów HTTP na stronach HTTPS (problem „niezabezpieczonych zależności”, który może osłabić wybór HTTPS jako canonical).
• HTTPS jako sygnał rankingowy (sierpień 2014) — pierwotne ogłoszenie Google opisujące HTTPS jako lekki sygnał.
• r/TechSEO — społeczność do debugowania „HTTPS is invalid / not evaluated”.

Sprawdź się: raport HTTPS

Pięć krótkich pytań o czytaniu i naprawianiu raportu HTTPS w Search Console. Wybierz odpowiedź przy każdym pytaniu, a następnie sprawdź wynik.

Dziennik zmian