Anonymisierte Suchanfragen in der Search Console

Du öffnest den Leistungsbericht der Search Console, wechselst auf die Registerkarte „Suchanfragen“ und addierst die Klicks der Tabelle. Dann wechselst du auf „Seiten“ und addierst dort. Die zweite Summe ist größer, und zwar nicht um Rundungsfehler, sondern spürbar. Die Erklärung ist kein Bug: Ein Teil der Suchanfragen wird von Google aus Datenschutzgründen nicht einzeln ausgewiesen. Sie heißen anonymisierte Suchanfragen, und ihre Klicks und Impressionen stecken in den Gesamtzahlen, fehlen aber in der Zeilenliste.

Dieser Beitrag erklärt, wie die Lücke zustande kommt, welche weiteren Grenzen die Zahlen verzerren (Zeilenlimits, Aggregationslogik, Filter), wie du den verborgenen Anteil für deine Property schätzt und was du mit dem Ergebnis anfängst. Den generellen Aufbau des Berichts setzen wir voraus, hier geht es nur um die Frage, warum die Summen nicht zusammenpassen.

Was „anonymisiert“ in der Search Console konkret bedeutet

Google zeigt in der Search Console nur Suchanfragen an, die von genug verschiedenen Nutzern gestellt wurden. Seltene Anfragen, die nur von sehr wenigen Personen innerhalb eines längeren Zeitraums eingegeben wurden, gelten als potenziell identifizierend. Denk an eine Suche, die einen Namen, eine Adresse, eine Krankheit oder ein sehr spezielles Problem enthält. Wenn sie in deinem Bericht erschiene, ließe sich unter Umständen nachvollziehen, wer sie gestellt hat. Deshalb werden solche Anfragen zusammengefasst und nicht als Text ausgegeben.

Wo genau die Schwelle liegt, veröffentlicht Google nicht, und sie ist nicht als feste, für alle gleiche Zahl dokumentiert. Du solltest sie deshalb nicht als Konstante in Berechnungen einbauen. Dokumentiert ist lediglich das Prinzip: Die Anfrage taucht als Text nicht auf, die zugehörigen Klicks und Impressionen zählen aber weiterhin in den Summen mit, sobald du nicht nach Suchanfrage aufschlüsselst.

Wichtig ist die Unterscheidung zwischen nicht gemessen und nicht angezeigt. Die Daten gehen nicht verloren. Ein Nutzer hat geklickt, der Klick wurde gezählt und deiner Seite zugeordnet. Nur die Zuordnung zu einem konkreten Suchbegriff wird dir vorenthalten. Das erklärt, warum die Seitenansicht und die Datumsansicht vollständiger sind als die Suchanfragen-Tabelle: Dort gibt es schlicht nichts zu anonymisieren, weil kein Suchtext ausgegeben wird.

Warum die Summen auseinanderlaufen: ein Zahlenbeispiel

Nimm ein fiktives Beispiel, das nur die Rechenlogik zeigt. Im Zeitraum der letzten drei Monate zeigt der Bericht ohne Filter insgesamt 10.000 Klicks. Du wechselst auf die Registerkarte „Suchanfragen“ und exportierst alle verfügbaren Zeilen. Die Klicks dieser Zeilen summieren sich auf 7.400. Die Differenz von 2.600 Klicks entspricht rechnerisch 26 Prozent, und genau das ist in diesem Beispiel der Anteil der anonymisierten Suchanfragen. Die Zahlen sind erfunden, die Rechnung ist es nicht.

Die Gegenprobe machst du in der Seitenansicht. Dort summieren sich die Klicks der Seiten wieder auf 10.000, weil jede Seite ihre vollständigen Klicks ausweist, unabhängig davon, über welche Suchbegriffe sie kamen. Die Seitenansicht ist also der Referenzwert, die Suchanfragen-Ansicht der reduzierte Ausschnitt.

