Tutorial: Ein SEO- und GEO-Sichtbarkeits-Dashboard auf Basis der Search Console API

Die Oberfläche der Search Console beantwortet eine Suchanfrage nach der anderen. Sie zeigt die obersten Zeilen, exportiert tausend davon und bietet keinen Weg, danach zu fragen, ob die Sichtbarkeit für ein ganzes Thema steigt, während Markensuchen lediglich stabil bleiben. Diese Frage verlangt gruppierte Anfragen, und Gruppieren verlangt sowohl mehr Zeilen, als die Oberfläche herausgibt, als auch einen Ort, an dem sich die Gruppen definieren lassen.

Die folgende Anleitung baut genau das: die Daten über die Search Console API ziehen, Anfragen mit regulären Ausdrücken in Looker Studio kategorisieren und die entstehenden Cluster lesen – mitsamt einer ehrlichen Darstellung dessen, was diese Daten über direkt auf der Ergebnisseite erzeugte Antworten nicht zeigen können.

Was die API liefert und die Oberfläche nicht

Der Leistungsbericht exportiert bis zu tausend Zeilen. Die Methode searchanalytics.query der API liefert bis zu 25.000 je Anfrage und blättert den Rest über startRow durch – das ist der Unterschied zwischen dem Kopf der Verteilung und dem langen Ende, in dem neue Themen zuerst auftauchen.

POST https://searchconsole.googleapis.com/webmasters/v3/sites/
     https%3A%2F%2Fexample.com%2F/searchAnalytics/query

{
  "startDate": "2026-07-01",
  "endDate": "2026-07-31",
  "dimensions": ["query"],
  "rowLimit": 25000,
  "startRow": 0,
  "dimensionFilterGroups": [{
    "filters": [{
      "dimension": "query",
      "operator": "includingRegex",
      "expression": "(?i)(preis|kosten|lizenz)"
    }]
  }]
}

Für ein Dashboard ruft der native Search-Console-Connector von Looker Studio dieselbe API ohne jeden Code auf – der praktische Weg, sofern die Daten nicht ohnehin in einem Warehouse landen. Eine strukturelle Einschränkung sollte vor jedem Entwurf bekannt sein: Der Connector bietet eine Tabelle auf Property-Ebene, in der die Dimension Suchanfrage existiert, und eine auf URL-Ebene, in der die Zielseite existiert – Suchanfrage und Zielseite lassen sich nicht kombinieren. Das ist eine Eigenschaft der Search-Console-Daten selbst und kein Fehler des Connectors, und kein berechnetes Feld umgeht sie.

Zwei Regex-Regeln, an denen das Ganze hängt

Beide Stellen, an denen sich ein regulärer Ausdruck schreiben lässt, verhalten sich anders, als es von Regex anderswo gewohnt ist.

Die Search Console verwendet RE2, ohne Lookahead und ohne Lookbehind. Der vertraute Kniff für Nicht-Marke – ein negativer Lookahead, der den Markennamen ausschließt – lässt sich schlicht nicht kompilieren. Der unterstützte Weg ist die Umkehrung des Filters selbst: ein eigener Regex-Filter auf stimmt nicht überein, mit dem Markenmuster als Ausdruck.

REGEXP_MATCH in Looker Studio verlangt, dass das Muster den gesamten Feldwert trifft, nicht einen Ausschnitt davon. Ein Muster acme trifft nur die Anfrage, die exakt das Wort acme ist; wer jede Anfrage treffen will, die es enthält, muss die Platzhalter ausschreiben:

-- Feld: Marke vs. Nicht-Marke
CASE
  WHEN REGEXP_MATCH(Query, '(?i).*(acme|acme corp|acmecorp|acme app).*')
    THEN 'Marke'
  ELSE 'Nicht-Marke'
END

Das Kennzeichen (?i) macht den Abgleich in beiden Systemen unabhängig von Groß- und Kleinschreibung. Die Markenalternation lohnt sich von Anfang an großzügig: Tippfehler, die Schreibweise mit und ohne Leerzeichen sowie der Produktname gehören in den Marken-Topf, denn jede davon, die draußen bleibt, bläht die Nicht-Marken-Zahl mit Suchen auf, die nie über Inhalte gewonnen wurden.

Aus Themen Cluster machen

