Search Console per MCP an Claude anbinden, nur lesend

Claude bekommt Zugriff auf die Google Search Console über einen MCP-Server, der die Search Console API anspricht. Der Server läuft lokal, meldet sich mit einem Google-Dienstkonto an und stellt Claude Werkzeuge wie „Leistungsdaten abfragen“ oder „URL prüfen“ bereit. Die Einrichtung dauert eine Viertelstunde. Die eigentliche Arbeit ist die Frage, welche Rechte dieses Dienstkonto bekommt.

Die Werkzeugliste eines Servers sagt nichts über seine Rechte. Das veröffentlichte npm-Paket mcp-server-gsc in Version 0.3.0 meldet Claude unter anderem ein Werkzeug submit_sitemap, fordert bei Google aber nur den Scope webmasters.readonly an (nachgesehen in dist/search-console.js des Pakets am 05.10.2026). Das Einreichen würde also scheitern. Umgekehrt fordert der meistgenutzte Server auf GitHub, AminForou/mcp-gsc, im Code den vollen Scope webmasters an, also Lesen und Schreiben. Was ein Server darf, entscheiden zwei Stellen, die du selbst in der Hand hast: der Scope und die Berechtigung des Kontos in der Search Console.

Warum ein MCP-Server überhaupt fremder Code mit deinen Rechten ist und welche Angriffe die Spezifikation selbst nennt, steht in MCP-Server sicher einsetzen. Hier geht es um die Search Console.

Wer die Server baut#

Google hat am 29.04.2026 über fünfzig verwaltete MCP-Server freigegeben, für BigQuery, Gmail, Drive und andere (Google Cloud Blog). Die Search Console ist nicht darunter. Einen offiziellen, als experimentell gekennzeichneten Server gibt es nur für Google Analytics, mit dem Lese-Scope analytics.readonly.

Für die Search Console bleiben Projekte von Einzelpersonen. Die GitHub-Suche nach „search console mcp“ ergab am 05.10.2026 rund 350 Repositorys. Eine Auswahl, geprüft am Quellcode:

Die Tabelle ist keine Empfehlung. Sie zeigt, wonach man sucht: Lese-Scope im Code, keine Schreibwerkzeuge oder eine Sperre dafür, ein Repository mit nachvollziehbarer Geschichte.

Die Rechte: Scope und Berechtigung#

Die Search Console API kennt zwei Scopes (Google, Authorizing requests): webmasters.readonly für „Read-only access“ und webmasters für „Read/write access“. Leistungsdaten (searchanalytics.query) und URL-Prüfung (urlInspection.index.inspect) gehen mit beiden. Sitemaps einreichen und Properties hinzufügen oder löschen verlangen den vollen Scope.

Die zweite Stelle ist der Nutzer in der Search Console. Google unterscheidet Inhaber, uneingeschränkte und eingeschränkte Nutzer (Google, Nutzer und Berechtigungen). Ein eingeschränkter Nutzer sieht Leistung, Links und alle Berichte, darf aber keine Sitemaps einreichen, keine URLs entfernen lassen und keine Überprüfung beantragen. Die URL-Prüfung steht für ihn als „Nur abrufen“ in der Tabelle. Mehrere READMEs raten dagegen, das Dienstkonto als „Full access“ oder sogar als Administrator einzutragen. Für reines Auswerten gibt es dafür keinen Grund.

Für ein Konto, das nur auswerten soll, gilt deshalb beides: Scope webmasters.readonly und Berechtigung „Eingeschränkt“. Fehlt eines davon, fängt das andere es auf. Ob ein eingeschränkter Nutzer über die API Sitemaps einreichen kann, beschreibt Google nicht; die Hilfeseite gilt für die Oberfläche. Mit dem Lese-Scope stellt sich die Frage gar nicht.

In eigener Sache: cyberscale fragt die Search Console seit September 2026 über ein Dienstkonto ab, aber per Skript im Repository und nicht per MCP. Dieses Konto hat den vollen Scope, weil ein Skript damit Sitemaps einreicht. Für einen KI-Agenten, der die Daten nur lesen soll, wäre das zu viel; er bekäme ein zweites, eigenes Dienstkonto.

Einrichtung in fünf Schritten#

1. Projekt und API. In der Google Cloud Console ein eigenes Projekt anlegen, unter „APIs & Services“ → „Library“ die Google Search Console API suchen und „Enable“ wählen (Google Cloud, APIs aktivieren).
2. Dienstkonto. IAM & Admin → Service accounts → „Create service account“, Name vergeben, ohne Rollen im Projekt abschließen. Die Adresse hat die Form name@projekt.iam.gserviceaccount.com (Google Cloud, Dienstkonten).
3. Schlüssel. Im Dienstkonto Keys → „Add key“ → „Create new key“ → JSON. Die Datei lässt sich nur einmal herunterladen. In Organisationen, die nach dem 03.05.2024 angelegt wurden, blockiert eine Richtlinie das Anlegen von Schlüsseln standardmäßig (Google Cloud, Schlüssel). Die Datei gehört außerhalb jedes Repositorys, mit Leserechten nur für dich: chmod 600.
4. In der Search Console eintragen. Property öffnen → Einstellungen → Nutzer und Berechtigungen → „Nutzer hinzufügen“, die Adresse aus dem Feld client_email der JSON-Datei eintragen, Berechtigung „Eingeschränkt“. Hinzufügen kann nur ein Inhaber.
5. Server einbinden. In Claude Code, für alle eigenen Projekte, mit festgeschriebener Version (Claude Code, MCP):

