Google Search Console — co to jest i jak z niej korzystać w firmie

Google Search Console to narzędzie, które według samego Google ma pomóc każdemu, kto ma stronę, zrozumieć, jak radzi sobie ona w wyszukiwarce — „to understand how they are performing on Google Search" (Google Search Central, aktualizacja 10.12.2025, odczyt 03.10.2026). Pokazuje to, co dzieje się w Google przed kliknięciem: czy strona jest w indeksie, na jakie zapytania się pojawia, na której pozycji i jak często ktoś w nią klika.

Każda z tych liczb ma definicję Google, która różni się od intuicji. Średnia pozycja to najwyższy wynik Twojej witryny uśredniony po zapytaniach, nie średnia wszystkich linków. Wyświetlenie liczy się nawet wtedy, gdy nikt nie przewinął strony wyników. Rzadkie zapytania są wliczone do sumy na wykresie, ale nie ma ich w tabeli. Status „URL is on Google" nie oznacza, że adres pokaże się w wynikach. A prośba o zindeksowanie, po którą sięga się najczęściej, niczego nie gwarantuje. Poniżej każdy raport opisujemy definicjami Google, a na końcu pokazujemy, jak wyglądają one na danych naszego bloga.

Google Search Console — co to jest i do czego służy

Najkrócej, słowami dokumentacji: Search Console „provides information on how Google crawls, indexes, and serves websites" — mówi, jak Google pobiera, indeksuje i pokazuje Twoją stronę (Google Search Central, odczyt 03.10.2026). Narzędzie bywa szukane także jako „searchconsole", „google webmastertool" czy „webmaster google console" — chodzi o tę samą usługę.

Nie musisz się logować codziennie. Google pisze wprost, że o nowych problemach wykrytych na stronie dostaniesz e-mail, a samo konto warto przejrzeć mniej więcej raz w miesiącu albo po zmianach w treści. Mapa witryny nie jest warunkiem pojawienia się w Google — strony mogą zostać odkryte bez niej — ale jej zgłoszenie w Search Console „might speed up your site's discovery" (to samo źródło).

Search Console kończy pracę na kliknięciu; co odwiedzający robi potem, mierzy Google Analytics. Ten podział i to, jak go użyć w diagnozie, opisujemy w tekście o wskaźnikach i celach strony. Tutaj dwie rzeczy, których tam nie ma.

Połączenie z GA4. Po połączeniu usługi Search Console ze strumieniem danych GA4 w Analytics pojawiają się dwa raporty: „Google Organic Search Queries" i „Google Organic Search Traffic". Search Console przechowuje dane z ostatnich 16 miesięcy, więc raporty w Analytics też obejmują najwyżej 16 miesięcy, a dane trafiają do obu narzędzi 48 godzin po zebraniu przez Search Console. Metryki z Search Console łączą się tylko z trzema wymiarami Analytics: stroną docelową, urządzeniem i krajem. Jeden strumień danych łączy się z jedną usługą Search Console (pomoc Google Analytics, odczyt 03.10.2026; strona pomocy nie podaje daty aktualizacji).

Dlaczego kliknięcie w Search Console prawie nigdy nie równa się sesji w GA4. Google odpowiada na to osobnym dokumentem i zaczyna od zastrzeżenia: kliknięcia i sesje liczy się inaczej, więc liczby będą się różnić, a małą rozbieżność można zignorować — ważne, żeby trendy miały ten sam kształt. Przy dużej rozbieżności Google wskazuje te przyczyny (Google Search Central, aktualizacja 07.01.2026, odczyt 03.10.2026):

• Wdrożenie Analytics — GA4 widzi tylko to, co zbiera tag, a na części podstron może go brakować; dane Search Console Google przetwarza jednakowo dla wszystkich usług.
• Zgoda na śledzenie — jeśli użytkownik odmówi, dane w Analytics są zaniżone (szczegóły w tekście o Consent Mode).
• Strefa czasowa — w Analytics ustawiasz własną, Search Console liczy dni w czasie pacyficznym (PT).
• Atrybucja — Analytics przypisuje sesje według modelu atrybucji, Search Console liczy każde kliknięcie w wyszukiwarce.
• Adresy kanoniczne — Search Console raportuje tylko adres kanoniczny w Google, Analytics każdy adres z kodem śledzącym.
• Podział ruchu — Search Console rozbija ruch na web, obrazy, wideo, wiadomości i Discover; Analytics dzieli go inaczej.
• Strony nie-HTML — pliki PDF wyświetlone lub kliknięte w wyszukiwarce są w Search Console, a Analytics może ich nie mierzyć.
• Boty — Analytics automatycznie wyklucza znane boty, Search Console niekoniecznie.

