API indeksowania Google

Co faktycznie robi Google Indexing API — oficjalnie wspierane tylko dla stron z danymi strukturalnymi JobPosting i BroadcastEvent (transmisje na żywo), a nie dla ogólnych treści. Mity, co naprawdę mówi Google i czego użyć zamiast tego, aby przyspieszyć indeksowanie.

Opublikowano po raz pierwszy: 22 cze 2026 · Ostatnia aktualizacja: 3 sie 2026 · Advanced
Języki

Google Indexing API to programowy sposób powiadamiania Google, że adres URL został dodany, zaktualizowany lub usunięty — ale Google oficjalnie wspiera go tylko dla stron z danymi strukturalnymi JobPosting lub BroadcastEvent (transmisje na żywo), a nie dla ogólnych treści. Największym mitem jest to, że indeksuje każdą stronę szybko; tak nie jest, a pomyślne przesłanie tylko potwierdza, że Google otrzymał Twoje żądanie, a nie że cokolwiek zostało zaindeksowane. Google wielokrotnie ostrzegał, że niewłaściwe użycie może skutkować odebraniem dostępu. W przypadku zwykłych stron użyj map witryn, linków wewnętrznych, jakości i okazjonalnego „Poproś o zindeksowanie” w Search Console.

TL;DR — 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: „spammers misuse the Indexing API… use it properly, or not use it”). 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.

Evidence for this claim Google documents the Indexing API for pages containing JobPosting or BroadcastEvent embedded in VideoObject, not general-purpose web indexing. Scope: Current documented eligibility. Confidence: high · Verified: Google Search Central: Indexing API overview Evidence for this claim An Indexing API notification tells Google that an eligible URL changed or was deleted; it does not guarantee crawling or indexing. Scope: Current API semantics and indexing caveat. Confidence: high · Verified: Google Search Central: Using the Indexing API

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. 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:

Evidence for this claim Google currently limits the Indexing API to pages with JobPosting or BroadcastEvent embedded in a VideoObject. Scope: official Google documentation, Search Console and production URL verification Confidence: high · Verified: Indexing API Quickstart
  • 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 — własne sformułowanie Google mówi, że to “oznacza, że Google może wkrótce spróbować ponownie zaindeksować ten adres URL,” a nie że 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” — przekroczenie ich “wymaga dodatkowej zgody na użycie i przydział zasobów” przez formularz zgłoszeniowy, a Google zauważa, że “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,” 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.”

Evidence for this claim Indexing API submissions undergo spam detection, and quota circumvention or abuse can lead to revoked access. Scope: official Google documentation, Search Console and production URL verification Confidence: high · Verified: Indexing API Quickstart

Przedstawiciele mówili to od lat. Już w maju 2022 John Mueller ujął to swoją aalogią z pojazdami budowlanymi: API “is meant for very specific kinds of content,” a używanie go gdzie indziej “doesn’t really make sense.” 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,” 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.”

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.” Jeśli panel pokazuje zieloną odznakę “zaindeksowano” na podstawie 200, to wnioskuje coś, czego API nigdy mu nie powiedziało.

Indexing API vs Request Indexing vs 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.

Add an expert note

Pin an expert quote

New person? Create their unclaimed profile at /admin/experts/ → Pin a quote first.