API indeksowania Google

TL;DR — Interfejs API indeksowania Google to sposób, dzięki któremu właściciele witryn mogą powiadomić Google „ta strona się zmieniła, przeindeksuj ją ponownie” za pomocą kodu zamiast klikania przycisków. Ale jest pewien haczyk, który większość przewodników pomija: Google oficjalnie obsługuje go tylko dla stron z ofertami pracy i stron z transmisjami na żywo. To nie jest skrót do szybszego indeksowania wpisów na blogu czy stron produktowych — Google mówi to wprost od dawna.

Czym jest interfejs API indeksowania

Gdy publikujesz lub zmieniasz stronę, zwykle czekasz, aż Google sam ją ponownie zindeksuje według własnego harmonogramu. Interfejs API indeksowania to sposób na wysłanie powiadomienia do Google — „hej, ten URL jest nowy/zaktualizowany” lub „ten URL zniknął, usuń go”. Robisz to za pomocą kodu (małego programu wywołującego serwery Google), a nie klikając w panelu.

To brzmi potężnie i takie jest — w przypadku dokładnie tych rzeczy, do których został stworzony.

Jedna rzecz, którą musisz zrozumieć

Google oficjalnie obsługuje interfejs API indeksowania tylko dla dwóch rodzajów stron:

1. Oferty pracy — strony z danymi strukturalnymi JobPosting (ogłoszenia o pracę, które wygasają i muszą szybko zniknąć).
2. Transmisje na żywo — strony z danymi strukturalnymi BroadcastEvent (wydarzenia wideo na żywo, które mają znaczenie tylko podczas transmisji).

To wszystko. Oba typy to treści wrażliwe na czas, które szybko tracą aktualność, dlatego Google stworzył dla nich szybką ścieżkę.

Jeśli nie masz ofert pracy ani transmisji na żywo, interfejs API indeksowania nie jest dla Ciebie — niezależnie od tego, co mówi wtyczka lub SaaS obiecujący „indeksowanie w kilka godzin”.

Mit, który warto zignorować

Największy mit w sieci to: „Użyj interfejsu API indeksowania, aby szybko zindeksować dowolną stronę.” To tak nie działa, a Google wielokrotnie nazywał używanie go do zwykłych stron nadużyciem. Ludzie i tak to robią, bo narzędzia sprzedają to jako trik na rozwój — ale Google może (i mówi, że to zrobi) cofnąć Ci dostęp za nadużywanie.

Jest też druga pułapka: gdy wyślesz URL i otrzymasz odpowiedź „sukces”, to oznacza tylko, że Google otrzymał Twoje żądanie. To nie oznacza, że strona została zaindeksowana. Wiele narzędzi zaciera tę granicę; dokumentacja Google jest w tej kwestii jasna.

Co zrobić zamiast tego, aby przyspieszyć indeksowanie

W przypadku zwykłych stron (blogi, produkty, artykuły) rzeczy, które naprawdę pomagają, są nudne, ale skuteczne:

• Prześlij XML sitemap w Google Search Console.
• Linkuj do nowych stron z innych stron w swojej witrynie.
• Spraw, aby strona była naprawdę warta indeksowania (jakość, a nie cienki filler).
• W jednorazowych przypadkach użyj „Request indexing” w narzędziu URL Inspection w Search Console — oszczędnie.

Chcesz wersję techniczną — konfigurację, rzeczywiste metody API, limity i dokładne cytaty Google? Przełącz się na zakładkę Advanced.

W skrócie — Interfejs API indeksowania to uwierzytelniany przez Google Cloud interfejs REST API (v3), który przyjmuje powiadomienia URL_UPDATED i URL_DELETED. Google oficjalnie obsługuje go tylko dla stron z JobPosting i BroadcastEvent-w-VideoObject (transmisje na żywo) — nie dla ogólnych treści. Odpowiedź 200 z punktu końcowego statusu potwierdza otrzymanie, a nie indeksowanie. Stanowisko Google zaostrzało się przez lata: 2022 („nie ma sensu”) → wrzesień 2024 (ostrzeżenie o spamie dodane do dokumentacji) → maj 2025 (Mueller: spamerzy nadużywają Indexing API, więc należy używać go właściwie albo wcale). Nadużywanie, w tym wiele kont w celu zawyżenia limitu, może skutkować cofnięciem dostępu. W przypadku ogólnych stron Twoje narzędzia to sitemapy, linki wewnętrzne, jakość i okazjonalne GSC „Request indexing” — i pamiętaj, że Google nie obsługuje IndexNow.

Czym naprawdę jest interfejs API indeksowania

