Teil VI · Kapitel 21
Agentic & API-gestütztes SEO
Wie Coding-Agenten SEO-Aufgaben über REST-APIs und CLIs ausführen — Schnittstellen-Hierarchie (API/CLI vor MCP), Automatisierbarkeit pro Disziplin, Orchestrierung statt Autonomie und die Compliance-Grenzen.
Kurz gefasst — Agentische, API-gestützte SEO heißt, SEO-Routinearbeit von einem Coding-Agenten über REST-APIs und CLIs ausführen zu lassen statt von Hand zu klicken. Zwei Sätze tragen das ganze Kapitel: Für den skalierten, unbeaufsichtigten Massen-Pull ist direktes API/CLI dem MCP überlegen — MCP ist für die interaktive Discovery im Chat. Und: Orchestrierung statt Autonomie — der Mensch definiert die Workflows, der Agent führt sie deterministisch aus. Die gratis, gemessene Datenbasis dafür liefern Googles eigene APIs (GSC, GA4, PSI, CrUX). Welche Werkzeuge sich konkret automatisieren lassen, steht nebenan in der Tool-Landschaft (Kap. 22); hier geht es um das Wie und das Warum.
Orchestrierung, nicht Autonomie
Das real funktionierende Muster agentischer SEO ist nüchtern: Tool-API → LLM-Auswertung → strukturierter Output, orchestriert in Code oder einem Workflow-Tool, mit dem Menschen in der Schleife. Datenabruf, technische Audits, Reporting, Keyword-Clustering und Brief-Erstellung sind so weitgehend automatisierbar. Was nicht automatisiert wird, ist das Urteil. R3
Strategie, Priorisierung, Datenqualitäts-Bewertung, Stakeholder-Kommunikation und kreative Content-Entscheidungen bleiben menschlich. Automatisierung exzelliert beim Sammeln, Strukturieren und Vorverdichten von Daten — und versagt beim Urteil unter Unsicherheit. Genau diese Arbeitsteilung ist der Hebel, nicht ihre Abschaffung.
Die Schnittstellen-Hierarchie — und warum API/CLI den Massen-Pull gewinnt
Ein Coding-Agent kann ein Werkzeug auf vier Wegen steuern — native CLI, REST-API + SDK, MCP-Server oder gar nicht (GUI-only). Die Tool-Landschaft (Kap. 22) stellt die vier Wege als Matrix gegenüber; hier zählt das Argument dahinter. R12b
Der Grund ist strukturell, nicht ideologisch. Weil das Protokoll zustandslos ist, lädt ein MCP-Client die Tool-Definitionen jedes verbundenen Servers nicht einmal pro Sitzung, sondern in jede Nachricht — pro Turn reist die volle Historie plus Tool-Schema erneut mit. Jede Definition kostet Hunderte Token; bei vielen Servern summiert sich das, bevor der Agent überhaupt eine Anfrage liest — GitHub maß bei seinem eigenen offiziellen Server „101 tools consuming 64.6k tokens by default” (GitHub-Discussion #1182, Okt. 2025). Bei nativer API/CLI dagegen schreibt der Agent einmal ein Command oder Skript und holt nur das extrahierte, gefilterte Ergebnis zurück — deterministisch, tokensparsam, in Cron-Jobs einsetzbar. R12b
Die zweite Entlastung ist Tool-Search bzw. Deferred Loading: Tool-Definitionen werden nicht vorab vollständig geladen, sondern erst bei Bedarf. Anthropic dokumentiert dafür ein „Tool Search Tool” (Beta, Nov. 2025) mit dem Richtwert, ab rund 10.000 Token Tool-Overhead zu verzögern. Dass Coding-Agenten wie Claude Code das standardmäßig tun, ist verbreitet, aber community-berichtet, nicht offiziell dokumentiert; und manche Clients schneiden die Tool-Liste still ab — Cursors MCP-Doku sandte 2025 nur „the first 40 tools” ans Modell (kein Fehler, einfach abgeschnitten; die Angabe ist inzwischen aus der Live-Doku verschwunden). Wer es genau wissen will, prüft den Overhead im eigenen Client und schaltet bei hohem Tool-Overhead (Richtwert rund 10.000 Token) oder echten Massen-Jobs auf Code-Execution oder die Direkt-API um. R12b
Die gemessene Gratis-Basis: Googles eigene APIs
Bevor man Budget in Drittanbieter steckt, steht ein mächtiges, billiges Fundament bereit: Googles eigene APIs liefern gemessene Erst-Daten und sind kostenlos. GSC (Search-Analytics + URL-Inspection), GA4 (Data API), PageSpeed Insights, CrUX und die Natural Language API decken Reporting, Index-Status, Performance und Entitäten ab — alles per REST, das meiste mit offiziellem SDK. R3
Der Zugang läuft über OAuth 2.0 oder ein Service Account: OAuth autorisiert im Namen eines Nutzers (Einwilligung nötig, Access-Token rund eine Stunde gültig), ein Service Account authentifiziert eine Maschine ohne Interaktion — das richtige Modell für unbeaufsichtigte Pipelines (GA4 sauber, GSC teils). Frei heißt aber nicht grenzenlos; jede dieser APIs hat harte, dokumentierte Quotas:
| API | Was sie liefert | Quota / Limit [Stand Mitte 2026] | Kosten |
|---|---|---|---|
| GSC — Search Analytics | Klicks, Impressionen, CTR, Position | rowLimit 25.000/Request; ~1.200 QPM pro Property | frei |
| GSC — URL Inspection | Index-/Render-Status je URL | 2.000/Tag & 600/Min pro Property (Projekt 10 Mio./Tag) | frei |
| PageSpeed Insights | Lab + Field, CWV, Vorschläge | großzügiges Tageskontingent (Größenordnung 25.000/Tag, projektverwaltet) | frei |
| CrUX API | echte Felddaten (28-Tage-Rolling) | 150/Min pro Projekt — nicht erhöhbar („not possible to pay for an increased quota”) | frei |
| Natural Language API | Entitäten + Salience (0–1) | erste 5.000 Units/Monat frei (1 Unit = 1.000 Zeichen) | dann ~$0,0010/Unit |
Die Quotas sind kein Detail, sondern Architekturvorgabe: Rate-Limits verlangen client-seitiges Drosseln und exponentielles Backoff bei HTTP 429, Feldselektion und Caching beugen Kostenfallen vor. Das gilt erst recht für bezahlte Dritt-APIs (Semrush rechnet in „Units”, historische Daten dort um ein Mehrfaches teurer als Live).
Automatisierbarkeit pro Disziplin
Nicht jede SEO-Disziplin ist gleich gut automatisierbar. Die folgende Matrix ordnet ein, was programmatisch geht, über welches Interface — der REST -Tag codiert die Gesamt-Steuerbarkeit (gefüllt ja · halb teilweise · Ring nein) plus die passenden Schnittstellen — und wo der Mensch zwingend bleibt. R3
| Disziplin | Was der Agent übernimmt | Bestes Interface | Mensch bleibt zuständig für |
|---|---|---|---|
| Reporting & Rank-/Visibility-Tracking | Dashboards, Wochenvergleiche, Drop-Alerts | RESTSDK | Narrative, Ursachenanalyse bei Anomalien |
| Technische Audits & Crawls | geplanter Crawl, maschinelle Auswertung der Exports | CLIMCP | Fix-Priorisierung nach Business-Impact |
| Core Web Vitals-Monitoring | Lab + Field im CI/Cron, Schwellen-Alerts | CLIREST | Ursachen-Debugging, Trade-offs |
| SERP-/Keyword-Daten-Pull | Massen-Abruf strukturierter SERP-Daten | RESTSDK | — (reiner Datenabruf) |
| Keyword-Recherche & Clustering | Volumen-/Difficulty-Pull, LLM-Cluster & Intent | RESTSDK | strategische Cluster-Auswahl, kommerzielle Relevanz |
| Content-Briefs, On-Page, Entitäten | SERP-Scrape, Brief-Entwurf, Salience-Extraktion | RESTSDK | kreative Entscheidung, E-E-A-T-Substanz, Faktentreue |
| Interne Verlinkung & Redirect-Mapping | Verlinkungslücken, Redirect-Maps aus Crawl + GSC | CLIREST | Architektur, Validierung der Redirect-Logik |
| Off-Page / Backlink-Monitoring | neue/verlorene Links, Spam-Vorfilter | REST | Disavow-Entscheidung (hohes Schadenspotenzial), Outreach |
Die halbe Ampel ist kein Mangel, sondern die ehrliche Grenze: Der Agent holt und strukturiert, der Mensch entscheidet. Eine fehlgeleitete Disavow-Datei oder ein falscher Redirect richten mehr Schaden an als die gesparte Zeit je wettmacht.
Vier Workflows, die heute laufen
Konkret sieht agentische SEO so aus — durchweg deterministisch und cron-bar:
- Nächtlicher Rank-Pull. Der Agent schreibt ein Python-Skript, das 5.000 Keyword-Tasks als Batch (100 pro POST) an die SERP-API eines API-first-Providers schickt (etwa DataForSEO Standard-Queue, ~$0,60/1.000 SERPs), die Ergebnisse per Webhook einsammelt und nur die extrahierten Positionen in eine Datenbank schreibt — kein Roh-JSON im Modell-Kontext. Der Job ist idempotent: ein zweiter Lauf schreibt nichts doppelt. R12b
- Geplantes Crawl-Audit. Screaming Frog headless per CLI im Cron (
--headless --crawl … --bulk-export …), die Ergebnis-CSV vom Agenten geparst und nach BigQuery/Sheets gepiped. Für die interaktive Variante der offizielle v24-MCP. - Performance im CI. Lighthouse-CLI bzw. Lighthouse CI
(
@lhci/cli) bei jedem Deploy, ergänzt um PSI/CrUX-Felddaten — CWV-Regression fällt auf, bevor sie live geht. - Quick-Win-Report. GSC- und GA4-Pull in ein Dashboard, automatischer Alert auf Seiten in Position 4–15 (Klicknähe ohne Top-Platzierung) — die klassische, kostenlose Hebel-Pipeline.
MCP für SEO — wofür es taugt, wofür nicht
MCP ist nicht der Verlierer dieser Geschichte, sondern für die falsche Aufgabe oft das falsche Werkzeug. Seine Stärke ist die interaktive Discovery: Ein Mensch fragt im Chat ad hoc „zeig mir die Top-Keywords von Domain X”, und der offizielle MCP-Server des Anbieters liefert echte Daten statt Halluzination. Für den unbeaufsichtigten Massen-Pull ist er es nicht — Token-Overhead, client-seitige Tool-Limits und die Abhängigkeit von der MCP-Implementierung sprechen dagegen. R12b
Dass dieser Vektor real ist und nicht Vision, zeigt die Institutionalisierung Ende 2025: Anthropic spendete MCP am 9. Dez. 2025 an die Agentic AI Foundation — einen „directed fund under the Linux Foundation”, mitgegründet von Anthropic, Block und OpenAI. Zwei Tage später, am 11. Dez. 2025, kündigte Google offizielle managed MCP-Server für eigene Dienste an (Maps, BigQuery, Compute Engine, GKE; Preview). Der Anschluss von SEO-Tools an das Agentic Web ist damit Infrastruktur, kein Versprechen. R3
Orchestrierung, Compliance und Grenzen
Wer Pipelines unbeaufsichtigt laufen lässt, übernimmt Verantwortung für ihr Verhalten. Drei Ebenen sind §5-hart:
Technische Robustheit. Idempotenz (kein doppeltes Schreiben bei Re-Runs), exponentielles Backoff bei 429, Secrets in Umgebungsvariablen oder einem Secret-Store statt im Code. Datenqualität mitdenken: Aggregatoren liefern aus Caches mit Latenz, verschiedene Tools zeigen für dasselbe Keyword verschiedene Werte — keiner ist „die Wahrheit”.
Halluzinations-Risiko. Ein LLM, das SEO-Daten auswertet, kann Zahlen falsch interpretieren oder plausibel klingende Fehlschlüsse ziehen. MCP reduziert das (echte Daten statt Erfindung), eliminiert es nicht. Jede konsequenzreiche Auswertung braucht ein menschliches Validierungs-Gate.
Scope- und Cloaking-Fallen. Die Google Indexing API ist offiziell nur für JobPosting- oder BroadcastEvent-Markup vorgesehen — sie als allgemeines Indexierungs-Werkzeug zu missbrauchen bringt keinen Vorteil und kann der Indexierungsleistung schaden. Und das agentische Ausliefern abweichender Inhalte an Bots gegenüber Menschen ist cloaking-nah: Google warnt davor ausdrücklich (siehe Tool-Landschaft (Kap. 22) und technisches SEO (Kap. 7)). Wo Automatisierung mehr Schaden als Nutzen stiftet — Disavow, Massen-Indexing, ungeprüfte Massen-Content-Generierung — gehört der Mensch zwingend in die Schleife.
Das größere Bild
Agentische SEO ist ein Hebel, kein Selbstzweck. Der seltene, sichtbare Skill ist nicht „ein Agent macht SEO”, sondern: die gratis, gemessenen Google-APIs, einen API-first-SERP-Provider und Crawler-CLIs zu idempotenten, cron-baren Pipelines zu verdrahten — und den Menschen dort entscheiden zu lassen, wo Urteil unter Unsicherheit gefragt ist. Gemessene Datenquellen plus deterministische Pipelines schlagen „autonome” Magie. Die Tool-Landschaft (Kap. 22) beantwortet welches Werkzeug; dieses Kapitel das wie. Zusammen sind sie das agentische Rückgrat dieses Nachschlagewerks.