Jak dodać stronę do Google Search Console: usługa domeny czy prefiks URL

Pierwsza decyzja to rodzaj usługi (w dokumentacji: property). Pomoc Google opisuje dwa podstawowe (pomoc Search Console, odczyt 03.10.2026):

• Usługa domeny (Domain property) obejmuje wszystkie subdomeny (m, www i inne) i wszystkie protokoły (http, https, ftp). Wymaga weryfikacji przez rekord DNS, chyba że strona stoi na usłudze Google, takiej jak Blogger czy Google Sites.
• Usługa z prefiksem URL (URL-prefix property) obejmuje tylko adresy zaczynające się od podanego prefiksu, łącznie z protokołem. https://www.twojafirma.pl/ nie obejmuje wtedy http://twojafirma.pl/.

Dla firmowej strony usługa domeny jest zwykle wygodniejsza, bo nie musisz pamiętać o wariantach z www i bez. Ceną jest dostęp do DNS — jeśli domenę trzyma ktoś inny, weryfikacja wymaga jego pomocy. Ta sama pomoc wymienia też usługi platformowe (Instagram, TikTok, X, YouTube) i limit do 1 000 usług na jednym koncie.

Weryfikacja potwierdza, że masz prawo do strony. Metody według pomocy Google (odczyt 03.10.2026): przesłanie pliku HTML, tag HTML, kod śledzenia Google Analytics, Google Tag Manager, konto Google Sites lub Blogger oraz rekord u dostawcy domeny (TXT albo CNAME w DNS). Plik HTML działa tylko dla usługi z prefiksem URL, nie dla usługi domeny.

Z tej samej strony pomocy warto zapamiętać dwie rzeczy. Weryfikacja trwa tak długo, jak długo Search Console widzi ważny token, i Google sprawdza to okresowo. Jeśli przy przebudowie strony zniknie plik albo tag weryfikacyjny, dostaniesz powiadomienie, a jeśli problemu nie naprawisz, uprawnienia wygasną po okresie przejściowym. Poza tym dane dla usługi zaczynają się zbierać, gdy tylko ktokolwiek ją doda, jeszcze przed weryfikacją, ale zanim się pojawią, mija kilka dni.

Szersze pytanie, jak w ogóle sprawić, żeby Google zobaczył stronę, opisujemy w tekście o pozycjonowaniu.

Logowanie i dostęp: kto w firmie, kto w agencji

Do Google Search Console logujesz się kontem Google, które jest właścicielem albo użytkownikiem usługi. Jeśli po zalogowaniu nie widzisz swojej strony, masz dwie drogi: ktoś z uprawnieniami właściciela dodaje Twoje konto albo sam weryfikujesz własność jedną z metod z poprzedniej sekcji. Jeśli logowanie do Search Console „nie działa", sprawdź najpierw, którym kontem Google jesteś zalogowany.

Role według pomocy Search Console (odczyt 03.10.2026):

• Właściciel — zweryfikowany albo delegowany; obaj mają te same uprawnienia.
• Użytkownik z pełnym dostępem (Full user) — widzi wszystkie dane i może wykonać część działań.
• Użytkownik z ograniczonym dostępem (Restricted user) — widzi większość danych.
• Powiązany (Associate) — osoba lub konto, które może wykonywać określone działania w imieniu witryny, ale nie otwiera samej Search Console ani jej danych.

Zasady, które mają skutki biznesowe: usługa musi mieć co najmniej jednego zweryfikowanego właściciela, inaczej nikt nie ma do niej dostępu. Użytkowników niebędących właścicielami może być najwyżej 100. Właścicieli delegowanych dodasz, dopóki łączna liczba właścicieli zweryfikowanych i delegowanych nie dojdzie do 500; liczby właścicieli zweryfikowanych limit nie ogranicza. Usunięcie właściciela wymaga skasowania jego tokenów weryfikacyjnych — bez tego usunięta osoba może ponownie potwierdzić własność. Pomoc dodaje zdanie warte zapamiętania: „If you've found an owner that you don't recognize, you might have been hacked."

