Ist es sicher, KI-Agenten mit der Google Search Console zu verbinden?

Die eigentliche Frage lautet nicht nur: „Ist MCP sicher?“

Wenn du einen KI-Assistenten nutzt, um die Leistung deiner Website auszuwerten, gibst du einem weiteren System Zugriff auf Informationen aus einem Google-Konto. Das kann nützlich und völlig legitim sein. Es bringt aber auch Entscheidungen mit sich, die du verstehen solltest, bevor du auf „Autorisieren“ klickst.

Die wichtigsten Risiken sind ein weiterer Zugriff, als der Workflow braucht, durchgesickerte Zugangsdaten, unnötig weitergegebene Suchanfragen-Daten, automatisierte Aktionen ohne ausreichende Kontrolle und ein Assistent, der nicht vertrauenswürdige Inhalte für Anweisungen hält.

Das Model Context Protocol, kurz MCP, legt fest, wie Clients und Tools miteinander kommunizieren. Es macht einen einzelnen Server nicht automatisch vertrauenswürdig. Du musst weiterhin prüfen, wer den Server betreibt, welche Berechtigungen er verlangt und was mit deinen Informationen geschieht.

Die gute Nachricht: Einen SEO-Reporting-Workflow kann man meist auf Lesezugriff und nachvollziehbaren Tool-Aufrufen aufbauen. Das ist ein deutlich sichererer Ausgangspunkt, als einen autonomen Agenten Website-Einstellungen ändern zu lassen.

Welche Informationen gibst du frei?

Die Google Search Console liefert Informationen zu den Properties, auf die dein Konto zugreifen kann: Seiten, Suchanfragen, Impressionen, Klicks, durchschnittliche Positionen, Indexierungsstatus und Sitemap-Daten. Keiner dieser Reports enthält das Passwort deines Google-Kontos, und ein korrekt umgesetzter OAuth-Ablauf sollte dich nie auffordern, dein Passwort in das Chatfenster eines Connectors einzugeben.

Trotzdem verdienen die Reports Sorgfalt. Eine Liste von Suchanfragen kann den Namen eines noch nicht angekündigten Features verraten. Eine Property-Liste kann Kundenbeziehungen offenlegen. Indexierungsinformationen können URL-Muster zeigen, die nach Interna aussehen. Agenturen können vertragliche Pflichten zum Umgang mit Kundendaten haben, auch wenn die Seiten selbst öffentlich sind.

Trenne zwei Fragen: Kann der Connector diese Informationen abrufen? und Darf der Assistent sie im konkreten Workspace weitergeben oder zusammenfassen? Eine technisch gelungene Verbindung beantwortet die zweite Frage nicht.

Lege vor dem Verbinden fest, welche Organisation, welches Google-Konto und welche Property der Agent verwenden soll. Vermeide einen breiten Zugriff über mehrere Kunden hinweg, wenn die Aufgabe nur eine Website betrifft.

Die Google-OAuth-Scopes verstehen

OAuth ist das Autorisierungssystem, mit dem eine Anwendung begrenzten Zugriff anfordern kann, ohne nach deinem Google-Passwort zu fragen. Der Zustimmungsbildschirm von Google sollte den Dienst und die angeforderten Berechtigungen benennen.

Google dokumentiert den Scope https://www.googleapis.com/auth/webmasters.readonly für schreibgeschützten Zugriff auf die Search Console und https://www.googleapis.com/auth/webmasters für weiter gefassten Zugriff. Die Search Analytics API listet diese unterstützten Autorisierungs-Scopes auf.

Für eine Aufgabe wie „Zeig, welche Seiten Klicks verloren haben“ sollte Lesezugriff in der Regel genügen. Sitemaps einzureichen oder zu entfernen, Properties zu ändern oder andere Schreiboperationen zu nutzen, erfordert eine andere Abwägung.

Beurteile die Sicherheit nicht allein anhand des ersten Zustimmungsbildschirms. Manche Anwendungen verlangen später weitere Berechtigungen, wenn eine Funktion aktiviert wird. Prüfe jede zusätzliche Google-Zustimmungsanfrage, vor allem beim Aktivieren administrativer Funktionen.

Bietet ein Connector zusätzlich GA4, Google Tag Manager oder Bing an, kann es dafür eigene Quellen und Berechtigungen geben. Sie zu verbinden sollte eine bewusste Entscheidung sein und nicht die Annahme, dass „Google-Zugriff“ bedeutet, alle Daten seien verfügbar.