Interfejs API indeksowania to programistyczny kanał push: interfejs REST API (v3), uwierzytelniany przez konto usługi Google Cloud, który wywołujesz, aby poinformować Google, że adres URL został dodany/zaktualizowany (URL_UPDATED) lub powinien zostać usunięty (URL_DELETED). Działa on obok map witryn i Search Console jako sposób na odkrywanie i odświeżanie adresów URL przez Google — ale jest najwęższym z nich pod względem typu treści.

W mojej prezentacji How Search Works wymieniam interfejs API indeksowania jako źródło odkrywania adresów URL z etykietą “ograniczone przypadki użycia” — co w dwóch słowach oddaje całą historię. Jest prawdziwy, działa i jest dozwolony tylko dla wycinka sieci.

Do czego Google oficjalnie go wspiera

To jest kluczowy fakt, więc przedstawię go tak, jak robi to Google: “The Indexing API can only be used to crawl pages with either JobPosting or BroadcastEvent embedded in a VideoObject.” (tłumaczenie) „Interfejs API indeksowania może być używany tylko do indeksowania stron z osadzonym JobPosting lub BroadcastEvent w VideoObject.” To wszystko — dwa typy danych strukturalnych:

• JobPosting — strony z ofertami pracy. Wygasają, a nieaktualne oferty to złe doświadczenie użytkownika, więc terminowe dodawanie/usuwanie ma znaczenie.
• BroadcastEvent w VideoObject — strony wydarzeń transmitowanych na żywo. Są istotne tylko podczas (i tuż wokół) transmisji.

Dlaczego tylko te dwa? Oba są z natury wrażliwe na czas i krótkotrwałe. Uzasadnienie Google jest takie, że szybkie powiadamianie o zmianach ma znacznie większe znaczenie dla nich niż dla stron wiecznie zielonych, które normalne indeksowanie obsługuje dobrze.

Jak to działa

Wymagania wstępne

Konfiguracja nie jest trywialna — to nie jest funkcja jednym kliknięciem:

• Projekt Google Cloud z włączonym interfejsem API indeksowania. Jak ujmuje to Google, “musisz poinformować Google o swoim kliencie i aktywować dostęp do interfejsu API.”
• Konto usługi z plikiem klucza JSON, przechowywanym bezpiecznie.
• Weryfikacja w Search Console witryny, a następnie dodanie konta usługi jako delegowanego właściciela witryny.
• OAuth: “Każde wywołanie interfejsu API indeksowania musi być uwierzytelnione tokenem OAuth, który otrzymujesz w zamian za swój klucz prywatny,” przy użyciu zakresu https://www.googleapis.com/auth/indexing.

Dwie metody (plus sprawdzenie statusu)

• URL_UPDATED — “Aby poinformować Google o nowym adresie URL do indeksowania lub że treść pod wcześniej przesłanym adresem URL została zaktualizowana.” Wyślij POST z adresem URL i "type": "URL_UPDATED". Udane wywołanie otrzymuje HTTP 200 — Google wyjaśnia, że odpowiedź “means that Google may try to recrawl this URL soon,” (tłumaczenie) „oznacza, że Google może wkrótce spróbować ponownie przeskanować ten adres URL”, a nie że na pewno to zrobi lub że indeksowanie nastąpi.
• URL_DELETED — przed żądaniem usunięcia Google wymaga, aby “adres URL zwracał kod statusu 404 lub 410 lub strona zawierała” meta tag noindex — to alternatywa, a nie “usuń stronę i dodaj też noindex.” Gdy to jest spełnione, wyślij POST z adresem URL i "type": "URL_DELETED", aby Google go usunął.
• Status (GET) — zwraca metadane (latest_update, latest_remove, notify_time). Krytyczne zastrzeżenie, dosłownie: żądanie GET “zwraca tylko informację, czy pomyślnie przesłano żądanie.” Nie mówi czy Google faktycznie zaindeksował lub usunął cokolwiek.
• Przetwarzanie wsadowe — aby zmniejszyć liczbę połączeń HTTP, możesz “połączyć do 100 wywołań interfejsu API indeksowania w jedno żądanie HTTP.” Limit jest nadal liczony na adres URL: 10 żądań w jednej partii nadal zużywa 10 żądań z limitu.

Limity

Domyślny limit Google ma trzy osobne wymiary, a nie tylko jedną liczbę:

• 200 żądań publikacji dziennie na projekt — obejmuje zarówno wywołania URL_UPDATED, jak i URL_DELETED łącznie. To liczba, na którą powołuje się większość przewodników.
• 180 żądań getMetadata (statusu) na minutę na projekt.
• 380 żądań na minutę na projekt we wszystkich punktach końcowych łącznie.

Wszystkie trzy są opisane jako “initial default quota for testing” (tłumaczenie) „początkowy domyślny limit do testów” — przekroczenie ich “wymaga dodatkowej zgody na użycie i przydział zasobów” przez formularz zgłoszeniowy, a Google zauważa: “the quota may increase or decrease based on the document quality.” (tłumaczenie) „Limit może wzrosnąć lub spaść w zależności od jakości dokumentu.” Powszechny “hack” polegający na tworzeniu wielu kont usługowych lub projektów w celu zawyżenia dziennego limitu jest dokładnie tym, co Google zabrania (patrz poniżej).

