GSC API 2026

GSC API 2026 — zaawansowane zapytania, bulk export i integracja z BigQuery

przez

TL;DR. Google Search Console API w 2026 roku to już nie tylko pobieranie top zapytań do arkusza. Trzy rzeczy, które naprawdę zmieniają grę: bezstratny bulk export do BigQuery (dzienny zrzut pełnego searchdata_site_impression i searchdata_url_impression), rozszerzone limity 25 000 wierszy na zapytanie przy paginacji tokenem, oraz nowe wymiary — hourly_timestamp, discover i googleNews — dostępne zarówno w API, jak i w eksporcie. W praktyce oznacza to, że zespoły SEO mogą dziś pracować na pełnym, nieagregowanym grafie zapytań i URL-i, łączyć go z danymi z crawla oraz modelami atrybucji AIO — bez limitu 1 000 wierszy UI i bez konieczności klejenia plików CSV. W tym artykule pokazujemy dokładnie, jak to uruchomić: od OAuth, przez paginację, po dashboardy w Looker Studio zasilane BigQuery.

Dlaczego GSC API 2026 to osobna kategoria narzędzia, nie „UI z eksportem”?

Interfejs Search Console w przeglądarce robi jedną rzecz dobrze — pokazuje trend. Do wszystkiego innego potrzebujesz API albo bulk exportu. Powód jest prosty i znany każdemu, kto próbował wyciągnąć dane z dużego serwisu. UI agreguje, zaokrągla i odcina na 1 000 wierszach. Dla sklepu z 40 tysiącami URL-i to jak patrzeć na morze przez dziurkę od klucza. Można zobaczyć falę, ale nie policzyć ryb.

W 2026 roku GSC API daje trzy rzeczy, których UI nigdy nie udostępni. Po pierwsze — pełną dystrybucję zapytań, także tych z 1–2 kliknięciami, które są zwykle najważniejsze dla topical authority. Po drugie — pary query × page bez utraty granularności, czyli dokładnie wiesz, które zapytanie prowadzi do którego URL. Po trzecie — możliwość cofnięcia się w czasie dalej niż 16 miesięcy, o ile codziennie zrzucasz dane do własnej hurtowni.

To nie jest egzotyka dla analityków. To jest baza operacyjna nowoczesnego SEO. Decyzje o konsolidacji treści, kanibalizacji, repozycjonowaniu w obrębie klastra — wszystkie te rzeczy wymagają surowych danych, nie wykresu w UI. Jeśli prowadzisz serwis powyżej 5 000 URL-i i nie zrzucasz GSC do hurtowni, tracisz sygnał. Zobacz też nasz rozbudowany przewodnik po łączeniu GA4 i GSC w artykule GA4 i Search Console w 2026, który uzupełnia ten tekst od strony atrybucji.

Jak wygląda uwierzytelnianie i co się zmieniło w 2026 względem poprzednich lat?

Fundament jest ten sam — OAuth 2.0 w wariancie service account lub user credentials. Różnica jest w zakresie uprawnień i w sposobie, w jaki Google egzekwuje granice projektów Cloud. Od końca 2025 roku Search Console API wymaga, żeby projekt GCP był aktywny i miał włączoną Search Console API w konsoli. Dla kont service account trzeba dodać adres e-mail service accounta jako właściciela w Search Console na poziomie property — bez tego searchAnalytics.query zwraca 403, nawet jeśli token jest poprawny.

W praktyce rekomendujemy service account, bo nie wymaga interwencji użytkownika, nie wygasa po zamknięciu sesji i skaluje się na wiele property jednocześnie. Dla bulk exportu do BigQuery service account musi mieć rolę BigQuery Data Editor w docelowym projekcie, a property w GSC musi mieć włączony Data export z tym projektem jako celem. To konfiguruje się raz, potem dane lecą codziennie o 04:00 UTC do tabel partycjonowanych po dacie.

Jedna rzecz, o której mało kto mówi: od 2026 Google waliduje zgodność tożsamości właściciela property z rolami IAM w projekcie docelowym bulk exportu. Jeśli ktoś z zespołu opuści organizację i zostanie usunięty z property, eksport przestanie działać w ciągu 48 godzin. Warto mieć procedurę rotacji właścicieli, bo inaczej w pewnym momencie ktoś otworzy BigQuery i zobaczy pustą tabelę z wczoraj.

Jakie endpointy i limity oferuje Search Console API w 2026?

GSC API ma mniej endpointów niż GA4, ale każdy z nich jest dokładnie zaprojektowany pod konkretny use case. Poniżej pełna lista tego, co jest aktualnie w produkcji, wraz z limitami z 2026 roku. Limity są wyższe niż w 2024, ale nadal agresywne — trzeba je znać, bo inaczej skończysz na 429 w środku zrzutu.

Endpoint Metoda Przeznaczenie Limit 2026
searchanalytics.query POST Klucz do wszystkiego — zapytania, URL-e, kraje, urządzenia, daty 25 000 wierszy / request, 1 200 req / min / project
sites.list GET Lista property dostępnych dla konta 600 req / min / project
sites.get GET Metadane property — poziom uprawnień 600 req / min / project
sitemaps.list GET Lista wszystkich sitemap w property 300 req / min / property
sitemaps.get GET Status konkretnego pliku sitemap 300 req / min / property
sitemaps.submit PUT Zgłoszenie nowej sitemap 300 req / min / property
urlInspection.index.inspect POST Status indeksowania pojedynczego URL 2 000 req / dzień / property
Bulk export → BigQuery — Pełny zrzut searchdata_* bez sampling-u ~50 mln wierszy / dzień / property (brak formalnego limitu)