Der Unterschied zwischen lesenden und schreibenden Tools

Lesende Tools rufen Daten ab. Beispiele sind das Auflisten von Properties, die Abfrage der Suchleistung und die Prüfung von Informationen zur indexierten Version einer URL. Sie können trotzdem sensible Reports preisgeben, sollten aber keine Einstellungen der Search Console verändern.

Schreibende Tools führen eine Aktion aus. Beispiele sind das Einreichen einer Sitemap, das Entfernen einer Property oder das Melden geänderter URLs an eine Suchmaschine. Solche Aktionen können betriebliche Folgen haben, auch wenn die API Erfolg meldet.

Ein sicherer Workflow macht Schreibzugriffe zur Ausnahme. Verlange einen konkreten Zweck, begrenze die verfügbaren Tools, prüfe die vorgeschlagenen Parameter und protokolliere, was passiert ist. Bei einem autonomen Agenten solltest du erwägen, schreibgeschützte Zugangsdaten von denen zu trennen, mit denen freigegebene Änderungen ausgeführt werden.

Die aktuelle Dokumentation von GSC Magic beschreibt schreibgeschützte Zugriffstoken und einen optionalen Schreibmodus für berechtigte Tarife. Solche Kontrollen solltest du bei jedem Anbieter suchen. Prüfe trotzdem die tatsächlichen Zustimmungsanfragen des Anbieters und die Anforderungen deiner Organisation, bevor du dich auf eine Marketingaussage verlässt.

Wie du mit Zugangsdaten umgehen solltest

Token sind Geheimnisse. Sie gehören in einen Authentifizierungsspeicher, eine Umgebung oder eine Client-Konfiguration, die für Geheimnisse gedacht ist, nicht in einen Blogkommentar, die README eines Repositorys oder ein Chatprotokoll.

Bei MCP-Clients mit OAuth-Unterstützung kann ein Autorisierungsablauf im Browser verhindern, dass du Token in Konfigurationsdateien einfügen musst. Für Clients, die ein Bearer-Token verlangen, erstellst du ein eng begrenztes Token, vergibst eine sinnvolle Laufzeit und widerrufst es, sobald du es nicht mehr brauchst.

Legst du ein Token in einer lokalen Konfigurationsdatei ab, stelle sicher, dass die Datei nicht in Git eingecheckt oder automatisch in ein gemeinsames Projekt synchronisiert wird. Ein Screenshot der Einstellungen kann ein Token genauso leicht preisgeben wie ein Code-Commit.

Teile kein echtes Token mit einem KI-Assistenten, um „den Fehler zu finden“. Die Struktur kannst du mit einem Platzhalter wie gsm_YOUR_TOKEN zeigen und den tatsächlichen Wert zurückhalten.

Ist ein Token offengelegt worden, widerrufe es und stelle ein neues aus. Die Nachricht zu bearbeiten, in der es preisgegeben wurde, reicht nicht.

Wie Prompt Injection in einem SEO-Workflow aussieht

Ein KI-Assistent liest unter Umständen Text von Webseiten, aus Logs, Suchergebnis-Snippets oder Tool-Ausgaben. Dieses Material kann schädliche Anweisungen enthalten, die jemand anderes geschrieben hat. Eine Webseite könnte zum Beispiel eine Zeile enthalten, die einen Agenten auffordert, seine ursprüngliche Aufgabe zu ignorieren und Analytics-Daten an einen anderen Ort zu senden.

Diese Zeile ist Website-Inhalt, keine Anweisung des Nutzers. Ein sicherer Agent behandelt sie als nicht vertrauenswürdige Daten und folgt weiter der eigentlichen Anfrage des Nutzers und den vergebenen Tool-Berechtigungen.

Search-Console-Zeilen sind strukturiert, können aber trotzdem Zeichenfolgen enthalten, die Dritte beeinflussen können, etwa den Text einer Suchanfrage oder URLs. Eine Suchanfrage, die wie ein Befehl aussieht, bleibt eine Suchanfrage. Ein robuster Workflow sollte keine Anweisungen ausführen, die in abgerufenen Daten stehen.

Der stärkste Schutz ist nicht ein einzelner magischer Prompt. Nutze Tools mit minimalen Rechten, trenne lesende von schreibenden Workflows, schränke Netzwerk- und Dateisystemzugriff ein, wo es angemessen ist, und behalte vor externen Aktionen einen Freigabeschritt bei.

