Mistrzowskie opanowanie Google search console i indexing API w 2026

W 2012 roku, żeby dodać stronę do Google, wypełniałeś formularz addurl.html i czekałeś.

W 2026 roku masz trzy realne narzędzia: raport pokrycia w Search Console, URL Inspection oraz - w wąskim, oficjalnie udokumentowanym zakresie - Indexing API. Do tego dochodzi sitemap XML jako kanał odkrywania i IndexNow jako protokół innych wyszukiwarek. Mylenie tych warstw to najczęstszy błąd w skryptach “natychmiastowej indeksacji” pod WordPressem.

Ten przewodnik jest dla dewelopera, który utrzymuje WordPressa albo headless front pod Google. Cel: wiedzieć, co mierzyć w GSC, kiedy Indexing API ma sens według dokumentacji Google, kiedy sitemap wystarczy, i kiedy spamowanie powiadomieniami tylko marnuje quota projektu.

#Raport pokrycia a URL Inspection

Google Search Console nie jest jednym ekranem. Dwa widoki rozwiązują inne problemy i nie wolno ich używać zamiennie.

Raport Pages (dawniej Coverage) to widok agregatowy. Pokazuje, ile URL-i jest w indeksie, ile wykluczonych, i z jakiego powodu: Discovered - currently not indexed, Crawled - currently not indexed, przekierowania, noindex, soft 404, błędy serwera. To miejsce, w którym szukasz trendów: skok wykluczeń po deployu, masa sierot po migracji slugów, spekulacja parametrów UTM w indeksie.

URL Inspection to diagnostyka jednego adresu. Pokazuje, czy Google zna URL, jaki kanoniczny wybrał, kiedy ostatnio crawlowano, czy rendering HTML się udał, czy structured data przechodzi. Przycisk “Request indexing” w Inspection to ręczny ping crawl budżetu dla tego jednego URL-a - nie jest zamiennikiem Indexing API i nie skaluje się do tysięcy ścieżek.

Praktyczny workflow na produkcji WPPoland wygląda tak:

1. W Pages znajdź kategorię wykluczenia z rosnącym licznikiem.
2. Weź 5-10 przykładowych URL-i z tej kategorii.
3. Odpal URL Inspection na każdym: sprawdź status HTTP, kanoniczny, datę crawla, rendered HTML.
4. Dopiero potem zmieniaj treść, linkowanie albo robots - nie wysyłaj masowo powiadomień API “na wszelki wypadek”.

Jeśli Inspection mówi Submitted and indexed, a strona nie rankinguje, problem nie leży w indeksacji. Kończysz debug crawl/index i wracasz do treści, intencji zapytania i konkurencji SERP.

#Oficjalny zakres Indexing API

Dokumentacja Google Search Central jest jednoznaczna: Indexing API służy do powiadamiania Google o stronach z markupiem JobPosting albo BroadcastEvent (transmisje na żywo / livestream). Typy powiadomień to URL_UPDATED i URL_DELETED.

To nie jest ogólny “push do indeksu” dla blogów, landingu usług, portfolio ani sklepu WooCommerce. Powiadomienie dowolnego URL-a poza tym zakresem:

• wykracza poza udokumentowany use case,
• nie gwarantuje szybszego crawl ani indeksacji,
• zużywa quota konta serwisowego w Google Cloud.

Społeczność SEO od lat testuje API na “zwykłych” stronach. Wyniki są niespójne: czasem Googlebot pojawia się szybko, czasem status w Inspection nie zmienia się wcale. Traktuj takie testy jako eksperyment, nie jako fundament architektury. W kodzie produkcyjnym zakładaj oficjalny kontrakt: oferty pracy i livestreamy z poprawnym JSON-LD.

Dla WordPressa oznacza to konkretne scenariusze:

• wtyczka lub CPT ofert pracy z JobPosting w head - wtedy URL_UPDATED przy publikacji / aktualizacji / wygaśnięciu oferty ma sens,
• strona wydarzenia z BroadcastEvent i realną transmisją - sens ma powiadomienie o starcie i o zakończeniu (URL_DELETED albo aktualizacja statusu),
• zwykły post blogowy, landing usług, kategoria WooCommerce - zostań przy sitemap + wewnętrznym linkowaniu + ewentualnym ręcznym Request indexing dla krytycznych URL-i.

#Quoty i konfiguracja konta serwisowego

Indexing API działa przez Google Cloud: włączasz API w projekcie, tworzysz service account, pobierasz klucz JSON, dodajesz e-mail konta serwisowego jako właściciela (Owner) property w Search Console. Bez Owner API odrzuci requesty.