Najważniejsze, co trzeba zrozumieć: limit 25 000 wierszy na request w searchanalytics.query dotyczy jednej odpowiedzi, nie całego zrzutu. Paginacja przez startRow pozwala pobrać dowolnie dużo danych — w praktyce zrzucamy property z 200 000 zapytań w około 8 minut. Limit dzienny dla URL Inspection to 2 000 na property, więc dla dużych serwisów jest to raczej narzędzie do sample-audytu niż masowego skanowania.

Jak wygląda minimalny poprawny request w Pythonie?

Poniżej kompletny, działający przykład — zrzut top zapytań z ostatnich 28 dni z paginacją. Ten kod wdrażam u klientów jako fundament — dalej dobudowuje się wymiary, filtry i wielowątkowość, ale kręgosłup jest zawsze ten sam.

from google.oauth2 import service_account
from googleapiclient.discovery import build

SCOPES = ["https://www.googleapis.com/auth/webmasters.readonly"]
creds = service_account.Credentials.from_service_account_file(
    "service-account.json", scopes=SCOPES
)
gsc = build("searchconsole", "v1", credentials=creds, cache_discovery=False)

site = "sc-domain:twojadomena.pl"
body = {
    "startDate": "2026-03-21",
    "endDate": "2026-04-17",
    "dimensions": ["query", "page", "country", "device"],
    "rowLimit": 25000,
    "startRow": 0,
    "dataState": "final",
}

rows = []
while True:
    resp = gsc.searchanalytics().query(siteUrl=site, body=body).execute()
    batch = resp.get("rows", [])
    rows.extend(batch)
    if len(batch) < 25000:
        break
    body["startRow"] += 25000

print(f"Pobrano {len(rows)} wierszy")

Kilka rzeczy, na które warto zwrócić uwagę. dataState: "final" oznacza dane w pełni przetworzone, bez „fresh” z ostatnich 2–3 dni, które jeszcze się zmieniają. Dla raportów produkcyjnych zawsze final. Dla alertingu „coś spadło wczoraj” — fresh. Drugie: sc-domain: to format dla property typu domain, bez slasha na końcu. Dla property typu URL prefix podaje się pełny adres z protokołem i slashem. Pomylenie tych formatów to najczęstszy powód 404 w pierwszej godzinie integracji.

Kiedy używać API, a kiedy bulk export do BigQuery?

To jest pytanie, które pada na każdym wdrożeniu i warto odpowiedzieć na nie raz a dobrze. API i bulk export to nie są konkurencyjne rozwiązania — one się uzupełniają. Każde ma inne miejsce w architekturze danych.

API używamy, gdy: potrzebujemy danych ad-hoc w skrypcie, robimy raport cykliczny do 28 dni wstecz, chcemy sprawdzić status indeksowania pojedynczych URL-i, albo automatyzujemy zgłaszanie sitemap. API jest szybkie, nie wymaga hurtowni, działa „od razu”. Dla serwisu do 20 000 URL-i i do 50 000 zapytań dziennie API w zupełności wystarczy i jest tańsze niż utrzymanie BigQuery.

Bulk export do BigQuery używamy, gdy: chcemy mieć dane z okresu dłuższego niż 16 miesięcy, potrzebujemy joinować GSC z GA4, CRM, crawlem Screaming Frog albo sitemap; mamy serwis z dziesiątkami tysięcy URL-i, gdzie paginacja API trwa godziny; budujemy dashboard w Looker Studio z cache-owaniem po stronie hurtowni; chcemy mieć dane w wymiarze godzinowym (hourly_timestamp dostępny tylko w eksporcie). Bulk export to też jedyny sposób, żeby dostać pełny, nieagregowany graf query × url × date × country × device — API zawsze coś przytnie przy dużych wolumenach.

Nasza rekomendacja dla serwisów powyżej 5 000 URL-i: bulk export zawsze, API jako uzupełnienie. Koszt BigQuery dla średniej wielkości serwisu to 10–40 USD / miesiąc, co jest mniej niż jeden licencjonowany slot narzędzia SEO klasy korporacyjnej.

Jak skonfigurować bulk export do BigQuery krok po kroku?

Konfiguracja wygląda na prostą, ale ma kilka pułapek, o które klienci rozbijają się regularnie. Poniżej framework, który sprawdza się u nas w 100% wdrożeń od początku 2025 roku.

  1. Utwórz projekt w Google Cloud dedykowany dla SEO — nie mieszaj z produkcyjnym projektem firmy. To ważne, bo bulk export tworzy dataset w tym projekcie i nie chcemy zanieczyszczać hurtowni marketingowej.
  2. Włącz Search Console API i BigQuery API w konsoli — bez tego export zwróci błąd 403 w fazie inicjalizacji.
  3. Utwórz service account z rolami BigQuery Data Editor i BigQuery Job User na poziomie projektu. Pobierz klucz JSON, przechowuj w secrets managerze, nigdy w repo.
  4. Dodaj service account jako właściciela property w Search Console (Settings → Users and permissions → Add user → rola Owner).
  5. Włącz Data export w Search Console (Settings → Bulk data export) podając ID projektu GCP, lokalizację datasetu (zawsze EU dla polskich serwisów, nie US) i dataset name.
  6. Poczekaj 48 godzin — pierwszy zrzut pojawi się następnego dnia po 04:00 UTC. Nie restartuj konfiguracji, jeśli nie widzisz danych pierwszego dnia. To normalne.
  7. Zweryfikuj tabele searchdata_site_impression i searchdata_url_impression w datasecie. Jeśli są, ale puste — sprawdź uprawnienia service accounta na property.
  8. Zbuduj widoki agregujące jako warstwę semantyczną w BigQuery, żeby Looker Studio i analitycy nie odpytywali tabel surowych (drogie query-e).
  9. Skonfiguruj alerting na kosztach w BigQuery — budżet 50 USD / miesiąc z powiadomieniem na 80%. Zły JOIN potrafi przepalić 100 USD w jedną noc.