Eine Sicherheits-Checkliste vor dem Verbinden

1. Prüfe, wer den Server betreibt. Nutze den vorgesehenen Anbieter und gleiche den Endpunkt mit dessen offizieller Dokumentation ab.
2. Sieh dir die Autorisierungsanfrage genau an. Wisse, welches Google-Konto, welche Properties und welche Scopes beteiligt sind.
3. Wähle standardmäßig Lesezugriff. Vermeide weitreichende Schreibrechte für routinemäßiges Reporting.
4. Prüfe den Umgang mit Daten. Sieh dir Aufbewahrung, Unterauftragsverarbeiter, Protokollierung, die Bedingungen der Modellanbieter und Löschoptionen an.
5. Vermeide geteilte Geheimnisse. Halte Token aus Chatnachrichten, eingecheckten Dateien und Screenshots heraus.
6. Begrenze die Fähigkeiten des Agenten. Eine Reporting-Aufgabe braucht weder Deployments noch beliebige Shell-Ausführung oder unkontrollierten Browserzugriff.
7. Überprüfe die Ausgaben. Verlange genaue Property-Kennungen, Zeiträume und gemeldete Zahlen.
8. Wisse, wie du den Zugriff widerrufst. Teste den Weg zum Trennen, bevor es eilig wird.
9. Trenne Kunden. Halte Kundendaten und Zugangsdaten im jeweils passenden Workspace.
10. Prüfe alle Schreibzugriffe. Eine abgesendete Anfrage und eine korrekt ausgeführte Aktion sind nicht zwangsläufig dasselbe.

Das klingt nach viel Aufwand, nur um ein einfaches Diagramm zu lesen, aber das meiste davon ist einmalige Einrichtung. Sind die Berechtigungen gut gestaltet, sollte ein gewöhnlicher Wochenreport langweilig sein, und zwar im guten Sinne.

So widerrufst du den Zugriff sicher

Nutzt du eine MCP-Integration nicht mehr, entferne oder deaktiviere sie im KI-Client und widerrufe das Token oder den Zugriff des verbundenen Kontos im Dashboard des MCP-Anbieters. Wurde Google-OAuth-Zugriff erteilt, sieh in den Verbindungen zu Drittanbieter-Apps deines Google-Kontos nach und widerrufe jede Berechtigung, die du nicht länger aufrechterhalten möchtest.

Das sind verschiedene Kontrollen. Einen Server aus dem Client zu entfernen, macht ein Token, das ein separater Anbieter ausgestellt hat, nicht unbedingt ungültig. Ebenso löscht das Trennen einer Google-Quelle nicht zwingend Daten, die zuvor in eine KI-Unterhaltung exportiert wurden.

Dokumentiere bei der Beendigung der Zusammenarbeit mit einem Kunden, welcher Dienst Zugriff hatte und wann er widerrufen wurde. Frag den Anbieter nach Löschung oder Aufbewahrung, wenn Verträge das verlangen.

Bekommt ein MCP-Server dein Google-Passwort?

Ein seriöser Google-OAuth-Ablauf leitet dich zur Autorisierungsseite von Google, statt dich aufzufordern, dem Connector dein Passwort zu verraten. Der verbundene Dienst erhält Autorisierungen oder Token, nicht dein Passwort. Das heißt nicht, dass er keinen sensiblen Zugriff hat: OAuth-Token können weitreichend sein und müssen geschützt werden.

Verlangt eine angebliche Search-Console-Integration, dass du dein Google-Passwort in ein normales Formular oder einen Chat einfügst, brich ab und prüfe sie unabhängig.

Kann ein Agent versehentlich dafür sorgen, dass eine Website deindexiert wird?

Eine schreibgeschützte Search-Console-Integration sollte keine zerstörerischen administrativen Aktionen über die Search Console ausführen können. Ein Agent, der die Dateien deiner Website bearbeiten und deployen kann, könnte aber über separate Code-Berechtigungen ein noindex, eine Weiterleitung oder ein robots.txt-Problem einführen.

Deshalb muss die Sicherheitsgrenze den KI-Client einschließen, nicht nur den MCP-Server. Halte die Reporting-Verbindung schreibgeschützt und prüfe Codeänderungen vor dem Deployment.

Denk daran, dass auch die Search Console selbst nicht jedes Indexierungsergebnis bestimmt. Googles URL Inspection API meldet den Status der indexierten Version; sie ist kein Live-Knopf zum Indexieren.

