Google Search Console Suchanalyse:

Der Blick auf den Sichtbarkeitsindex im SEO-Tool des Vertrauens kann bei manchen für Stimmungsschwankungen am Montagmorgen sorgen: Geht die Kurve hoch, startet man beseelt in die neue Woche, geht die Kurve runter, dann nimmt sie die Laune direkt mit in den Keller. Ähnlich ist es beim Blick auf die Suchanalyse-Daten der Google Search Console. 

Doch was auf den ersten Blick als identische (Trend-)Indikatoren aussieht, ist nicht direkt miteinander verknüpft: Denn während SEO-Tools (meistens) einen Sichtbarkeitsindex darstellen, der schwankende Suchanfragen außen vorlässt und auf einem (recht) stabilen Keywordpool basiert, liefert die Google Search Console einen dynamischen Trafficindex, der grundsätzlich alle Suchanfragen einfließen lassen kann. 

Der Unterschied: Sichtbarkeit sagt, du rankst für Suchanfrage A mit einem (gemittelten) Suchvolumen von B auf Platz C, woraus sich der Sichtbarkeitswert D ergibt. Wie viele Klicks daraus entstehen, z.B. aufgrund von Events verursachten steigenden oder sinkenden Suchvolumen, das hat auf die Sichtbarkeit keinen Einfluss. Und ganz zu schweigen von Suchanfragen, die in der Google Search Console zu Trafficanstiegen führen, aber von SEO-Tools nicht erfasst werden. 

Doch die Arbeit mit den Suchanalyse-Daten ist mit einigen Stolpersteinen versehen. Schauen wir doch direkt mal auf die klassischen Themen, auf die die meisten stoßen.

Die Basics: URL vs. Website-Daten

Die Suchanalyse-Daten der Google Search Console werden in zwei Aggregationen abgespeichert, nämlich nach Webauftritt (in der GSC auch byProperty genannt) und nach URLs (byPage, nachfolgend auch Seiten genannt). Was bedeutet das? Besonders dann, wenn ein Nutzer nach einem Unternehmen sucht (also eine klassische „Brand-Suchanfrage“ stellt), dann kommt es häufig vor, dass mehrere Seiten einer Website erscheinen. Betrachten wir die Daten nach Website, dann ist aus dieser Suchanfrage eine Impression, und idealerweise auch ein Klick entstanden.

Es wurden allerdings mehrere unterschiedliche Seiten der Website angezeigt – betrachten wir also die Suchanfrage unter dem Aspekt „wie viele Seiten waren für diese eine Suchanfrage in den Suchergebnissen zu sehen?“, dann sind es mehrere. Bei beispielsweise fünf angezeigten Seiten der Property wurden aus einer Suche fünf Impressionen – und womöglich auch mehrere Klicks. 

Die unmittelbare Folge: Wann immer in der Google Search Console nach Seiten gefiltert wird, steigen die erzielten Klicks und Impressionen. Und da selten mehrere URLs derselben Domain für dieselbe Suchanfrage angeklickt werden, sinkt in der Folge die durchschnittliche Klickrate. In Abbildung 1 kommen durch die Filterung nach URL 22 weitere Klicks und 58.776 Impressionen hinzu – in der Folge sinkt die Klickrate deutlich.

Die Basics: Unsichtbare und unvollständige Daten

Die Google Search Console sieht immer prall gefüllt aus mit vielen Daten. Doch sind das eigentlich alle? Stimmen die Werte oberhalb des Charts mit den Werten der Tabelle überein? Bei Betrachtung der Suchanfragen ist das eher die Ausnahme als die Regel! Um es konkret zu benennen: Google liefert nur für einen Teil der Klicks die dazugehörigen Suchanfragen.

Abbildung 2 zeigt ein solches Beispiel: Die analysierte URL hat 19 Klicks erzielt, allerdings ergibt die Summe der Klicks in der Datentabelle nur 5 – über welche Suchanfragen die anderen 14 Klicks entstanden sind, ist unbekannt.