Ten framework mamy spisany jako checklist w audycie technicznym SEO 2026 — polecamy lekturę, jeśli wdrażasz to razem z innymi integracjami danych.

Jak wygląda struktura tabel searchdata_* i jakie są najważniejsze kolumny?

Bulk export tworzy trzy tabele, z których dwie są operacyjne. searchdata_site_impression zawiera dane na poziomie całej property (bez URL), searchdata_url_impression — na poziomie pojedynczego URL. Trzecia tabela, ExportLog, to metadane o statusie eksportu (nie używamy jej do analiz). Obie tabele operacyjne są partycjonowane po data_date — partycjonowanie jest absolutnie kluczowe dla kosztów, bo bez filtra po dacie query przeczesuje całą historię.

Najważniejsze kolumny w searchdata_url_impression, które warto znać: data_date (DATE, partition key), site_url (STRING), url (STRING, pełny URL), query (STRING), is_anonymized_query (BOOL — true dla zapytań anonimizowanych przez Google), country, search_type (web, image, video, news, discover, googleNews), device, is_amp_top_stories, impressions, clicks, sum_top_position. Średnia pozycja to sum_top_position / impressions + 1 — Google loguje top position zero-indexed, więc trzeba dodać 1.

W 2026 pojawiła się też nowa kolumna hourly_timestamp dla property, które mają włączony rozszerzony eksport. Daje ona agregację godzinową kliknięć i impresji, co otwiera zupełnie nowe możliwości analizy — można wreszcie zobaczyć, o której godzinie Google podnosi Twoją stronę w wynikach Discover albo kiedy wpada ruch z AI Overviews. Dla większości serwisów to jest godzina 06:00–08:00 rano, ale dla niektórych nisz — zupełnie co innego.

Jakie są najczęstsze zapytania SQL, które warto mieć gotowe?

Poniżej trzy query-e, które u nas leżą w szufladzie każdego konsultanta i są pierwsze do uruchomienia przy nowym projekcie. Wszystkie filtrują po data_date, bo inaczej koszt byłby nie do przyjęcia.

Query 1 — top 100 stron z największym spadkiem klików tydzień-do-tygodnia:

WITH t AS (
  SELECT url,
         SUM(IF(data_date BETWEEN '2026-04-04' AND '2026-04-10', clicks, 0)) AS prev_clicks,
         SUM(IF(data_date BETWEEN '2026-04-11' AND '2026-04-17', clicks, 0)) AS curr_clicks
  FROM `project.searchconsole.searchdata_url_impression`
  WHERE data_date BETWEEN '2026-04-04' AND '2026-04-17'
  GROUP BY url
)
SELECT url, prev_clicks, curr_clicks,
       curr_clicks - prev_clicks AS delta,
       SAFE_DIVIDE(curr_clicks - prev_clicks, prev_clicks) * 100 AS delta_pct
FROM t
WHERE prev_clicks > 50
ORDER BY delta ASC
LIMIT 100;

Query 2 — kanibalizacja (zapytania, gdzie rankuje więcej niż jeden URL w top 10):

SELECT query,
       COUNT(DISTINCT url) AS competing_urls,
       ARRAY_AGG(STRUCT(url, clicks, impressions) ORDER BY clicks DESC LIMIT 3) AS top_urls
FROM `project.searchconsole.searchdata_url_impression`
WHERE data_date BETWEEN '2026-03-21' AND '2026-04-17'
  AND SAFE_DIVIDE(sum_top_position, impressions) + 1 <= 10
GROUP BY query
HAVING competing_urls >= 2 AND SUM(impressions) > 200
ORDER BY SUM(impressions) DESC
LIMIT 100;

Query 3 — sygnały Discover (jeśli masz ruch z Discover):

SELECT url,
       SUM(clicks) AS discover_clicks,
       SUM(impressions) AS discover_impr,
       SAFE_DIVIDE(SUM(clicks), SUM(impressions)) * 100 AS ctr
FROM `project.searchconsole.searchdata_url_impression`
WHERE data_date BETWEEN '2026-03-21' AND '2026-04-17'
  AND search_type = 'discover'
GROUP BY url
HAVING discover_impr > 1000
ORDER BY discover_clicks DESC
LIMIT 50;

Trzymaj te query-e w repozytorium razem z kodem pipelinów. Wersjonowanie zapytań analitycznych to często pomijany aspekt, a to one są prawdziwą wartością Twojej hurtowni SEO.

Jak zautomatyzować alerty na spadkach widoczności?

Najwartościowsze wdrożenie, jakie można zbudować na GSC API, to system wczesnego ostrzegania. Nie czekasz, aż klient zadzwoni, że „ruch spadł” — dostajesz Slacka o 07:15 rano, że wczoraj 12 URL-i straciło ponad 30% klików tydzień-do-tygodnia.

Architektura jest prosta. Cloud Scheduler wywołuje Cloud Function o 07:00 UTC. Function czyta wczorajszą partycję z searchdata_url_impression, porównuje do poprzedniego tygodnia (średnia 7-dniowa), filtruje URL-e z istotnym spadkiem i wysyła webhook na Slacka. Cały kod to około 120 linii Pythona, uruchomienie kosztuje grosze miesięcznie.