Praktyczna reguła, którą wyprowadzamy z tych zasad:

1. Zweryfikowanym właścicielem jest firma, na koncie, które nie odejdzie razem z pracownikiem.
2. Agencja dostaje pełny albo ograniczony dostęp, nie własność. Prośbę o zindeksowanie może wysłać tylko właściciel albo użytkownik z pełnym dostępem, więc wykonawca prowadzący SEO potrzebuje zwykle pełnego.
3. Po zakończeniu współpracy usuń użytkowników agencji, a jeśli agencja weryfikowała się własnym tokenem, usuń ten token.

Do audytu wystarcza dostęp do odczytu — co audyt robi z tymi danymi, opisujemy w tekście o audycie strony.

Raport skuteczności: kliknięcia, wyświetlenia, CTR i średnia pozycja

Raport skuteczności (w interfejsie: Performance) domyślnie pokazuje kliknięcia i wyświetlenia z ostatnich trzech miesięcy (pomoc Search Console, odczyt 03.10.2026). Dane możesz rozbić według zapytań, stron, krajów, urządzeń, wyglądu w wynikach i dat, a typ wyszukiwania przełączyć między web (także wyszukiwanie obrazem w Google Lens i Circle to Search), grafiką, wideo i wiadomościami.

Definicje poniżej pochodzą ze strony pomocy „What are impressions, position, and clicks?" (odczyt 03.10.2026). Google zaznacza, że opisane reguły mogą się zmieniać.

Kliknięcie to każde kliknięcie, które przenosi użytkownika na stronę poza wyszukiwarką Google, Discover lub Google News. Jeśli ktoś kliknie, wróci i kliknie ten sam link jeszcze raz, liczy się jedno kliknięcie.

Wyświetlenie oznacza, że użytkownik widział, albo mógł widzieć, link do Twojej strony. Liczy się, gdy wynik jest na bieżącej stronie wyników, niezależnie od tego, czy został przewinięty do widoku. Wyjątkiem są karuzele i rozwijane elementy — tam wynik musi zostać przewinięty albo rozwinięty.

CTR — co to jest

CTR (click-through rate) to kliknięcia podzielone przez wyświetlenia. Na przykład 50 kliknięć przy 1 000 wyświetleń daje 5% — to arytmetyka, nie wzorzec do porównań. Skoro wyświetlenie liczy się także wtedy, gdy nikt nie przewinął wyniku do widoku, CTR może spaść, gdy przybywa wyświetleń na dalszych pozycjach albo na zapytania luźno związane z tematem strony. Niski CTR może więc oznaczać słaby tytuł albo po prostu szerszą widoczność.

W naszej usłudze (sc-domain:digitalvantage.pl) CTR całej witryny w oknie 05.07–02.10.2026 był poniżej 0,1% — dane własne, z ograniczeniem: to okres przebudowy treści bloga, w którym Google wiele wpisów dopiero pobierał ponownie. Jak pisać tytuły i opisy, które podnoszą CTR, opisujemy w tekście o copywritingu SEO. Benchmarków „CTR na pozycji pierwszej" nie podajemy, bo Google ich nie publikuje.

Średnia pozycja — jak ją liczy Google

Tu łatwo o nieporozumienie. Google definiuje pozycję jako „the topmost position occupied by a link to your property or page in search results, averaged across all queries in which your property appeared" — najwyższą pozycję zajętą przez link do Twojej witryny, uśrednioną po wszystkich zapytaniach, w których się pojawiła.

Przykład z pomocy Google: na pierwsze zapytanie Twoja witryna ma linki na pozycjach 2, 4 i 6 — liczy się 2. Na drugie zapytanie linki na pozycjach 3, 5 i 9 — liczy się 3. Średnia pozycja wynosi (2 + 3) / 2 = 2,5. Pozostałe linki nie obniżają średniej, bo w ogóle nie wchodzą do rachunku.

Kolejne reguły z tej samej strony:

• Link musi mieć wyświetlenie, żeby jego pozycja została zapisana.
• Reklamy nie zajmują pozycji.
• Kliknięcia, wyświetlenia i pozycję przypisuje się do adresu kanonicznego linku.
• Blok AI Overview zajmuje jedną pozycję i wszystkie jego linki dostają tę samą; kliknięcia w nim liczą się jak zwykłe kliknięcia.
• W Discover pozycja nie jest zapisywana.

