Google aktualizuje dokumentację Indexing API i usuwa formularz zgody na wyższy limit

Google po cichu zaktualizowało 16 października trzy kluczowe podstrony dokumentacji Indexing API, usuwając wzmianki o domyślnym limicie jako puli przeznaczonej wyłącznie do testów oraz oficjalny formularz wnioskowania o wyższy limit. Jeśli prowadzisz job board lub serwis ze streamami wideo i czekałeś na zwiększenie limitu zapytań, Google zostawiło Twój projekt w zupełnej próżni informacyjnej. Z dokumentacji wycięto instrukcję uzyskiwania zgody na wyższe pule zapytań, nie podając w zamian żadnej alternatywnej ścieżki.

Przejrzałem zmiany w dokumentacji technicznej i zestawiłem je z realiami pracy nad indeksacją dużych serwisów. Sprawdź, co dokładnie zniknęło, jakie limity nadal obowiązują i jak zarządzać widocznością stron bez opierania się na niepewnych endpointach Google.

Co dokładnie zmieniło się w dokumentacji Indexing API?

Rewizja objęła trzy podstrony w Google Search Central: stronę główną z limitami (using-api), przewodnik szybkiego startu (quickstart) oraz szczegóły techniczne dotyczące przydziału zasobów. W oficjalnym rejestrze zmian (Google Search Central Changelog) pojawiła się lakoniczna notatka: zaktualizowano stronę limitów, aby odzwierciedlić bieżące zasady oraz usunąć nieaktualny formularz.

Kiedy jednak zestawimy stary i nowy tekst dokumentacji, skala cięć okazuje się znacznie szersza niż zwykłe porządki w kodzie:

Powiększ

1. Usunięto wzmianki o puli testowej: Wcześniej dokumentacja na stronie Indexing API Using the API powtarzała, że początkowy limit 200 zapytań służy wyłącznie do wdrożenia, konfiguracji i testów (onboarding and testing). To sformułowanie całkowicie wykreślono.
2. Skasowano sekcję „Request quota and approval”: Zniknął bezpośredni link do formularza Google Docs/Cloud, przez który deweloperzy zgłaszali zapotrzebowanie na wyższe limity produkcyjne. Usunięto też informację, że przydział zależy od jakości zgłaszanych dokumentów.
3. Wyrzucono porównanie z mapami witryn: Z przewodnika Indexing API Quickstart wycięto cały akapit rekomendujący używanie Indexing API zamiast sitemap dla treści o krótkim cyklu życia (np. ogłoszenia o pracę, relacje na żywo). Zniknęła też sugestia równoległego utrzymywania sitemapy XML dla reszty serwisu.

Jakie limity Indexing API obowiązują po zmianach?

Choć usunięto wzmianki o procesie akceptacji wniosków, same parametry techniczne przepustowości interfejsu pozostały w dokumentacji nienaruszone. Każdy nowo utworzony projekt w ekosystemie Google otrzymuje sztywno zdefiniowaną pulę żądań:

Wycięcie sformułowania o „limicie testowym” przy jednoczesnym pozostawieniu liczby 200 publish requests rodzi fundamentalne pytanie techniczne: czy Google traktuje teraz 200 zapytań dziennie jako ostateczny, produkcyjny limit dla większości projektów? Na ten moment nowe konta serwisowe po spięciu z projektem nadal natychmiast raportują domyślną pulę 200 wywołań.

Kto może legalnie korzystać z Indexing API w SEO?

Wokół Indexing API od lat narosło mnóstwo mitów. W sieci popularne są wtyczki do CMS-ów obiecujące natychmiastowe indeksowanie każdego nowego wpisu na blogu czy produktu w sklepie. Prawda techniczna jest jednak bezwzględna i Google wcale jej w tej aktualizacji nie zmieniło.

Zgodnie z oficjalną specyfikacją API jest przeznaczone wyłącznie dla dwóch typów podstron posiadających prawidłowo wdrożone dane strukturalne:

• Ogłoszenia o pracę z mikrodanymi JobPosting.
• Transmisje wideo na żywo oznaczone jako BroadcastEvent zagnieżdżony wewnątrz VideoObject.

Zgłaszanie za pomocą tego API standardowych artykułów, podstron usługowych czy kategorii e-commerce stanowi jawne naruszenie wytycznych antyspamowych wyszukiwarki. Google wprost przypomina w dokumentacji, że próby obchodzenia limitów (np. przez tworzenie wielu projektów w konsoli dla jednej domeny) mogą skutkować całkowitym zablokowaniem dostępu do interfejsu. Jeżeli Twoje podstrony nie indeksują się tradycyjną drogą, problem niemal zawsze leży po stronie architektury informacji lub błędów renderowania - sprawdź dlaczego Google i AI nie widzą Twojej strony w zestawieniu 10 przyczyn technicznych.

