Google Search Console MCP

Ein MCP-Server für die Google Search Console API – Suchleistungsdaten, URL-Indexstatus, Sitemap-Verwaltung und Eigentümerliste.

Läuft auf drei Arten aus einer Codebasis: stdio (lokal, via npx), Streamable HTTP (selbst gehostet) und Cloudflare Workers (gehostet unter einer URL). Implementiert MCP 2026-07-28 mit automatischem Fallback auf 2025-11-25, 2025-06-18 und 2025-03-26, sodass es mit Clients auf beiden Seiten des Protokollwechsels funktioniert.

Null Laufzeitabhängigkeiten.

Schnellstart

npx google-search-console-mcp auth

Das führt dich durch die Erstellung eines Google-OAuth-Clients, führt den Zustimmungsfluss aus, prüft die Anmeldedaten gegen die Live-API und gibt einen fertig einzufügenden Konfigurationsblock für deinen MCP-Client aus. Drei Minuten, größtenteils Wartezeit auf der Google-Cloud-Oberfläche.

Dann fügst du das gedruckte JSON in deine Client-Konfiguration ein und startest ihn neu.

Related MCP server: searchconsole-mcp

Tools

Jede Methode in der Search Console API v1, plus zwei zusammengesetzte.

Seitenverifizierung und sites.add/sites.delete sind bewusst nicht verfügbar – das Hinzufügen und Verifizieren von Eigentümern ist ein Browserflow, der nicht Inhalt eines Agenten-Tools sein sollte.