Eine typische Verwirrung entsteht beim Filtern. Sobald du im Bericht einen Filter auf eine Suchanfrage setzt, etwa „enthält“ oder einen regulären Ausdruck, verschwinden die anonymisierten Anfragen auch aus dem Diagramm und den Gesamtzahlen oben. Der Filter kann sie nicht treffen, weil sie keinen Text haben. Setzt du einen Filter auf „Suchanfrage enthält nicht ...“, bleiben sie dagegen erhalten. Du kannst also dieselbe Seite mit zwei Filtern vergleichen und zwei verschiedene Summen erhalten, ohne dass etwas kaputt ist.

Weitere Gründe, warum Zahlen nicht zusammenpassen

Anonymisierung ist der größte, aber nicht der einzige Grund. Wer die Lücke sauber schätzen will, muss die übrigen Effekte kennen, sonst wird alles Fehlende den anonymisierten Anfragen zugeschrieben.

Zeilenlimits. Die Oberfläche der Search Console zeigt und exportiert nur eine begrenzte Zahl von Zeilen, bei einer Aufschlüsselung sind es etwa tausend. Die API liefert deutlich mehr, aber auch dort gibt es eine Obergrenze pro Tag, Property und Suchtyp. Bei großen Websites mit sehr langem Schwanz fällt also zusätzlich Material weg, das nicht anonymisiert, sondern einfach abgeschnitten ist. Ein Bericht, der nur die erste Seite eines Exports auswertet, verwechselt beides.

Aggregation nach Property oder nach Seite. Die Search Console kann Daten je Property oder je Seite zusammenfassen. Wenn mehrere deiner Seiten für dieselbe Anfrage ranken, zählt die Aggregation nach Property die Anfrage einmal, die Aggregation nach Seite je Seite. Bei Impressionen führt das zu Abweichungen, die nichts mit Datenschutz zu tun haben. Bei Klicks ist der Effekt geringer, aber nicht null, etwa wenn ein Nutzer mehrfach sucht.

Unterschiedliche Zeiträume und Verzögerung. Die jüngsten Tage sind vorläufig. Wer die Suchanfragen-Ansicht heute und die Seitenansicht gestern exportiert hat, vergleicht unterschiedliche Stände. Vergleiche nur Exporte, die im selben Moment mit identischen Datumsgrenzen und identischem Suchtyp gezogen wurden.

Suchtyp und Filter. Web, Bilder, Videos und News sind getrennte Suchtypen. Die Ansicht „Web“ ist der Standard. Wer in einem Bericht den Suchtyp wechselt, im anderen nicht, bekommt andere Summen. Ebenso wirken Länder-, Geräte- und Darstellungsfilter auf beide Ansichten, aber die Anonymisierung greift innerhalb dieser Teilmengen oft stärker, weil jede Teilmenge weniger Nutzer je Anfrage enthält.

Den anonymisierten Anteil selbst schätzen

Eine Schätzung brauchst du aus zwei Gründen: um zu wissen, wie vollständig deine Suchanfragen-Analyse ist, und um die Zahlen richtig zu beschriften, wenn du sie weitergibst. Das Vorgehen ist einfach, erfordert aber Disziplin bei den Einstellungen.

Vorab ein Hinweis zum Bulk-Export:

Der Bulk-Export nach BigQuery kennzeichnet anonymisierte Zeilen mit einem eigenen Feld und lässt dort den Suchtext leer. Damit lässt sich der Anteil pro Tag und pro Seite exakt berechnen, statt ihn aus Differenzen abzuleiten. Wer ohnehin mit diesem Export arbeitet, sollte diese Kennzeichnung nutzen. Bei der Web-Oberfläche und der API bleibt die Differenzrechnung der gangbare Weg, und zwar Schritt für Schritt:

• Lege einen festen Zeitraum fest, zum Beispiel die letzten vollen 28 Tage ohne die vorläufigen Tage, und lasse ihn für alle Schritte unverändert.
• Notiere die Gesamtklicks und Gesamtimpressionen ohne jeden Filter und ohne Aufschlüsselung. Das ist dein Nenner.
• Rufe die Daten mit der Dimension „Suchanfrage“ ab, am besten über die API oder den Bulk-Export, damit das Zeilenlimit der Oberfläche nicht stört, und summiere Klicks und Impressionen der Zeilen. Das ist dein Zähler.
• Die Differenz geteilt durch den Nenner ist der Anteil, den du nicht einzeln sehen kannst. Rechne Klicks und Impressionen getrennt, denn die Anteile unterscheiden sich meist.
• Wiederhole die Rechnung für wichtige Segmente: einzelne Seiten oder Verzeichnisse, Länder, Geräte. So siehst du, wo die Lücke klafft.