claude mcp add --scope user --transport stdio \
  --env GOOGLE_APPLICATION_CREDENTIALS=/home/du/.config/gsc/claude-lesen.json \
  gsc -- npx -y mcp-server-gsc@0.3.0

--env braucht danach mindestens eine weitere Option vor dem Servernamen, sonst liest der Befehl den Namen als zweites Wertepaar. claude mcp list zeigt, ob der Server startet. In Claude Desktop steht derselbe Eintrag in claude_desktop_config.json, auf dem Mac unter ~/Library/Application Support/Claude/, unter Windows in %APPDATA%\Claude\ (MCP, lokale Server). Claude im Browser kann lokale Server nicht starten, dort gehen nur entfernte Konnektoren über eine öffentlich erreichbare Adresse.

Schreibwerkzeuge zusätzlich sperren#

Claude Code erzwingt Berechtigungen selbst, nicht über das Modell (Claude Code, Permissions). Werkzeuge eines MCP-Servers heißen mcp__<server>__<werkzeug>, und eine Sperrregel in ~/.claude/settings.json geht jeder Freigabe vor:

{
  "permissions": {
    "deny": ["mcp__gsc__submit_sitemap"]
  }
}

Das ist die dritte Stelle nach Scope und Berechtigung. Sie lohnt sich vor allem bei Servern mit vollem Scope, etwa wenn jemand später doch OAuth mit dem eigenen Inhaberkonto verwendet. Eine Sperre per Platzhalter wie mcp__gsc__submit_* funktioniert ebenfalls.

Was es bringt#

Die Search Console API liefert dasselbe wie der Leistungsbericht, nur ohne dessen Grenze von 1.000 Zeilen: bis zu 25.000 Zeilen je Abfrage, nach Suchanfrage, Seite, Land, Gerät, Datum und Darstellung, für bis zu 16 Monate zurück (Google, searchanalytics.query). Claude kann damit Fragen beantworten, für die man sonst exportiert und in einer Tabelle sortiert: Welche Seiten stehen für eine Suchanfrage nebeneinander? Wo gibt es Impressionen auf Platz 8 bis 15, aber kaum Klicks? Welche Seite hat seit dem letzten Umbau verloren?

Zwei Grenzen gehören in jede Auswertung:

• Neue Daten kommen mit zwei bis drei Tagen Verzögerung, und seltene Suchanfragen lässt Google aus Datenschutzgründen weg (Google, Search-Console-Daten). Eine Summe über alle Suchanfragen ist deshalb kleiner als die Summe der Property.
• Die URL-Prüfung ist auf 2.000 Abfragen am Tag und 600 in der Minute je Property begrenzt (Google, Limits). Ein Agent, der „alle Seiten prüfen“ soll, verbraucht das bei einer größeren Website an einem Vormittag. Was die URL-Prüfung meldet und wie man sie liest, steht in URL-Prüfung in der Search Console.

Die Daten selbst sind wenig heikel: Google zeigt keine einzelnen Nutzer, nur zusammengefasste Suchanfragen. Heikel ist der Zugang. Ein Schlüssel mit vollem Scope, der im falschen Ordner liegt, erlaubt einem Fremden, Sitemaps zu tauschen und Nutzer zu sehen.

Was nicht hilft#

Das eigene Inhaberkonto per OAuth anbinden, weil es schneller geht. Der Server handelt dann mit allen Rechten, die du hast, in allen Properties, die du hast.

Ein Dienstkonto für alles. Das Skript, das Sitemaps einreicht, und der Agent, der auswertet, bekommen je ein eigenes Konto. Google empfiehlt das ausdrücklich: ein Dienstkonto je Anwendung, Schlüssel regelmäßig erneuern, nicht mehr gebrauchte deaktivieren und löschen (Google Cloud, Schlüssel verwalten).

npx -y mcp-server-gsc ohne Version. Das holt bei jedem Start die neueste Fassung, die du nie gesehen hast.

Den Schlüssel in .mcp.json schreiben. Die Datei wird mit dem Repository geteilt. Dort steht höchstens ${GOOGLE_APPLICATION_CREDENTIALS}, der Pfad kommt aus der Umgebung.

Ohne MCP geht es auch#

Wer nur regelmäßig dieselben Zahlen braucht, kommt ohne Agenten aus. Der Bulk-Export der Search Console schreibt alle Leistungsdaten, ohne die anonymisierten Suchanfragen, täglich nach BigQuery (Google, Bulk-Export), und ein Skript mit dem Lese-Scope reicht für einen wöchentlichen Bericht. MCP lohnt sich, wenn die Fragen jedes Mal andere sind. Wie das in einen Arbeitsablauf mit Branch, Bau-Prüfung und Pull Request passt, zeigt Claude Code für SEO.

Stand 11.10.2026. Quellen, Repositorys und das npm-Paket am 05.10.2026 geprüft; Sternezahlen und Fassungen ändern sich laufend.