Google dodaje też, że ta sama liczba może znaczyć różne rzeczy w różnych sytuacjach, i zaleca śledzić zmianę pozycji w czasie, zwłaszcza nagłe skoki, obok samej wartości. Jak nie oszukać się tymi liczbami — na przykład gdy jedno zapytanie o markę rozkłada się na wiele adresów — opisujemy w tekście o pozycjonowaniu.

Jak sprawdzić pozycję strony w Google

W Search Console robisz to w raporcie skuteczności: filtrujesz po zapytaniu albo po stronie i patrzysz na kolumnę pozycji. Zanim wyciągniesz wniosek, pamiętaj o różnicy, którą opisuje pomoc Google: na wykresie średnia pozycja dotyczy najwyższego wyniku całej witryny, w tabeli — konkretnego adresu albo wiersza. Dlatego liczba nad wykresem i liczby w tabeli się różnią i obie są poprawne.

Druga pułapka: na karcie zapytań w tabeli nie ma zapytań anonimizowanych. Jeśli strona ma pozycję, a w tabeli nie widać żadnego zapytania, które by ją tłumaczyło, prawdopodobnie właśnie tam jest jej ruch (więcej w następnej sekcji).

Jeśli chcesz oddzielić zapytania o markę od reszty, użyj filtra wyrażeń regularnych. W filtrze zapytań lub stron wybierasz „Custom (regex)", a do wykluczenia — „Doesn't match regex". Search Console używa składni RE2, dopasowanie jest domyślnie częściowe (wyrażenie trafia w dowolny fragment, chyba że użyjesz ^ lub $) i nie rozróżnia wielkości liter, chyba że poprzedzisz wyrażenie (?-i). Kilka wariantów rozdzielasz kreską pionową i obejmujesz nawiasem (pomoc Search Console, odczyt 03.10.2026). Dla ilustracji: (digital vantage|digitalvantage) z opcją „Doesn't match regex" pokazuje zapytania bez nazwy marki. Ta sama pomoc ostrzega, że filtr po zapytaniu lub adresie może zmienić sumy z powodu obcinania danych i pominięcia zapytań anonimizowanych.

Granice danych: 16 miesięcy, 1 000 wierszy i zapytania, których nie widać

Zanim porównasz raport z czymkolwiek innym, sprawdź, czego w nim nie ma.

Historia: 16 miesięcy. Tę liczbę podaje pomoc Google Analytics przy integracji z Search Console: „Search Console keeps data for the last 16 months" (pomoc GA4, odczyt 03.10.2026). Jeśli chcesz porównywać dłuższe okresy, eksport musisz robić sam.

Świeżość. Według pomocy o rozbieżnościach w danych zebrane dane są zwykle dostępne po 2–3 dniach, a dni (poza widokiem 24-godzinnym) liczone są w czasie pacyficznym (pomoc Search Console, odczyt 03.10.2026). W widoku ostatnich 24 godzin punkty na wykresie to godziny i zawierają dane wstępne, oznaczone linią przerywaną, które mogą się jeszcze zmienić (pomoc Search Console). W GA4 dane z Search Console pojawiają się 48 godzin po zebraniu. W API parametr dataState rozróżnia dane ostateczne (final, domyślnie), wszystkie razem ze świeżymi (all) i godzinowe (hourly_all), a daty liczone są w czasie pacyficznym (dokumentacja API, aktualizacja 11.08.2026, odczyt 03.10.2026).

Zapytania anonimizowane. To zapytania, których nie wpisało więcej niż kilkadziesiąt osób w ciągu dwóch, trzech miesięcy. Google zawsze pomija je w tabelach, ale wlicza do sum na wykresie, chyba że filtrujesz po zapytaniu (Search Central Blog, Daniel Waisberg, 19.10.2022, odczyt 03.10.2026). Stąd częsta „niezgodność": suma wierszy tabeli jest mniejsza niż liczba nad wykresem.

Agregacja. Wykres liczy dane według usługi: jeśli dwa wyniki z Twojej witryny pojawią się na jedno zapytanie, to jedno wyświetlenie. Tabela z zapytaniami, krajami, urządzeniami i datami też liczy według usługi, ale tabela ze stronami i wyglądem w wynikach — według strony. Dlatego sumy wykresu i tabeli mogą się różnić.