Czy można go używać do zwykłych stron? Co Google naprawdę mówi

Krótka odpowiedź: nie, w sposób wspierany — a Google był pod tym względem niezwykle konsekwentny i coraz bardziej dosadny.

Dokumentacja zawiera ostrzeżenie o spamie. Około września 2024 Google dodało język do szybkiego startu, czyniąc stanowisko jednoznacznym: “All submissions through the Indexing API undergo rigorous spam detection,” (tłumaczenie) „Wszystkie zgłoszenia przez Indexing API przechodzą rygorystyczne wykrywanie spamu” oraz “any attempts to abuse the Indexing API, including the use of multiple accounts or other means to exceed usage quotas, may result in access being revoked.” (tłumaczenie) „Próby nadużycia API, w tym używanie wielu kont lub innych sposobów przekraczania limitów, mogą skutkować cofnięciem dostępu”.

Przedstawiciele mówili to od lat. Już w maju 2022 John Mueller ujął to swoją analogią z pojazdami budowlanymi: API “is meant for very specific kinds of content,” (tłumaczenie) „jest przeznaczone do bardzo konkretnych rodzajów treści”, a używanie go gdzie indziej “doesn’t really make sense.” (tłumaczenie) „nie ma większego sensu”. Do maja 2025 ton stał się ostrzejszy — Mueller: “We see a lot of spammers misuse the Indexing API like this, so I’d recommend just sticking to the documented & supported use-cases,” (tłumaczenie) „Wielu spamerów nadużywa Indexing API, dlatego zalecam trzymanie się udokumentowanych i obsługiwanych zastosowań” oraz “I’d just use it properly, or not use it. If we wanted to suggest that people could use it regardless, we’d document it as such.” (tłumaczenie) „Używałbym go właściwie albo wcale; gdyby dowolne użycie było zalecane, zostałoby tak udokumentowane”.

Ta trajektoria — 2022 “nie ma sensu” → 2024 ostrzeżenie o spamie w dokumentacji → 2025 “spamerzy nadużywają… używaj go właściwie albo nie używaj” — to wieloletni wzorzec, a nie jednorazowy incydent. Relacje prasowe również zauważają, że API jest skutecznie zalewane przez blogerów i specjalistów SEO traktujących zwykłe strony tak, jakby kwalifikowały się do użycia.

Prawdziwe ryzyko, precyzyjnie ujęte. Mueller nie obiecuje algorytmicznej kary. Uczciwe ujęcie jest takie: to nie jest wspierane i jest sprzeczne z wytycznymi, treści wprowadzane niewłaściwie mogą nie pozostać zaindeksowane, a twój dostęp może zostać cofnięty. Nie przesadzaj, twierdząc, że to gwarantowane działanie ręczne — ale nie udawaj też, że to nic nie kosztuje.

Mit punktu końcowego statusu

To zasługuje na osobną uwagę, ponieważ wiele narzędzi myli się w tej kwestii: udane przesłanie to potwierdzenie otrzymania, a nie obietnica indeksacji. Status GET “only returns whether you successfully submitted a request.” (tłumaczenie) „zwraca tylko informację, czy żądanie zostało pomyślnie przesłane”. Jeśli panel pokazuje zieloną odznakę “zaindeksowano” na podstawie 200, to wnioskuje coś, czego API nigdy mu nie powiedziało.

API indeksowania a Żądanie zindeksowania a IndexNow

Trzy rzeczy są ciągle mylone. To różne mechanizmy:

• Indexing API (Google): programowy, ale ograniczony treściowo do JobPosting/BroadcastEvent. Najwęższy z trzech.
• Request Indexing (GSC URL Inspection): działa dla każdej strony, którą posiadasz, ale jest ręczny, jedna URL na raz i przeznaczony do okazjonalnego użycia — i to prośba, a nie gwarancja.
• IndexNow: otwarty, międzywyszukiwarkowy protokół push (Bing, Yandex, Yep, Seznam, Naver) — a Google go nie używa. To międzywyszukiwarkowy odpowiednik Indexing API i ten, który faktycznie popieram: pomogłem wdrożyć integrację IndexNow w Ahrefs Site Audit. Ale nie dociera do Google.

(Pełne zestawienie w zakładce Frameworks.)

Co robić zamiast tego dla zwykłych stron

Jeśli nie publikujesz ofert pracy ani transmisji na żywo, Indexing API nie jest twoim narzędziem, a Google mówi to wielokrotnie. Twoje prawdziwe dźwignie w Google to te nieefektowne:

• Sitemaps — dla pokrycia i odkrywania.
• Linki wewnętrzne — osierocone strony mają problemy; strony z linkami są znajdowane.
• Jakość treści — Google decyduje, co warto indeksować; cienkie strony utykają na “Discovered – currently not indexed” bez względu na to, jak mocno je wypychasz.
• GSC “Request indexing” — dla prawdziwych jednorazowych przypadków, oszczędnie.

W przypadku wypychania między wyszukiwarkami (Bing i inne, nie Google) IndexNow jest właściwym narzędziem. A jeśli zależy Ci na tym, dlaczego strony nie są indeksowane w pierwszej kolejności, to kwestia częstotliwości crawlowania i jakości, a nie kwestia API.

Podsumowanie AI

Skrócona wersja wersji zaawansowanej:

• Co to jest: uwierzytelniony przez Google Cloud interfejs API REST (v3) do wysyłania powiadomień URL_UPDATED / URL_DELETED do Google.
• Jedna istotna kwestia: oficjalnie obsługiwany tylko dla stron JobPosting i BroadcastEvent (livestream) — nie dla ogólnych treści. Oba typy są z założenia wrażliwe na czas.
• Mit nr 1: „indeksuje każdą stronę szybko”. Nie indeksuje; Google nazywa szersze użycie nadużyciem. Pomyślne przesłanie tylko potwierdza, że Google otrzymał żądanie, a nie że cokolwiek zostało zaindeksowane.
• Stanowisko Google zaostrzyło się z czasem: 2022 „nie ma sensu” → wrzesień 2024 ostrzeżenie o spamie dodane do dokumentacji → maj 2025 Mueller „spamerzy nadużywają… używaj go właściwie albo wcale”.
• Ryzyko: nieobsługiwane / niezgodne z wytycznymi; wiele kont w celu obejścia limitu ~200/dzień może skutkować cofnięciem dostępu. Nie musi to być ręczna kara — ale treść może nie zostać zaindeksowana.
• To nie to samo co IndexNow (między wyszukiwarkami, Bing/Yandex/itd. — Google go nie używa) ani GSC Request Indexing (dowolna strona, ręcznie, okazjonalnie).
• Dla normalnych stron: sitemapy + linki wewnętrzne + jakość + okazjonalne GSC Request Indexing.

Oficjalna dokumentacja

Podstawowa dokumentacja źródłowa od Google.

Google — Indexing API

• Szybki start z Indexing API — przegląd, ograniczenie JobPosting/BroadcastEvent i ostrzeżenie o wykrywaniu spamu.
• Jak korzystać z Indexing API — metody URL_UPDATED / URL_DELETED i zastrzeżenie dotyczące punktu końcowego statusu.
• Wymagania wstępne — projekt Cloud, konto usługi, zakres OAuth i delegowana własność w Search Console.
• Limity i cennik — domyślny limit (200) i wymagana zgoda na zwiększenie.

Google — kontekst dla ogólnych stron

• Poproś Google o ponowne przeskanowanie adresów URL — mapy witryn i ścieżka „Request indexing” w Search Console dla normalnych treści.
• Szczegółowy przewodnik po działaniu wyszukiwarki Google — gdzie odkrywanie adresów URL i potok skanowanie → indeksowanie → wyświetlanie mają zastosowanie.

Cytaty ze źródła

Oficjalne wypowiedzi Google. Każdy link to link bezpośredni, który przeskakuje do cytowanego fragmentu na stronie źródłowej.

Dokumentacja Google — ograniczenie

• “The Indexing API can only be used to crawl pages with either JobPosting or BroadcastEvent embedded in a VideoObject.” (tłumaczenie) „Indexing API może być używane tylko do crawlowania stron z osadzonym JobPosting lub BroadcastEvent w VideoObject.” — Google Search Central, Indexing API Quickstart. Przejdź do cytatu
• “The Indexing API allows site owners to directly notify Google when their job posting or livestreaming video pages are added or removed.” (tłumaczenie) „Indexing API umożliwia właścicielom witryn bezpośrednie powiadamianie Google, gdy ich strony z ofertami pracy lub transmisjami na żywo zostaną dodane lub usunięte.” Przejdź do cytatu

Dokumentacja Google — ostrzeżenie o spamie (dodane do dokumentacji około września 2024)

• “All submissions through the Indexing API undergo rigorous spam detection.” (tłumaczenie) „Wszystkie przesłania przez Indexing API przechodzą rygorystyczne wykrywanie spamu.” Przejdź do cytatu
• “Any attempts to abuse the Indexing API, including the use of multiple accounts or other means to exceed usage quotas, may result in access being revoked.” (tłumaczenie) „Wszelkie próby nadużycia Indexing API, w tym użycie wielu kont lub innych środków w celu przekroczenia limitów użycia, mogą skutkować cofnięciem dostępu.” Przejdź do cytatu