Dieselbe Konstruktion, erweitert, wird zur Dimension, auf der das Dashboard aufbaut. Die Reihenfolge zählt – der erste zutreffende Zweig gewinnt, die Marke gehört also nach vorn, sonst landet eine markenbezogene Suche nach einer Funktion im Cluster dieser Funktion:

-- Feld: Anfrage-Cluster
CASE
  WHEN REGEXP_MATCH(Query, '(?i).*(acme|acmecorp).*')              THEN 'Marke'
  WHEN REGEXP_MATCH(Query, '(?i).*(preis|kosten|was kostet).*')    THEN 'Preise'
  WHEN REGEXP_MATCH(Query, '(?i).*(integrat|api|webhook|sync).*')  THEN 'Integrationen'
  WHEN REGEXP_MATCH(Query, '(?i).*(vs |alternative|vergleich).*')  THEN 'Vergleich'
  ELSE 'Ohne Treffer'
END

Einen ausdrücklichen Zweig Ohne Treffer statt einer Auffangbezeichnung zu behalten ist das, was das Feld pflegbar hält. Dieser Topf ist eine Arbeitsliste: nach Impressionen sortiert, führt er die Nachfrage auf, die die Taxonomie noch nicht abbildet – und jedes Cluster nach den ersten beiden entsteht üblicherweise aus dem Lesen dieser Liste.

Das Dashboard lesen

Mit einer Cluster-Dimension genügen drei Diagramme. Impressionen je Cluster im Zeitverlauf zeigen, ob die Sichtbarkeit breiter wird oder sich zusammenzieht. Klicks und CTR je Cluster zeigen, ob diese Sichtbarkeit zu Besuchen wird. Eine Tabelle der Anfragen ohne Treffer speist die nächste Runde der Taxonomie.

Die Falle in dieser Ansicht ist das Marken-Cluster. Markensuchen steigen mit Bekanntheit, mit Kampagnen und mit der Saison, und sie konvertieren weit besser als alles andere – ein gesund aussehender Gesamtwert kann darunter also schrumpfende Nicht-Marken-Cluster verbergen. Marke und Nicht-Marke als getrennte Linien statt als eine Sichtbarkeitssumme zu berichten hält genau das sichtbar.

Was diese Daten über generative Ergebnisse nicht sagen

Die Search Console hat keine Dimension für KI-generierte Antworten. Impressionen, die innerhalb eines generativen Ergebnisses entstanden sind, stecken in denselben Leistungsdaten wie gewöhnliche Ergebnisse, und es gibt keinen Filter, der sie trennt – jedes Dashboard, das aus dieser Quelle generative Sichtbarkeit zu messen behauptet, schließt also, statt zu messen.

Was die Daten hergeben, ist ein beobachtenswertes Muster: ein informationsgetriebenes Cluster, dessen Impressionen stabil bleiben oder wachsen, während Klicks und CTR zurückgehen, über einen Zeitraum ohne Rankingverlust, der das erklären würde. Diese Form passt dazu, dass Antworten schon auf der Ergebnisseite befriedigt werden – sie passt aber auch zu einem geänderten Snippet oder einer verschobenen Anfragemischung innerhalb des Clusters. Deshalb gehört sie als zu prüfende Frage in einen Bericht und nicht als vorzeigbare Kennzahl.

Innerhalb der Leitplanken bleiben

Drei Eigenschaften der Quelldaten begrenzen, was das Dashboard ehrlich behaupten kann. Seltene Anfragen werden aus Datenschutzgründen vollständig zurückgehalten, die Anfragezeilen summieren sich also immer auf weniger als die Property-Gesamtwerte – die Differenz ist kein abzugleichender Fehler, und Cluster-Anteile sind als Anteile der berichteten Anfragen zu lesen. Die Historie endet nach sechzehn Monaten, was einen Jahresvergleich möglich macht, aber kein zweites Jahr davon; alles Längere braucht eine eigene Ablage. Und die durchschnittliche Position ist bereits ein nach Impressionen gewichteter Durchschnitt innerhalb jeder Zeile; diese Durchschnitte über ein Cluster hinweg zu mitteln ergibt eine Zahl, die präzise aussieht und wenig bedeutet – weshalb Impressionen und Klicks die Aussage besser tragen als die Position.