Eksport. Z interfejsu wyeksportujesz najwyżej 1 000 wierszy; wartości pokazane jako ~ lub - trafiają do pliku jako zera. Przez API i Looker Studio limit wynosi 50 000 wierszy dziennie na witrynę na typ wyszukiwania — przy czym, jak pisze Google, „may not be reached in all cases" (wpis z 19.10.2022 cytowany wyżej). Dla wymiarów bez zapytań i adresów — krajów, urządzeń, wyglądu w wynikach — Search Console pokazuje i eksportuje wszystkie dane.

Raport indeksowania stron: statusy słowami Google

Raport indeksowania stron (Page indexing) odpowiada na pytanie, czy Google ma Twoją stronę. Nazwy statusów podajemy tak, jak zapisuje je pomoc Search Console (odczyt 03.10.2026; interfejs i API mogą pokazywać półpauzę zamiast łącznika), z naszym polskim objaśnieniem.

Dwa statusy łatwo pomylić, więc zestawiamy je obok siebie:

Pierwszy status dotyczy harmonogramu pobierania, drugi decyzji podjętej po obejrzeniu strony. Pomoc nie podaje przy drugim przyczyny odmowy — inaczej niż przy statusach duplikatów, które przyczynę nazywają wprost. Co robić ze stronami pobranymi i odrzuconymi, opisujemy w tekście o pozycjonowaniu.

Pozostałe powody niezaindeksowania według tej samej pomocy:

• URL marked 'noindex' — strona sama prosi o wykluczenie.
• URL blocked by robots.txt — z zastrzeżeniem Google, że blokada „does not guarantee that the page won't be indexed through some other means".
• Soft 404 i Not found (404) — przy tym drugim Google pisze, że nie da się kazać Googlebotowi trwale zapomnieć adresu. Więcej w tekście o błędzie 404.
• Server error (5xx) — opisane w tekście o błędach serwera; obok niego Redirect error oraz blokady 401, 403 i inne błędy 4xx.
• Alternate page with proper canonical tag — strona alternatywna poprawnie wskazuje kanoniczną; „nothing you need to do".
• Duplicate without user-selected canonical — duplikat bez wskazanego adresu kanonicznego; Google wybrał inny adres i tej strony nie pokaże.
• Duplicate, Google chose different canonical than user — wskazałeś adres kanoniczny, ale Google uznał inny za lepszy.
• Page with redirect — adres przekierowuje.

Są też dwa ostrzeżenia przy stronach zaindeksowanych: Indexed, though blocked by robots.txt i Page indexed without content. Status „URL is unknown to Google" nie należy do tego raportu — pokazuje go sprawdzanie adresu URL i oznacza, że Google tego adresu wcześniej nie widział (pomoc).

Wskazówki z pomocy, które oszczędzają czas:

• Jeśli strona ma mniej niż 500 podstron, raport „prawdopodobnie" nie jest Ci potrzebny — wystarczy wyszukiwanie z operatorem site:.
• Nie oczekuj, że zaindeksowane będą wszystkie adresy — tylko strony kanoniczne.
• To, że strona jest zaindeksowana, nie gwarantuje, że pojawi się w wynikach.
• Listy przykładowych adresów są ograniczone do 1 000 pozycji.
• Walidacja poprawki trwa zwykle do około dwóch tygodni, czasem znacznie dłużej; problem znika z tabeli 90 dni po ostatnim wystąpieniu.
• Zasadniczo naprawisz tylko problemy, przy których źródłem jest „Website".

Ile trwa indeksowanie i co robić, gdy strona czeka miesiącami, opisujemy w tekście o czasie pozycjonowania.

Nasz serwis w tym raporcie: wrzesień i październik 2026

Sprawdziliśmy stan indeksu wszystkich wpisów bloga w naszej mapie witryny (posts-sitemap.xml) dwukrotnie — 9 września i 3 października 2026 — przez URL Inspection API. Pomiędzy tymi datami przepisaliśmy treści bloga. Wyniki podajemy jako udział wpisów bloga w mapie witryny w danym dniu:

W naszych danych udział zaindeksowanych wpisów podwoił się, z 20% do 40%. Udział pobranych i niezaindeksowanych spadł z około połowy (51%) do niespełna jednej trzeciej (28%). Udziały wpisów znalezionych, ale niepobranych (16% → 17%), i nieznanych Google (12% → 14%) się nie poprawiły.