Kilka zasad, które wyciągnąłem z 3 lat prowadzenia takiego systemu. Po pierwsze — nie alertuj na URL-ach z mniej niż 50 klików tygodniowo, bo szum statystyczny zabije Ci sygnał. Po drugie — używaj dwóch porównań (tydzień-do-tygodnia i 7-dniowa średnia rolująca), bo jedno może być mylące w okresach świątecznych. Po trzecie — grupuj spadki po katalogach URL, bo spadek w całym katalogu /blog/ to zupełnie inny problem niż jeden URL na dnie. Integrację z Zapierem pokazujemy w artykule Alerty GSC w Zapier.

Najczęstsze błędy przy pracy z GSC API i bulk exportem

W ciągu ostatnich dwóch lat przejrzałem konfiguracje kilkudziesięciu serwisów i wszystkie błędy sprowadzają się do kilku powtarzalnych wzorców. Zapisz to i wróć, zanim uruchomisz produkcję.

Błąd 1 — mieszanie strefy czasowej UTC z lokalną. GSC zawsze loguje dane w Pacific Time (PT, UTC-8/-7). Jeśli porównujesz z GA4 w Warsaw Time, masz przesunięcie 8–9 godzin, które widać szczególnie w raportach godzinowych. Zawsze normalizuj daty w BigQuery przez DATE(data_date, 'Europe/Warsaw').

Błąd 2 — ignorowanie is_anonymized_query. Google anonimizuje około 30–50% zapytań (pokazuje jako pusty string). Jeśli nie filtrujesz tego pola, Twoje TOP zapytania będą zdominowane przez „brak zapytania”. Zawsze używaj WHERE is_anonymized_query = FALSE w raportach top-query.

Błąd 3 — porównywanie searchdata_site_impression z searchdata_url_impression. Sumy się nie zgadzają i to jest by design. site_impression to „impresja strony w wynikach” (jedna impresja = jedno wyświetlenie SERP z Twoją stroną), url_impression to „impresja konkretnego URL” (jeden SERP może mieć 2–3 Twoje URL-e). Nie próbuj tego uzgadniać, to dwie różne metryki.

Błąd 4 — paginacja API bez backoff-u. Przy 25 000 wierszach na request limity dzienne wyczerpują się szybko. Zawsze dodawaj exponential backoff na 429 (start 1s, max 60s, 5 retry).

Błąd 5 — eksport do US zamiast EU. Jeśli jesteś polskim serwisem i wybrałeś lokalizację US dla datasetu, masz wyższe koszty transferu danych do Looker Studio (który domyślnie jest w EU). Zawsze EU dla polskich serwisów.

Błąd 6 — brak filtra po search_type. Dane Discover i Google News są w tej samej tabeli co Web. Jeśli ich nie filtrujesz, Twoje raporty organic search mieszają trzy różne źródła ruchu.

Błąd 7 — trzymanie klucza service account w repozytorium. To brzmi oczywiste, ale widzę to regularnie. Zawsze secrets manager, zawsze .gitignore, zawsze pre-commit hook, który blokuje pliki JSON wyglądające jak credential.

Jak integrować dane GSC z GA4 i CRM w jednej hurtowni?

To jest etap „dojrzały” wdrożenia — moment, w którym GSC przestaje być osobnym narzędziem, a staje się jednym z wielu źródeł w Twoim data layer. Architektura referencyjna wygląda tak: GSC bulk export leci do BigQuery dataset searchconsole, GA4 export leci do analytics, CRM eksportuje nocą przez Fivetran do crm, a na wierzchu masz dataset mart z widokami, które joinują to wszystko po URL (dla GSC × GA4) i po user_id / transaction_id (dla GA4 × CRM).

Jedna subtelność — GSC loguje URL kliknięty w SERP-ie, GA4 loguje URL, na który trafił użytkownik po wszystkich przekierowaniach. Jeśli masz redirect 301 ze starego URL na nowy, w GSC widzisz stary, w GA4 — nowy. Join trzeba robić przez tabelę mapowania redirectów, inaczej 10–20% traffic-u ucieka. To jest detal, który odróżnia amatorską integrację od profesjonalnej.

Dla polskich serwisów polecamy trzymać też tabelę canonical URL (z crawla Screaming Frog albo Sitebulb) w tym samym datasecie, bo wtedy joinu robisz nie po URL raw, ale po canonical URL. To eliminuje problemy z URL-ami z parametrami UTM, które Google czasem indeksuje mimo canonical.

Jak wykorzystać GSC API do zasilania modeli AIO i monitoringu cytowań?

To jest temat 2026 roku. GSC nie pokazuje bezpośrednio, że cytuje Cię ChatGPT — ale pokazuje sygnały, które silnie korelują z cytowalnością. Mamy kilka praktycznych technik, które sprawdzają się u klientów.

Pierwsza — anomalia impresji bez klików. Jeśli URL nagle zyskuje 3x więcej impresji bez wzrostu klików, a pozycja nie spadła — prawdopodobnie zaczął być cytowany w AI Overview. Google loguje impresję dla AIO (bo strona jest w podsumowaniu), ale kliknięcia lecą gdzie indziej. Taki wzorzec monitorujemy jako osobny alert.

Druga — zapytania pytające w trendzie. Zapytania zaczynające się od „jak”, „dlaczego”, „co to”, „kiedy” są najczęściej cytowane przez modele AI. Monitorujemy udział zapytań pytających w total impressions jako proxy dla „gotowości AIO”. Serwisy z udziałem powyżej 40% są strukturalnie lepiej przygotowane do ery AI search.

