Analityka SEO od lat wygląda tak samo: eksport CSV z Search Console, wklejenie do arkusza, tabela przestawna, wnioski. Model Context Protocol zmienia w tym jeden element, ale za to najbardziej uciążliwy. Zamiast przenosić dane do narzędzia, w którym myślisz, podłączasz asystenta bezpośrednio do źródła. To jeden z tych elementów układanki, które opisaliśmy szerzej w tekście o tym, co agenci AI realnie automatyzują w pracy SEO. Poniżej konkret: jak to podłączyć, o co pytać i gdzie ten model zawodzi.
Model Context Protocol w dwóch zdaniach
MCP to otwarty standard opublikowany przez Anthropic pod koniec 2024 roku, który opisuje, w jaki sposób asystent AI rozmawia z zewnętrznym systemem. Zamiast pisać osobną integrację dla każdej pary (model, narzędzie), stawiasz serwer MCP, który wystawia zestaw funkcji, a klient MCP (Claude Desktop, Cursor, własna aplikacja) potrafi je wywołać.
Praktyczna konsekwencja jest taka, że serwer MCP do Search Console napisany raz działa z każdym klientem obsługującym ten protokół. Architektura jest prosta: klient pyta serwer o listę dostępnych narzędzi, serwer odpowiada schematem JSON, model decyduje, które wywołać i z jakimi argumentami, a wynik wraca do kontekstu rozmowy. Specyfikacja jest publiczna i opisana w dokumentacji Model Context Protocol.
Warto od razu rozwiać nieporozumienie. MCP nie jest modelem, nie jest usługą chmurową i nie wysyła twoich danych nigdzie poza tym, dokąd sam je skierujesz. To warstwa transportowa i kontrakt na opis narzędzi, nic więcej.
Co zyskujesz, dając asystentowi dostęp do danych
Różnica między wklejeniem eksportu a żywym połączeniem nie polega na wygodzie. Polega na liczbie iteracji, które jesteś w stanie wykonać w jednej sesji.
Przy pracy na eksporcie każde nowe pytanie oznacza powrót do interfejsu, zmianę filtra, nowy plik. W praktyce kończysz po trzech, czterech cięciach danych, bo koszt kolejnego jest zbyt wysoki. Przy połączeniu przez MCP asystent sam dociąga to, czego brakuje: jeśli wnioskowanie wymaga rozbicia zapytań na kraje, model po prostu wykonuje drugie zapytanie do API i wraca z odpowiedzią.
Druga korzyść to spójność wymiarów. Search Console anonimizuje część zapytań, agreguje dane inaczej dla wymiaru query i page, a sumy po segmentach nie zgadzają się z totalem. Asystent, który ma dostęp do surowego API, może sam sprawdzić, czy różnica wynika z anonimizacji, czy z błędu w zakresie dat. Na eksporcie tej informacji zwyczajnie nie ma.
Trzecia rzecz to łączenie źródeł. Jeżeli obok Search Console podepniesz drugi serwer MCP z dostępem do GA4, dostajesz w jednym kontekście dane o widoczności i o zachowaniu użytkownika. Jak taki pipeline metryk SEO i AIO poskładać sensownie, opisaliśmy osobno.
Konfiguracja połączenia krok po kroku
Krok 1: projekt i uprawnienia w Google Cloud
Zaczynasz w konsoli Google Cloud. Tworzysz projekt, włączasz Google Search Console API, a następnie generujesz poświadczenia. Masz dwie ścieżki. OAuth 2.0 działa w imieniu twojego konta i wymaga jednorazowej autoryzacji w przeglądarce. Konto serwisowe nie wymaga interakcji, ale musisz ręcznie dodać jego adres e-mail jako użytkownika usługi w Search Console, inaczej API zwróci pustą listę witryn.
Dla pracy jednoosobowej wygodniejszy jest OAuth. Dla automatyzacji, która ma chodzić w tle, konto serwisowe. Zakresy i limity opisuje dokumentacja Search Analytics API.
Krok 2: serwer MCP
Możesz użyć gotowego serwera z ekosystemu open source albo napisać własny. Własny ma sens częściej, niż się wydaje, bo Search Console ma wąskie API: w zasadzie potrzebujesz trzech narzędzi. Pierwsze to lista witryn na koncie, drugie to zapytanie do Search Analytics z parametrami zakresu dat, wymiarów i filtrów, trzecie to inspekcja pojedynczego adresu URL.
Kluczowa decyzja projektowa dotyczy opisów narzędzi. Model wybiera funkcję na podstawie tekstu w schemacie, więc opis w stylu „pobiera dane” gwarantuje złe wywołania. Opis powinien mówić, że wymiar query i wymiar page nie sumują się do totalu, że maksymalny rowLimit to 25000 i że dane mają około dwudniowe opóźnienie.
Krok 3: podpięcie klienta
W kliencie rejestrujesz serwer w pliku konfiguracyjnym: komenda uruchamiająca proces, argumenty i zmienne środowiskowe z poświadczeniami. Po restarcie klienta narzędzia powinny pojawić się na liście dostępnych. Pierwszy test wykonaj zawsze na liście witryn, bo to najtańsze wywołanie i od razu pokazuje, czy autoryzacja przeszła.
Krok 4: weryfikacja liczb
Ostatni krok bywa pomijany, a jest najważniejszy. Zadaj asystentowi pytanie, na które znasz odpowiedź, na przykład o liczbę kliknięć w zeszłym miesiącu, i porównaj wynik z interfejsem Search Console. Rozbieżność zwykle oznacza inną strefę czasową albo zakres dat liczony od innego dnia. Dopóki ten test nie przejdzie, nie ufaj żadnej analizie z tego połączenia.
Bezpieczeństwo: zakresy uprawnień i dane wrażliwe
Search Console API ma dwa zakresy OAuth. Pierwszy, zakończony na webmasters.readonly, daje wyłącznie odczyt. Drugi, webmasters, pozwala też zarządzać witrynami i sitemapami. Do analityki wybierz zawsze wersję readonly. Zasada jest banalna, a chroni przed sytuacją, w której model błędnie interpretuje polecenie i usuwa mapę witryny.
Druga kwestia to miejsce przechowywania poświadczeń. Plik konfiguracyjny klienta MCP to zwykły JSON na dysku, więc token odświeżania trafia tam w postaci jawnej. Trzymaj go poza repozytorium, ustaw restrykcyjne uprawnienia do pliku i nie wrzucaj tej konfiguracji do współdzielonego backupu.
Trzecia sprawa dotyczy tego, co wypływa do modelu. Zapytania użytkowników z Search Console to dane behawioralne i potrafią zawierać nazwiska, numery zamówień albo frazy wpisane przez pomyłkę. Jeżeli pracujesz na koncie klienta, sprawdź w umowie, czy przekazywanie tych danych do zewnętrznego dostawcy modelu jest dopuszczalne. Część dostawców oferuje tryb bez retencji i to jest minimum, od którego warto zacząć rozmowę.
Praktyczny kompromis, który sprawdza się w agencjach: serwer MCP filtruje wyniki po stronie serwera, zanim trafią do kontekstu. Odcięcie zapytań brandowych albo maskowanie fraz zawierających cyfry kosztuje kilkanaście linii kodu i zamyka większość ryzyka.
Przykładowe polecenia analityczne
Dobre polecenie dla asystenta z dostępem do danych wygląda inaczej niż zapytanie do wyszukiwarki. Podajesz cel analityczny, nie parametry techniczne.
- Kanibalizacja: „Znajdź zapytania, dla których w ostatnich 28 dniach wyświetlały się co najmniej dwa różne adresy URL, i pokaż, jak dzieliły się kliknięcia.”
- Spadki pozycji: „Porównaj ostatnie 28 dni z poprzednimi 28 dniami na poziomie strony. Pomiń strony poniżej 100 wyświetleń i pokaż tylko te, gdzie pozycja pogorszyła się o więcej niż 3 miejsca.”
- Luka CTR: „Wypisz strony z pozycją od 5 do 10 i CTR poniżej mediany dla tego przedziału pozycji.”
- Nowe zapytania: „Które zapytania pojawiły się w ostatnich 14 dniach, a nie występowały w poprzednich 90 dniach, i mają co najmniej 20 wyświetleń?”
- Rozbicie geograficzne: „Dla tej strony pokaż wyświetlenia w podziale na kraje i powiedz, czy wzrost pochodzi z Polski.”
Ostatni przykład jest ważniejszy, niż wygląda. Wiele pozornych sukcesów okazuje się ruchem z rynku, którego nie obsługujesz. Asystent sprawdzi to jednym dodatkowym wywołaniem, a w interfejsie to kilka kliknięć, których zwykle nikt nie wykonuje.
Jeżeli któreś z tych poleceń uruchamiasz co tydzień, przenieś je do harmonogramu zamiast powtarzać ręcznie. Do tego nadają się klasyczne narzędzia workflow opisane w przeglądzie automatyzacji SEO w n8n i Make, a MCP zostaje tam, gdzie ma przewagę: w pracy eksploracyjnej.
Ograniczenia i typowe błędy
Najczęstszy błąd to traktowanie odpowiedzi modelu jako wyniku obliczenia. Model dostaje dane z API, ale liczenie median, różnic procentowych i korelacji wykonuje w sposób, który bywa zawodny przy większych tabelach. Jeżeli decyzja zależy od konkretnej liczby, poproś o pokazanie surowych wierszy i przelicz kluczowy wskaźnik samodzielnie.
Drugi problem to okno danych. Search Console przechowuje 16 miesięcy historii, więc analizy rok do roku działają tylko do pewnego momentu. Dane z ostatnich dwóch, trzech dni są niekompletne i porównanie „ostatnie 7 dni” z tygodniem sprzed miesiąca systematycznie zaniża świeży okres.
Trzecia pułapka to limit wierszy. API zwraca maksymalnie 25000 wierszy na zapytanie, a przy pobraniu zapytań dla pojedynczej strony domyślne limity bywają znacznie niższe. Obcięta lista wygląda jak kompletna, więc asystent zbuduje wniosek na fragmencie danych, nie sygnalizując tego. Wymuś w opisie narzędzia informację o liczbie zwróconych wierszy i o tym, czy limit został osiągnięty.
Czwarta kwestia to koszt kontekstu. Wrzucenie kilku tysięcy wierszy do rozmowy zużywa budżet tokenów i pogarsza jakość dalszych odpowiedzi. Lepszy wzorzec to agregacja po stronie serwera MCP: narzędzie zwraca gotowe podsumowanie plus opcjonalnie 50 najważniejszych wierszy.
Na koniec rzecz organizacyjna. MCP nie zastępuje raportowania. To narzędzie do zadawania pytań, nie do dowożenia cyklicznych raportów, bo każda sesja daje nieco inne sformułowania i inną kolejność wniosków. Raport buduj na deterministycznym pipeline, a asystenta używaj do rozumienia, dlaczego liczby w tym raporcie wyglądają tak, a nie inaczej.
Najczęstsze pytania
Czy MCP jest darmowe?
Sam protokół i serwery open source tak. Płacisz za model, który konsumuje dane, oraz ewentualnie za hosting serwera. Search Console API również nie pobiera opłat, ma jedynie limity liczby zapytań.
Czy potrzebuję umiejętności programowania?
Do uruchomienia gotowego serwera wystarczy edycja pliku konfiguracyjnego i przejście przez autoryzację Google. Własny serwer z filtrowaniem danych wymaga już podstaw Pythona albo Node.js.
Czy dane z Search Console trafiają do treningu modelu?
Zależy od dostawcy i planu. Usługi biznesowe zwykle deklarują brak wykorzystania danych klienta do treningu, plany konsumenckie bywają inne. Sprawdź to przed podłączeniem konta klienta.
Czym MCP różni się od zwykłej wtyczki do przeglądarki?
Wtyczka czyta to, co widzi interfejs, więc dziedziczy jego ograniczenia. Połączenie przez MCP sięga do API, co daje dostęp do filtrów i wymiarów niedostępnych w widoku przeglądarki, a także do pełnego zakresu 16 miesięcy.
Czy da się przez MCP wysyłać adresy URL do indeksacji?
Do tego służy osobne Indexing API, formalnie przeznaczone tylko dla ofert pracy i transmisji na żywo. Search Console API pozwala jedynie sprawdzić status adresu przez inspekcję URL, bez zgłaszania go do indeksacji.