Dokumentacja Google — zastrzeżenie dotyczące punktu końcowego statusu (obalanie mitów)

• “The GET request doesn’t tell you when Google indexes or removes a URL; it only returns whether you successfully submitted a request.” (tłumaczenie) «Żądanie GET nie informuje Cię, kiedy Google indeksuje lub usuwa adres URL; zwraca jedynie informację, czy pomyślnie przesłałeś żądanie.» — Google Search Central, Jak korzystać z Indexing API. Przejdź do cytatu

Dokumentacja Google — limity (quota)

• “The default value is set to 200.” (tłumaczenie) „Wartość domyślna wynosi 200.” (żądania publikacji/dzień) — Google Search Central, limity i cennik. Przejdź do cytatu
• “The default value is set to 180.” (tłumaczenie) „Wartość domyślna wynosi 180.” (getMetadata, żądania statusu/minutę) i “The default value is set to 380.” (tłumaczenie) „Wartość domyślna wynosi 380.” (wszystkie punkty końcowe/minutę) — dwa pozostałe wymiary limitów, które większość przewodników pomija. Przejdź do 180 · Przejdź do 380
• “The quota may increase or decrease based on the document quality.” (tłumaczenie) «Limit może wzrosnąć lub spaść w zależności od jakości dokumentu.» — Google Search Central, limity i cennik. Przejdź do cytatu

Dokumentacja Google — przetwarzanie wsadowe i usuwanie

• “you can combine up to 100 calls to the Indexing API into a single HTTP request.” (tłumaczenie) „Możesz połączyć do 100 wywołań Indexing API w pojedyncze żądanie HTTP.” — Google Search Central, Jak korzystać z Indexing API. Przejdź do cytatu
• “the URL must return a 404 or 410 status code or the page must contain” (tłumaczenie) „Adres URL musi zwracać kod statusu 404 lub 410, albo strona musi zawierać” meta tag noindex — przed żądaniem usunięcia. — Google Search Central, Jak korzystać z Indexing API. Przejdź do cytatu
• “An HTTP 200 response means that Google may try to recrawl this URL soon.” (tłumaczenie) «Odpowiedź HTTP 200 oznacza, że Google może wkrótce spróbować ponownie przeszukać ten adres URL.» — Google Search Central, Jak korzystać z Indexing API (o URL_UPDATED). Przejdź do cytatu

John Mueller, Google Search Advocate — Bluesky, ~maj 2025

• “We see a lot of spammers misuse the Indexing API like this, so I’d recommend just sticking to the documented & supported use-cases.” (tłumaczenie) «Widzimy, że wielu spamerów nadużywa Indexing API w ten sposób, więc polecam trzymać się udokumentowanych i obsługiwanych przypadków użycia.»
• “I’d just use it properly, or not use it. If we wanted to suggest that people could use it regardless, we’d document it as such.” (tłumaczenie) «Po prostu używałbym go właściwie albo wcale. Gdybyśmy chcieli sugerować, że można go używać bez względu na wszystko, udokumentowalibyśmy to w ten sposób.» Przeczytaj relację

John Mueller, Google — SEO office-hours, maj 2022 (ramy „pojazdów budowlanych”)

• “The indexing API is meant for very specific kinds of content. And using it for other kinds of content doesn’t really make sense.” (tłumaczenie) «Indexing API jest przeznaczone do bardzo konkretnych rodzajów treści. Używanie go do innych rodzajów treści nie ma sensu.»
• “It’s not that it’s illegal or that it will cause problems if you put construction vehicles on your medical website. But it doesn’t really make sense.” (tłumaczenie) «Nie chodzi o to, że to nielegalne lub że spowoduje problemy, jeśli umieścisz pojazdy budowlane na swojej stronie medycznej. Ale to nie ma sensu.» Przeczytaj relację

Indexing API — ściągawka

Obsługiwane przypadki użycia (to jest pełna lista)

Dwie metody

Przetwarzanie wsadowe: połącz do 100 wywołań w jedno żądanie HTTP — limit nadal jest liczony na URL, a nie na partię.

Szybkie fakty

• Domyślny limit ma trzy części: 200 żądań publikacji/dzień, 180 żądań statusu (getMetadata)/minutę, 380 żądań/minutę we wszystkich punktach końcowych. Limit powyżej tego wymaga zgody Google i może się zmieniać wraz z jakością dokumentów.
• 200 ≠ zindeksowano. Odpowiedź sukcesu potwierdza otrzymanie zgłoszenia, nic więcej.
• Wiele kont w celu obejścia limitu = cofnięcie dostępu (zgodnie z dokumentacją).
• Uwierzytelnianie: projekt Google Cloud + konto usługowe + OAuth, zakres https://www.googleapis.com/auth/indexing, konto usługowe dodane jako delegowany właściciel GSC.
• To nie IndexNow (międzywyszukiwarkowy, nie Google). Nie jest zamiennikiem map witryn ani funkcji Request Indexing w GSC.