Limitu dziennego nie kopiuj z artykułów ani z pamięci. Quota jest przypisana do projektu w Google Cloud Console (Quotas / Metrics dla Indexing API). Google może ją zmieniać; twój limit widzisz tylko w konsoli swojego projektu. Zanim napiszesz crona, odczytaj aktualny limit i zostaw zapas na peaki publikacji ofert.

Implementacja w PHP typowo używa googleapis/google-api-php-client:

$client = new Google_Client();
$client->setAuthConfig('/secure/path/service-account.json');
$client->addScope(Google_Service_Indexing::INDEXING);

$service = new Google_Service_Indexing($client);
$notification = new Google_Service_Indexing_UrlNotification();
$notification->setUrl('https://example.com/pl/oferta/senior-wordpress/');
$notification->setType('URL_UPDATED');

$service->urlNotifications->publish($notification);

Uwagi inżynierskie, które omijają “hello world” z dokumentacji:

• trzymaj JSON klucza poza webrootem i poza repozytorium,
• loguj url, type, HTTP status i message z odpowiedzi API,
• nie retry’uj w pętli przy 429 / quota - odkładaj do kolejki z backoffem,
• przed URL_UPDATED upewnij się, że strona zwraca 200, nie ma noindex, a JSON-LD JobPosting/BroadcastEvent jest w HTML (nie tylko w JS po hydracji).

Po publish sprawdź URL Inspection. Powiadomienie to sygnał, nie gwarancja indeksacji. Jeśli markup jest zepsuty albo strona jest thin, Google może zignorować URL mimo 200 z API.

#Kiedy nie spamować Indexing API

Najkrótsza reguła: jeśli strona nie jest ofertą pracy ani livestreamem w sensie dokumentacji, nie buduj wokół Indexing API pipeline’u “każdy publish = publish notification”.

Nie spamuj API w tych sytuacjach:

• codzienny post blogowy albo aktualizacja treści marketingowej,
• masowa regeneracja permalinków po zmianie struktury URL,
• cron co 5 minut “odświeżający” te same ścieżki,
• próba “naprawy” Discovered - currently not indexed tysiącami powiadomień,
• deploy CSS/JS bez zmiany treści indeksowanej,
• staging / preview URL-e (nawet jeśli przypadkiem są w GSC).

Dlaczego to szkodzi: zużywasz quota, którą potrzebujesz w dniu masowej publikacji ofert. Generujesz szum w logach. Nie naprawiasz przyczyny wykluczenia - Google i tak ocenia jakość, kanoniczność i crawl budget. Jeśli Pages pokazuje Crawled - currently not indexed, problem zwykle siedzi w treści, duplikatach, braku linków wewnętrznych albo słabym sygnale E-E-A-T - nie w braku pingu API.

Zamiast spamu:

1. Popraw treść i linkowanie wewnętrzne.
2. Upewnij się, że URL jest w sitemap i sitemap jest zaakceptowany w GSC.
3. Dla pojedynczego krytycznego URL użyj Request indexing w URL Inspection.
4. Indexing API zostaw dla JobPosting / BroadcastEvent zgodnie z dokumentacją.

#Sitemap XML: podstawowy kanał odkrywania

Sitemap nadal jest domyślnym, skalowalnym sposobem powiedzenia Google “te URL-e istnieją”. WordPress (core, Yoast, Rank Math, własny generator Astro) powinien emitować aktualną mapę; Ty jako deweloper odpowiadasz za poprawność, nie za “czy plugin coś robi”.

Minimum techniczne:

• każdy indeksowalny kanoniczny URL w <loc>,
• aktualizacja mapy po publish / unpublish,
• zgłoszenie sitemap w Search Console (Sitemaps) albo przez robots.txt (Sitemap: https://…/sitemap.xml),
• brak soft 404 i przekierowań w <loc> - mapuj cele 200,
• osobne rozszerzenia obrazów (image:image), gdy zależy Ci na Google Images / Lens.

Przykład fragmentu z obrazem:

<url>
  <loc>https://wppoland.com/pl/przyklad/</loc>
  <image:image>
    <image:loc>https://wppoland.com/images/przyklad.avif</image:loc>
  </image:image>
</url>

Sitemap nie wymusza indeksacji. Mówi Google o istnieniu URL-a. Jeśli URL ląduje w Discovered - currently not indexed, mapa zadziałała jako odkrycie; brak indeksu to decyzja jakościowa / budżetowa, nie “zepsuta mapa”.

Programowe zgłaszanie map (Search Console API) ma sens przy wielu property albo automatyzacji CI. Dla jednej witryny wystarczy jednorazowe dodanie w UI i monitoring statusu “Success” / “Couldn’t fetch”.

#Debugowanie stanów “discovered” i “crawled - not indexed”

Te dwa stany mylą się w ticketach SEO.

Discovered - currently not indexed: Google zna URL (sitemap, link, inny sygnał), ale jeszcze nie crawlowano albo crawl odłożono. Częste przyczyny: niski priorytet w budżecie, masa nowych URL-i naraz, słabe linkowanie, parametry / facety.

Crawled - currently not indexed: Googlebot był na stronie i zdecydował, że na razie nie wrzuca jej do indeksu. Tu patrzysz na thin content, near-duplicate, kanoniczny wskazujący indziej, render bez treści, niski sygnał z linków wewnętrznych.

Checklist deweloperski przed eskalacją do “włączmy Indexing API”:

• HTTP 200, bez noindex / X-Robots-Tag,
• kanoniczny self-reference zgodny z URL w GSC,
• treść w pierwszym HTML (nie dopiero po client-side fetch),
• ≥ jednego znaczącego linku wewnętrznego z indeksowanej strony,
• brak kopii pod drugim slugiem / parametrem,
• URL obecny w sitemap.

Dopiero gdy checklist jest zielony, a URL jest JobPosting/BroadcastEvent, wracasz do Indexing API. W pozostałych przypadkach API nie jest lekarstwem.

#IndexNow to nie Google Indexing API

IndexNow to otwarty protokół powiadamiania wyszukiwarek o nowych i usuniętych URL-ach. Bing, Yandex i partnerzy go obsługują. Google nie jest uczestnikiem IndexNow - powiadomienie IndexNow nie idzie do Googlebota.

Różnice praktyczne:

W WordPressie plugin “IndexNow” albo własny endpoint z kluczem w rootcie ma sens, jeśli zależy Ci na Bing. Nie myl go z Google Indexing API w nazwie zmiennej, cronie ani dokumentacji wewnętrznej - to dwa różne kontrakty, dwa różne authy, dwa różne efekty.

#robots.txt i budżet crawla

robots.txt nie indeksuje i nie deindeksuje. Steruje dostępem botów. W 2026 warto świadomie rozdzielić:

• Googlebot / Google-InspectionTool - pozwól na ścieżki, które mają być w indeksie,
• boty AI / scrapery, które nie budują Twojego ruchu z wyszukiwarki - decyzja produktowa (blokada vs allow),
• ścieżki admin, preview, feedy parametryczne - Disallow tam, gdzie crawl nic nie daje.

Przykład obronny (dostosuj do polityki firmy):

User-agent: GPTBot
Disallow: /

User-agent: CCBot
Disallow: /

User-agent: Googlebot
Allow: /

Blokada scrapera nie naprawi Crawled - currently not indexed. Może jedynie ograniczyć zbędny ruch. Budżet Googlebota zarządzasz jakością URL-i, sitemapą i linkowaniem - nie listą Disallow na konkurencyjne LLM-y.

#Minimalny stack automatyzacji pod WordPress

Dla typowej witryny firmowej / agencyjnej:

1. Generator sitemap (plugin lub SSG) + status Success w GSC.
2. Monitoring Pages raz w tygodniu (albo Search Console API w CI).
3. URL Inspection na URL-ach z regresją po deployu.
4. Indexing API tylko jeśli publikujesz JobPosting / BroadcastEvent.
5. Opcjonalnie IndexNow pod Bing - osobny job, osobny klucz.

Dla portalu z setkami ofert pracy dziennie dodaj kolejkę powiadomień, odczyt quoty z Cloud Console, alert przy zbliżeniu do limitu i walidację JSON-LD przed publish. Bez walidacji markupu marnujesz requesty.

#Podsumowanie operacyjne

• Pages = trend i kategorie wykluczeń; URL Inspection = jeden URL pod lupą.
• Indexing API = oficjalnie JobPosting i BroadcastEvent; generic URL notification jest poza kontraktem.
• Quota: tylko z Google Cloud Twojego projektu, bez liczb z pamięci.
• Sitemap zostaje podstawą odkrywania; API go nie zastępuje.
• Nie spamuj powiadomieniami przy problemach jakościowych.
• IndexNow ≠ Google; to inna wyszukiwarka i inny protokół.

Nie czekaj na cudowny ping. Najpierw spraw, żeby URL był wart crawl. Potem wybierz właściwy kanał powiadomienia - i tylko ten.