Google Search Console MCP: jak podłączyłem GSC do Claude

Serwer MCP — co to jest, w dwóch akapitach

MCP (Model Context Protocol) to otwarty protokół, przez który asystent AI wywołuje zewnętrzne narzędzia. Serwer MCP jest pośrednikiem: z jednej strony rozmawia z asystentem, z drugiej odpytuje API konkretnej usługi. W przypadku Search Console oznacza to, że Claude sam pobiera raport zapytań, sprawdza adres URL albo porównuje okresy, zamiast prosić mnie o eksport do CSV i wklejenie go do czatu.

Serwer działa lokalnie, na tym samym komputerze co Claude Desktop lub Claude Code, i komunikuje się z asystentem przez standardowe wejście i wyjście. Osobny hosting nie jest potrzebny.

Który serwer wybrałem i co sprawdziłem przed instalacją

Postawiłem na Google Search Console MCP — pakiet Pythona gsc-mcp-tools. Przesądziły trzy rzeczy:

• Zakres. 61 narzędzi: raporty Search Analytics, sprawdzanie URL, mapy witryny, Indexing API, a do tego GA4, dane CrUX, PageSpeed oraz audyty danych strukturalnych, hreflang, nagłówków i linkowania wewnętrznego.
• Konto usługi. Można obejść się bez logowania w przeglądarce, co przy lokalnym serwerze działającym tygodniami jest po prostu wygodniejsze.
• Klient konsolowy w zestawie. Każde narzędzie jest dostępne także jako polecenie gsc-cli. Przydało się, gdy Claude jeszcze nie widział nowego serwera.

Przed instalacją sprawdziłem to samo, co przy każdym serwerze MCP: czy kod jest otwarty, jaka jest licencja, jakie zależności i dokąd program łączy się w sieci. Licencja MIT, ruch wychodzi wyłącznie do API Google, IndexNow i na sprawdzane strony, a tokeny leżą w lokalnych plikach. Dlaczego nie warto pomijać takiej weryfikacji, pisałem w tekście o bezpieczeństwie narzędzi AI.

Krok 1. Autoryzacja: konto usługi zamiast OAuth

Pakiet ma dwa tryby. OAuth to zwykłe logowanie w przeglądarce na własne konto Google. Konto usługi to techniczny użytkownik projektu Google Cloud z kluczem JSON: nie trzeba się logować, a serwer nie zależy od ważności tokenów OAuth. Do lokalnego serwera wybrałem to drugie.

1. W projekcie Google Cloud włączyć Google Search Console API. Do wysyłania adresów i danych GA4 — dodatkowo Web Search Indexing API i Google Analytics Data API.
2. Utworzyć konto usługi i pobrać klucz JSON.
3. Nadać dostęp w samej Search Console: Ustawienia → Użytkownicy i uprawnienia → Dodaj użytkownika i wpisać adres konta usługi.

Najmniej oczywisty jest punkt trzeci. Role w Google Cloud nie mają żadnego wpływu na Search Console: dopóki adres nie trafi na listę użytkowników usługi, każde wywołanie kończy się błędem 403 — nawet z bezbłędnym kluczem. API do tego kroku nie ma, zostaje formularz i właściciel strony.

Nadałem uprawnienia „Pełne”: wystarczają do raportów i sprawdzania URL. Poziom „Właściciel” jest potrzebny tylko do Indexing API i bez powodu lepiej go nie przyznawać.

Trochę czasu zaoszczędziłem, bo konto usługi już miałem — założyłem je wcześniej dla Google Analytics. Jedno konto może działać w kilku usługach Google, a dostęp w każdej nadaje się osobno. Klucz trzymam poza folderami synchronizowanymi z chmurą, bo w praktyce to hasło do danych.

Krok 2. Instalacja — i pierwsza pułapka: zabrakło miejsca

Instaluję przez pipx, żeby pakiet miał własne, odizolowane środowisko:

python -m pipx install gsc-mcp-tools

Instalacja przerwała się błędem No space left on device. Dysk systemowy C: był zapchany niemal do końca — zostało około 200 MB, a pipx domyślnie zakłada środowisko właśnie tam. Rozwiązanie to przeniesienie katalogów pipx na inny dysk przed instalacją:

$env:PIPX_HOME = "D:\pipx"
$env:PIPX_BIN_DIR = "D:\pipx\bin"
python -m pipx install gsc-mcp-tools

Środowisko zajęło około 270 MB. W katalogu bin pojawiły się trzy programy: gsc-mcp — serwer, gsc-mcp-tools — ten sam serwer pod nazwą pakietu, oraz gsc-cli — klient konsolowy.

Krok 3. Rejestracja w Claude Code

Klucz przekazuje się przez zmienne środowiskowe. W PowerShellu:

$k = "C:\keys\gsc.json"
claude mcp add gsc -s user `
  -e GSC_SKIP_OAUTH=true `
  -e "GSC_SERVICE_ACCOUNT_PATH=$k" `
  -- D:\pipx\bin\gsc-mcp.exe

Flaga -s user zapisuje serwer w konfiguracji użytkownika, a nie w pliku projektu. U mnie ma to znaczenie: folder projektu synchronizuje się z chmurą, a ścieżki do klucza nie ma tam po co trzymać. Dla narzędzi GA4 w tym samym poleceniu dopisuje się -e GA4_PROPERTY_ID=….

claude mcp list

Przy gsc pojawił się status „Connected”. I druga nieoczywistość: w już otwartej sesji nowych narzędzi nie ma. Lista ładuje się przy starcie sesji, więc po dodaniu serwera trzeba otworzyć nową. Poza tym „Connected” oznacza tylko, że proces się uruchamia i odpowiada na handshake — a nie, że uprawnienia w Search Console są już nadane.

Krok 4. Test bez Claude — i błąd w kliencie

Żeby nie czekać na nową sesję, postanowiłem sprawdzić dostęp klientem konsolowym z tego samego pakietu:

gsc-cli list

Wyłożył się, zanim w ogóle połączył się z Google: ValueError: badly formed help string. Ślad stosu pokazał, że klient bierze pierwszą linijkę opisu każdego narzędzia i przekazuje ją do argparse jako tekst pomocy. W jednym z opisów jest znak %, a nowy argparse (u mnie Python 3.14) sprawdza takie teksty od razu przy tworzeniu poleceń i traktuje procent jak początek szablonu formatowania.

Wystarczyła jedna poprawka w gsc_mcp/cli.py — zamiana procentu na podwójny przed przekazaniem:

help=help_text.replace("%", "%%")

Sam serwer MCP nie był dotknięty, psuł się tylko klient. Poprawka siedzi jednak w zainstalowanym pakiecie i zniknie przy aktualizacji, więc takie rzeczy lepiej zgłaszać autorowi.

Jeszcze jeden szczegół: parametry-listy podaje się, powtarzając flagę, a nie po przecinku. Ciąg z przecinkami nie wywołuje błędu, tylko po cichu staje się jednym „adresem”:

gsc-cli batch-url-inspection `
  --site https://example.com/ `
  --urls https://example.com/a `
  --urls https://example.com/b

Po poprawce polecenie gsc-cli list-properties zwróciło moją stronę z uprawnieniem siteFullUser — dostęp działa.

Co wyszło na działającej stronie

Śmieciowe adresy. Google wciąż trzymał osiem zbędnych URL: /ru?Itemid=232 i sąsiednie — pozostałości dawno usuniętych pozycji menu — oraz dwa stare adresy w formacie /ru/component/content/article/2-…?catid=14 należące do dwóch nieopublikowanych od dawna artykułów z 2019 i 2021 roku. Wszystkie osiem zwraca teraz 410 Gone.

Ze starymi adresami była pouczająca historia. Reguła przekierowania ustawiona na oryginalny adres w ogóle nie działała. Okazało się, że Joomla sama przechwytuje stary format /component/content/article/… i zwraca 301 na pośredni ?view=article&id=… — i dopiero ten drugi adres naprawdę odpowiada 404. Regułę trzeba było założyć właśnie na niego. Przy okazji znalazł się błąd w konektorze MCP dla Joomli: narzędzie do tworzenia przekierowań zapisywało kod odpowiedzi w złym polu.

Sprawdzanie URL. Dla takich adresów z parametrami narzędzie zwróciło NEUTRAL i puste pola. To nie błąd wywołania — Google po prostu nie ma dla nich osobnych danych. Pakiet oznacza je jednak kategorią fetch_error, co wprowadza w błąd, więc lepiej patrzeć na same pola. Dla zwykłej strony to samo narzędzie zwróciło „PASS”, datę ostatniego skanowania i adres kanoniczny.

Szybkie wygrane. Narzędzie quick_wins pokazało, że strona główna jest średnio na 8. pozycji, ale w cztery tygodnie przy 295 wyświetleniach dostała jedno kliknięcie. Oczekiwany CTR dla takiej pozycji to około 3 %, rzeczywisty — 0,3 %. Najbliższe zadanie jest więc jasne: tytuł i opis w wynikach wyszukiwania.

Co się sprawdziło, a co nie

• Działa od razu: porównanie okresów, wyszukiwanie fraz, które straciły ruch, szybkie wygrane, zbiorcze sprawdzanie URL, audyt mapy witryny i techniczny audyt strony. Odpowiedź przychodzi w kilka sekund, a Claude sam dobiera narzędzie do pytania.
• Wymaga przygotowania: narzędzia GA4 potrzebują dostępu konta usługi w Google Analytics, a dane CrUX — osobnego klucza API i odpowiedniego ruchu.
• Z zastrzeżeniami: Indexing API jest oficjalnie przeznaczone tylko dla stron z ofertami pracy i transmisjami, a limit to 200 zapytań dziennie. Dla zwykłych podstron nie warto na nim polegać.
• Zawsze pamiętać: dane Search Console mają 2–3 dni opóźnienia, a mała strona ma ich po prostu niewiele.

Krótka lista kontrolna

1. Włączyć Google Search Console API w projekcie Google Cloud.
2. Utworzyć konto usługi, pobrać klucz JSON i trzymać go poza folderami w chmurze.
3. Dodać adres konta w Search Console z uprawnieniami „Pełne”.
4. Zainstalować gsc-mcp-tools przez pipx; przy braku miejsca przenieść PIPX_HOME.
5. Zarejestrować serwer poleceniem claude mcp add w zakresie użytkownika.
6. Sprawdzić dostęp poleceniem gsc-cli list-properties i otworzyć nową sesję Claude.

Jeśli nie masz ochoty przechodzić tej drogi samodzielnie, możemy zintegrować Google Search Console z asystentem AI za Ciebie — na Twoim komputerze albo w Twojej chmurze.

Victor Parhimchik, założyciel studia internetowego IT Deweloper