Trzecia — comparison queries. Zapytania typu „X vs Y”, „najlepsze X 2026” są w AIO cytowane statystycznie częściej. Zbudowanie klastra treści pod takie query-e jest szybką wygraną. Jeśli planujesz audyt pod AIO, zerknij do naszego artykułu szablon audytu AIO 2026 — jest tam mapping sygnałów GSC na metryki AIO.

Czy BigQuery to jedyna opcja, czy są alternatywy?

BigQuery jest domyślnym celem bulk exportu, bo Google go wspiera natywnie — ale to nie jest jedyna hurtownia, w której chcesz mieć te dane. Można zrobić to w Snowflake, Redshift albo lokalnie w Postgres / DuckDB — tylko że musisz zbudować warstwę ETL samodzielnie.

Najczęstszy wzorzec dla firm, które już mają hurtownię nie-Google: bulk export leci do BigQuery jako staging, potem Airbyte / Fivetran / własny Python przerzuca partycje do docelowej hurtowni co 24h. Koszt BigQuery w tym scenariuszu to dosłownie kilka dolarów miesięcznie (bo tylko ingest + transfer), a dane masz tam, gdzie są zespoły analityczne.

Dla małych serwisów (do 10 000 URL-i) świetnie sprawdza się DuckDB lokalnie zasilany z API przez skrypt nocny. Nie masz kosztu hurtowni, query-e są szybkie, a 28 dni danych mieści się w kilku GB. To jest idealne dla konsultantów SEO, którzy chcą mieć własne „studio analityczne” bez infrastruktury chmurowej.

Pełną dokumentację API znajdziesz na developers.google.com/webmaster-tools, a dokumentację BigQuery Data Export na support.google.com/webmasters.

FAQ — najczęstsze pytania o GSC API i bulk export

Czy GSC API jest darmowe?

Tak, samo API jest bezpłatne w ramach limitów projektowych GCP. Bulk export do BigQuery jest darmowy po stronie Search Console — płacisz tylko za storage BigQuery (około 0,02 USD / GB / miesiąc) i query-e (5 USD / TB skanowanych danych). Dla średniego serwisu to 10–30 USD / miesiąc.

Jak długo dane są przechowywane w GSC i w bulk exporcie?

W UI i API — maksymalnie 16 miesięcy. W bulk exporcie do BigQuery — dowolnie długo, dane zostają w Twoich tabelach po dostarczeniu. Dlatego bulk export ma sens długoterminowo: po 2 latach masz historię niedostępną nigdzie indziej.

Czy mogę eksportować dane z Property zweryfikowanej przez HTML tag zamiast domain property?

Tak, bulk export działa dla obu typów property — URL prefix i domain. Rekomendujemy jednak domain property, bo łapie wszystkie subdomeny i protokoły, co ułatwia analizę krzyżową.

Ile wierszy dziennie generuje średnia polska strona?

Mały blog (500 URL-i, 10k sesji / miesiąc) — około 3 000–8 000 wierszy dziennie w searchdata_url_impression. Średni sklep (5 000 produktów) — 50 000–200 000 wierszy. Duży portal (50 000 URL-i) — 500 000–2 000 000 wierszy dziennie. Roczny storage dla dużego portalu to około 30–80 GB, czyli kilka dolarów miesięcznie.

Czy hourly_timestamp jest dostępny dla wszystkich property?

Od marca 2026 — tak, dla wszystkich property z włączonym bulk exportem. Wcześniej było to w fazie beta dla wybranych kont. Warto zweryfikować w schemacie tabeli, czy kolumna się pojawiła — czasami propagacja trwa kilka dni.

Jak pogodzić GSC API z RODO i polskim prawem?

GSC nie loguje danych osobowych, więc RODO w klasycznym sensie tu nie obowiązuje. Zapytania anonimizowane (is_anonymized_query = TRUE) to zapytania, które Google uznał za potencjalnie identyfikujące użytkownika — są już usunięte z danych. Jeśli łączysz GSC z GA4, RODO wchodzi po stronie GA4 i zgód na cookies, nie po stronie GSC.

Czy mogę mieć jeden bulk export dla wielu property?

Nie, każde property ma osobną konfigurację eksportu. Wszystkie mogą lecieć do tego samego projektu GCP, ale do różnych datasetów. Dla klienta z 20 property robimy jedną konfigurację dla każdej, a potem view w datasecie mart, który je sumuje.

Co zrobić, gdy bulk export nagle przestanie dostarczać dane?

Kolejność sprawdzania: (1) czy service account / właściciel property nadal jest aktywny, (2) czy projekt GCP ma aktywny billing, (3) czy BigQuery API nie zostało przypadkiem wyłączone, (4) czy dataset nadal istnieje w projekcie, (5) ExportLog w datasecie — tam są logi błędów z GSC. 90% przypadków to problem z IAM po zmianach personalnych.

Jak wersjonować zapytania i pipeline’y danych GSC w zespole?

Rzecz, której prawie nikt nie robi na początku, a która ratuje życie po pół roku — wersjonowanie wszystkiego, co dotyka danych GSC. Query-e SQL, definicje widoków, schemat tabel stagingowych, konfiguracja alertów — wszystko idzie do repozytorium Git. Bez tego nie da się odpowiedzieć na pytanie „dlaczego liczby w dashboardzie wyglądają inaczej niż trzy miesiące temu”.

Rekomendowana struktura repo to osobne katalogi dla warstw. sql/staging/ zawiera widoki, które tylko oczyszczają surowe tabele bulk exportu (filtr dat, normalizacja URL, unnesting tablic). sql/marts/ to modele biznesowe — jeden plik na encję (page_performance, query_health, cannibalization_signals). sql/reports/ to query-e, które zasilają konkretne dashboardy. Taki podział jest dokładnie tym, co popularyzuje dbt, i dla projektów powyżej 5 tabel warto po prostu wdrożyć dbt zamiast wymyślać własną konwencję.