To zgadza się z definicjami Google z poprzedniej sekcji: przepisanie treści może zmienić decyzję podjętą po obejrzeniu strony, ale nie zmienia harmonogramu pobierania ani tego, czy Google w ogóle trafił na adres.

Dwa zastrzeżenia. Po pierwsze, mianownik się zmienił: według naszych danych w październiku w mapie witryny było o około 12% mniej wpisów bloga, bo scalone teksty przekierowaliśmy. Część przesunięcia wynika więc z usunięcia słabych wpisów, nie tylko z ponownej oceny. Po drugie, wrześniowe udziały opublikowaliśmy już w tekście o pozycjonowaniu; październikowe są nowe.

Zaindeksowany to nie znaczy widoczny. W oknie 05.07–02.10.2026 jakiekolwiek wyświetlenie miało 12% wpisów bloga w mapie witryny, a w dziale /zasoby/ (narzędzia, raporty, szablony) 59% adresów z mapy. Te liczby zastępują wcześniejsze 14% i 54% z okna 18.06–15.09.2026. Spośród wpisów zaindeksowanych 3 października 73% nie miało w tym 90-dniowym oknie ani jednego wyświetlenia. Ograniczenie: wiele z nich Google pobrał ponownie po przepisaniu, między 20.09 a 03.10.2026, więc okno mierzy głównie stare wersje tekstów.

Sprawdzanie adresu URL i prośba o zindeksowanie: co daje, a czego nie

Sprawdzanie adresu URL (URL Inspection) pokazuje stan jednej strony. Według pomocy Search Console (odczyt 03.10.2026) wynik domyślny to „not a live test" — dane z ostatnio zaindeksowanej wersji strony, nie z bieżącej. A komunikat „URL is on Google" nie gwarantuje, że strona pojawi się w wynikach.

Kiedy strona „nie chce się zaindeksować", zacznij od adresu kanonicznego. W sekcji Page indexing wyniku są dwa pola obok siebie:

• User-declared canonical — adres, który wskazałeś jako kanoniczny (tagiem <link rel="canonical">, nagłówkiem HTTP, w mapie witryny lub inną metodą). Google pisze, że weźmie go pod uwagę, ale nie gwarantuje, że go wybierze.
• Google-selected canonical — adres, który Google wybrał jako kanoniczny spośród podobnych stron. Jeśli jest tu nieoczekiwany adres, pomoc radzi wskazać wersję kanoniczną jawnie.

Jeśli oba pola wskazują różne adresy, strona może być w porządku, a w indeksie siedzi po prostu inny adres — to sytuacja ze statusu „Duplicate, Google chose different canonical than user" (pomoc). Pole Google-selected canonical widać tylko w wyniku z indeksu. Test na żywo, jak pisze Google, nie umie przewidzieć wyboru adresu kanonicznego.

Test na żywo ma też inne granice. Google pisze, że nie ma testu, który zagwarantuje, że strona trafi do indeksu, a test na żywo nie sprawdza duplikatów, zgodności z wytycznymi jakości i bezpieczeństwa, działań ręcznych ani usunięć.

Request indexing, czyli prośba o zindeksowanie, według dokumentacji Google (aktualizacja 10.12.2025, odczyt 03.10.2026):

• może ją wysłać tylko właściciel albo użytkownik z pełnym dostępem;
• pobranie może potrwać „anywhere from a few days to a few weeks";
• nie gwarantuje, że strona pojawi się w wynikach „instantly or even at all";
• limit zgłoszeń istnieje, ale Google nie podaje jego wysokości, a wielokrotne zgłaszanie tego samego adresu nie przyspieszy pobrania;
• przy wielu adresach właściwą drogą jest mapa witryny;
• przy statusie „Crawled - currently not indexed" ponowne zgłaszanie nie jest potrzebne (pomoc).

Mapy witryn w Search Console

Mapę witryny w Google zgłaszasz w raporcie map witryn (Sitemaps), ale tylko jako właściciel usługi. Jeśli nim nie jesteś, wpisz adres mapy do pliku robots.txt (pomoc Search Console, odczyt 03.10.2026).

Raport pokazuje cztery statusy: Success (wszystkie adresy trafiają do kolejki pobierania), Has errors, Couldn't fetch i Unknown. „Success" nie oznacza zaindeksowania: Google pisze, że nie ma gwarancji, iż adres znaleziony w mapie zostanie pobrany albo zaindeksowany.