Und die Google Indexing API?

Manche Tools werben damit, Seiten „automatisch zu indexieren“. Das verdient besondere Skepsis. Die Dokumentation der Indexing API von Google beschränkt die unterstützte Nutzung auf Seiten mit dem angegebenen JobPosting- oder Livestream-BroadcastEvent-Markup. Für gewöhnliche SaaS-Landingpages und Blogbeiträge ist sie keine allgemeine Lösung.

Ein Tool, das behauptet, den Index von Google zur Aufnahme beliebiger Seiten zwingen zu können, übertreibt, was die offizielle API verspricht. Auch eine Sitemap-Übermittlung ist ein Hinweis zur Entdeckung, keine Garantie.

Innerhalb der unterstützten Grenzen kannst du Prüfungen und Benachrichtigungen automatisieren. Verwechsle eine erfolgreiche API-Antwort aber nicht mit erfolgreicher Sichtbarkeit in der Suche.

So testest du einen neuen Connector mit minimalem Risiko

Beginne mit einem kleinen lesenden Experiment. Bitte den KI-Client nach der Autorisierung, die zugänglichen Search-Console-Properties aufzulisten, und warte auf deine Auswahl. Fordere dann die Gesamtklicks und Impressionen für einen vollständigen Zeitraum von sieben Tagen an.

Vergleiche das Ergebnis mit der Oberfläche der Google Search Console, mit derselben Property, demselben Suchtyp und demselben Zeitraum. Siehst du eine Abweichung, untersuche die Anfrageparameter, statt anzunehmen, dass einer der Dienste falsche Zahlen liefert. Search-Console-Daten können je nach Property und Seite unterschiedlich aggregiert sein.

Bitte den Agenten als Nächstes, die Seite mit dem größten Verlust zu ermitteln, weise ihn aber an, keine Inhalte oder Einstellungen zu ändern. Erst wenn der Report plausibel ist, solltest du umfassendere Workflows in Betracht ziehen.

Unsere Übersicht zum Google Search Console MCP erklärt den Ablauf einer Anfrage und gängige Tools.

Fragen zum KI-Zugriff

Ist ein selbst gehosteter MCP-Server immer privater?

Nicht automatisch. Er kann dir mehr Kontrolle geben, aber nur, wenn Hosting, Speicherung der Zugangsdaten, Protokollierung und Updates ordentlich betreut werden. Ein ungepflegter selbst gehosteter Server kann weniger sicher sein als ein sorgfältig betriebener gehosteter.

Zeigt mir die Google Search Console, welche KI-Prompts auf meine Daten zugegriffen haben?

Nicht als Standardbericht der Search Console. Dein MCP-Anbieter oder dein Client bietet möglicherweise Protokolle der Tool-Aufrufe; prüfe diese Funktionen, statt anzunehmen, dass Google für dich einen Prüfpfad für den Agentenzugriff führt.

Kann ich den Zugriff auf eine Property beschränken?

Die Property-Berechtigungen deines Google-Kontos in der Search Console sind eine wichtige Grenze. Manche Anbieter bieten zusätzlich Beschränkungen auf Workspace- oder Website-Ebene. Prüfe das tatsächliche Verhalten der Tools und die Kontrollen deiner Organisation, bevor du von einer fein abgestuften Trennung ausgehst.

Sind Search-Console-Reports öffentlich, weil die Google-Suchergebnisse öffentlich sind?

Nein. Die Google-Suchergebnisse sind öffentlich, aber die aggregierten Reports deines Kontos und die Informationen zum Property-Zugriff sind private Dienstdaten.

Ist Lesezugriff völlig risikofrei?

Nein. Er verringert das Risiko ungewollter Änderungen, aber vertrauliche Informationen können trotzdem offengelegt, gespeichert oder in einem ungeeigneten Workspace verwendet werden.

So startest du am sichersten

Nimm eine vorgesehene Property, die geringsten nötigen Rechte und eine lesende Abfrage, die du gegenprüfen kannst. Halte Änderungen in einem separaten Prüfprozess. So profitierst du von KI-gestützter Suchanalyse, ohne unnötige Kontrolle abzugeben.

Die Dokumentation von GSC Magic beschreibt die aktuellen Optionen für Zugriffstoken und Schreibmodus. Vergleiche diese Kontrollen mit den obigen Anforderungen, bevor du entscheidest, ob ein gehosteter Connector zu deinem Workflow passt.