Dla zespołów polskich polecam jedną dodatkową rzecz — komentarze w SQL-u po polsku. Kiedy przychodzi nowy analityk, angielski opis „weekly cannibalization by cluster” nie tłumaczy kontekstu biznesowego tak dobrze jak „wykrywa kanibalizację w obrębie kategorii, pomija strony produktowe”. Ta drobna rzecz skraca onboarding z tygodnia do dwóch dni.

Testy regresyjne na modelach danych to kolejny element, o którym zespoły marketingowe zapominają. W dbt wystarczy kilka linijek w pliku YAML — not_null na kluczach, unique tam, gdzie powinno być, accepted_values dla kolumny search_type. Taki prosty test wychwyci sytuację, w której Google nagle doda nowy typ wyszukiwania i Twoje query-e zaczną się sypać cicho, bez błędu.

Jak mierzyć zwrot z wdrożenia GSC API w BigQuery?

To pytanie pada zawsze na slajdzie finansowym. Klient pyta „ile mnie to będzie kosztować rocznie i co dostanę w zamian”. Odpowiedź musi być konkretna, bo marketing tradycyjnie ma problem z uzasadnianiem inwestycji w infrastrukturę danych.

Koszt roczny dla średniego serwisu (5–20 tys. URL-i) to około 300–700 USD (storage + query-e + Looker Studio Pro opcjonalnie). Koszt wdrożenia jednorazowy — 3–5 dni roboczych konsultanta, czyli 6 000–12 000 PLN w realiach polskich agencji. W sumie pierwszy rok to około 10 000–18 000 PLN całkowitego kosztu. To nie jest dużo, jeśli porównamy z licencją jednego narzędzia SEO klasy enterprise.

Co się dostaje w zamian, mierzalnie. Po pierwsze — skrócenie czasu reakcji na spadki widoczności z 7–14 dni (gdy ktoś zauważy w UI) do 24 godzin (alert). To przekłada się bezpośrednio na ratowanie ruchu, który inaczej byłby stracony na kolejne 2 tygodnie. Po drugie — skrócenie czasu audytu kanibalizacji z 4–8 godzin ręcznej roboty na property do 15 minut query. Dla agencji obsługującej 20 klientów to 80–160 godzin miesięcznie oszczędzone. Po trzecie — zdolność do podejmowania decyzji na surowych danych, nie na widoku, co eliminuje błędy systemowe, które niewidzialnie psują ROI.

Dla klientów korporacyjnych dodajemy jeszcze jedną rzecz — możliwość zasilenia modeli ML własnymi danymi SEO. Jeśli firma ma zespół data science, który buduje modele atrybucji, GSC w BigQuery jest naturalnym źródłem. Bez tego ML-owcy muszą wycinać dane z UI ręcznie, co jest absurdem w 2026.

Jak wygląda rozszerzony request z filtrami i grupowaniem w cURL?

Dla zespołów, które pracują w shellu albo integrują GSC z platformami nie-Python (Node, Go, Rust), przydaje się sama forma REST-owa bez warstwy klienta. Poniżej przykład, który u nas leży jako snippet w zespole DevOps.

curl -X POST 
  "https://searchconsole.googleapis.com/webmasters/v3/sites/sc-domain%3Atwojadomena.pl/searchAnalytics/query" 
  -H "Authorization: Bearer ${ACCESS_TOKEN}" 
  -H "Content-Type: application/json" 
  -d '{
    "startDate": "2026-03-21",
    "endDate": "2026-04-17",
    "dimensions": ["query", "page", "device"],
    "dimensionFilterGroups": [{
      "filters": [
        {"dimension": "country", "operator": "equals", "expression": "pol"},
        {"dimension": "query", "operator": "includingRegex", "expression": "^(jak|dlaczego|co to)"}
      ]
    }],
    "rowLimit": 25000,
    "startRow": 0,
    "dataState": "final",
    "type": "web"
  }'

Kilka uwag do tego requestu, które wynikają z praktyki. Kraj podaje się w ISO-3 (pol, deu, gbr), nie ISO-2. Filtr regex nie działa dla wszystkich wymiarów — sprawdza się dla query i page, ale np. dla country dostaniesz błąd. Typ web to standardowe wyszukiwanie; dla Discover używaj discover, dla Google News — googleNews. Zakresy dat starsze niż 16 miesięcy są odrzucane z 400, nawet jeśli dane są w bulk exporcie.

Token dostępu generuje się z service accounta przez Cloud CLI komendą gcloud auth application-default print-access-token — wygodne do testów, nie do produkcji. Na produkcji robi się to normalnie przez bibliotekę OAuth, która odświeża token automatycznie.

Jak budować dashboard w Looker Studio oparty o bulk export?

Looker Studio (ex Data Studio) jest naturalnym wyborem dla warstwy wizualizacji, bo łączy się z BigQuery bez dodatkowych konektorów. Trzeba tylko pamiętać o kilku zasadach, żeby koszt query-ów nie wystrzelił w kosmos.

Pierwsza zasada — nigdy nie podłączaj Looker Studio bezpośrednio do tabel searchdata_*. Zawsze przez widok agregujący. Każde odświeżenie dashboardu to query, a jeśli widget skanuje pełną tabelę — płacisz za każde skanowanie. Widok agregujący do poziomu dziennego redukuje koszt 100-krotnie.