Der Server bietet außerdem Prompts (performance_review, indexing_audit, query_opportunities, sitemap_health) und Ressourcen (gsc://guide/search-analytics, gsc://guide/url-inspection, gsc://guide/sitemaps), die Agenten bei Bedarf lesen können.

Authentifizierung

Schritt 1 – einen Google-OAuth-Client erstellen

Das Juchst du nur einmal. Der Server kann das nicht für dich tun: Google verlangt einen Menschen in seiner Kommandobestätigung.

1. Öffne die Google Cloud Console und wähle ein Projekt aus oder erstelle eines.

2. Aktiviere die Search Console API für dieses Projekt.

3. Konfiguriere den OAuth-Zustimmungsbildschirm. External ist für persönlichen Gebrauch in Ordnung. Füge dein eigenes Google-Konto unter Testnutzer hinzu.

4. Gehe zu Anmeldedaten → Anmeldedaten erstellen → OAuth-Client-ID. Wähle den Anwendungstyp Desktop-App.

5. Kopiere die Client-ID und den Clientgeheimnis.

Testen vs. Veröffentlicht. Solange sich der Zustimmungsbildschirm im Test befindet, läuft Googles Ablaufdatum der Aktualisierungstokens nach 7 Tagen ab und du wirst auth wöchentlich erneut ausführen müssen. Wenn du die App veröffentlichst (Zustimmungsbildschirm → App veröffentlichen), werden sie dauerhaft. Für ein Einzelbenutzer-Internal-Tool ist das Veröffentlichen sicher und erfordert keine Verifizierungsprüfung durch Google, solange du innerhalb der Bereiche webmasters Geschütze von der Suchkonsole bleibst.

Schritt 2 – Einrichtungsablauf ausführen

npx google-search-console-mcp auth

Dies öffnet eine kleine Seteingsseite, die von 127.0.0.1 aus geliefert wird. Füge Client-ID und Clientgeheimnis ein, wähle vollständigen oder schreibgeschützten Zugriff, und es führt den Zustimmungsablauf aus, tauscht den Code (mit PKCE) gegen ein Refresh-Token ein und ruft list_sites auf, um zu verfizieren, dass die Anmeldedaten funktionieren – und zeigt dir die genauen Eigenschaften, die sie erreichen.

Die Abschlussseite gibt dir den Anmeldedaten-Blob und eine fertig einzufügende Konfiguration für Claude Desktop, Claude Code und Remote-Bereitstellend mit jeweils einer Kopieren-Schaltfläche. Dieselben Werte werden zur Sicherung auf der Terminal ausgegeben.

Auf einem Headless-Rechner oder über SSH verwende stattdessen auth --terminal für die promptgesteuerte Variante.

Das Ergebnis ist ein Anmeldeblob – base64url-codiertes JSON, das deine Client-ID, dein Clientgeheimnis und dein Refresh-Token enthält:

eyJ2IjoxLCJjcmVkZW50aWFscyI6eyJ0eXBlIjoib2F1dGhfcmVmcmVzaF90b2tlbiIsImNsaWVu…

Behandle den Blob als Passwort. Jeder, der ihn hat, hat bis zu deinen Wideruf unter myaccount.google.com/permissions Zugriff auf die Search Console. (Übersetzungsanmerkung: "Jeder" hier maskulin.)

Er ist ein einziger opaquekartiger String, sodass ein Wert alles enthält, was der Server braucht – er passt direkt in eine Umgebungsvariable oder einen Authorization-Header, ohne dass eine Anmeldedaten-Datei auf der Festplatte erforderlich Durch OAuth-Ablauf

Servicekonto. Nützlich für CI und für teamverwaltete Eigenschaften. Erstellt ein Servicekonto in Google Cloud und fügt dann client_email als Benutzer für die Eigenschaft in der Search Console hinzu (Einstellungen → Benutzer und Berechtigungen). Codiere die heruntergeladene Schlüsseldatei direkt:

base64 -i service-account.json | tr -d '\n'

Der Server akzeptiert einen rohen Servicekonto-Schlüssel als Blob – keine Hülle erforderlich.

Bestehendes Zugriffstoken. Setze {"type":"access_token","access_token":"ya29..."}. Kein Refresh möglich, daher nur für kurzlive Skripte.

Scopes

Read-only während auth fordert den engeren Scope an. --read-only am Server ist zusätzlich, eine defensivere Blockerie, die Mutationstools ablehnt, bevor sie die API erreichen.

Ausführung

Lokal (stdio)

Die von auth gedruckte Konfiguration:

{
  "mcpServers": {
    "google-search-console": {
      "command": "npx",
      "args": ["-y", "google-search-console-mcp"],
      "env": { "GSC_CREDENTIALS": "<your blob>" }
    }
  }
}

Konfigurationsdatei-Speicherorte:

Installiere es ordentlich, wenn du nicht jedes Mal durch npx gehen willst:

npm install -g google-search-console-mcp

Selbst gehostetes HTTP

GSC_CREDENTIALS=<blob> npx google-search-console-mcp http --port 8787

Bietet POST http://127.0.0.1:8787/mcp. Bindet standardmäßig an die Loopback-Schnittstelle – übergib --host 0.0.0.0 bewusst, wenn du es tatsächlich Öallenge-Leuchтать, um TLS zu schützen, falls du das tust.

Browserbasierte Clients werden abgewiesen, es sei denn, du nennst sie namentlich, weil ein Server, der eigene Anmeldedaten hält, sonst von jeder Seite steuertbar wäre, die du besuchst. Normale MCP-Clients senden keinen Ursprungsheader und sind nicht betroffen; eine browserbasiertes Client benötigt eine nicht zugelassene Liste von Ursprüngen:

npx google-search-console-mcp http --allowed-origins http://localhost:6274   # MCP Inspector

Ein abgelehnte Ursprung erhält einen 403–den der Browser nicht lesen kann (keine CORS-Header bei einer Verweigerung, standardmäßig), sodass er als generischer CORS-Fehler erscheint – prüfe die Startzeit Origins: des Servers, wenn ein Browserclient keine Verbindung herstellen kann. --allowed-origins '*' deaktiviert die Prüfung.

Cloudflare Workers

git clone https://github.com/russjeffery/google-search-console-mcp.git
cd google-search-console-mcp
npm install
npx wrangler deploy

Dein Endpunkt ist https://google-search-console-mcp.<subdomain>.workers.dev/mcp.

Standardmäßig speichert der Worker keine Geheimnisse. Jeder Client sendet seinen eigenen Anmelde-Blob als Bearer-Token, sodass eine gemeinsame Bereitstellung nie Googles Daten von jemandem, egal wer, d.h. alle geheim bleibt, und verschiedene Benutzer derselben URL sehen nur ihre eigenen Eigenschaften.

Für eine private Single-Tenant-Bereitstellung direkt:

npx wrangler secret put GSC_CREDENTIALS     # your blob
npx wrangler secret put MCP_SHARED_SECRET   # token clients must present

Clients senden dann das gemeinsame Geheimnis, nicht den Blob.

Optionale vars in wrangler.jsonc:

Durch Verbindung eines Clients zum Remote-Server

{
  "mcpServers": {
    "google-search-console": {
      "type": "http",
      "url": "https://your-worker.workers.dev/mcp",
      "headers": { "Authorization": "Bearer <your blob>" }
    }
  }
}

In der Claude-Web- oder Desktop-Oberfläche unter Einstellungen → Konnektoren → Benutzerdefinierten Konnektor hinzufügen.

Drucke das für deine Bereitstellung aus:

npx google-search-console-mcp config --url https://your-worker.workers.dev/mcp

CLI

google-search-console-mcp [command] [options]

  stdio     Run as a stdio MCP server (default)
  http      Run a local Streamable HTTP MCP server
  auth      Guided setup in your browser: OAuth flow, blob, client config
  config    Print client config for existing credentials
  doctor    Verify credentials by calling the API

doctor ist das erste Werkzeug, wenn etwas nicht funktioniert – es trennt „Anmeldedaten sind falsch" von „Client kann den Server nicht starten".

Optionen: --credentials <blob>, --site <siteUrl>, --read-only, --port, --host, --endpoint, --secret, --allowed-origins, --url, --terminal, --no-browser.

--allowed-origins akzeptiert eine durch Komma getrennte Liste; nicht gesetzt bedeutet nur Nicht-Browser-Clients. Einträge werden ohne Beachtung der Groß-/Kleinschreibung abgeglichen, und ein nachgestellter Schrägstrich wird ignoriert.

--site setzt eine Standard-Eigenschaft, sodass Tools siteUrl weglassen können – ist praktisch, wenn eine Bereitstellung nur eine einzige Site abdeckt.

Protokollunterstützung

Die Revision 2026-07-28 hat Streamable HTTP grundlegend geändert: kein initialize-Handshake, keine Sitzungen, kein Mcp-Session-Id, kein GET-Stream, und Zweersts-Metadaten in params._meta, die in HTTP-Header gespiegelt wird. Das offizielle TypeScript-SDK implementiert das ­noch nicht, daher ist die Protokollebene hier handgeschrieben und dual, auch in beiden Ärchs.

Die Ära wird pro Anfrage erkannt:Eine Anfrage mit modernem _meta wird als modern behandelt, ein initialize wählt Legacy aus. GET und DELETE auf dem Endpunkt geben 405 zurück, wie es die Revision vorschreibt.

Header- Validierung ist standardmäßig strikt, gemäß Spezifikation. Wenn ein Client modernes _meta ohne die Header zu senden, setzt du MCP_STRICT_HEADERS=0 (oder --loose-headers) ein, statt herabzstufen.

{"type": "text"}

Zur Autorisierung: Der OAuth-2.1-Ablauf der Spezifikation geht davon aus, dass der Server ein Ressourcenserver mit eigenem Autorisierungsserver ist. Dieser Server verwendet stattdessen das Bearer-Token, um Ihre Google-Anmeldedaten direkt zu übertragen – die Spezifikation erlaubt benutzerdefinierte Strategien, und das bedeutet, dass eine gehostete Bereitstellung keine Geheimnisse speichert und keine Benutzerdatenbank benötigt. Der Nachteil ist, dass Clients, die eine automatische OAuth-Erkennung erwarten, den Header manuell konfigurieren müssen, wie oben gezeigt.

Arbeiten mit den Daten

Vier Eigenschaften von Search-Console-Daten führen zu den meisten falschen Schlussfolgerungen. Die Tool-Beschreibungen und die gebündelte Fähigkeit behandeln diese ausführlich; kurz:

1. Daten hinken ~3 Tage hinterher. Verwenden Sie lastDays und die Tools wählen ein sicheres Fenster. Ein Bereich, der heute endet, zeigt einen falschen Rückgang.

2. Abfragedaten sind datenschutzgefiltert. Die Gruppierung nach query verwirft seltene Abfragen stillschweigend, sodass Klicks auf Abfrageebene nie die Gesamtsumme der Property ergeben. Diese Lücke ist kein verlorener Traffic.

3. Position ist invertiert. Position 3 schlägt Position 8; eine negative Änderung ist eine Verbesserung. compare_search_analytics gibt ein explizites improved-Flag zurück.

4. Durchschnittswerte heben sich auf. Flache Schlagzeilenzahlen verbergen regelmäßig große gegenläufige Bewegungen. Gruppieren Sie nach Seite oder Abfrage, bevor Sie schlussfolgern, dass sich nichts geändert hat.

Kontingente

• Suchanalysen: ~1.200 Abfragen/Minute pro Property.

• URL-Inspektion: ~2.000/Tag pro Property – die bindende Einschränkung. Bewusst stichprobenartig vorgehen.

Nicht über die API verfügbar

Der aggregierte Index-Coverage-Bericht, Live-URL-Tests, das Anfordern der Indexierung, Core Web Vitals, manuelle Maßnahmen, Sicherheitsprobleme, Linkberichte und Entfernungen haben kein API-Äquivalent und sind daher nicht enthalten. Die URL-spezifische inspect_url ist der nächste Ersatz für Coverage-Fragen.

Agent-Fähigkeit

skills/google-search-console/ ist eine sofort installierbare Fähigkeit, die einem Agenten beibringt, diese Tools gut zu nutzen – die oben genannten Fallstricke, eine Diagnoseleiter für Traffic-Änderungen, Heuristiken zum Finden von Chancen und eine Nachschlagetabelle für den Coverage-Status.

cp -r skills/google-search-console ~/.claude/skills/

Das gleiche Referenzmaterial ist zur Laufzeit über die gsc://guide/*-Ressourcen des Servers verfügbar, sodass Agenten ohne installierte Fähigkeit es weiterhin lesen können.

Entwicklung

npm install
npm run build       # compile to dist/
npm run typecheck
npm test
npm run cf:dev      # Worker locally via wrangler

Schneller manueller Check gegen den HTTP-Transport:

GSC_CREDENTIALS=<blob> npm run build && node dist/bin/cli.js http &

curl -s http://127.0.0.1:8787/mcp \
  -H 'content-type: application/json' \
  -H 'MCP-Protocol-Version: 2026-07-28' \
  -H 'Mcp-Method: tools/list' \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/list","params":{"_meta":{"io.modelcontextprotocol/protocolVersion":"2026-07-28","io.modelcontextprotocol/clientCapabilities":{}}}}' | jq '.result.tools[].name'

Fehlerbehebung

Sicherheit

• Der Anmeldedaten-Blob ist Ihr Google-Zugriff. Committen Sie ihn nicht, fügen Sie ihn nicht in freigegebene Dokumente ein. Widerrufen Sie unter myaccount.google.com/permissions.

• Der HTTP-Modus bindet standardmäßig an 127.0.0.1 und validiert Origin gegen ALLOWED_ORIGINS, um DNS-Rebinding zu blockieren. Nicht gesetzt bedeutet, dass keine Browser-Origin erlaubt ist – listen Sie sie explizit auf oder verwenden Sie *, um die Prüfung zu deaktivieren. /health und / sind ausgenommen; sie legen keine berechtigte Fähigkeit offen.

• Der Vergleich des gemeinsamen Geheimnisses ist längenüberprüft und konstantzeitig.

• Die Standard-Worker-Bereitstellung speichert überhaupt keine Anmeldedaten.

• --read-only / GSC_READ_ONLY=1 blockiert Sitemap-Mutationen unabhängig vom gewährten OAuth-Bereich.

Lizenz

MIT