Z tej samej pomocy: usunięcie mapy z raportu nie sprawia, że Google zapomni ją albo zapisane w niej adresy. Raport pokazuje tylko mapy zgłoszone przez raport albo API, maksymalnie 1 000 zgłoszeń. W raporcie indeksowania stron możesz z kolei zawęzić widok do stron z mapy filtrem „All submitted pages" i porównać je ze stronami spoza mapy.

Raport Core Web Vitals i Search Console Insights

Raport Core Web Vitals bierze dane z raportu CrUX, czyli od prawdziwych użytkowników Chrome (pomoc Search Console, odczyt 03.10.2026). Grupuje podobne strony w grupy adresów i dla każdej pokazuje 75. percentyl z ostatnich 28 dni, osobno dla telefonów i komputerów. Status grupy wyznacza jej najgorsza metryka. Grupy bez minimum danych dla LCP i CLS w raporcie się nie pojawiają, a komunikat „No data available" oznacza nową usługę albo za mało danych w CrUX. Tabela przykładów jest ograniczona do 200 wierszy.

Wynik pojedynczego adresu w PageSpeed Insights „might not match" wyniku grupy w tym raporcie, bo PageSpeed Insights pokazuje zwykle dane dla pojedynczych adresów. Jak czytać raport tego narzędzia, opisujemy w artykule o PageSpeed Insights. Progi i znaczenie metryk są w tekście o Core Web Vitals.

Search Console Insights w nowej wersji, ogłoszonej 30.06.2025, jest wbudowany w główny interfejs Search Console i zastępuje samodzielną wersję beta (Search Central Blog, 30.06.2025, odczyt 03.10.2026). Pokazuje trend kliknięć i wyświetleń, najlepsze strony i zapytania oraz te, które rosną lub spadają — kolejność „trending" wynika z bezwzględnej zmiany liczby kliknięć, nie procentowej. Jedna z kart dzieli ruch na zapytania o markę i pozostałe. Klasyfikację robi AI i, jak pisze pomoc, może się mylić; karta nie działa dla usług podrzędnych ani dla witryn z małą liczbą wyświetleń. Funkcja jest wprowadzana stopniowo i może nie być dostępna dla wszystkich. Jeśli jej nie masz albo jej nie ufasz, filtr regex z wcześniejszej sekcji daje ten sam podział na Twoich warunkach.

API Search Console: kiedy interfejs przestaje wystarczać

Interfejs wystarcza do pojedynczych pytań. Gdy chcesz sprawdzać setki adresów albo trzymać historię dłużej niż 16 miesięcy, potrzebujesz API. Limity według dokumentacji Google (aktualizacja 28.08.2025, odczyt 03.10.2026):

• Search Analytics API (dane z raportu skuteczności): 1 200 zapytań na minutę na witrynę i 1 200 na użytkownika, 30 000 000 dziennie i 40 000 na minutę na projekt, do tego krótkoterminowy i dobowy limit obciążenia. Najdroższe są zapytania grupowane lub filtrowane jednocześnie po stronie i zapytaniu.
• URL Inspection API: 2 000 zapytań dziennie i 600 na minutę na witrynę.

URL Inspection API pokazuje stan indeksu tylko dla wersji, która jest w indeksie Google. Nie ma w nim testu na żywo ani prośby o zindeksowanie — tego nie zautomatyzujesz. Limit 2 000 dziennie dotyczy API, nie przycisku w interfejsie. Nasze dane z sekcji o własnym serwisie zebraliśmy właśnie tą drogą, z tempem dopasowanym do tych limitów.

Co sprawdzać i jak często

Rutyna, która wynika wprost z dokumentacji Google:

• Na co dzień polegaj na e-mailach od Search Console o nowych problemach — codzienne logowanie nie jest potrzebne.
• Raz w miesiącu i po każdej zmianie treści otwórz raport skuteczności i porównaj okresy.
• Po wdrożeniu sprawdź raport indeksowania stron i przejrzyj zmienione adresy w sprawdzaniu adresu URL, zaczynając od pól z adresem kanonicznym.
• Pozycje czytaj jako zmianę w czasie, a nie pojedynczy odczyt.

Jeśli chcesz przejść przez stronę samodzielnie, punkt po punkcie, skorzystaj z checklisty audytu strony internetowej.