SEO-APIs: Daten abrufen, prüfen und verarbeiten

SEO-APIs liefern Daten in einem strukturierten, maschinenlesbaren Format. Ein Skript führt Abfragen wiederholt aus, verbindet Quellen und speichert Ergebnisse. Die Schnittstelle liefert dabei genau die Daten, die Endpunkt, Rechte und Limits vorsehen.

API steht für Application Programming Interface. Die Schnittstelle verarbeitet eine definierte Anfrage und antwortet mit strukturierten Daten. Für SEO-Projekte kommen Daten aus der Google Search Console, Analyse-Systemen, Crawlern und Datenbanken infrage.

Der Hub Technisches SEO: Infrastruktur, Architektur und Jamstack ordnet Datenquellen in Crawling, Indexierung, Auslieferung und Betrieb ein.

Einsatzbereiche für SEO-APIs

Eine API lohnt sich, wenn ein Team dieselbe Abfrage wiederholt, Eigenschaften oder Zeiträume zusammenführt oder Daten in einen festen Prüfprozess übernimmt.

Ein einmaliger Export reicht aus, wenn du wenige Daten benötigst. Eine API bringt Nutzen, wenn der Abruf wiederholbar, dokumentiert und prüfbar sein soll.

Datenquelle und Frage zuerst festlegen

Der technische Abruf startet mit der Fachfrage: Welche Entscheidung soll der Datensatz stützen?

Eine Abfrage braucht mindestens:

• →Datenquelle
• →Konto oder Property
• →Zeitraum
• →benötigte Dimensionen und Messwerte
• →Filter
• →Granularität
• →Zielort für das Ergebnis

Wer Klicks nach URL und Suchanfrage auswertet, braucht einen anderen Datensatz als ein Team, das den bekannten Indexierungsstatus einzelner URLs prüft. Beide Aufgaben gehören in getrennte Auswertungen.

Die SEO-Strategie mit Audit und Roadmap ordnet Kennzahlen und ihre wirtschaftliche Aussage ein. Dieser Beitrag behandelt den technischen Datenfluss.

Search Analytics API und URL Inspection API unterscheiden

Die Google Search Console stellt verschiedene APIs bereit. Zwei Endpunkte bearbeiten unterschiedliche Aufgaben.

Search Analytics API

Die Search Analytics API liefert Leistungsdaten wie Klicks, Impressionen, Klickrate und durchschnittliche Position. Abfragen gruppieren Dimensionen wie Seite, Suchanfrage, Land, Gerät oder Datum. Filter und Gruppierung bestimmen, welche Zeile ein Ergebnis bildet.

Die Schnittstelle liefert keinen unbegrenzten Rohdatensatz. Google begrenzt Antworten nach internen Regeln auf die wichtigsten Zeilen. Große oder stark segmentierte Abfragen verlangen eine Planung nach Zeitraum und Dimension.

Der Abruf dokumentiert:

URL Inspection API

Die URL Inspection API liefert Prüfdaten zur Version einer URL, die Google im Index kennt. Dazu gehören Indexierungsstatus, letzter Crawl und kanonische Angaben. Die API führt keinen Live-Test der veränderten Seite aus.

Für die Prüfung trennst du drei Ebenen:

1. →Die Website antwortet mit einem Statuscode und Inhalt.
2. →Die API meldet den bei Google bekannten Stand.
3. →Die Search Console zeigt Leistungsdaten für einen Zeitraum.

Erst der Vergleich dieser Ebenen macht eine Abweichung sichtbar.

Zugriff und Rechte einrichten

Google-APIs nutzen OAuth 2.0. Der Zugriff richtet sich nach dem Anwendungsfall. Ein interaktives Werkzeug für einen einzelnen Nutzer braucht einen anderen Ablauf als ein interner Dienst mit begrenztem Konto.

Rechte klein halten

Ein Zugang erhält nur die Rechte, die der Abruf verlangt. Konten, Properties und Scopes werden dokumentiert. Getrennte Umgebungen für Entwicklung und Betrieb verhindern, dass Tests auf produktive Daten oder Konfigurationen zugreifen.

Geheimnisse schützen

Client-Secrets, Tokens und Schlüssel gehören in eine Secret-Verwaltung oder geschützte Laufzeitumgebung – niemals in Quellcode, Repositories oder Ausgabedateien.

Protokolle enthalten keine Tokens. Skripte bereinigen Fehlermeldungen vor der Ausgabe.

Token und Ablauf behandeln

Ein Zugriffstoken hat eine begrenzte Gültigkeit. Der Client erkennt abgelaufene Tokens und nutzt den vorgesehenen Erneuerungsweg. Ein wiederholter manueller Login oder ein fest eingetragener Token reicht im Betrieb nicht aus.

Abfragen reproduzierbar bauen

Du dokumentierst jede API-Anfrage als Eingabe. Dasselbe Skript bearbeitet mit denselben Parametern denselben Fragetyp.

{
  "startDate": "2026-08-01",
  "endDate": "2026-08-31",
  "dimensions": ["page", "query"],
  "rowLimit": 25000,
  "startRow": 0
}