Druga zasada — używaj BI Engine dla najpopularniejszych dashboardów. To warstwa cache’u Google Cloud, która koszt skanowań sprowadza prawie do zera dla query-ów mieszczących się w pamięci. Dla dashboardu SEO monitorowanego codziennie jest to absolutnie warte 30 USD / miesiąc rezerwacji.

Trzecia zasada — partition filter jako obowiązkowy parametr w każdym widoku. W BigQuery można skonfigurować widok tak, że bez filtra po dacie zwraca błąd. To zabezpieczenie przed sytuacją, w której ktoś przypadkiem uruchomi raport na całą historię i zapłaci 200 USD za jeden klik.

Praktyczny template dashboardu, który mamy u siebie jako punkt startowy: jedna strona z top-line metrykami (clicks, impressions, CTR, avg position — z filtrem zakresu dat), druga strona z top zapytaniami (ze wskaźnikiem zmian tygodniowych), trzecia z top URL-ami i ich trendem, czwarta z alertami (spadki i kanibalizacja), piąta z raportem Discover, szósta z analizą wymiaru godzinowego. Sześć stron, każda z 3–5 widgetami, łącznie 20–30 widgetów. To pokrywa 90% potrzeb zespołu SEO.

Jak wersjonować zapytania i pipeline’y danych GSC w zespole?

Rzecz, której prawie nikt nie robi na początku, a która ratuje życie po pół roku — wersjonowanie wszystkiego, co dotyka danych GSC. Query-e SQL, definicje widoków, schemat tabel stagingowych, konfiguracja alertów — wszystko idzie do repozytorium Git. Bez tego nie da się odpowiedzieć na pytanie „dlaczego liczby w dashboardzie wyglądają inaczej niż trzy miesiące temu”.

Rekomendowana struktura repo to osobne katalogi dla warstw. sql/staging/ zawiera widoki, które tylko oczyszczają surowe tabele bulk exportu (filtr dat, normalizacja URL, unnesting tablic). sql/marts/ to modele biznesowe — jeden plik na encję (page_performance, query_health, cannibalization_signals). sql/reports/ to query-e, które zasilają konkretne dashboardy. Taki podział jest dokładnie tym, co popularyzuje dbt, i dla projektów powyżej 5 tabel warto po prostu wdrożyć dbt zamiast wymyślać własną konwencję.

Dla zespołów polskich polecam jedną dodatkową rzecz — komentarze w SQL-u po polsku. Kiedy przychodzi nowy analityk, angielski opis „weekly cannibalization by cluster” nie tłumaczy kontekstu biznesowego tak dobrze jak „wykrywa kanibalizację w obrębie kategorii, pomija strony produktowe”. Ta drobna rzecz skraca onboarding z tygodnia do dwóch dni.

Testy regresyjne na modelach danych to kolejny element, o którym zespoły marketingowe zapominają. W dbt wystarczy kilka linijek w pliku YAML — not_null na kluczach, unique tam, gdzie powinno być, accepted_values dla kolumny search_type. Taki prosty test wychwyci sytuację, w której Google nagle doda nowy typ wyszukiwania i Twoje query-e zaczną się sypać cicho, bez błędu.

Jak mierzyć zwrot z wdrożenia GSC API w BigQuery?

To pytanie pada zawsze na slajdzie finansowym. Klient pyta „ile mnie to będzie kosztować rocznie i co dostanę w zamian”. Odpowiedź musi być konkretna, bo marketing tradycyjnie ma problem z uzasadnianiem inwestycji w infrastrukturę danych.

Koszt roczny dla średniego serwisu (5–20 tys. URL-i) to około 300–700 USD (storage + query-e + Looker Studio Pro opcjonalnie). Koszt wdrożenia jednorazowy — 3–5 dni roboczych konsultanta, czyli 6 000–12 000 PLN w realiach polskich agencji. W sumie pierwszy rok to około 10 000–18 000 PLN całkowitego kosztu. To nie jest dużo, jeśli porównamy z licencją jednego narzędzia SEO klasy enterprise.

Co się dostaje w zamian, mierzalnie. Po pierwsze — skrócenie czasu reakcji na spadki widoczności z 7–14 dni (gdy ktoś zauważy w UI) do 24 godzin (alert). To przekłada się bezpośrednio na ratowanie ruchu, który inaczej byłby stracony na kolejne 2 tygodnie. Po drugie — skrócenie czasu audytu kanibalizacji z 4–8 godzin ręcznej roboty na property do 15 minut query. Dla agencji obsługującej 20 klientów to 80–160 godzin miesięcznie oszczędzone. Po trzecie — zdolność do podejmowania decyzji na surowych danych, nie na widoku, co eliminuje błędy systemowe, które niewidzialnie psują ROI.

Dla klientów korporacyjnych dodajemy jeszcze jedną rzecz — możliwość zasilenia modeli ML własnymi danymi SEO. Jeśli firma ma zespół data science, który buduje modele atrybucji, GSC w BigQuery jest naturalnym źródłem. Bez tego ML-owcy muszą wycinać dane z UI ręcznie, co jest absurdem w 2026.

Jak wygląda rozszerzony request z filtrami i grupowaniem w cURL?

Dla zespołów, które pracują w shellu albo integrują GSC z platformami nie-Python (Node, Go, Rust), przydaje się sama forma REST-owa bez warstwy klienta. Poniżej przykład, który u nas leży jako snippet w zespole DevOps.