Rechenbeispiel: die Lücke pro Seite prüfen

Die Gesamtquote kann täuschen, deshalb lohnt sich ein Blick auf einzelne Seiten. Nimm zwei fiktive Seiten derselben Website. Seite A ist eine Kategorieseite mit 1.000 Klicks, von denen die Suchanfragen-Zeilen 950 ausweisen. Seite B ist ein Ratgeber zu einem Nischenproblem mit ebenfalls 1.000 Klicks, aber die Zeilen weisen nur 450 aus. Über die Property gerechnet ergibt das eine Lücke von 30 Prozent, und das klingt nach einem mittleren Problem. In Wahrheit ist die Kategorieseite fast vollständig sichtbar und der Ratgeber zur Hälfte im Dunkeln.

So gehst du vor: Filtere den Bericht auf die einzelne Seite, lies die Gesamtklicks ab, wechsle auf die Suchanfragen-Tabelle und summiere die Zeilen. Bei vielen Seiten automatisierst du das über die API, indem du Seite und Suchanfrage als Dimensionen abfragst und pro Seite summierst. Der Abgleich zeigt dir, bei welchen Seiten eine Keyword-Analyse belastbar ist und bei welchen du besser auf Themen und Suchabsicht schaust.

Dabei fällt oft etwas Nützliches auf: Seiten mit hoher Lücke sind häufig genau die, die viele Varianten einer Frage beantworten. Das ist ein Hinweis auf gutes thematisches Matching, nicht auf ein Problem. Ein Ranking-Tracker mit festem Keyword-Set sieht diesen Traffic nie, weil er nur die Begriffe beobachtet, die jemand vorher eingetragen hat.

Datenhaltung, Sichtbarkeit und Vergleichbarkeit über die Zeit

Die Search Console hält ihre Leistungsdaten nur für einen begrenzten Zeitraum vor, etwa sechzehn Monate. Wer Jahresvergleiche machen will, muss die Daten regelmäßig sichern, sonst fehlt später die Basis. Bei Suchanfragen kommt hinzu, dass sich die Anonymisierung nicht rückwirkend auflösen lässt: Was damals unter der Schwelle lag, bleibt anonym, auch wenn die Anfrage heute häufiger auftritt.

Für Zeitreihen bedeutet das: Berechne den anonymisierten Anteil in jeder Periode neu und speichere ihn neben den Rohdaten. Steigt der Anteil, hat sich dein Traffic stärker in den langen Schwanz verlagert, etwa nach neuen Ratgebern. Sinkt er, konzentriert sich der Traffic auf häufigere Anfragen, etwa nach einer Markenkampagne. Beides verändert die Sichtbarkeit der Suchanfragen-Tabelle, ohne dass sich die tatsächliche Leistung im gleichen Maß verändert hat.

Wenn du Kennzahlen wie die durchschnittliche Position oder die Klickrate nur aus den sichtbaren Zeilen berechnest, beziehen sie sich auf eine selektive Teilmenge. Die sichtbaren Anfragen haben tendenziell mehr Volumen und stabilere Positionen, die versteckten sind spezifischer. Formuliere Ergebnisse deshalb vorsichtig und ordne sie als Aussage über die sichtbaren Suchanfragen ein.

Was die Größe des verborgenen Anteils beeinflusst

Es gibt keine allgemeingültige Quote, und du solltest misstrauisch sein, wenn jemand eine nennt. Der Anteil hängt von der Struktur deines Traffics ab, und die Mechanik dahinter lässt sich gut beschreiben.

Langer Schwanz. Je mehr deiner Klicks von einmaligen, sehr spezifischen Formulierungen kommen, desto mehr fällt unter die Schwelle. Eine Website mit vielen Ratgebern zu Nischenproblemen, Fehlermeldungen oder Produktnummern hat in der Regel einen höheren anonymisierten Anteil als eine Seite, deren Traffic sich auf wenige Markenbegriffe konzentriert.