Minimalne wywołanie publikacji (tylko dla obsługiwanych treści)

To jest kształt pojedynczego powiadomienia URL_UPDATED. Używaj go tylko dla stron z danymi strukturalnymi JobPosting lub BroadcastEvent — do tego właśnie API jest przeznaczone. Krok uwierzytelniania (wymiana klucza konta usługowego na token OAuth) został pominięty dla zwięzłości; w praktyce użyłbyś biblioteki klienta API Google, aby uzyskać token.

Żądanie

POST https://indexing.googleapis.com/v3/urlNotifications:publish
Authorization: Bearer <OAUTH_TOKEN>
Content-Type: application/json

{
  "url": "https://example.com/jobs/senior-seo-analyst",
  "type": "URL_UPDATED"
}

Aby zgłosić usunięcie (po usunięciu strony lub dodaniu noindex):

{
  "url": "https://example.com/jobs/senior-seo-analyst",
  "type": "URL_DELETED"
}

Sprawdzanie statusu — zauważ, że odpowiedź informuje tylko o tym, że żądanie zostało przyjęte, a nie o tym, czy cokolwiek zostało zindeksowane:

GET https://indexing.googleapis.com/v3/urlNotifications/metadata?url=https%3A%2F%2Fexample.com%2Fjobs%2Fsenior-seo-analyst
Authorization: Bearer <OAUTH_TOKEN>

200 tutaj oznacza „otrzymaliśmy Twoje zgłoszenie” — to nie jest potwierdzenie, że Google zindeksował (lub usunął) URL.

Przetwarzanie wsadowe wielu URL-i: możesz połączyć do 100 pojedynczych wywołań w jedno wieloczęściowe żądanie HTTP do https://indexing.googleapis.com/batch zamiast wysyłać 100 osobnych żądań — ale limit jest nadal liczony na URL, więc partia 100 wywołań nadal zużywa 100 żądań z Twojego dziennego limitu. Biblioteki klienta API Google (Java, Python, JavaScript, PHP, .NET) obsługują formatowanie partii za Ciebie; ręczne tworzenie ich rzadko się opłaca.

API indeksowania a Żądanie zindeksowania a IndexNow

Struktura decyzyjna: ustal, co masz i która wyszukiwarka Cię interesuje, a następnie wybierz kanał.

Jak wybrać

1. Masz oferty pracy lub transmisje na żywo i chcesz to zautomatyzować? → Indexing API.
2. Chcesz wypchnąć zwykłe strony do Bing/Yandex/Yep? → IndexNow.
3. Chcesz, aby Google ponownie przeszukał jedną zwykłą stronę, raz? → GSC „Request indexing”.
4. Chcesz, aby zwykłe strony były indeksowane na dużą skalę w Google? → Nie ma przycisku do wypychania. Sitemaps + linki wewnętrzne + jakość. (I cierpliwość — patrz częstotliwość przeszukiwania.)

Model myślowy: Indexing API brzmi jak najbardziej zaawansowane z tych trzech, bo to API, ale pod względem typu treści jest najwęższe. Moc i zakres to nie to samo.

Narzędzia

• Google Cloud Console — utwórz projekt, włącz Indexing API i wygeneruj klucz JSON service-account, którym będziesz się uwierzytelniać.
• Google Search Console — URL Inspection — w przypadku zwykłych stron to jest Twoje prawdziwe narzędzie: sprawdź, jak URL został przeszukany/wyrenderowany/zaindeksowany, i użyj „Request indexing” w przypadku okazjonalnych jednorazowych zapytań.
• Google Search Console — Sitemaps & Coverage — przesyłaj sitemaps i sprawdzaj, co jest zaindeksowane, „Discovered – currently not indexed” lub wykluczone.
• Google API client libraries — najczystszy sposób obsługi wymiany tokenów OAuth dla wywołań Indexing API (zamiast ręcznego podpisywania JWT).
• Integracja IndexNow (Ahrefs Site Audit itp.) — dla międzysilnikowego kanału wypychania (Bing i inne, nie Google). Właściwe narzędzie, gdy chcesz programowego wypychania, którego ludzie chcieliby od Indexing API dla zwykłych stron.

Zasoby warte Twojego czasu

Moje powiązane teksty

• Czym jest Googlebot i jak działa? — gdzie Indexing API znajduje się wśród źródeł odkrywania URL-i przez Google (linki, mapy witryn, RSS, GSC i API).
• Jak naprawić stan „Wykryto — obecnie nie zindeksowano” — prawdziwa strona „dlaczego moje strony się nie indeksują”; rozwiązaniem jest jakość i linki wewnętrzne, a nie API do wypychania.
• Przewodnik dla początkujących po technicznym SEO — gdzie przeszukiwanie i indeksowanie wpisują się w szerszy obraz.