Wie viele Suchanfragenklicks Google (nicht) liefert, ist von Property zu Property unterschiedlich. Häufig liegt über eine Website insgesamt betrachtet die Zuordenbarkeit von Klicks zu Suchanfragen bei 30-40 % der Gesamtklicks – entsprechend fehlen mehr Daten, als von Google zur Verfügung gestellt werden! Für einzelne Unterseiten kann das allerdings auch anders aussehen: Mal liefert Google gar keine Suchanfrage mit Klicks, mal alle. Wie sagen SEOs mit schöner Regelmäßigkeit: it depends!

Diese fehlenden Daten haben noch eine weitere Implikation: Auf Daten, die nicht bekannt sind, kann nicht gefiltert werden. Viele werden es schon in der Google Search Console gesehen haben: Wenn nach „Suchanfrage enthält [Begriff]“ und anschließend auf „Suchanfrage enthält den [Begriff] nicht“ gefiltert wird, dann ergeben die beiden Teilwerte addiert nur einen Bruchteil der Klicks und Impressionen der von Google gemeldeten Gesamtwerte. Google weiß schlicht nicht, ob diese „unbekannten“ Suchanfragen den Begriff beinhalten oder nicht. Das sind die sogenannten anonymisierten Suchanfragen – und diese sorgen bei viele Websites für mehr als 50 % oder mehr der Klicks!

Doch nach welcher Logik entscheidet Google, ob eine Suchanfrage in der Google Search Console erscheinen kann? In einem Google Blogpost (siehe einfach.st/gsc48) steht dazu „Anonymisierte Suchanfragen sind Suchanfragen, die innerhalb von zwei bis drei Monaten von nicht mehr als ein paar Dutzend Nutzern gestellt wurden“. Sowohl auf den Zeitraum als auch die tatsächlichen Suchanfragen bezogen ziemlich unspezifische Angaben. 

Doch Moment: In meiner Google Search Console sind doch auch Suchanfragen enthalten, die nur eine Impression erzielt haben in den letzten 6 Monaten. Wie geht das denn? In der Regel liegt das daran, dass die eigene Website nicht dauerhaft für die Suchanfrage zu sehen war. Sprich die Nachfrage war höher, für die eigene Property ist aber nur ein Datenpunkt gespeichert worden. Denn primär speichert Google die Statistiken zu den Suchanfragen an sich ab, und eben nicht für eine bestimmte Property.

Durch die fehlenden Daten ergibt sich noch eine Herausforderung: Wer mit den unvollständigen Query-Daten als Ausgangsbasis für eine Analyse arbeitet, der kommt schnell zu einer datenseitig korrekten Aussage wie „die Beispiel-URL aus Abbildung 2 hat nur 5 Klicks“ – das ist grundsätzlich richtig, allerdings liefert Google die Information „dazu kommen 14 Klicks für nicht bereitgestellte Suchanfragen dazu“ eben nicht im Interface oder die GSC API. Im Extremfall liefert Google gar keine Suchanfrage mit Klicks zu einer URL – wer diese URL jetzt löscht, der schneidet sich unter Umständen einiges an Traffic weg. Die Lösung ist, zum einen die URL-Klicks zu erheben und – wo nötig – die Suchanfragen-Performance danebenzulegen. Denn auf URL-Ebene sind alle Klicks vorhanden.

Wer jetzt denkt, dass bei meiner Beispiel-URL aus Abbildung 2 nur die Suchanfragen fehlen, der irrt sich: Auch eine Betrachtung der Klicks nach Ländern und Geräten ergibt in der Summe nur 5 Klicks, da diese Eigenschaften nur zusammen mit der Suchanfrage erfasst werden, wenn eine Analyse „byPage“ durchgeführt wird. Google anonymisiert also nicht nur die Suchanfrage an sich, sondern auch die dazugehörigen weiteren Datenpunkte wie „über welches Gerät?“ oder „aus welchem Land?“.

Und jetzt kommt ein „it depends“ direkt hinterher: Denn immer dann, wenn die Daten „byProperty“ angeschaut werden, also keine Einschränkung für URLs vorgenommen wurde, dann stimmen die Werte oberhalb des Charts für Länder und Geräte und die der jeweiligen Tabelle wiederum (fast) überein. Warum nur fast? Die Gesamtwerte oben sind „byProperty“, in der Tabelle zählt Google allerdings wiederum nach „byPage“ – wenn also aus einer Suche mehrere Klicks zur Property erfolgen, dann tauchen diese Klicks in der Datentabelle auf.