Das Beispiel zeigt eine Form. Property, Zeitraum, Dimensionen und Filter richten sich nach der Analysefrage.

Seitenweise abrufen

Wenn ein Endpunkt Ergebnisse in Seiten aufteilt, erhöht der Client die Startposition oder verarbeitet einen Fortsetzungswert. Der Ablauf endet, wenn die Antwort keine weitere Seite meldet oder weniger Zeilen als angefordert liefert.

Der Client speichert zusätzlich:

• →Anfrageparameter
• →Abrufzeitpunkt
• →API-Version oder Endpunkt
• →Anzahl empfangener Zeilen
• →Warnungen und Fehler

Damit lässt sich ein späterer Bericht auf seinen Ursprung zurückführen.

Quotas, Fehler und Wiederholungen behandeln

APIs begrenzen Anfragen. Die Grenzwerte hängen vom Dienst, Endpunkt und Projekt ab. Die Dokumentation des Anbieters gehört deshalb zum Betrieb.

Der Client unterscheidet Fehlerarten:

Exponential Backoff vergrößert die Pause zwischen begrenzten Wiederholungen. Zufällige Streuung verhindert, dass mehrere Prozesse gleichzeitig erneut anfragen. Wiederholungen brauchen eine Obergrenze gegen Endlosschleifen.

Daten prüfen, bevor sie in den Bericht fließen

Der erfolgreiche HTTP-Status belegt nur, dass der Endpunkt eine Antwort geliefert hat. Vor der Auswertung folgen technische und fachliche Prüfungen.

Technische Prüfung

• →Sind alle erwarteten Felder vorhanden?
• →Stimmen Datentypen und Datumsformat?
• →Gibt es doppelte Zeilen?
• →Sind alle Seiten des Abrufs verarbeitet?
• →Wurden Fehler oder Teilantworten protokolliert?

Fachliche Prüfung

• →Passt die Property zur Website?
• →Sind Zeitraum und Zeitzone vergleichbar?
• →Entsprechen Filter und Dimensionen der Frage?
• →Wurden Änderungen an Tracking, Website oder Angebot dokumentiert?
• →Werden aggregierte Werte mit Detailzeilen verwechselt?

Eine Zahl benötigt Datenquelle, Zeitraum und Abfrage für die Prüfung.

Daten speichern und Zugriffe begrenzen

Ein kleiner Abruf lässt sich als CSV oder Parquet speichern. Wiederkehrende oder verbundene Daten verlangen eine Datenbank oder ein Data Warehouse.

Das Zielschema hält mindestens diese Informationen fest:

Speicherfristen und Zugriffe richten sich nach Zweck und Datenart. Skripte erfassen keine vertraulichen oder personenbezogenen Daten ohne Zweck.

SEO-APIs mit Python verbinden

Python eignet sich als Client, weil Bibliotheken HTTP-Anfragen, Tabellen und Datenbanken unterstützen. Die Programmiersprache ist das Werkzeug; der Prüfplan entscheidet über Abruf und Bewertung.

Der Beitrag SEO mit Python automatisieren behandelt Aufbau, Tests und Grenzen solcher Skripte. Die Methodik der Logfile-Analyse zeigt eine andere Datenquelle für tatsächliche Serveranfragen.

Checkliste für eine API-Pipeline

Häufige Fragen zu SEO-APIs

Liefert die Search Console API alle Suchanfragen?

Nein. Die API stellt die von Google verfügbaren und nach internen Grenzen verarbeiteten Daten bereit. Sie protokolliert nicht jede einzelne Suche.

Ist die URL Inspection API ein Live-Crawler?

Nein. Sie liefert Prüfdaten zur Version, die Google im Index kennt. HTTP-Status und HTML der aktuellen Seite werden getrennt geprüft.

Muss jede SEO-Auswertung automatisiert werden?

Nein. Ein manueller Export reicht für eine kleine oder einmalige Frage. Automatisierung lohnt sich, wenn Abruf, Prüfung und Ausgabe wiederkehren.

Muss eine Fachperson die API-Ausgabe vor der Veröffentlichung prüfen?

Ja. Fachpersonen prüfen Aggregation, Filter, Zeiträume und Datenlücken, bevor Entscheidungen oder Berichte entstehen.

Nächster Schritt

Die SEO-Strategie mit Audit und Roadmap legt fest, welche Daten ein Projekt braucht. Für eine operative technische Prüfung bietet OLDSCHOOLSEO Suchmaschinenoptimierung für Unternehmen an.

Projektanfrage per E-Mail senden · Erstgespräch mit Sandra buchen

Sandra Krone und Michael Kienzler | Seriöse Suchmaschinenoptimierung aus Stuttgart | Seit 2018

Über den Autor: Michael Kienzler

Michael Kienzler ist Partner und Gründer von OLDSCHOOLSEO. Seine Arbeit beginnt bei der Analyse der technischen Architektur und der Daten, um daraus die Potenziale für die redaktionelle und strategische Weiterentwicklung abzuleiten.

Mehr über die GründerProfil auf LinkedIn