Google Search Console pokazuje status indeksacji strony, ale ręczne klikanie „Sprawdź adres URL” dla kilkuset podstron to nie jest monitoring — to syzyfowa robota, którą porzucisz po trzecim dniu. Mało kto wie, że ten sam mechanizm jest dostępny programistycznie: URL Inspection API pozwala odpytać Google o status dowolnego adresu z twojej własnej witryny i zbudować na tym prawdziwy, automatyczny monitoring indeksacji. W tym poradniku pokazujemy, jak to API działa, jakie ma limity i pułapki — oraz kiedy opłaca się złożyć rozwiązanie samemu, a kiedy sięgnąć po gotowe.
Czym jest URL Inspection API
To oficjalne API Google (część Search Console API), które dla podanego adresu zwraca dokładnie to, co widzisz w narzędziu „Sprawdzenie adresu URL”: werdykt indeksacji, stan pokrycia, datę ostatniego crawla Googlebota, wykryty adres kanoniczny i informacje o robots.txt. Kluczowa właściwość: API wyłącznie odczytuje dane. Nie da się nim niczego „zgłosić do indeksacji” — narzędzia, które to obiecują, mylą je z Indexing API (a tamto oficjalnie obsługuje tylko oferty pracy i transmisje na żywo).
Co zwraca API — najważniejsze pola
| Pole | Co mówi |
|---|---|
verdict | PASS = strona w indeksie; NEUTRAL/FAIL = poza nim |
coverageState | Dokładny status, np. „Submitted and indexed”, „Discovered — currently not indexed”, „Crawled — currently not indexed” |
lastCrawlTime | Kiedy Googlebot OSTATNIO odwiedził stronę — bywa sprzed miesięcy; nie mylić z datą sprawdzenia |
googleCanonical / userCanonical | Który adres Google uznał za kanoniczny — rozjazd z twoją deklaracją to częsta, niewidoczna przyczyna „braku” strony w wynikach |
robotsTxtState | Czy robots.txt blokuje crawlowanie adresu |
Limity i wymagania — tu wykłada się większość projektów
- 2 000 zapytań dziennie na witrynę (i 600 na minutę) — twardy limit Google, nie do podniesienia. Serwis z 20 000 podstron potrzebuje ~10 dni na pełny cykl sprawdzenia, więc bez priorytetyzacji ważnych adresów monitoring traci sens.
- Uprawnienia: właściciel lub pełny użytkownik property — konto z dostępem „ograniczonym” (restricted) dostanie odmowę. To najczęstsza przyczyna „nie działa” przy kontach agencyjnych.
- Konfiguracja OAuth — do samodzielnego użycia potrzebujesz projektu w Google Cloud, ekranu zgody i przejścia weryfikacji aplikacji, jeśli chcesz udostępnić narzędzie komukolwiek poza sobą.
- Świeżość danych — API zwraca stan z indeksu Google, który sam w sobie bywa opóźniony; status potrafi też falować (strony wypadają z indeksu i wracają), więc pojedynczy odczyt to migawka, nie diagnoza.
Architektura sensownego monitoringu
Niezależnie od tego, czy budujesz sam, czy bierzesz gotowca, dobry monitoring indeksacji sprowadza się do czterech elementów:
- Inwentarz adresów — pełna lista URL-i do pilnowania (w WordPressie: opublikowane wpisy, strony, typy własne), aktualizowana przy każdej publikacji i usunięciu.
- Kolejka z priorytetami — świeże publikacje i strony poza indeksem sprawdzane najpierw; reszta cyklicznie w ramach limitu 2 000/dzień.
- Historia — zapis statusu w czasie, bo dopiero trend pokazuje problem: dzień, w którym strona wypadła z indeksu, znaczy więcej niż jej dzisiejszy status.
- Reakcja — z danych musi coś wynikać: wzmocnienie linkowania wewnętrznego do stron, których Google nie odkrył, i poprawa treści tam, gdzie Google crawlował i odmówił.
Zbudować samemu czy wziąć gotowe?
Samodzielna budowa ma sens, jeśli masz jedną witrynę, ogarniasz Google Cloud i wystarczy ci skrypt wrzucający wyniki do arkusza. Koszt wejścia to projekt GCP, OAuth, obsługa limitów i utrzymanie tego wszystkiego na bieżąco — dla kilkuset adresów da się to zamknąć w wieczór, ale historia, priorytety i integracja z WordPressem to już realny projekt.
Po stronie gotowców ciekawym przykładem jest IndexFixer Pro — wtyczka WordPress polskiego autora, która realizuje dokładnie opisaną wyżej architekturę, ale całą obsługę API przenosi na własny serwer: użytkownik loguje się kontem Google (zakres tylko do odczytu) i nie zakłada żadnego projektu w Google Cloud. Do tego dokłada mechanizm, którego skrypt w arkuszu nie zrobi: widget dynamicznego linkowania wewnętrznego, który wystawia Googlebotowi linki do aktualnie niezaindeksowanych stron i sam je wymienia po indeksacji. Dokumentacja techniczna na GitHubie uczciwie opisuje, co narzędzie może, a czego nie — łącznie z limitami API i faktem, że indeksacja zawsze pozostaje decyzją Google. Szczegóły działania i zrzuty panelu znajdziecie w przewodniku konfiguracji.
FAQ
Czy URL Inspection API przyspiesza indeksację?
Nie. API tylko odczytuje status. Przyspieszać można pośrednio: monitorując statusy i reagując — linkowaniem wewnętrznym na problemy z odkrywaniem, poprawą treści na odmowy indeksacji.
Czy 2 000 zapytań dziennie wystarczy?
Dla serwisu do ~2 000 adresów — tak, pełny obraz codziennie. Powyżej trzeba priorytetyzować: świeże wpisy i strony poza indeksem częściej, stabilnie zaindeksowane rzadziej.
Dlaczego lastCrawlTime jest sprzed trzech miesięcy, skoro sprawdzałem wczoraj?
Bo to dwie różne daty: twoje sprawdzenie to odczyt z bazy Google, a lastCrawlTime mówi, kiedy Googlebot faktycznie odwiedził stronę. Stary lastCrawlTime przy statusie „not indexed” to sygnał, że Google stracił stroną zainteresowanie — i właśnie tu pomaga linkowanie wewnętrzne.