Die Basics: Der (globale) Durchschnitt

Eine Klickrate von 30,8 % ist auch auf einer durchschnittlichen Position von 21,5 möglich – wenn man einfach alles in einen Topf wirft und den Durchschnitt bildet. Es kommt regelmäßig vor, dass eine Website für dieselbe Suchanfrage in ganz unterschiedlichen Ländern gefunden wird. Bei mir gibt es mit „robots noindex“ eine solche Suchanfrage – der deutschsprachige Artikel zu dem Thema ist in Deutschland sehr gut auffindbar, aber auch auf hinteren Plätzen in Brasilien oder der Türkei. Nimmt man alle Daten zusammen, dann ergibt sich eine durchschnittliche Position von 21,5, obwohl für mich das Ranking eher in deutschsprachigen Ländern relevant ist. 

Aus genau diesem Grund ist es bei der Analyse von Suchanfragen so wichtig, den Länderfilter zu verwenden – mit dem Nachteil, dass dadurch viele Klicks „unsichtbar“ werden, da sie keinem Land zugeordnet werden können (und die Suchanfrage fehlt).

Insgesamt sollten die Durchschnittswerte immer mit gewisser Skepsis betrachtet werden, da sich die darunterliegenden Daten stetig verändern. Verbessert sich das Ranking für einen stark nachgefragtes Keyword ans Ende der Top 10, dann gehen die Impressionen hoch bei einer gleichzeitig (noch) niedrigen CTR, und in der Folge kann sich die Gesamt-CTR der Website verschlechtern. Oder in SEO-Tools steigt die Sichtbarkeit, aber die durchschnittliche Position in der GSC sinkt, da die Website auf einmal für deutlich mehr Suchanfragen gefunden wird.

Zudem können Ranking-Tracker die Daten verfälschen – so gibt es regelmäßig Suchanfragen, die im Hauptland auf Platz 40+ vierstellige Suchanfragen ausweisen. Ob sich tatsächlich so viele Suchende auf diese hinteren Plätze verirren? In der Regel sind Ranking-Checker dafür verantwortlich, da diese 100 Ergebnisse anzeigen lassen und nicht die klassische Paginierung – entsprechend bekommen alle angezeigten Seiten eine Impression. Google bemüht sich zwar, solche automatisierten Abfragen zu ignorieren, doch das funktioniert nicht immer.

Um noch einen weiteren Faktor zum Thema „Vorsicht bei Durchschnittswerten“ ins Feld zu führen: Die Suchergebnisse können sich zwischen Desktop und Mobil deutlich unterscheiden. Von daher ist es für viele Analysen zusätzlich sinnvoll, sich auf die mobilen Suchergebnisse und deren Performance zu konzentrieren, wenn der Bärenanteil des Traffics über Mobilgeräte kommt.

Wer komplett ins Rabbit-Hole abtauchen möchte, der beschäftigt sich in allen Details damit, welche Suchergebnistypen (k)einen Einfluss auf die von Google bestimmte Position haben (siehe einfach.st/gsc49). So haben „Ergebnisse“, die eine neue Google-Suche erzeugen, keine Position, obwohl sie auf dem Bildschirm zum Teil prominent zu sehen sind. 

Ein Beispiel ist die Anzeige von Filmen in Abbildung 5 – da ein Klick auf die einzelnen Titel nicht zu einer (externen) Website führt, sondern eine neue Google-Suche auslöst, wird diesen Ergebnissen keine Position zugewiesen. Wer hier auf „Mehr“ klickt, der schiebt die klassischen organischen Ergebnisse komplett aus dem sichtbaren Bereich. Selbes gilt für weitere bekannte Suchergebnisintegrationen wie Wetterdiagramme – die nehmen viel Platz ein, haben aber keine Position. An dieser Stelle sei an meinem Beitrag „Pixelrank – wo stehst du wirklich?“ aus Ausgabe #81 erinnert, der mittlerweile online auf websiteboosting.com frei lesbar ist. 

Die Basics: Wohin werden die Daten zugeordnet?