Moje wystąpienia

• Jak działa wyszukiwarka (SlideShare) — mój przewodnik po odkrywaniu, przeszukiwaniu, renderowaniu, indeksowaniu i rankingu; slajd o odkrywaniu URL-i oznacza Indexing API jako „ograniczone przypadki użycia”. (Moje stałe zastrzeżenie: „Tak rozumiem te systemy… opis nie będzie w 100% kompletny ani dokładny.”)

O IndexNow (jego odpowiednik w innych wyszukiwarkach — pamiętaj, że Google nie używa tego protokołu)

• Integracja IndexNow w Site Audit Ahrefs — kanał push, który faktycznie polecam, dla Bing/Yandex/Yep, a nie Google.
• Jak przesyłać strony do IndexNow w Site Audit.

Od innych

• Google dodaje ostrzeżenie o spamie do dokumentacji Indexing API (Search Engine Journal, wrzesień 2024) — dokumentuje, kiedy dodano język dotyczący wykrywania spamu.
• Google ponownie apeluje, by nie używać Indexing API do nieobsługiwanych treści (Search Engine Roundtable, maj 2025) — Barry Schwartz omawia ostrzeżenie Muellera na Bluesky, aby zaprzestać niewłaściwego używania API.
• Nadużycie Indexing API może prowadzić do problemów z SEO (StanVentures, maj 2025) — przytacza dosłownie cytaty Muellera z maja 2025 na Bluesky i wyjaśnia ryzyko cofnięcia dostępu.
• Czy używanie Indexing API dla zwykłej witryny jest dobre czy złe? (iLoveSEO, maj 2022) — transkrypcja porównania Muellera do „pojazdów budowlanych” podczas godzin biurowych.
• Według Google blogerzy zalewają Indexing API (Optimixed) — omawia, jak niewłaściwe użycie przez blogerów i specjalistów SEO przeciążyło API.
• r/TechSEO — społeczność do debugowania indeksowania i crawl.

Częste problemy

Problemy, na które ludzie faktycznie napotykają z Indexing API, w kolejności objaw → przyczyna → rozwiązanie.

”Otrzymałem odpowiedź 200, ale strona nadal nie jest zaindeksowana”

• Objaw: Wywołanie URL_UPDATED (lub status GET) zwraca sukces, ale strona nigdy nie pojawia się w wynikach wyszukiwania, a Search Console nadal pokazuje “Wykryto – obecnie nie zindeksowano”.
• Przyczyna: Kod 200 potwierdza tylko, że Google otrzymał powiadomienie. Według dokumentacji Google endpoint statusu “only returns whether you successfully submitted a request” (tłumaczenie) „zwraca tylko informację, czy żądanie zostało pomyślnie przesłane” — nie mówi, czy cokolwiek zostało przeszukane, zaindeksowane lub usunięte.
• Rozwiązanie: Przestań traktować odpowiedź API jako potwierdzenie indeksowania. Sprawdź faktyczny status indeksowania w narzędziu URL Inspection w Search Console lub w raporcie Coverage. Jeśli strona nadal nie jest zaindeksowana po rozsądnym czasie oczekiwania, problem leży w wykrywaniu/jakości (patrz “Co zamiast tego” w zakładce Advanced), a nie w wywołaniu API.

”Mój dostęp do Indexing API został cofnięty”

• Objaw: Wywołania, które wcześniej działały, zaczynają kończyć się błędem, a Google Cloud/Search Console pokazuje, że dostęp konta usługi został odebrany.
• Przyczyna: Google wprost stwierdza: “any attempts to abuse the Indexing API, including the use of multiple accounts or other means to exceed usage quotas, may result in access being revoked.” (tłumaczenie) „Próby nadużycia Indexing API, w tym użycie wielu kont lub innych środków w celu przekroczenia limitów, mogą skutkować cofnięciem dostępu.” Najczęstszym wyzwalaczem jest przesyłanie stron, które nie są JobPosting/BroadcastEvent, lub tworzenie dodatkowych kont usługi, aby obejść domyślny limit około 200/dzień.
• Rozwiązanie: Przejrzyj, co przesyłasz — jeśli to ogólne treści (wpisy na blogu, strony produktów, cokolwiek bez danych strukturalnych JobPosting lub BroadcastEvent), przestań. API nie jest udokumentowane do obsługi takich treści, a Mueller powiedział wprost: “Po prostu używałbym go właściwie albo wcale.” Nie ma udokumentowanej ścieżki odwołania poza pozostaniem w obsługiwanym przypadku użycia w przyszłości.

”Przesyłanie zwykłych stron nie wydaje się niczego zmieniać”