Traffic-Volumen. Kleine Websites haben weniger Nutzer je Anfrage. Dieselbe Anfrage, die bei einem großen Wettbewerber oft genug vorkommt, bleibt bei dir unter der Schwelle. Mit wachsendem Traffic schrumpft der Anteil häufig, ohne dass sich etwas an deiner Strategie geändert hätte. Vergleiche darum Monate nicht naiv miteinander.

Sprache und Thema. Sprachen mit langen Komposita, wie das Deutsche, erzeugen viele Varianten derselben Frage. Jede Variante wird seltener gestellt. Dazu kommen Sprachassistenten und längere Fragesätze, die selten wortgleich wiederkehren.

Seitentyp. Produkt- und Kategorieseiten werden oft über wiederkehrende Begriffe gefunden, Ratgeber über viele Varianten. Darum sind die Lücken je Seite sehr unterschiedlich, und ein Durchschnitt über die ganze Property verdeckt das.

Was du mit der Lücke praktisch anfängst

Das Wichtigste vorweg: Die anonymisierten Anfragen sind kein Grund, der Search Console zu misstrauen. Sie sind ein Grund, die Ansichten für die richtige Frage zu wählen.

Für Gesamttrends von Klicks und Impressionen nimmst du Datum oder Seite, nie die Suchanfragen-Summe. Wenn ein Kollege behauptet, der Traffic sei um ein Viertel gesunken, weil die Tabelle weniger Klicks zeigt, prüfe zuerst, ob er Zeilen summiert hat.

Für Themenanalysen, also welche Formulierungen Nutzer verwenden, bleibt die Suchanfragen-Tabelle brauchbar, aber als Stichprobe des sichtbaren Teils. Behandle sie wie eine Umfrage mit unbekannter Ausfallquote: Muster sind verlässlich, Absolutwerte sind es nicht. Wenn die Ausfallquote einer Seite sehr hoch ist, sagt die Tabelle für genau diese Seite wenig.

Für Berichte schreibst du den Stand dazu. Ein Satz wie „Die Suchanfragen-Daten decken etwa drei Viertel der Klicks ab“ (mit dem von dir berechneten Wert) verhindert Diskussionen und macht deine Analyse glaubwürdiger. Gleiches gilt für Dashboards, etwa in Looker Studio: Zeige die Gesamtkennzahl aus einer Quelle ohne Suchanfrage-Dimension und nicht aus der Tabelle.

Und für Entscheidungen auf Seitenebene gilt: Eine Seite mit vielen Klicks und kaum sichtbaren Suchanfragen ist kein Fehler. Sie zeigt, dass ihr Traffic aus vielen seltenen Varianten besteht. Für die Optimierung lohnt sich dann der Blick auf die Themenbreite der Seite und nicht auf einzelne Keywords.

Häufige Fehler beim Umgang mit der Lücke

Der erste Fehler ist, die Differenz als Datenverlust zu melden und ein Ticket an die Entwicklung zu schreiben. Der Tracking-Code ist nicht beteiligt, die Search Console misst serverseitig bei Google.

Der zweite ist, die Lücke mit Analytics-Daten schließen zu wollen. Webanalyse-Tools kennen den Suchbegriff der organischen Google-Suche seit Langem nicht mehr und zeigen dafür „nicht angegeben“. Sie bieten keinen Ersatz für die fehlenden Zeilen, sondern nur eine Ansicht der Landingpages.

Der dritte ist, den anonymisierten Anteil hochzurechnen, indem man die sichtbaren Suchbegriffe proportional aufstockt. Das unterstellt, dass die versteckten Anfragen genauso verteilt sind wie die sichtbaren, und das stimmt fast nie: Sie sind per Definition selten, also der lange Schwanz. Hochrechnen verzerrt dann besonders die Top-Begriffe nach oben.

Der vierte ist, Exporte verschiedener Tage oder mit unterschiedlichen Filtern zu mischen. Halte Datumsgrenzen, Suchtyp und Filter fest und dokumentiere sie, wie du es bei jeder Messung tun würdest.