Co z wnioskami o wyższy limit złożonymi przed aktualizacją?

Usunięcie formularza stawia pod znakiem zapytania los serwisów, które złożyły aplikacje w poprzednich miesiącach. Właściciele portali rekrutacyjnych często czekali na rozpatrzenie wniosków o rozszerzenie puli ponad 200 zapytań przez całe kwartały, nie otrzymując żadnej informacji zwrotnej.

W zaktualizowanej dokumentacji Google nie poświęciło temu problemowi ani jednego zdania. Nie wiemy, czy:

• Wnioski oczekujące w kolejce zostały anulowane,
• Rozpatrywanie odbywa się obecnie wyłącznie wewnętrznymi kanałami wsparcia dla wybranych partnerów strategicznych,
• Domyślny limit 200 zapytań ma wystarczyć każdemu mniejszemu wydawcy.

Taki brak przejrzystości pokazuje dobitnie, że opieranie procesów biznesowych (takich jak natychmiastowa publikacja setek ofert pracy dziennie) na niestabilnych proceduralnie narzędziach zewnętrznych niesie spore ryzyko operacyjne.

Jak sprawdzić aktualny przydział w Google Cloud Console?

Po usunięciu linku do formularza z dokumentacji Search Central jedynym miejscem, w którym możesz zweryfikować stan swojego projektu, jest panel chmurowy.

Powiększ

Aby sprawdzić swoje limity:

1. Zaloguj się na konto powiązane z Twoją usługą i przejdź do Google Cloud Console API Dashboard.
2. Wybierz projekt, w którym włączona jest usługa Indexing API.
3. Przejdź do zakładki Quotas & System Limits (Limity i przydziały systemowe).
4. Przefiltruj listę według usługi Indexing API, aby zobaczyć bieżące zużycie dzienne oraz limity minutowe.

Część deweloperów wskazuje, że formularz wnioskowania o zmianę limitu wciąż bywa widoczny z poziomu interfejsu konsoli chmurowej (przycisk edycji przydziału przy danej metryce), jednak bez oficjalnej dokumentacji trudno ocenić, czy wnioski składane tą ścieżką trafiają do dedykowanego zespołu Search Central, czy przepadają w ogólnej kolejce Google Cloud.

Standardowe indeksowanie zamiast polegania na API

Niezależnie od przyszłości Indexing API, fundamentem widoczności w sieci pozostaje poprawnie zoptymalizowana infrastruktura serwisu. Wycofanie przez Google rekomendacji dotyczącej przedkładania API nad sitemapy na stronie szybkiego startu to czytelny sygnał: standardowe protokoły sieciowe są i będą podstawą działania robotów.

Jeśli zarządzasz serwisem o dużej rotacji podstron, skup się na elementach, nad którymi masz pełną kontrolę:

• Precyzyjny plik sitemap.xml: Zadbaj o aktualność znacznika <lastmod>, dziel mapy na logiczne paczki do 50 000 adresów URL i usuwaj z nich natychmiast strony zwracające kod 404 lub przekierowania 301.
• Wydajne linkowanie wewnętrzne: Bot odkrywa nowe podstrony przede wszystkim przez kod HTML. Skrócenie drogi dotarcia do nowych publikacji z poziomu strony głównej pozwala crawlerom zaindeksować zawartość w kilka godzin. Przeczytaj mój przewodnik wyjaśniający dokładnie jak działa indeksowanie strony w Google.
• Brak barier w plikach konfiguracyjnych: Sprawdź, czy reguły w pliku sterującym crawlerami nie odcinają zasobów renderujących stronę. Zobacz co to jest plik robots.txt i jak poprawnie nim zarządzać.
• Monitoring w Google Search Console: Weryfikuj statusy podstron w raporcie Indeksacja i reaguj na błędy wykryte przez silnik. Szczegółowe metody pracy z tym narzędziem opisałem w artykule: Google Search Console - kompletny przewodnik z praktycznymi zastosowaniami.
• Zrozumienie harmonogramu bota: Pamiętaj, że od pobrania kodu do umieszczenia adresu w indeksie mija określony czas zależny od parametrów domeny, co szczegółowo analizowałem w tekście o tym, jak Google ujawnia czasy crawlowania, indeksowania i aktualizacji.

Zaloguj się do Google Cloud Console, zweryfikuj bieżące zużycie zapytań w swoim projekcie i upewnij się, że Twoja domena nie próbuje wysyłać adresów pozbawionych wymaganych danych strukturalnych. Zamiast czekać na odblokowanie wyższych limitów, dopracuj architekturę informacji i mapy XML - to one gwarantują stabilne indeksowanie w długim terminie.