• Objaw: Wysyłasz URL_UPDATED dla zwykłego artykułu lub strony produktu i nic się nie zmienia — brak szybszego indeksowania, brak szybszego crawlowania.
• Przyczyna: Typ treści nie jest jednym z dwóch obsługiwanych przez Google. Interfejs Indexing API “can only be used to crawl pages with either JobPosting or BroadcastEvent embedded in a VideoObject.” (tłumaczenie) „może być używany tylko do skanowania stron z osadzonym JobPosting lub BroadcastEvent w VideoObject.” Zgłoszenia poza tym zakresem nie są udokumentowanym, wspieranym sygnałem.
• Rozwiązanie: To nie jest błąd do naprawienia — to niewłaściwe narzędzie. W przypadku zwykłych stron użyj mapy witryny, linków wewnętrznych i (w przypadku sporadycznych jednorazowych zgłoszeń) “Request indexing” w narzędziu URL Inspection w Search Console.

”Osiągam limit limitu”

• Objaw: Zgłoszenia zaczynają zawieść lub być ograniczane — albo około 200/dzień, albo w krótszych seriach nawet poniżej 200/dzień.
• Przyczyna: Google faktycznie egzekwuje trzy oddzielne domyślne limity: 200 żądań publikacji (URL_UPDATED/URL_DELETED) na dzień, 180 żądań statusu (getMetadata) na minutę i 380 żądań na minutę łącznie dla wszystkich punktów końcowych. Seria sprawdzeń statusu może ograniczyć Cię na limitach per-minutowych na długo przed osiągnięciem dziennego limitu 200. Przekroczenie któregokolwiek z tych limitów “wymaga dodatkowej zgody na użycie i alokację zasobów,” a Google zauważa: “the quota may increase or decrease based on the document quality.” (tłumaczenie) „Przyznany limit może wzrosnąć lub spaść w zależności od jakości dokumentu.”
• Rozwiązanie: Jeśli legalnie publikujesz/aktualizujesz tak wiele stron JobPosting lub BroadcastEvent dziennie, poproś o zwiększenie limitu przez Google Cloud — nie twórz dodatkowych kont usługowych ani projektów, aby to obejść, ponieważ jest to wyraźnie wymienione jako rodzaj nadużycia, które prowadzi do cofnięcia dostępu.

Listy kontrolne

Zanim dotkniesz Indexing API

• Potwierdź, że strony, które chcesz zgłosić, faktycznie zawierają dane strukturalne JobPosting lub BroadcastEvent osadzone w VideoObject — jedyne dwa typy treści obsługiwane przez Google.
• Jeśli żaden z nich nie ma zastosowania, zatrzymaj się tutaj. Użyj map witryn, linków wewnętrznych, jakości treści i sporadycznego GSC “Request indexing” — nie API.
• Zdecyduj, czy Twoja objętość zgłoszeń realistycznie zmieści się w domyślnym limicie ~200/dzień, czy będziesz musiał poprosić o zwiększenie.

Konfiguracja

• Utwórz (lub wybierz) projekt Google Cloud i włącz w nim Indexing API.
• Utwórz konto usługowe i pobierz jego plik klucza JSON; przechowuj go bezpiecznie (nigdy nie commituj go do publicznego repozytorium).
• Zweryfikuj swoją witrynę w Search Console, jeśli jeszcze tego nie zrobiłeś.
• Dodaj adres e-mail konta usługowego jako delegowanego właściciela witryny w Search Console.
• Potwierdź, że możesz wymienić klucz konta usługowego na token OAuth z zakresem https://www.googleapis.com/auth/indexing (zwykle za pomocą biblioteki klienta Google API zamiast ręcznego podpisywania JWT).

Wysyłanie powiadomienia

• Wybierz właściwą metodę: URL_UPDATED dla nowej lub zmienionej obsługiwanej strony, URL_DELETED po usunięciu strony lub oznaczeniu jej noindex.
• Wyślij POST z adresem URL i poprawnym polem type na https://indexing.googleapis.com/v3/urlNotifications:publish.
• Traktuj odpowiedź 200 jako potwierdzenie odbioru tylko — nie dowód, że strona została zaindeksowana lub usunięta.
• Sprawdź w Search Console (URL Inspection lub Coverage), jeśli potrzebujesz potwierdzić faktyczny status indeksowania.

Pozostając w ramach wytycznych

• Zgłaszaj tylko strony JobPosting/BroadcastEvent przez to API — nic innego.
• Nie twórz wielu kont usługowych ani projektów tylko po to, aby przekroczyć limit; poproś o legalne zwiększenie.
• Jeśli nie jesteś pewien, czy strona kwalifikuje się, traktuj to jako “nie kwalifikuje się” i użyj dla niej map witryn/linków wewnętrznych/Request indexing.

Quiz

Pięć pytań, aby sprawdzić, co faktycznie utkwiło na temat Indexing API.

Dziennik zmian