Im Jahr 2019 ist Google auf eine aus meiner Sicht nach wie vor unverständliche Idee gekommen: Die Suchanalyse-Daten werden nicht mehr der tatsächlich angezeigten URL zugewiesen, sondern der jeweils als von Google als kanonisch bestimmten Adresse (siehe einfach.st/gsc50. 

Was heißt das konkret? Wenn dieselben Inhalte unter der .de- und .at-Domain eines Unternehmens vorliegen, dann kann es sein, dass eine der beiden Versionen als kanonische URL bestimmt wird. Nehmen wir einmal an, dass das die .de-URL des Inhalts ist. 

Durch die Umstellung werden die Klickdaten der .de-URL zugewiesen, obwohl in der österreichischen Google-Suche (durch hreflang) die .at-URL zu sehen war und angeklickt wurde. Entsprechend sieht es in der GSC so aus, als ob viele Nutzer mit dem Standort Österreich über Google auf die .de-Website zugreifen. Interessant wird es immer, wenn sich Google für eine neue kanonische URL entscheidet... Die tatsächlichen Einstiegsseiten lassen sich am besten mit der Webanalyse-Software auswerten. 

Die Basics: Das Zeilenlimit

Wer „klassisch“ im Browser mit der Google Search Console arbeitet, der muss mit einem weiteren Problem umgehen: Den maximal 1.000 Zeilen. Ob indexierte Seiten oder Suchanfragen – nach maximal 1.000 Zeilen ist Schluss. Entsprechend sind von 101.102 indexierten Seiten nur 1.000 Seiten zu sehen.

Im Vergleich zu den anderen Berichten funktioniert die Suchanalyse ein bisschen anders, denn über die Filter können jeweils unterschiedliche 1.000 Zeilen abgefragt werden. So ist es möglich, von Google die Daten zu „Welche Suchanfragen beinhalten ein a?“ zu erhalten. 

Innerhalb der „nicht-anonymisierten“ Daten werden anschließend (bis zu) 1.000 Suchanfragen angezeigt, die ein a enthalten. Das geht in anderen Berichten nicht, da dort nur die von Google angezeigten Daten über das Trichtersymbol oberhalb der Tabelle gefiltert werden können und auch der Zeitraum nicht verändert werden kann. Neue Daten werden dadurch nicht geholt.

Wenn die maximal angezeigten 1.000 Zeilen ein relevantes Problem für die gerade angedachte Analyse sind, dann hilft ein Ausweichen vom Google Search Console Interface auf die API oder den BigQuery-Export. Denn die Google Search Console bietet zwei Datentöpfe. 

Die Datentöpfe der Suchanalyse

Nach den Grundlagen schauen wir am besten einmal auf die Wege, über die die Suchanalyse-Daten abgefragt werden können. Neben dem klassischen Google Search Console Interface gibt es die Google Search Console API und seit Februar 2023 die direkte Datenspeicherung in BigQuery (einfach.st/gsc51). Jeder der Wege hat seine Anwendungsfälle und Daseinsberechtigung. 

„Nur der Export über BigQuery liefert wirklich alle Daten!“

Erklärungsbedürftig ist vermutlich der Punkt „anonyme Suchanfragen“. Zwar liefert uns auch BigQuery nicht alle Suchanfragen, für die die Website in der Suche zu sehen war (und idealerweise geklickt wurde), sondern nur die Statistiken zu einer ansonsten anonymen Suchanfrage. Sprich die Suchanfrage steht nicht zur Verfügung, allerdings bekommt man die Information, dass es Suchanfragen gab, die nicht geliefert wurden. 

Insgesamt liefert Google momentan 41 Datenpunkte zu jedem Eintrag in der Tabelle, von der Suchanfrage und Einstiegsseite über Klicks und Impressionen hin zu unterschiedlichen Suchtrefferdarstellungen (im GSC Interface ist das die „Darstellung in der Suche“) – das entspricht bis auf die zusätzlichen „anonymized“-Informationen der Datenstruktur des Webinterface und der API. Apropos Darstellung in der Suche: Zwar gibt es viele verschiedene Filter, doch solche wie „Newsbox“ oder „Bilderbox“ würden der GSC super zu Gesicht stehen. Denn aktuell ist ein Ranking in der Websuche nicht nach unter anderem diesen beiden Ergebnistypen analysierbar.

In Abbildung 7 ist ein Ausschnitt der Daten zu sehen. Um die Daten abzufragen, müssen SQL-Anfragen geschrieben werden. 

Auf dieser granularen Basis kann Google die Daten bereitstellen – doch diese Datengranularität für alle Websites auf Verdacht im Sinne von „das wollen die Seiten eventuell nutzen“ vorzuhalten, wäre sowohl mit Blick auf die Speicherung als auch die Abfrage sehr ressourcenintensiv. 

Dazu kommt, dass der Anteil der Websites, die die GSC überhaupt aktiv nutzt, aus meinem Bauchgefühl heraus eher überschaubar ist. Daher ist eine Speicherung der Daten auf maximaler Granularität etwas, was Google erst nach Einrichtung des Exports über die Google Search Console startet. Mit anderen Worten: Jegliche historischen Daten sind verloren und können nicht wiederhergestellt werden. 

Ob das ein Manko ist? Es kommt darauf an. Persönlich sehe ich nur wenige sinnvolle Anwendungsfälle für eine langfristige Datenspeicherung. Um es plakativ zu benennen: Was bringt es mir, dass ich für den 03.05.2012 sagen kann, wie viele Klicks ich über Suchanfrage A aus Deutschland über Mobilgeräte bekommen habe, und auf welcher Rankingposition das war? SEO-Erfolg ergibt sich zwar aus den Taten der Vergangenheit, doch nur die Zukunft lässt sich gestalten. Von daher nicht alten Rankings hinterhertrauern, sondern überlegen, für welche Themen durch welche Maßnahmen bessere Rankings erzielt werden können.

Doch zurück zum eigentlichen Thema. Für die Datenspeicherung und -abfrage in BigQuery gibt es von Google Freikontingente, doch wer viele Daten speichern und prozessieren möchte, der wird früher oder später zur Kasse gebeten. Als dauerhaft kostenfreie Alternative gibt es über die Google Search Console API und das Webinterface vorprozessierte Daten, die einen guten Querschnitt darstellen und auch für die letzten 16 Monate zu bekommen sind (sofern die Property bestätigt war). 

Was viele SEOs nach wie vor nicht machen, ist die Nutzung von möglichst spezifischen URL-Präfix-Properties für alle relevanten Verzeichnisse der Website. Denn die GSC-Daten erfasst und (vor-)prozessiert Google nicht auf Grundlage der Domain, sondern anhand der in der Search Console verifizierten URL-Struktur. In der Folge stehen für die separat verifizierten Verzeichnisse mehr Daten zur Verfügung, als wenn nach dem Verzeichnis in der Hauptproperty gefiltert wird. 

Grundsätzlich gilt: Je mehr Traffic über unterschiedliche Suchanfragen eine Website erzielt, desto größer wird der Datengewinn durch die Verifizierung der Verzeichnisse. Bei wem die tausendste Suchanfrage in der bisher bestätigten Hauptproperty maximal eine zweistellige Anzahl an Klicks in 3 Monaten generiert, der braucht sich mit Verzeichnissen nicht groß beschäftigen. Empfehlen kann ich die Anlage einer granularen Verifizierung dennoch.

Das grundsätzliche Potenzial zeigt Abbildung 8: Der geschätzte Jens Fauldrath von get:traction hat mit seinem Team dieselben Daten für unterschiedliche (Sub-)Verzeichnisse sowohl über spezifische Properties als auch die Haupt-Property (in der Abbildung Root-Property genannt) abgefragt und die Daten miteinander verglichen. Bei der sehr großen Domain (10 Millionen URLs!) waren die Daten-Zugewinne durch die spezifischen Properties zum Analysezeitpunkt enorm. Auf kleinere Websites lassen sich die Daten allerdings nicht 1:1 übertragen.

Als get:traction die Analyse durchgeführt hat, gab es den BigQuery-Export noch nicht. Da in diesem „alle“ Rohdaten zur Verfügung stehen, sieht das Ergebnis heute anders aus. Den BigQuery-Export in der Domain-Property zu aktivieren, liefert „alle“ Daten und ein zusätzlicher BigQuery-Export über spezifische Properties liefert keinen zusätzlichen Datengewinn. Bei der Abfrage über die GSC-API gilt allerdings nach wie vor, dass spezifische Properties deutlich mehr Daten liefern.

Um wichtige Verzeichnisse möglichst schnell a) zu identifizieren und b) zu verifizieren, sei mein kostenloses Chrome-Plugin GSC Helper empfohlen. Wer sich in der Suchanalyse die Seiten-Daten anschaut, der bekommt durch einen Klick auf das Plugin-Logo die Daten nach Verzeichnis aggregiert. Dazu wird ein Link zur jeweiligen URL-Präfix-Property generiert, über den auch die erstmalige Bestätigung möglich ist. Ein separater Verifizierungsschlüssel ist dazu nicht notwendig, solange das genutzte Google-Konto über Inhaberrechte für die „Elternproperty“ verfügt.