curl -X POST 
  "https://searchconsole.googleapis.com/webmasters/v3/sites/sc-domain%3Atwojadomena.pl/searchAnalytics/query" 
  -H "Authorization: Bearer ${ACCESS_TOKEN}" 
  -H "Content-Type: application/json" 
  -d '{
    "startDate": "2026-03-21",
    "endDate": "2026-04-17",
    "dimensions": ["query", "page", "device"],
    "dimensionFilterGroups": [{
      "filters": [
        {"dimension": "country", "operator": "equals", "expression": "pol"},
        {"dimension": "query", "operator": "includingRegex", "expression": "^(jak|dlaczego|co to)"}
      ]
    }],
    "rowLimit": 25000,
    "startRow": 0,
    "dataState": "final",
    "type": "web"
  }'

Kilka uwag do tego requestu, które wynikają z praktyki. Kraj podaje się w ISO-3 (pol, deu, gbr), nie ISO-2. Filtr regex nie działa dla wszystkich wymiarów — sprawdza się dla query i page, ale np. dla country dostaniesz błąd. Typ web to standardowe wyszukiwanie; dla Discover używaj discover, dla Google News — googleNews. Zakresy dat starsze niż 16 miesięcy są odrzucane z 400, nawet jeśli dane są w bulk exporcie.

Token dostępu generuje się z service accounta przez Cloud CLI komendą gcloud auth application-default print-access-token — wygodne do testów, nie do produkcji. Na produkcji robi się to normalnie przez bibliotekę OAuth, która odświeża token automatycznie.

Jak budować dashboard w Looker Studio oparty o bulk export?

Looker Studio (ex Data Studio) jest naturalnym wyborem dla warstwy wizualizacji, bo łączy się z BigQuery bez dodatkowych konektorów. Trzeba tylko pamiętać o kilku zasadach, żeby koszt query-ów nie wystrzelił w kosmos.

Pierwsza zasada — nigdy nie podłączaj Looker Studio bezpośrednio do tabel searchdata_*. Zawsze przez widok agregujący. Każde odświeżenie dashboardu to query, a jeśli widget skanuje pełną tabelę — płacisz za każde skanowanie. Widok agregujący do poziomu dziennego redukuje koszt 100-krotnie.

Druga zasada — używaj BI Engine dla najpopularniejszych dashboardów. To warstwa cache’u Google Cloud, która koszt skanowań sprowadza prawie do zera dla query-ów mieszczących się w pamięci. Dla dashboardu SEO monitorowanego codziennie jest to absolutnie warte 30 USD / miesiąc rezerwacji.

Trzecia zasada — partition filter jako obowiązkowy parametr w każdym widoku. W BigQuery można skonfigurować widok tak, że bez filtra po dacie zwraca błąd. To zabezpieczenie przed sytuacją, w której ktoś przypadkiem uruchomi raport na całą historię i zapłaci 200 USD za jeden klik.

Praktyczny template dashboardu, który mamy u siebie jako punkt startowy: jedna strona z top-line metrykami (clicks, impressions, CTR, avg position — z filtrem zakresu dat), druga strona z top zapytaniami (ze wskaźnikiem zmian tygodniowych), trzecia z top URL-ami i ich trendem, czwarta z alertami (spadki i kanibalizacja), piąta z raportem Discover, szósta z analizą wymiaru godzinowego. Sześć stron, każda z 3–5 widgetami, łącznie 20–30 widgetów. To pokrywa 90% potrzeb zespołu SEO.

Co dalej? Roadmap dla zespołów SEO na 2026

Mamy teraz pełen obraz tego, co GSC API 2026 oferuje i jak to uruchomić. Ostatnia rzecz, o której warto powiedzieć, to strategiczne ułożenie tych danych w codziennej pracy zespołu SEO. Bez tego masz po prostu drugą hurtownię, z której nikt nie korzysta.

Pierwszy krok — daily standup z alertami GSC. Codziennie rano jeden analityk przegląda alerty z nocnego joba, zgłasza do Jiry wszystkie spadki powyżej progu, taguje kategorię problemu (indeksowanie, treść, linki, techniczne). To powinno trwać 15 minut dziennie. Jeśli trwa dłużej, albo progi są za luźne, albo serwis ma systemowy problem.

Drugi krok — comiesięczny przegląd kanibalizacji. Query 2 z tego artykułu uruchamiany raz w miesiącu, wyniki idą na meeting zespołu contentu. Dla każdego przypadku decyzja: konsolidujemy URL-e, rerankujemy przez linkowanie wewnętrzne, czy zostawiamy. To jest najszybszy sposób na odzyskanie pozycji bez pisania nowej treści.

Trzeci krok — kwartalny audyt AIO przez sygnały GSC. Udział zapytań pytających, udział comparison queries, ruch z Discover, anomalie impresji vs klików. To daje obraz, czy Twój serwis jest strukturalnie przygotowany do ery AI search, czy pozostaje jedynie „klasycznym SEO”. Odpowiedź na to pytanie definiuje budżet i priorytety na kolejny kwartał.

GSC API 2026 nie jest już „nice to have” dla SEO. Dla serwisów powyżej 5 000 URL-i to baza operacyjna — tak jak GA4 jest bazą dla analityki produktowej. Im szybciej zespół to zrozumie i wdroży, tym większa przewaga nad konkurencją, która nadal eksportuje CSV z UI. W ciągu najbliższych 18 miesięcy widoczność w AI Overviews i modelach LLM stanie się głównym KPI obok klasycznego organic traffic, a jedyne miejsce, gdzie można to mierzyć systematycznie, to hurtownia danych z GSC jako fundamentem. Czas zacząć budować.

GSC API 2026 — zaawansowane zapytania, bulk export i integracja z BigQuery
Screaming Frog 2026 — nowe funkcje dla audytu technicznego i JavaScript SEO