W raporcie indeksowania stron w Search Console ten status brzmi niegroźnie, bo nie ma w nim słowa „błąd”. Google po prostu informuje, że zna adres URL, ale go jeszcze nie pobrał. Problem polega na tym, że „jeszcze” potrafi oznaczać kilka dni albo kilka miesięcy, a różnica między jednym i drugim wynika z decyzji, których raport nie pokazuje. Jeśli dopiero zaczynasz czytać dane z konsoli, zacznij od szerszego kontekstu: nasz przewodnik po raportach Google Search Console wyjaśnia, które liczby są decyzyjne, a które tylko opisowe.
Dwa statusy, które łatwo pomylić
Pierwsza rzecz, którą trzeba ustalić, to czy Google w ogóle pobrał stronę. „Wykryto, obecnie nie zaindeksowano” znaczy, że robot zobaczył adres w sitemapie albo w linku, dodał go do kolejki i na tym poprzestał. Treści nie widział.
Zupełnie inaczej wygląda sytuacja opisana jako „Przeskanowano, obecnie nie zaindeksowano”. Tam robot pobrał dokument, przeczytał go i zdecydował, że nie trafi do indeksu. To już ocena treści, nie kolejki.
Trzeci status, „Zaindeksowano, ale zablokowano przez plik robots.txt”, jest całkowicie odrębnym przypadkiem: adres siedzi w indeksie, choć robot nie miał prawa go pobrać, więc Google zbudował wpis z samych sygnałów zewnętrznych, głównie z anchorów linków. Tam naprawa polega na odblokowaniu dostępu albo na świadomym wypchnięciu strony z indeksu. W naszym przypadku nie ma czego odblokowywać, bo nic nie jest zablokowane.
To rozróżnienie decyduje o kierunku pracy. Przy „wykryto” walczysz o pobranie. Przy „przeskanowano” walczysz o ocenę. Mieszanie tych dwóch ścieżek jest najczęstszym powodem, dla którego zespoły tygodniami poprawiają teksty, które robot nigdy nie przeczytał.
Trzy przyczyny, które stoją za tym statusem
Przeciążony serwer i limit pobierania
Google opisuje to wprost w dokumentacji o zarządzaniu budżetem crawlowania: jeśli próba pobrania obciążyłaby witrynę, robot przesuwa ją na później. Na współdzielonym hostingu bez cache strony wystarczy kilka równoległych żądań, żeby czasy odpowiedzi poszły w sekundy, a Google zinterpretował to jako sygnał, by zwolnić. Objaw jest zdradliwy, bo strona dla człowieka działa normalnie.
Niska przewidywana wartość adresu
Robot nie musi czytać dokumentu, żeby zgadywać, co w nim jest. Wzór adresu, kategoria, pozycja w strukturze i jakość sąsiednich stron z tego samego szablonu wystarczają, by przypisać nowemu URL-owi niski priorytet. Jeśli poprzednie 200 adresów o podobnym wzorze okazało się cienkie, kolejne będą czekać najdłużej.
Duplikacja i warianty tego samego adresu
Parametry sortowania, paginacja, wersje z ukośnikiem na końcu i bez niego, identyfikatory sesji: każdy taki wariant zjada miejsce w kolejce. Google widzi tysiące adresów, z których większość prowadzi do tej samej treści, i racjonalnie ogranicza tempo. Tu zwykle leży przyczyna, gdy status pojawia się masowo na dużym serwisie, a nie na kilku tekstach.
Pojedyncze adresy czy cały szablon
Zanim cokolwiek poprawisz, rozstrzygnij skalę. Wyeksportuj listę adresów z tym statusem i pogrupuj je po wzorcu URL, po typie treści i po dacie publikacji. Interesują cię trzy rozkłady.
- Po szablonie: jeśli 90 procent przypadków siedzi w jednym katalogu, problem jest systemowy i dotyczy sposobu generowania tych stron.
- Po dacie: jeśli wszystkie zalegające adresy są starsze niż kilka tygodni, a świeże wchodzą do indeksu w ciągu doby, działa mechanizm preferujący nowość. Backlog nie odrobi się sam.
- Po głębokości: policz, ile kliknięć ze strony głównej dzieli robota od adresu. Kolejka nie lubi głębokości sześciu i więcej.
Dopiero przy wyniku rozproszonym, bez wyraźnego skupienia, warto schodzić do poziomu pojedynczych tekstów. Przy skupieniu w jednym szablonie poprawianie treści jest stratą czasu, bo naprawy wymaga infrastruktura wokół niej. Metodykę takiego przeglądu rozpisaliśmy w materiale o audycie technicznym SEO i jego punktach kontrolnych.
Linkowanie wewnętrzne jako sygnał priorytetu
Sitemapa jest zgłoszeniem, nie rekomendacją. Z oficjalnej dokumentacji sitemap wynika jasno, że obecność adresu w pliku nie gwarantuje ani pobrania, ani indeksacji. Linki wewnętrzne działają inaczej: mówią robotowi, że ktoś w serwisie uważa ten dokument za wart pokazania.
Praktyczny test zajmuje kwadrans. Zestaw listę adresów ze statusem „wykryto” z wynikiem crawla własnego serwisu i sprawdź, ile linków wewnętrznych prowadzi do każdego z nich. W większości audytów, które prowadziliśmy, zalegające adresy mają zero albo jeden link i pochodzą wyłącznie z sitemapy. To nie korelacja przypadkowa, to opis mechanizmu. Adresy bez żadnego linku wewnętrznego, czyli strony sieroty, to pierwsza grupa, którą warto w tym zestawieniu oznaczyć i obsłużyć osobno.
Dodanie linku ma sens tylko wtedy, gdy stoi w zdaniu, które czyta człowiek, i prowadzi ze strony, którą robot już pobiera regularnie. Blok „zobacz także” wklejony w stopkę pięciuset tekstów jest dla kolejki niemal niewidoczny, bo powtarzalne moduły są odfiltrowywane jako nawigacja.
Scalić, przepisać czy usunąć
Część adresów w tym raporcie nie powinna istnieć. Decyzja jest prostsza, niż się wydaje, jeśli zadasz jedno pytanie: czy ta strona ma własną intencję wyszukiwania, której nie obsługuje żadna inna strona w serwisie?
| Sytuacja | Decyzja |
|---|---|
| Dwa teksty odpowiadają na to samo pytanie, oba cienkie | Scalić w jeden pełny materiał, przekierować słabszy adres |
| Temat ma sens, ale tekst nie wnosi nic ponad konkurencję | Przepisać z własnymi danymi, zostawić adres |
| Strona powstała automatycznie i nikt jej nie czyta | Usunąć i zwrócić kod 410 albo wyłączyć z indeksowania |
| Wariant adresu z parametrem | Kanonikalizacja do wersji podstawowej |
Skracanie listy adresów to najszybszy sposób na przyspieszenie kolejki, bo działa od razu na mianownik: mniej adresów o niskim priorytecie oznacza więcej pobrań dla tych, które zostały. Zanim zdecydujesz, co wyrzucić, przejrzyj portfolio w sposób, który opisaliśmy w materiale o audycie treści i ocenie istniejącego portfolio.
Jedna uwaga techniczna. Przy większych zmianach w szablonach łatwo wpaść w pułapkę podawania robotowi innej wersji strony niż użytkownikowi, zwłaszcza gdy w tle działa narzędzie do testów. Granicę między poprawnym eksperymentem a cloakingiem rozbieramy w tekście o testach A/B i SEO.
Ręczne żądanie indeksowania: co naprawdę daje
Przycisk „Poproś o zaindeksowanie” w narzędziu do sprawdzania adresu URL jest użyteczny, ale w bardzo wąskim zakresie. Wpycha jeden adres do przyspieszonej kolejki i zwykle skutkuje pobraniem w ciągu kilku godzin lub dni. Czego nie robi: nie gwarantuje indeksacji, nie podnosi priorytetu innych adresów w serwisie, nie naprawia przyczyny i nie ma sensu jako proces powtarzany co tydzień na tej samej liście.
Dobre zastosowanie to weryfikacja hipotezy. Zgłoś ręcznie pięć adresów reprezentujących szablon, odczekaj kilka dni i sprawdź wynik. Jeśli wszystkie trafiły do indeksu, przyczyną była kolejka, czyli priorytet i linkowanie. Jeśli po pobraniu przeszły w status „Przeskanowano, obecnie nie zaindeksowano”, przyczyną jest ocena treści i cała dalsza praca wygląda inaczej. To jeden z niewielu eksperymentów w SEO, który daje odpowiedź w tydzień.
Ile realnie trzeba czekać
Dla nowego, dobrze podlinkowanego adresu na serwisie o ustabilizowanym crawlu normą jest pobranie w ciągu 1–7 dni. Dla adresu z backlogu, który zalega od miesiąca i nie ma linków wewnętrznych, mówimy o tygodniach i nie ma górnej granicy. Po wprowadzeniu zmian strukturalnych pierwsze efekty w raporcie widać zwykle po 2–4 tygodniach, bo tyle trwa przeliczenie tempa pobierania i aktualizacja danych w konsoli.
Co z tego wynika dla harmonogramu pracy: traktuj ten status jako wskaźnik tempa, nie jako listę zadań. Monitoruj udział adresów ze statusem „wykryto” w całej puli opublikowanych URL-i i obserwuj, czy ten udział rośnie, czy maleje. Rosnący oznacza, że publikujesz szybciej, niż Google zdąży pobierać, i to jest decyzja biznesowa, nie techniczna usterka.
FAQ
Czy status „wykryto, obecnie nie zaindeksowano” to kara od Google?
Nie. To stan kolejki, nie sankcja. Google zna adres i odłożył jego pobranie, najczęściej z powodu obciążenia serwera albo niskiego przewidywanego priorytetu. Kary mają w konsoli własną sekcję: ręczne działania i problemy z bezpieczeństwem.
Ile adresów z tym statusem jest normą?
Na dużym serwisie z paginacją, filtrami i archiwami kilkanaście procent puli to typowy obraz. Niepokojące jest nie samo istnienie takiego zbioru, ale sytuacja, w której obejmuje on świeże, wartościowe teksty albo rośnie z miesiąca na miesiąc.
Czy ponowne zgłoszenie sitemapy pomaga?
Zwykle nie zmienia nic, jeśli sitemapa już była poprawnie przetworzona. Realny wpływ ma dopiero usunięcie z niej adresów bez wartości oraz rzetelne pole lastmod, aktualizowane tylko przy faktycznej zmianie treści.
Jak sprawdzić, czy serwer jest przyczyną?
Zestaw dane z raportu statystyk indeksowania: średni czas odpowiedzi i liczbę pobrań dziennie. Czasy powyżej około 600 ms w połączeniu ze spadającą liczbą żądań to mocna przesłanka. Potwierdzeniem jest logika logów serwera, w których widać odpowiedzi 5xx dla Googlebota.
Czy warto usuwać takie adresy z sitemapy?
Tak, jeśli świadomie nie chcesz ich w indeksie. Sitemapa powinna zawierać wyłącznie adresy kanoniczne, które mają trafić do wyszukiwarki. Trzymanie w niej stron, których nie zamierzasz rozwijać, rozcieńcza sygnał i spowalnia pobieranie tych właściwych.
Co zrobić, gdy po pobraniu strona przechodzi w „przeskanowano, obecnie nie zaindeksowano”?
To zmiana diagnozy. Robot przeczytał dokument i uznał, że nie wnosi nowej wartości wobec tego, co już ma w indeksie. Wtedy pracuje się nad unikalnością treści, intencją zapytania i konsolidacją materiałów o tym samym temacie, a nie nad crawlem.