Welche Daten braucht man für gute Analysen?

Wer sich jetzt fragt, welche Datenquelle für was genutzt werden sollen: Das ist vom Analyseziel abhängig. In vielen Fällen reichen die bis zu 1.000 Datenpunkte im Search Console Interface, speziell bei der Analyse einzelner Seiten. Denn das eine einzelne Seite z.B. bis zu 1.000 trafficstarke Suchanfragen abdeckt, ist sehr selten der Fall. Und häufig tun wir SEOs so, als ob wir die zeitlichen Kapazitäten haben, auch die 1.318 beste URL zu optimieren – doch in der Realität wurden selbst die am besten funktionierenden URLs schon länger nicht mehr auf Aktualität oder Optimierungspotenziale abgeklopft (ertappt? =)).

Wann immer mehrere Seiten analysiert werden sollen, dann ist mindestens die Nutzung der API ein Muss. Denn über das Interface ist es nur für jeweils eine Seite möglich, eine Zuordnung von Suchanfrage zu Einstiegsseite zu erhalten – und hier liegt häufig viel Potenzial versteckt, da die Einstiegsseiten häufig nicht gut genug zu den in den Suchanfragen ausgedrückten Bedürfnissen passen. Für vermutlich 99% der Websites sind die Daten des Interface und der API ausreichend – das restliche 1 % der Websites gewinnen bei vielen Tausenden täglichen organischen Zugriffen durch die Nutzung der BigQuery-Daten zusätzliche Erkenntnisse.

