Dlaczego Google zna URL, ale go nie pobrał?
Status wskazuje etap przed odczytaniem dokumentu. Diagnoza ma znaleźć pierwszą niespełnioną relację między ważnością URL-a, kolejką crawlu i dostępnością hosta.
- Pytanie kontrolneCzy ten URL powinien być pobierany i indeksowany?SprawdźOceń jego intencję, rolę oraz to, czy nie jest filtrem, sortowaniem lub technicznym wariantem.Dalszy krokAdres bez roli usuń z puli priorytetowej. Ważny URL przeprowadź przez kolejne sprawdzenia.Tak: sprawdź wzorzecNie: ogranicz zbędny URL
- Pytanie kontrolneCzy problem dotyczy pojedynczej strony czy całej grupy?SprawdźPodziel adresy według daty, katalogu, szablonu i sitemapy.Dalszy krokPojedynczy świeży URL może czekać. Powtarzalny wzorzec wymaga diagnozy systemowej.Tak: oceń priorytetNie: diagnozuj szablon
- Pytanie kontrolneCzy URL ma crawlable link i miejsce w czystej sitemapie?SprawdźSama znajomość adresu nie mówi Google, jak ważny jest w architekturze.Dalszy krokPołącz ważny URL z właściwym hubem, kategorią lub listingiem i usuń sprzeczne sygnały.Tak: sprawdź hostNie: popraw priorytet
- Pytanie kontrolneCzy host pozwala Google zwiększyć crawl capacity?SprawdźSprawdź DNS, robots.txt, połączenia, 5xx, 429 oraz czas odpowiedzi w Crawl Stats.Dalszy krokPrzywróć stabilność przed ponawianiem zgłoszeń URL-i.Tak: sprawdź pulę URL-iNie: napraw host
- Pytanie kontrolneCzy Googlebot traci czas na zbędną przestrzeń adresów?SprawdźLogi pokażą udział filtrów, parametrów, kalendarzy, przekierowań i błędów.Dalszy krokOgranicz generowanie oraz crawl URL-i bez roli, aby uporządkować postrzeganą pulę adresów.Tak: obserwuj kolejkęNie: uporządkuj pulę URL-i
Co Google wie o stronie ze statusem „Wykryto - obecnie nie zindeksowano”?
Google zna adres URL, ale w danych raportu nie ma jeszcze pobrania tej strony przez Googlebota. Oficjalny opis Google mówi, że crawl został przełożony, zwykle po to, aby nie przeciążyć witryny. Dlatego data ostatniego crawlu jest pusta. Po angielsku status nazywa się „Discovered - currently not indexed”.
To odróżnia go od komunikatu „Zeskanowano - obecnie nie zindeksowano”, przy którym Google pobrało dokument, lecz nie zapisało go w indeksie. Porównanie tych etapów ma znaczenie, bo naprawianie treści przed potwierdzeniem crawlu odpowiada na inne pytanie niż to, które stawia aktualny status.
| Źródło danych | Co potwierdza? | Ograniczenie |
|---|---|---|
| Raport Indeksowanie stron | URL należy do grupy „Wykryto - obecnie nie zindeksowano”, a źródłem statusu są Systemy Google. | Pokazuje wzorzec i skalę, ale lista przykładów nie musi obejmować wszystkich adresów. |
| Inspekcja URL | W danych indeksu pole ostatniego crawlu jest puste, bo raport nie odnotował pobrania strony. | Test wersji aktywnej sprawdza dostępność teraz; jego sukces nie dowodzi wcześniejszego regularnego crawlu. |
| Logi serwera | Brak zweryfikowanego żądania Googlebota do konkretnego URL-a potwierdza, że robot nie dotarł do dokumentu. | User-agent można podszyć. Zweryfikuj IP przez reverse DNS, potwierdź domenę Google i wykonaj forward DNS do tego samego IP albo użyj oficjalnych zakresów Googlebota. |
Kiedy czekać, a kiedy diagnozować status Wykryto?
Decyzję zacznij od skali i powtarzalności, a nie od wieku jednego adresu. Kilka świeżych URL-i w zdrowym serwisie może przejść do crawlu bez zmian. Ten sam status obejmujący cały katalog, większość nowych produktów albo dużą część domeny wskazuje na wzorzec, który trzeba znaleźć w architekturze, puli adresów lub kondycji hosta.
Kilka nowych URL-i
Najczęściej jest to kolejka i naturalne opóźnienie, jeśli host działa stabilnie, a adresy mają linki wewnętrzne.
Pierwszy krokSprawdź rolę URL-a, crawlable link, sitemapę i test wersji aktywnej. Potem obserwuj, zamiast przebudowywać serwis.
Wiele URL-i jednego szablonu
Problem zwykle leży w architekturze danego typu stron albo w masowym generowaniu podobnych adresów.
Pierwszy krokPorównaj wzorzec linkowania, crawl depth, parametry, canonicale i obecność szablonu w sitemapach.
Duża część całej witryny
Trzeba rozdzielić ograniczenie hosta od niskiego crawl demand i rozrostu puli znanych URL-i.
Pierwszy krokPołącz Page Indexing, Crawl Stats i logi. Nie diagnozuj tysięcy adresów pojedynczo.
Google wykryło URL - dlaczego źródło odkrycia nadal ma znaczenie?
Status potwierdza odkrycie adresu, ale nie potwierdza jego wysokiego priorytetu w kolejce. Sitemap może powiedzieć „ten URL istnieje”, natomiast crawlable link z kategorii lub huba pokazuje także relację, hierarchię i powód, dla którego robot ma do niego wrócić.
| Źródło | Jak Google poznaje URL? | Co mówi o priorytecie? |
|---|---|---|
| Link wewnętrzny | Google znajduje adres na wcześniej pobranej stronie. | Miejsce linku, kontekst i pozycja strony źródłowej pokazują rolę URL-a w hierarchii. |
| Sitemap.xml | Mapa zgłasza adres jako przeznaczony do pobrania. | Czysta mapa kanonicznych URL-i i wiarygodny lastmod pomagają; sama obecność nie gwarantuje crawlu. |
| Link zewnętrzny | Google może odkryć URL poza Twoją domeną. | Popularność adresu jest jednym z elementów crawl demand, ale nie zastępuje architektury własnego serwisu. |
| Wcześniejsze dane Google | Adres mógł istnieć wcześniej, pojawić się w przekierowaniu albo innej znanej wersji. | Stare, błędne i przekierowane URL-e mogą pozostawać w postrzeganej puli adresów hosta. |
Najważniejsze linki powinny być zwykłymi elementami <a> z prawidłowym atrybutem href. Przycisk obsługiwany wyłącznie zdarzeniem JavaScript nie tworzy równie pewnej ścieżki crawlu. Orphan page może być znana z sitemapy, ale nadal pozostaje poza normalnym przepływem kontekstu i ważności serwisu.
Crawl capacity i crawl demand - dwa warunki wizyty Googlebota
Google pobiera te URL-e, które jednocześnie może i chce pobrać. Crawl capacity limit opisuje bezpieczną wydajność hosta, a crawl demand - zapotrzebowanie na odwiedzenie konkretnych adresów. „Crawl budget” jest wynikiem obu elementów, a nie stałym limitem przydzielonym raz na zawsze.
| Element | Pytanie | Kiedy rośnie? | Kiedy spada? |
|---|---|---|---|
| Crawl capacity limit | Ile żądań host może bezpiecznie obsłużyć? | Odpowiedzi są stabilne, a opóźnienie i Time to First Byte pozostają na bezpiecznym poziomie. | Rosną czasy odpowiedzi, błędy 5xx, sygnały ograniczania 429 albo problemy z dostępnością. |
| Crawl demand | Które znane URL-e Google chce teraz odwiedzić? | Adresy są istotne, popularne, zmienione lub należą do wartościowej i aktualnej części serwisu. | Google zna dużo duplikatów i adresów bez roli albo nie widzi potrzeby częstego odświeżania. |
Jak filtry, parametry i kalendarze opóźniają crawl ważnych stron?
Masowo generowane adresy powiększają postrzeganą przez Google pulę URL-i. Robot nie wie przed pobraniem, czy kolejna kombinacja filtra okaże się użyteczna. Gdy serwis wystawia tysiące sortowań, parametrów sesji, pustych filtrów lub dat nieskończonego kalendarza, odkrywanie nowych, wartościowych dokumentów może zwolnić.
- każda kolejność tych samych parametrów tworzy osobny adres;
- filtry można łączyć bez limitu, także gdy wynik jest pusty;
- kalendarz generuje linki do dowolnie odległych dat;
- identyfikatory sesji, śledzenie i sortowanie trafiają do linków wewnętrznych;
- nieistniejące kombinacje zwracają 200 zamiast 404;
- sitemapy zawierają przekierowania, duplikaty lub adresy techniczne.
Najpierw ustal, które filtry mają popyt i wartość jako osobne strony. Pozostałe ogranicz u źródła: w sposobie generowania linków, strukturze parametrów, odpowiedziach 404 i regułach crawlowania. Canonical może z czasem zmniejszać crawl wersji niekanonicznych, ale nie zastępuje kontroli nieskończonej przestrzeni adresów.
Co sprawdzić w serwerze, DNS i robots.txt?
Kondycja hosta wpływa na liczbę równoległych połączeń i czas, jaki Google może przeznaczyć na crawling. Nawet dostępny w przeglądarce URL może czekać, jeśli robot obserwował wcześniej wolne odpowiedzi, błędy serwera, problemy z DNS, niedostępny robots.txt albo ograniczanie ruchu przez CDN i zaporę.
| Obszar | Czego szukać? | Co zrobić? |
|---|---|---|
| robots.txt | Crawl Stats pokazuje dostępność pliku. Powtarzające się odpowiedzi 429 lub 5xx dla robots.txt mogą spowolnić albo zatrzymać crawling hosta. | Zapewnij stabilną odpowiedź 200, 403, 404 lub 410 i sprawdź, czy reguła nie blokuje ważnej sekcji. |
| DNS | Błędy rozwiązywania nazwy oznaczają, że Google nie mógł połączyć hosta z adresem serwera. | Sprawdź konfigurację DNS, dostępność serwerów nazw i ciągłość odpowiedzi u operatora domeny. |
| Połączenie z hostem | Niepełna odpowiedź, timeout, reset połączenia, przeciążenie WAF/CDN albo blokada Googlebota mogą przerwać pobranie. | Porównaj Crawl Stats, monitoring uptime, reguły zapory i logi błędów aplikacji oraz reverse proxy. |
| Wydajność i statusy | Wzrost latency, TTFB, 5xx i 429 obniża limit wydajności crawlowania, ponieważ Google chroni serwer przed przeciążeniem. | Ustal godziny i typy URL-i powodujące przeciążenie, a następnie popraw wydajność lub ogranicz kosztowne ścieżki. |
| Finalny URL i przekierowania | Test wersji aktywnej ujawnia, czy adres zwraca stabilne 200, czy prowadzi przez łańcuch, pętlę albo nietrafne przekierowanie. | Linkuj i umieszczaj w sitemapie finalny adres. Skróć łańcuchy oraz usuń pętle, zanim ponownie ocenisz kolejkę crawlu. |
Jak połączyć GSC, Crawl Stats i logi Googlebota?
Każde źródło odpowiada na inne pytanie. Page Indexing grupuje statusy, Inspekcja URL sprawdza pojedynczy adres, Crawl Stats pokazuje kondycję hosta i rozkład żądań, a logi serwera potwierdzają rzeczywiste wizyty. Dopiero ich połączenie oddziela lukę priorytetu od luki dostępności.
01 / Page Indexing
Policz status i podziel adresy według sitemapy, katalogu, szablonu oraz daty publikacji.
OgraniczenieRaport pokazuje próbki URL-i i odświeża się z opóźnieniem.
02 / Inspekcja URL
Potwierdź brak daty ostatniego crawlu i sprawdź, czy wersja aktywna jest dziś dostępna dla Google.
OgraniczenieTest aktywny jest testem na żądanie, a nie dowodem wejścia URL-a do zwykłej kolejki crawlu.
03 / Crawl Stats
Sprawdź status hosta, wykres żądań, średni czas odpowiedzi, 5xx, 429 oraz typy Googlebota.
OgraniczenieLista URL-i jest przykładowa; raport nie zastępuje pełnych logów serwera.
04 / Logi serwera
Zmierz realne żądania zweryfikowanego Googlebota według katalogu, statusu, czasu i typu URL-a.
OgraniczenieBrak żądania potwierdza brak crawlu, ale sam nie wyjaśnia decyzji kolejki.
05 / Crawl własny
Porównaj graf linków, crawl depth i orphan pages z sitemapami oraz adresami znanymi Google.
OgraniczenieCrawler SEO pokazuje Twoją architekturę, nie zachowanie Googlebota.
W logach licz udział zweryfikowanego Googlebota w poszczególnych katalogach i typach URL-i, nie tylko łączną liczbę żądań. Wzrost crawlu nie pomaga, jeśli większość wejść trafia w sortowania, łańcuchy przekierowań i błędy. Metodę oceny kompletności danych, weryfikacji robota, segmentacji żądań i odpowiedzi HTTP rozwija analiza logów serwera w SEO.
Jak naprawić „Wykryto - obecnie nie zindeksowano”?
Nie istnieje jedna naprawa statusu, ponieważ status opisuje wynik, a nie przyczynę. Działanie wybierz po wzorcu danych: pojedynczy ważny URL potrzebuje innego ruchu niż przeciążony host albo milion kombinacji filtrów.
| Wzorzec | Dowód | Działanie |
|---|---|---|
| URL jest nowy, ważny i dostępny | Pojedyncze adresy, zdrowy host, brak fali parametrów, crawlable link z powiązanej strony. | Dodaj adres do czystej sitemapy, zapewnij opisowy link wewnętrzny i daj Google czas. Przy pilnym pojedynczym URL-u możesz raz użyć prośby o indeksowanie. |
| Ważne URL-e są głęboko lub bez linków | Sitemap zna adresy, ale crawl własny klasyfikuje je jako orphan pages albo pokazuje wysoką głębokość. | Włącz je do architektury: kategorii, hubu, listingu lub kontekstowo powiązanego dokumentu. Link musi być elementem <a> z prawidłowym href. |
| Googlebot pobiera głównie filtry i parametry | Logi i Crawl Stats pokazują wysoki udział kombinacji bez popytu, pustych wyników i powtarzalnych ścieżek. | Ogranicz przestrzeń URL-i, ujednolić generowanie parametrów, zwracaj 404 dla nonsensownych kombinacji i blokuj crawling ścieżek, których nie chcesz w Google. |
| Spadek crawlu zbiega się z problemem hosta | Crawl Stats pokazuje czerwony status hosta, wzrost czasu odpowiedzi, DNS, 5xx, 429 albo problemy z robots.txt. | Najpierw przywróć stabilność hosta. Zmiana treści lub kolejne zgłoszenie sitemapy nie usuwa ograniczenia połączenia. |
| Duża grupa adresów nie ma roli w wyszukiwarce | CMS generuje strony bez popytu i unikalnej funkcji: sortowania, sesje, duplikaty lub nieskończone kalendarze. | Usuń źródło generowania i linkowania zbędnych URL-i. Utrzymuj w sitemapach wyłącznie finalne adresy, które rzeczywiście mają być pobierane. |
Czego nie robić i jak sprawdzić, czy problem znika?
Skuteczność poprawki mierzy się zmianą wzorca crawlu, a nie samym kliknięciem „Poproś o zindeksowanie”. Obserwuj kohortę adresów przez kolejne tygodnie: ile URL-i przeszło z „Wykryto” do crawlu, czy Googlebot częściej odwiedza strony priorytetowe i czy poprawił się status hosta.
- nie wnioskuj z tego statusu, że Google przeczytał i negatywnie ocenił treść konkretnej strony - według raportu jeszcze jej nie pobrał;
- nie wysyłaj tej samej, niezmienionej sitemapy kilka razy dziennie i nie klikaj wielokrotnie prośby o indeksowanie;
- nie traktuj crawl budgetu jako domyślnej diagnozy każdej małej strony - najpierw sprawdź link, sitemapę i dostępność;
- nie dodawaj kolejnych linków do wszystkich adresów bez decyzji, które URL-e mają realną rolę w wyszukiwarce;
- nie używaj noindex jako sposobu oszczędzania crawlu - robot musi pobrać URL, aby odczytać tę dyrektywę;
- nie ufaj samemu user-agentowi w logach - zweryfikuj, czy żądanie rzeczywiście pochodzi od Googlebota.
- liczba i udział ważnych URL-i nadal oznaczonych jako „Wykryto”;
- czas od publikacji do pierwszego żądania zweryfikowanego Googlebota;
- udział crawlu na URL-ach priorytetowych wobec filtrów, parametrów, 3xx, 4xx i 5xx;
- średni czas odpowiedzi oraz status DNS, robots.txt i połączenia z hostem;
- liczba orphan pages i głębokość najważniejszych typów podstron;
- przejście URL-a do kolejnego statusu - także „Zeskanowano - obecnie nie zindeksowano”, które wymaga już innej diagnozy.
FAQ - strona wykryta, ale obecnie niezindeksowana
01Czy „Wykryto - obecnie nie zindeksowano” to błąd?
Nie zawsze. Status oznacza, że Google zna URL, ale raport nie odnotował jeszcze jego pobrania. Dla kilku świeżych stron może być stanem przejściowym. Diagnozy wymaga wtedy, gdy obejmuje ważne adresy przez dłuższy czas, powtarza się dla całego szablonu albo towarzyszy mu spadek crawlu i problemy hosta.
02Czym różni się od „Zeskanowano - obecnie nie zindeksowano”?
Przy statusie „Wykryto” Google zna adres, lecz według raportu jeszcze go nie pobrał, dlatego data ostatniego crawlu jest pusta. Przy „Zeskanowano” Google pobrał dokument i dopiero później nie dodał go do indeksu. Pierwszy status kieruje diagnozę na kolejkę, architekturę i host; drugi częściej na wartość dokumentu, duplikację i technikę po pobraniu.
03Czy niska jakość treści powoduje status Wykryto?
Sam status nie dowodzi oceny treści konkretnego URL-a, bo dokument nie został jeszcze pobrany. Google podaje jednak, że crawl demand na poziomie witryny zależy między innymi od jakości i relewantności. Jakość może więc wpływać na priorytety całego serwisu, ale nie wolno przedstawiać jej jako rozpoznanej wady nieprzeczytanej strony.
04Ile czekać na crawl strony?
Google nie podaje terminu dla pojedynczego adresu. Nowe strony mogą czekać od kilku dni do kilku tygodni. Zamiast ustalać arbitralny deadline, porównaj adres z innymi opublikowanymi w tym samym czasie: jeśli tylko jeden czeka, sprawdź jego linkowanie; jeśli czeka cały typ URL-i, diagnozuj wzorzec i host.
05Czy można wymusić indeksowanie strony?
Nie ma metody gwarantującej crawl ani indeksowanie. Dla ważnego pojedynczego URL-a możesz użyć opcji „Poproś o zindeksowanie” po sprawdzeniu dostępności i linkowania. Dla większej grupy właściwymi sygnałami są crawlable linki, czysta sitemap.xml, kontrola puli URL-i i stabilny serwer.
06Czy sitemap.xml wystarczy, skoro Google już wykrył adres?
Nie. Obecność w sitemapie może wyjaśniać, skąd Google zna URL, ale mapa jest wskazówką, a nie poleceniem pobrania. Jeżeli adres już ma status „Wykryto”, kolejne przesłanie tej samej mapy nie rozwiązuje luki priorytetu ani problemu hosta.
07Kiedy crawl budget jest realnym problemem?
Google kieruje zaawansowany poradnik przede wszystkim do serwisów z około milionem lub większą liczbą stron zmienianych co tydzień, witryn z ponad 10 tysiącami adresów zmienianych codziennie oraz serwisów z dużym udziałem statusu „Discovered - currently not indexed”. To orientacyjne progi, nie sztywne limity.
08Jak sprawdzić, czy Googlebot naprawdę odwiedził URL?
Najdokładniejszym dowodem są logi serwera, ponieważ rejestrują konkretne żądanie, czas i odpowiedź. Nie ufaj jednak samemu user-agentowi. Dla pojedynczego IP wykonaj reverse DNS, sprawdź domenę Google, a następnie forward DNS, który musi zwrócić ten sam adres IP. Przy analizie na większą skalę porównuj IP z oficjalnymi zakresami Googlebota. Crawl Stats pokazuje trend i próbki, ale nie pełną listę każdego żądania.
Masz setki ważnych URL-i wykrytych, ale nadal niepobranych?
Połączymy dane GSC, crawl serwisu i logi Googlebota. Wskażemy, czy priorytetem jest architektura linków, redukcja zbędnych adresów, poprawa sitemap czy stabilność hosta.
Źródła i dalsza lektura
- Google Search Console - raport Indeksowanie stron i opis statusu Discovered - currently not indexed
- Google Crawling Infrastructure - crawl capacity limit, crawl demand i zarządzanie crawl budgetem
- Google Search Console - Crawl Stats, status hosta, DNS, robots.txt i połączenie z serwerem
- Google Search Central - diagnozowanie błędów crawlowania i analiza logów
- Google Crawling Infrastructure - zarządzanie crawlingiem nawigacji fasetowej
- Google Search Central - crawlable linki i atrybut href
- Google Crawling Infrastructure - reverse DNS, forward DNS i zakresy IP robotów Google