Diagnostyka indeksacji
Brak strony w wynikach Google nie zawsze oznacza to samo. URL może w ogóle nie znajdować się w indeksie albo może być zaindeksowany, lecz wyświetlać się tak nisko, że trudno go znaleźć.
Te dwa przypadki wymagają innej diagnostyki. Najpierw trzeba potwierdzić, czy Google zna konkretny adres i może go pobrać. Dopiero później warto analizować treść, dopasowanie do zapytania oraz konkurencję.
Poniżej znajdziesz 12 technicznych przyczyn, przez które strona nie jest widoczna w Google, oraz praktyczne sposoby ich sprawdzenia. Nie każda przyczyna jest błędem — czasem noindex, canonical albo przekierowanie są ustawione celowo.
1. Strona jest nowa i Google jeszcze jej nie odkrył
Nowy URL nie trafia do wyników automatycznie w chwili publikacji. Google musi najpierw odkryć adres, dodać go do kolejki pobierania, odwiedzić stronę i ocenić, czy nadaje się do indeksacji. Sam fakt, że strona działa w przeglądarce, nie potwierdza, że Google już ją zna.
Odkrywanie odbywa się między innymi przez linki z innych znanych stron oraz sitemapę. Jeżeli nowa podstrona nie ma żadnego linku wewnętrznego, a mapa witryny nie została zaktualizowana, robot może dotrzeć do niej później.
Jak to sprawdzić?
- Wklej dokładny URL do narzędzia Sprawdzanie adresu URL w Google Search Console.
- Sprawdź, czy strona jest podlinkowana z indeksowalnej podstrony witryny.
- Potwierdź obecność URL-a w aktualnej sitemapie XML.
2. Strona ma noindex
Dyrektywa noindex informuje wyszukiwarkę, że danego dokumentu nie należy umieszczać w indeksie. Może znajdować się w znaczniku <meta name="robots"> w kodzie HTML albo w nagłówku HTTP X-Robots-Tag.
Noindex bywa prawidłowy dla stron logowania, koszyka, filtrów technicznych lub wewnętrznych wyników wyszukiwania. Problem pojawia się wtedy, gdy obejmuje ważną stronę ofertową, kategorię albo artykuł. W WordPressie warto też sprawdzić, czy nie została zaznaczona opcja zniechęcająca wyszukiwarki do indeksowania całej witryny.
Jak to sprawdzić?
Sprawdź źródło HTML, nagłówki odpowiedzi oraz wynik URL Inspection. Zobacz też poradnik Noindex i robots.txt — czym się różnią i kiedy ich używać. Nie usuwaj noindex bez ustalenia, dlaczego został dodany.
3. robots.txt blokuje dostęp
Plik robots.txt steruje pobieraniem adresów przez roboty. Reguła Disallow może zablokować konkretny katalog, wzorzec URL albo nawet całą witrynę. Taka blokada nie jest tym samym co noindex: ogranicza dostęp robota do treści, zamiast przekazywać dyrektywę dotyczącą indeksacji.
Szczególnie ryzykowne są pozostałości po środowisku testowym, na przykład Disallow: /, oraz zbyt szerokie reguły obejmujące zasoby potrzebne do renderowania strony. Jeżeli Google nie może pobrać dokumentu, nie zobaczy również umieszczonego w nim noindex ani canonicala.
Jak to sprawdzić?
Otwórz /robots.txt w swojej domenie i porównaj reguły z dokładną ścieżką problematycznego URL-a. Następnie sprawdź komunikat w Search Console. Szczegółowe przykłady znajdziesz w artykule o noindex i robots.txt.
4. Brakuje strony w sitemap.xml
Sitemap XML pomaga wyszukiwarce odkryć ważne adresy, zwłaszcza w rozbudowanych witrynach albo serwisach z niewystarczającym linkowaniem wewnętrznym. Brak URL-a w sitemapie nie zakazuje indeksacji, ale może utrudnić lub opóźnić odkrycie strony.
W mapie powinny znajdować się kanoniczne, indeksowalne adresy zwracające poprawną odpowiedź. Umieszczanie w niej przekierowań, błędów 404, stron noindex lub duplikatów wysyła niespójne sygnały i utrudnia diagnostykę.
Jak to sprawdzić?
Otwórz sitemapę, wyszukaj pełny URL i sprawdź jej status w Google Search Console. Pamiętaj, że obecność w mapie nie gwarantuje indeksacji. Więcej informacji zawiera poradnik Sitemap XML — jak działa i co powinna zawierać.
5. Canonical wskazuje inny URL
Znacznik rel="canonical" wskazuje preferowany adres dla podobnych lub powielonych wersji treści. Jeśli ważna strona ma canonical prowadzący do innego URL-a, przekazuje sygnał, że to inny adres powinien być traktowany jako reprezentatywny.
Częste przyczyny to skopiowany szablon, błędne generowanie adresów po migracji, canonical do strony kategorii albo pozostawiona domena testowa. Canonical jest sygnałem, a nie bezwzględnym poleceniem — Google może wybrać inny adres, jeśli pozostałe sygnały są sprzeczne.
Jak to sprawdzić?
Porównaj canonical zadeklarowany w kodzie z canonicalem wybranym przez Google w URL Inspection. Sprawdź protokół, host, końcowy slash i parametry. Zobacz również artykuł Canonical — co to jest, kiedy pomaga i kiedy szkodzi.
6. Strona zwraca nieprawidłowy status HTTP
Indeksowalna strona powinna zwykle zwracać status 200 OK wraz z właściwą treścią. Status 404 lub 410 oznacza brak zasobu, 5xx wskazuje problem serwera, a 401 lub 403 ogranicza dostęp. Zdarzają się też soft 404: serwer zwraca 200, lecz treść wygląda jak komunikat „nie znaleziono”.
Jednorazowy błąd nie musi od razu usunąć strony z wyników, ale powtarzające się problemy ograniczają możliwość pobierania i aktualizacji dokumentu. Sprawdź, czy użytkownik i robot otrzymują tę samą właściwą treść oraz status HTTP.
Jak to sprawdzić?
- Sprawdź końcowy status HTTP i pełny łańcuch odpowiedzi.
- Porównaj wynik z raportem indeksowania w Search Console.
- Zweryfikuj, czy strona błędu nie odpowiada kodem 200.
7. Istnieją błędne przekierowania
Przekierowanie powinno prowadzić do aktualnego, równoważnego adresu. Pętla, zbyt długi łańcuch, przekierowanie na stronę niezwiązaną z pierwotną treścią albo trasa kończąca się błędem może uniemożliwić dotarcie do właściwego dokumentu.
Po migracji często pozostają linki wewnętrzne prowadzące przez stare URL-e. Użytkownik może ostatecznie trafić na dobrą stronę, ale crawler wykonuje dodatkowe żądania, a diagnoza canonicali i sitemap staje się mniej czytelna.
Jak to sprawdzić?
Prześledź każde przejście od pierwszego URL-a do końcowej odpowiedzi i sprawdź, czy cel zwraca 200. Następnie popraw linki wewnętrzne tak, by prowadziły bezpośrednio do celu. Zobacz poradnik Błędy 404 i przekierowania — jak je diagnozować.
8. Google widzi duplikat strony
Ta sama lub bardzo podobna treść może być dostępna pod wieloma adresami: z parametrami, przez HTTP i HTTPS, z różnymi wariantami hosta, w kilku kategoriach albo jako wersja do druku. Google grupuje takie adresy i wybiera jeden adres kanoniczny.
Jeżeli za właściwy zostanie uznany inny URL, sprawdzany adres może nie pojawiać się w wynikach mimo poprawnego statusu 200. Nie oznacza to kary. To decyzja o tym, która wersja najlepiej reprezentuje zestaw duplikatów.
Jak to sprawdzić?
W Search Console porównaj canonical zadeklarowany przez właściciela z adresem wybranym przez Google. Sprawdź także przekierowania, sitemapę i linki wewnętrzne — wszystkie powinny konsekwentnie wskazywać preferowany URL.
9. Brakuje linkowania wewnętrznego
Strona osierocona nie ma zwykłych linków prowadzących do niej z innych indeksowalnych podstron. Może znajdować się w sitemapie, ale brak miejsca w architekturze serwisu utrudnia odkrycie i ocenę jej znaczenia.
Link powinien być prawdziwym elementem <a href="...">, dostępnym bez wykonywania nietypowej interakcji. Przycisk obsługiwany wyłącznie przez JavaScript, tekst bez odnośnika albo link ujawniany dopiero po akcji użytkownika może nie spełniać tej roli.
Jak to sprawdzić?
Znajdź wszystkie linki przychodzące z własnej witryny i oceń, czy ich kontekst jest naturalny. Ważna podstrona powinna być osiągalna ze struktury kategorii, oferty albo powiązanych treści. Praktyczne zasady opisuje artykuł Linkowanie wewnętrzne — jak budować czytelną strukturę.
10. Strona ma problemy techniczne z renderowaniem
Google potrafi wykonywać JavaScript, ale pobieranie i renderowanie są oddzielnymi etapami. Jeżeli główna treść pojawia się dopiero po błędnym żądaniu API, wymaga kliknięcia, korzysta z zablokowanych zasobów albo skrypt kończy się wyjątkiem, robot może zobaczyć niepełny dokument.
Problem bywa niewidoczny w zwykłej przeglądarce, ponieważ użytkownik ma zapisane dane, inne uprawnienia albo korzysta z zasobów, których Googlebot nie może pobrać. W serwisach JavaScriptowych trzeba porównać początkowy HTML z wyrenderowanym DOM.
Jak to sprawdzić?
W URL Inspection uruchom test wersji opublikowanej, obejrzyj wyrenderowaną stronę i sprawdź załadowane zasoby oraz błędy JavaScript. Potwierdź, że tytuł, H1, główna treść i linki istnieją również w wersji dostępnej dla robota.
11. Google zna stronę, ale jeszcze jej nie indeksuje
Search Console może pokazać, że URL został odkryty lub nawet pobrany, ale obecnie nie jest zaindeksowany. Taki status nie wskazuje jednej konkretnej usterki. Trzeba sprawdzić dostępność, jakość i unikalność treści, spójność canonicala oraz miejsce strony w strukturze serwisu.
Nie warto wielokrotnie wysyłać tej samej prośby o indeksację bez usunięcia przyczyny. Najpierw upewnij się, że dokument wnosi samodzielną wartość, nie jest pustym wariantem innej strony i otrzymuje czytelne linki wewnętrzne.
Jak to sprawdzić?
Połącz dane z URL Inspection z raportem indeksowania. Zapisz datę ostatniego pobrania, status indeksacji oraz canonical wybrany przez Google. Po poprawkach możesz poprosić o ponowne sprawdzenie adresu, ale przetworzenie zmian wymaga czasu.
12. Strona jest zaindeksowana, ale zajmuje bardzo niską pozycję
Jeżeli URL znajduje się w indeksie, techniczny problem z indeksacją nie musi istnieć. Strona może jednak odpowiadać na inne zapytania niż zakłada właściciel, mieć zbyt ogólną treść, konkurować z inną podstroną tej samej witryny albo przegrywać z lepiej dopasowanymi wynikami.
W tym przypadku operator site: może być tylko pomocniczą wskazówką. Jego wyniki nie są pełną listą zaindeksowanych stron, dlatego brak URL-a w takim wyszukiwaniu nie przesądza o braku indeksacji. Do sprawdzenia konkretnego adresu użyj URL Inspection, a dane o zapytaniach, wyświetleniach, kliknięciach i średniej pozycji sprawdź w Search Console.
Jak to sprawdzić?
W raporcie skuteczności wybierz konkretną stronę i sprawdź zapytania, na które już się wyświetla. Porównaj intencję tych zapytań z tytułem, H1 i treścią. Pomocny będzie poradnik Title, meta description i H1 — role i najczęstsze błędy.
Jak sprawdzić, co dzieje się z konkretnym URL-em?
Najbardziej użytecznym punktem startowym jest narzędzie Sprawdzanie adresu URL w Google Search Console. Wklej pełny adres — razem z protokołem, hostem, ścieżką i ewentualnymi parametrami. Nie sprawdzaj jedynie domeny, jeśli problem dotyczy konkretnej podstrony.
- Sprawdź, czy URL znajduje się w Google i jaki jest podany powód wykluczenia.
- Porównaj ostatnio pobraną wersję z aktualnym stanem strony.
- Zweryfikuj możliwość indeksowania, status pobrania i stan robots.txt.
- Porównaj canonical zadeklarowany przez witrynę z canonicalem wybranym przez Google.
- Jeśli strona została zmieniona, uruchom test wersji opublikowanej i dopiero po poprawkach poproś o ponowne sprawdzenie.
URL Inspection pokazuje stan znany Google, a nie gwarancję przyszłej indeksacji. Wynik trzeba zestawić z odpowiedzią HTTP, kodem strony, linkowaniem oraz sitemapą. Instrukcję pracy z danymi znajdziesz w artykule Google Search Console — jak zacząć i co sprawdzać.
Kiedy warto wykonać techniczny audyt SEO?
Pojedynczy URL można często sprawdzić ręcznie. Audyt techniczny jest bardziej przydatny, gdy problem dotyczy wielu typów stron, pojawił się po migracji lub przebudowie, liczba wykluczonych adresów rośnie albo sygnały są sprzeczne.
Techniczny skan witryny pozwala porównać statusy HTTP, dyrektywy indeksowania, canonicale, nagłówki i linki dla większego zbioru adresów. Sam automat nie zna jednak wszystkich decyzji biznesowych. Dlatego wyniki wymagające kontekstu — na przykład celowy noindex — powinny zostać zweryfikowane przed uznaniem ich za aktywny problem.
Techniczny audyt SEO — informacja
Możliwość przesłania domeny do audytu zostanie udostępniona po zakończeniu przygotowań formalnych. Na tym etapie nie zbieramy danych.
Najkrótsza kolejność diagnostyki
- Potwierdź dokładny URL i jego końcowy status HTTP.
- Sprawdź URL Inspection: indeksację, pobranie i canonical.
- Zweryfikuj noindex oraz dostęp w robots.txt.
- Sprawdź canonical, sitemapę i linki wewnętrzne.
- Jeżeli URL jest w indeksie, przejdź do analizy zapytań i dopasowania treści.
Taka kolejność oddziela brak indeksacji od niskiej pozycji i ogranicza ryzyko poprawiania elementu, który nie jest rzeczywistą przyczyną problemu.
Co przygotować przed diagnozą?
Najwięcej czasu traci się nie na samo sprawdzenie strony, lecz na porównywanie różnych wersji adresu i nieaktualnych danych. Zapisz dokładny URL, datę zauważenia problemu oraz informację, czy strona była ostatnio publikowana, przenoszona albo edytowana. Jeśli zmieniał się CMS, domena, protokół lub struktura kategorii, uwzględnij to w diagnozie.
Przygotuj też dostęp do właściwej usługi Google Search Console — tej, która obejmuje sprawdzany host lub całą domenę. Zanotuj status URL Inspection, datę ostatniego pobrania, canonical zadeklarowany przez właściciela oraz canonical wybrany przez Google. Te cztery informacje pozwalają szybko odróżnić problem dostępności od decyzji o duplikacie.
- dokładny URL wraz z protokołem i parametrami;
- końcowy status HTTP oraz adres po przekierowaniach;
- wartość meta robots i nagłówka X-Robots-Tag;
- canonical z kodu strony;
- informację, czy URL znajduje się w sitemapie i linkowaniu wewnętrznym;
- wynik testu wersji opublikowanej w Search Console.
Nie porównuj przy tym adresów „na oko”. Dla wyszukiwarki wariant HTTP, HTTPS, host z www, host bez www i URL z parametrem mogą być odrębnymi adresami. Diagnostyka powinna dotyczyć dokładnie tej wersji, która ma pojawiać się w wynikach.