Wer den BigQuery Export noch nicht eingerichtet hat und zukünftig nutzen möchte, der findet bei Google eine umfangreiche Anleitung. Diese ist in der GSC unter „Einstellungen“ => „Bulk-Datenexport“ zu finden. Von dort aus wird der Datenexport angelegt. Selbst für Neulinge beim Umgang mit der Google Cloud Console ist die Einrichtung innerhalb von 15-30 Minuten machbar. 

Zum Abschluss noch ein Tipp: Um die Daten mittels SQL abzufragen, sind Tools wie www.ga4sql.com eine große Hilfe. Für einfache Analysen können auch Daten einfach in Google Sheets exportiert werden und dort analysiert werden.

Hinweis zu Cookies

Unsere Webseite verwendet Cookies. Diese haben zwei Funktionen: Zum einen sind sie erforderlich für die grundlegende Funktionalität unserer Website. Zum anderen können wir mit Hilfe der Cookies unsere Inhalte für Sie immer weiter verbessern. Hierzu werden pseudonymisierte Daten von Website-Besuchern gesammelt und ausgewertet. Das Einverständnis in die Verwendung der Cookies können Sie jederzeit widerrufen. Weitere Informationen zu Cookies auf dieser Website finden Sie in unserer Datenschutzerklärung und zu uns im Impressum.

Einstellungen

Erforderlich

Zustimmen

Diese Cookies werden für eine reibungslose Funktion unserer Website benötigt.

	GSC Interface	GSC API	BigQuery
Zugänglichkeit	Einfach	Mittel

Name	Zweck	Ablauf	Typ	Anbieter
CookieConsent	Speichert Ihre Einwilligung zur Verwendung von Cookies.	1 Jahr	HTML	Website
fe_typo_user	Ordnet Ihren Browser einer Session auf dem Server zu. Dies beeinflusst nur die Inhalte, die Sie sehen und wird von uns nicht ausgewertet oder weiterverarbeitet.	Session	HTTP	Website