GSC: Zahlen, Daten, Fakten Fuckups Feedback

Die Zahlen in der GSC stimmen nicht!? So oder so ähnlich hören wir es von unseren Kunden oder anderen SEOs. Aber stimmt das? Bislang haben wir immer den Grund gefunden, warum die Zahlen falsch aussehen.

Fakt ist:
Die Google Search Console lügt nicht. Aber sie ist ein hochkomplexes Tool und als Nutzer muss man wissen, wie man sie lesen muss. Sonst kann sie einen an vielen Stellen aufs Glatteis führen. An anderen Stellen stören uns nur die Bedienbarkeit oder kleine Details. All die Stellen wollen wir Euch zeigen und erklären, wie Ihr damit am besten umgehen könnt.

Versteht uns dabei nicht falsch. Wir sind große Fans der Google Search Console. Es gibt großartige Reports. Und sie ist die einzige Datenquelle für (halbwegs genaue) Zahlen über unseren Google Traffic aus erster Hand.

Viele Analysen wären ohne die Google Search Console deutlich schmaler, deutlich schwieriger oder schlicht unmöglich. Die Frage “Könnt ihr bitte eure GSC-Properties für uns freigeben?” steht am Anfang jeder unserer Kundenbeziehungen.

Da wir täglich mit der Search Console arbeiten, geht daraus eine lange Liste an Kritikpunkten und Verbesserungsvorschlägen hervor, die wir mit Euch und Google (Hey John, kannst Du uns hören?) teilen wollen.

Deswegen musst Du Dich damit beschäftigen:

Ganz einfach: Wenn Ihr regelmäßig mit der Google Search Console arbeitet, müsst Ihr diese Probleme kennen, sonst werden sie Euch betreffen, beeinflussen und in die Irre führen. Wir helfen Euch dabei, typische Interpretationsfehler zu vermeiden und für einige Fälle schlagen wir Dir Workarounds vor.

Dieser Artikel ist ein Steigerungslauf von kleinen optischen Ungereimtheiten bis hin zu gefährlichen Datenproblemen.

Außerdem haben wir einige Verbesserungsvorschläge, die wir selbst schon als Feedback an Google gegeben haben. Je mehr von Euch die gleichen Punkte fordern, desto wahrscheinlicher ist es, dass das Google Search Console Team dafür Ressourcen bekommt, um das Feedback auch umzusetzen. John Mu betont schließlich immer wieder, dass sie unser Feedback brauchen, damit sie die GSC verbessern können.

Wieso variiert die Reihenfolge der Menüstruktur?

Zugegeben, dieser erste Punkt ist Pedanterie, aber wenn man täglich mit verschiedenen Properties arbeitet, dann nervt es einfach.

  • Bei Properties mit "Discover"-Bericht folgt die "URL-Prüfung" als zweiter Punkt nach der "Übersicht", darunter aufklappbar erscheint der Bereich "Leistung".
  • Ohne "Discover"-Bericht lässt "Leistung" sich nicht aufklappen und ist zwischen "Übersicht" und "URL-Prüfung" platziert. Klar: Google möchte nicht mit leeren Reports enttäuschen.
    Aber muss deswegen die Reihenfolge geändert werden? Wenn man mit unterschiedlichen Properties arbeitet, ist es störend, wenn die gewohnten Klickstrecken variieren.
  • Warum sind einige Punkte so benannt beziehungsweise übersetzt worden, dass sie nicht vollständig dargestellt werden können, wie die “Nutzerfreundlichkeit auf Mobil…”?

Screenshot: Menüpunkte mit abgeschnittenem Text

  • Weshalb kommt mal ein “&” (Sicherheit & Manuelle Maßnahmen) und mal ein “und” (Vorherige Tools und Berichte) zum Einsatz?

Screenshot: Menüpunkte mit inkonsistenter Schreibweise

Feedback an Google:

In nichtenglischen Sprachversionen die Menüpunkte bitte konsistenter bennenen und unnötig abgeschnittene Menüpunkte vermeiden.

Leistung

Der Bereich Leistung ist ein stetiger Quell der Freude und Frustration:

  • Je nach Property steht er für sich (und bezieht sich dann ausschließlich auf die Google-Suche-Ergebnisse)
  • oder ist unterteilt in "Google-Suche-Ergebnisse" und "Discover".

🤔 Wäre es aus Gründen der Konsistenz nicht sinnvoll, immer die unterteilte Variante anzuzeigen und bei Properties ohne Daten zu Discover entsprechend einen Hinweis zu platzieren, das und warum dies so ist? Wobei die aktuelle Lösung für Nutzer von Properties ohne Discover einen Klick einspart. Eine Ansicht ähnlich wie beim Geschwindigkeitsreport wäre hier sinnvoll.

Google-Suche-Ergebnisse

Im Bericht der Google-Suche-Ergebnisse gibt es Einiges zu entdecken, was auf den ersten Blick nicht schlüssig ist. Zudem vermissen wir Möglichkeiten, die vorhandenen Daten weiter zu filtern und zu formen.

Seiten-Filter

Wenn man den Leistungsbericht öffnet, werden per Default die Daten für den Suchtyp Web der letzten drei Monate angezeigt. In unserem Beispiel finden wir:

Klicks Impressionen ø CTR ø Position
2.020 292.293 0,7% 48,3

Werden weitere Filter gesetzt, verändern sich die Werte. So weit, so logisch. Allerdings kommt es häufig zu unerwarteten Ergebnissen: Wenden wir auf die Dimension "Seiten" den Filter “enthält: /” oder “enthält nicht: jeqwfegdgfngfweg” an, verändern sich die Werte:

Klicks Impressionen ø CTR ø Position
2.033 323.783 0,6% 44,9

Screenshot: Seitenfilter

Die Klicks und Impressionen haben zugenommen, obwohl die Filter in beiden Fällen keine unserer URLs betreffen:

  • denn alle URLs enthalten einen “/”
  • wenn man die Werte für einen nicht existierenden URL-Bestandteil wie "jeqwfegdgfngfweg" ausschließt, sollte sich dies ebenfalls nicht auswirken

Dennoch sehen wir eine Differenz von 13 Klicks und 31.490 Impressionen, auch bei der Klickrate und der Position gibt es einen Unterschied.

Das gleiche Phänomen beeinflusst das Ergebnis, wenn ein Filter für den Produktordner gesetzt wird. Immer wenn ein Seitenfilter genutzt wird, verändert sich die Aggregation der Daten und damit auch die Kennzahlen.

Woran liegt das? Wenn Ihr denkt, die Search Console Daten sind falsch, dann liegt Ihr falsch. Die Erklärung für das Phänomen finden wir in der Dokumentation von Google. Unter dem Punkt “Aggregating data by property vs by page” steht Folgendes:

“If a single search element contains several links (as many do), impressions are counted by URL or by property, depending on your view in the Search Analytics report.”

Google zählt alle Impressionen und Klicks auf einer Suchergebnisseite (Search Engine Result Pages beziehungsweise SERP) auf zwei Weisen: “byProperty” und “byPage”.

byProperty

“byProperty” bedeutet, die Klicks, Impressionen und Positionswerte werden für die gesamte Property erfasst, unabhängig davon, welche URL genau in den SERPs angezeigt wurde.

Wenn mehrere URLs von Eurer GSC-Property in der gleichen SERP angezeigt werden, ob durch Mehrfach-Rankings, Sitelinks oder Featured Snippets, wird auch nur eine Impression gezählt (die mit der besten Position). Und auch nur ein Klick, wenn Ergebnisse der Property geklickt wurden.

byPage

Welche URL angezeigt oder geklickt wird, wird nur unter “byPage” gezählt. Dabei wird nicht erfasst, ob und wie viele andere URLs der gleichen Property gleichzeitig angezeigt werden.

Falls das noch nicht ganz klar geworden ist:
Google hat es wirklich sehr schön erklärt, daher seht Euch nochmal die Dokumentation an!

Was hat das mit den Filtern zu tun?

Google versucht, die Daten “byProperty” anzuzeigen, weil es die intuitivere Zählweise ist. Für das Filtern nach URLs, muss die Search Console im Hintergrund auf “byPage” umgeschaltet werden, denn “byProperty” können die Daten nicht auf einzelne URLs bezogen werden. Die Aggregation “byPage” summiert die Impressionen aller angezeigten URLs.

Wenn Ihr viele Sitelinks, Mehrfach-Rankings oder Ähnliches habt, dann ergibt das wesentlich mehr Impressionen und auch mehr Klicks (in unserem Beispiel waren es 13 Klicks). Mehr Klicks sind es, wenn aus der selben Suche heraus ein Nutzer mehrere Ergebnisse der Property anklickt. Entweder, weil er mehrere Ergebnisse in Tabs öffnet, oder, weil er nach einem Ergebnis zurückspringt und ein anderes wählt.

🤔 Muss man einfach wissen, kann man nix machen.

Feedback an Google:

Ob die aggregierten Werte in der Tabelle im Leistungsbericht unter Berücksichtigung von einzelnen URLs oder propertyweise aggregiert wurden, ist häufig nicht ersichtlich und führt zu unnötiger Verwirrung.

Bitte für die aggregierten Werte und die Tabellenwerte kennzeichnen, ob diese Zahlen, bei den aktuell genutzten Filtern, auf Basis der byPage oder byProperty Aggregation berechnet wurden.

Übrigens: "jeqwfegdgfngfweg" ist kein geheimer Google-Code. Sondern unser Beispiel für einen URL-Bestandteil, den es nicht gibt. Bei uns gibt es einen "Fachbegriff" dafür: “die Katze über die Tastatur laufen lassen” - So häufig benötigen wir diese Werte.

Grenzen der Genauigkeit

Wenn man denkt, man hat die Filter-Logiken im Leistungs-Bericht der GSC durchdrungen, dann stolpert man über den folgenden Sachverhalt:

Screenshot: Edge-Case-Werte

Das Beispiel stammt aus einer umfangreichen Property. An den Zeitverläufen sieht man, dass die Zählweisen "byProperty" und "byPage" unterschiedliche Datenquellen sind. Unter "byProperty" zeigt Google nicht mehr alle Impressionen, sondern nur noch Daten von den Tagen, an denen auch Klicks vorhanden sind. Irgendwo müssen die großen Serverfarmen im Silicon Valley wohl mal ein paar Abkürzungen nehmen!

🤔 Wie bei den beiden anderen Filterphänomenen gilt: Muss man einfach wissen, kann man nix machen.

Query-Filter

Nicht nur der Seiten-Filter hat seine Tücken, sondern auch der Query-Filter: In der Standard-Ansicht sehen wir:

Klicks Impressionen ø CTR ø Position
2.020 292.293 0,7% 48,3

Ein beliebter Filter für die Suchbegriffe ist die Marke.

Diese kann eingeschlossen oder ausgeschlossen werden. Wenn man beide Filter einmal ausführt, erhält man die folgenden Werte:

  • “enthält: <marke>”: 236 Klicks und 1.345 Impressionen
  • “enthält nicht: <marke>”: 282 Klicks und 248.748 Impressionen

Screenshot: Query-Filter in der GSC

Wir erwarten, dass die Summe der Werte für “enthält: <marke>” und “enthält nicht: <marke>” gleich dem Ergebnis ohne Suchbegriff-Filter sind. Tatsächlich sieht es aber anders aus:

 Ohne Filter  Mit Marke  Ohne Marke  Summe Mit Marke + Ohne Marke  Differenz ohne Filter vs. Summe
Klicks  2.020  236  282  518  1.502
Impressionen  292.293  1.345  248.748  250.093  42.200 

Auch dafür finden wir eine Erklärung bei Google. Tief versteckt im Abschnitt “Queries” der Performance Report Dokumentation steht zum Thema “Anonymized queries”:

“Very rare queries (called anonymized queries) are not shown in these results to protect the privacy of the user making the query. Anonymized queries are always omitted from the table. Anonymized queries are omitted from the chart totals when you filter by query (either queries containing or queries not containing a given string).”

Google zeigt uns einen großen Teil des Longtails nicht im Detail an. Bei einigen Properties ist der Anteil dieser anonymisierten Suchanfragen bis zu 70% aller Klicks. Google gibt keine Grenzwerte an, wann Suchanfragen unter diesen Filter fallen. Behaltet bei Euren Auswertungen also im Hinterkopf, dass Ihr einen großen Teil des Longtails nicht angezeigt bekommt.

🤔 Auch hier gilt wieder: Muss man einfach wissen, kann man nix machen.

Tipp: Nonbrand Filter

Überlegt Euch, wie Ihr den Nonbrand-Anteil Eures SEO-Traffics berechnet.

Bei den meisten Domains ist es unwahrscheinlich, dass der Longtail überwiegend aus Brand Traffic besteht. Wenn Ihr Nonbrand mit “enthält nicht: <marke>” errechnet, fehlt der Longtail in dieser Betrachtung, genauso wie Variationen, die durch den Filter nicht abgedeckt sind.

Für Analyse von Brand vs Nonbrand bleiben Euch zwei Optionen:

  • Nonbrand = Total - Brand
  • Analyse: Brand vs Nonbrand vs Longtail

Durch dieses Vorgehen erreicht man in der Regel gute Näherungswerte. Genauer wird es, wenn man die Daten via API zieht und komplexere Filter anwendet, als die GSC es aktuell zulässt.

Sprungmarken URLs und Sitelinks

Ein weiterer Effekt der "byProperty"-Wertung lässt sich im Zusammenhang mit erweiterten Snippets — zum Beispiel durch Sitelinks oder Sprungmarken — beobachten.

URLs die Google in Sitelinks oder als Sprungmarke ausspielt, werden selten geklickt. Bei der aktuellen Logik der Datenbank ist das leider nicht anders abbildbar. Bedenkt die "byPage"-Logik besonders, wenn Ihr Euch die Klickraten anseht.

Wir Wingmen wünschen uns, dass solche Links stattdessen in der Tabelle unter “Darstellung in der Suche” (Search Appearance) angezeigt werden… Aber in diesem Teil der Search Console ist leider so gut wie alles irreführend. Es ist sehr wahrscheinlich, dass Google selbst die Impressionen und Klicks für Sitelinks und andere zusätzliche Links erfasst und analysiert. Um das auch für uns transparent zu machen, wäre ein Filter, der bei der "byPage"-Aggregation nur die “primären” Links eines Snippets in den Report einfließen lässt, sehr hilfreich.

🤔 Daher gilt auch hier: Behalte es im Hinterkopf! Wir haben unseren Wunsch als Feedback bei Google eingekippt.

Feedback an Google:

Aktuell kann im Leistungsbericht nicht unterschieden werden, ob eine Impression oder ein Klick auf den primären Link eines Snippets entfallen ist, oder ob es sich um einen sekundären Link eines Snippets, wie z.B. Sitelinks oder Sprungmarken ("Weiter zu"/"jump to"-Links) handelt.

Bitte schafft eine Möglichkeit, die primären Links zu filtern, also Klicks, Impressionen, CTR und Positionswerte von z.B. Sitelinks, Sprungmarkenintegrationen und Ähnlichem nicht anzuzeigen oder ausschließlich anzuzeigen.

Wochenwerte oder gleitender Mittelwert

Fast jede Property hat im Bereich Leistung einen deutlichen Wochenverlauf: Typischerweise dominiert die Zeitspanne von Montag bis Freitag, häufig mit einem Peak am Mittwoch. Samstags und Sonntags fallen die Graphen für Klicks und Impressionen erkennbar ab:

Screenshot: Wochenwerte in der Search Console

Aber es gibt auch Seiten, bei denen am Wochenende mehr los ist:

Screenshot: Wochenwerte in der Search Console freizeitthemen

So oder so: Je länger der betrachtete Zeitraum ist, desto schwieriger ist es, durch die Schwankungen die Gesamtentwicklung einzuschätzen.

🤔 Wir Wingmen würden gerne von der Tag-basierten Ansicht auf eine Wochen- oder Monats-Sicht wechseln können. In Google Analytics gibt es eine derartige Darstellung bereits.

Screenshot: Wochen/Monats Darstellung in Google Analytics

Alternativ zu den aggregierten Zeiträumen wäre ein (als solcher eindeutig erkennbarer) gleitender Durchschnitt eine nützliche Ansicht. Sinnvollerweise mit einem einstellbaren Fenster, um auch andere Saisonalitäten als den Wochenrythmus berücksichtigen zu können. Aber das geht vermutlich zu weit. Immerhin kannst Du inzwischen innerhalb der Tabelle im Reiter: „Zeiträume“ die Daten für eine eigene Visualisierung / weitere Bearbeitung herunterladen und in Excel fix einen gleitenden Mittelwert eintragen.

Feedback an Google:

Die Leistungsdaten haben in der Regel einen starken Wochenrhythmus. Dadurch ist die Interpretation der Graphen im Leistungsbericht bei langen Zeiträumen erschwert. Bitte schafft eine Möglichkeit, die Graphen neben dem täglichen Verlauf auch auf Wochen und Monatsbasis zu visualisieren (ähnlich der Funktionalität in Google Analytics).

Noch schöner wäre eine Darstellung mit einem (als solchen eindeutig erkennbaren) gleitenden Mittelwert (https://de.wikipedia.org/wiki/Gleitender_Mittelwert). Sinnvollerweise auch mit einem einstellbaren Fenster, um weiterhin andere Saisonalitäten ausgleichen zu können.

(Kein) Folder-Vergleich

Durch den Vergleich von Seiten ist es auf URL-Ebene möglich, verschiedene Inhalte nebeneinander zu legen. Das ist praktisch, wenn ein Inhalt innerhalb der Property die URL geändert hat und weitergeleitet wird.

Vergleichen wir die alte und die neue URL miteinander, sehen wir, wann und wie gut die Klicks, Impressionen, etc. den Wechsel vollzogen haben.

Screenshot: Vergleich von Einzel-URLs im Leistungsbericht

Allerdings ist dieser Vergleich auf zwei konkrete URLs begrenzt. Ganze Folder oder Subdomains können nicht miteinander verglichen werden, sind aber ein häufiger Use-Case. Natürlich kann man sich mit entsprechenden Daten-Exporten behelfen und alles selbst zusammenbauen. Viel einfacher wäre es aber solche Analysen in der GSC selbst machen zu können.

🤔Feature Request: Könnte im Vergleichsmodus zusätzlich zu “URL ist genau” auch die Auswahl aus den Filtern, “URLs mit” und “URLs ohne” ergänzt werden? Das wäre ziemlich, ziemlich cool.

(Keine) Suchanfragen-Kombination

Bei Suchanfragen stößt der Filter an seine Grenzen: Es kann nur ein Begriff oder eine Schreibweise angegeben werden. Komplexere Filter, um beispielsweise verschiedene Schreibweisen einer Marke zu adressieren, funktionieren nicht. So könnten wir einen Filter setzen für “Suchanfragen mit: gsc” oder für “Suchanfragen mit: google search console”. Beide Filter sind nicht miteinander verknüpfbar, was schade ist. Auch für mehrere Schreibweisen gilt: Daten via API ziehen und mit Excel, Python oder RegEx durch den Datenwolf drehen.

🤔 Feature Request: Wäre es nicht hilfreich, Filter innerhalb der Suchanfragen miteinander kombinieren zu können?

Am meisten könnte man aus den Filtern herausholen, wenn man die Möglichkeit hätte, reguläre Ausdrücke anzuwenden. Reguläre Ausdrücke sind mit aufwändigen Datenbankabfragen verbunden, aber das ist im Prinzip bereits über das Data Studio möglich. Die Infrastruktur steht und die Möglichkeit flexibel zu filtern würde den Leistungsbericht erheblich aufwerten.

🤔 Wieso gibt es bisher keine Möglichkeit, komplexere Filter durch den Einsatz von RegEx anzuwenden? Ist das geplant? Wir würden das extrem feiern! Schon alleine die Möglichkeit, Wildcards einzusetzen, wäre sehr hilfreich.

Wir feiern die RegEx-Filter extrem seit dem 02.Juni 2021. Denn seitdem sind alle 3 oben genannten Probleme gelöst. 🥳

Data Looker Studio Connector

Data Studio heist inzwischen Looker Studio. Und Inzwischen ist dieser Bug auch behoben und in byPage Daten können wir auch in Looker Studio Dashboards Positionsdaten ausgeben.

Machen wir einen Sprung von der Google Search Console ins Google Data Studio. Dort können wir Daten aus verschiedensten Quellen zusammenführen und tolle Dashboards bauen. Neben Google Analytics, Google Spreadsheets, BigQuery, eigenen SQL Datenbanken und vielen anderen Datenquellen (16 von Google und 161 von Partnern, siehe https://datastudio.google.com/data) kann auch die GSC angezapft werden.

Dimensionen und Metriken des GSC-DataStudio Connectors

Außerdem können wir die gewünschten Regulären Ausdrücke anwenden. Aber warum fehlt im URL Connector, also für Auswertungen "byPage", die Position.
Ich wiederhole noch einmal:
Warum. Fehlt. Im. URL. Connector. Die. POSITION!

In der API kann sie mit ausgegeben werden und so schwer wird es nicht sein, den gewichteten Mittelwert in der Aggregation von Datastudio auszugeben.

🤔 Vielleicht wird es irgendwann nachgerüstet. Sonst müssen wir uns selbst daran setzen so einen Connector zu bauen.

Vergleichstabellen

Zurück zur GSC selbst. Die eingeschränkten Vergleichsmöglichkeiten haben wir bereits moniert. Loben würden wir den Vergleich von Zeiträumen und Devices. Aber dabei fällt doch noch ein Fallstrick auf, der für das Google Search Console Team zu beheben sein sollte:

Screenshot: Vergleichstabelle mit fehlenden Daten

Screenshot: Vergleichtabelle gefiltert auf die betreffende Suchanfrage

Wenn wir den Vergleich nutzen, um zwei Zeiträume oder Desktop und Mobile zu vergleichen, ist das Ergebnis häufig größer als die üblichen 1000 Zeilen der Tabellendarstellung in der GSC. In diesem Fall haben aber viele Zeilen in jeweils einer der beiden verglichenen Filter-Varianten Null Klicks und Impressionen. Werden die betroffenen Suchanfragen oder Seiten einzeln aufgerufen, zeigt die GSC jedoch für beide Zeiträume oder Geräte Klicks mit Werten größer als Null an.

Grund dafür ist die Begrenzung der Tabelle auf 1000 Zeilen. Diese wirkt bei beiden Varianten des Vergleiches und die jeweils 1000 Zeilen werden dann in der Tabelle einfach nebeneinander dargestellt, also ein outer Join der Tabellen auf dem Suchwort. Falls eine Query in einer der beiden gefilterten Varianten Teil der ersten 1000 Zeilen ist und in der Anderen nicht, füllt die GSC den Wert für den der anderen Variante mit Null.

Das die Tabelle auf 1000 Zeilen Limitiert ist, ist irritierend. Das bei Vergleichen das Ergebnis irreführend ist, ist deprimierend und zeitraubend.

Die Datenbankabfrage so einzurichten, dass alle Tabellenwerte korrekt ausgegeben werden, ist kein Hexenwerk.

🤔Falls es doch Einschränkungen gibt, die von außen nicht sichtbar sind, gebt keine falschen Werte aus, sondern ein ehrliches “not Available” mit einer Erklärung.

Feedback an Google:

Bei den Tabellen werden beim Einsatz von Vergleichen fehlerhafte Daten angezeigt.

Wenn ein Wert nur in einer der beiden verglichenen Ergebnissen unter den ersten 1.000 ist, werden 0 Impressionen und Klicks für die andere Dimension angegeben, auch wenn ein gezieltes Filtern zeigt, dass für diesen Wert eigentlich Klicks und Impressionen vorhanden sind.

Entweder sollten hier die korrekten Werte ausgespielt werden oder zumindest klar mit "not available" gekennzeichnet sein.

Darstellung in der Suche

Neben den Suchanfragen, Seiten, Ländern, Geräten und Zeiträumen gibt es im Bereich Leistung eine weitere Dimension: “Darstellung in der Suche” (Search Appearance). Die Grundidee dieses Abschnittes ist großartig:

Hier können wir sehen, wie wir abgesehen vom Standard-Snippet in der Suche zu sehen sind. Leider wurden verschiedene Ebenen zusammengeworfen und einige Punkte sind nicht voneinander abgegrenzt. Eine tiefgreifende Analyse stößt daher schnell an ihre Grenzen. Am meisten stören uns dabei diese Punkte:

Screenshot Search Appearance

AMP non-rich results vs AMP article vs AMP article rich results

In der Google Search Console tauchen “AMP non-rich results” und “AMP article” auf.

Die Dokumentation spricht dagegen von “AMP article” und “AMP article rich results”. Es wäre schön, wenn in der Dokumentation nicht das Gegenteil von dem was dargestellt wird steht. Ich bin mir nicht sicher, ob tatsächlich die “AMP non-rich results” reportet werden oder versehentlich eine Verneinung erwähnt wurde.

Rich results

Wenn man der Dokumentation traut, sind in diesem Punkt die interessanten Suchintegrationen, die in der Search-Gallery aufgeführt sind, zusammengefasst.

Aufwändig erstellte Markups, wie z.B. FAQ- oder How To-Integrationen, werden zusammengeworfen mit Standardauszeichnungen, wie Breadcrumbs. Das macht diesen Bericht wertlos.

Einige SERP-Integrationen aus der Search-Gallery haben inzwischen eigene Zeilen in der "Darstellung in der Suche" bekommen. Zum Beispiel “FAQ rich results”. Verwenden wir verschiedene Filter, kommen wir zu folgender Vermutung:

  • Nicht alle Integrationen aus der Search-Gallery Rich Results gehen ein
  • Oder sie sind nicht aus den Rich-Snippets herausfilterbar
  • Sie werden doppelt und damit irreführend gezählt

Auch hier wünschen wir uns eine Klarstellung.

List/Details rich results (Google for Jobs, Events)

Lange haben wir darauf gewartet, dass Google for Jobs bei uns an den Start geht. Nachdem es dieses Feature schon seit 2017 in den USA gibt, wurde es im Mai 2019 in Deutschland gelaunched. Seit Mitte Dezember ist das Event Listing in den deutschen SERPs vertreten. Job und Eventportale betrachten die Entwicklung mit gemischten Gefühlen. Weitere ähnliche Suchintegrationen folgen in Zukunft in anderen Bereichen.

Die Integrationen gibt es für jene Webseiten, die strukturierte Daten im Einsatz haben, um Stellenausschreibungen oder Events auszuzeichnen. Diese zeigt Google in Google for Jobs und den Event Listings an. Die Properties haben im Bereich "Verbesserungen" einen entsprechenden Abschnitt mit Informationen zu Fehlern, Warnungen und gültigen Seiten für diese Features. Zusätzlich gibt es im Leistungsbericht unter der Dimension "Darstellung in der Suche" einen Einblick darüber, wie gut die ausgezeichneten Stellenangebote oder Events funktionieren.

Tabelle für Job Einblendungen in der GSC

Dabei gibt es das Job/Event Listing und das Job/Event Detail. Was als Klick und Impression zählt ist leider unübersichtlich geregelt.

Auch hierzu gibt es eine Dokumentation. Trotzdem ist es nicht einfach und intuitiv zu verstehen, was und wie genau gezählt wird. Außerdem wurden viele Dinge vermischt, so dass die meisten Metriken in diesem Bereich nicht als Entscheidungsgrundlage taugen. Wir nehmen das am Beispiel Google for Jobs auseinander:

Listing Klick:

Klicks sind Klicks auf einen Job in der Google-for-Jobs-Übersicht oder dem kurzen Listing, das in der SERP eingeblendet wird. Im Unterschied zu der übrigen Goolge Search Console handelt es sich nicht um Klicks, die den Nutzer auf die Seite der angezeigten Property leiten, sondern um die Navigation innerhalb von Google.

Damit kommt man auf die Job-Detail-Seite von Google und erhält dort die entsprechende Job-Detail-Impression. Ob diese Klicks in die ungefilterte Zählung von Klicks eingehen ist in der Dokumentation nicht explizit ausgeschlossen. Wenn es so wäre, würde das die gesamte Logik des Leistungsberichts grundlegend infrage stellen. Wir hoffen das nicht.

Listing Impression:

Impressionen hier zählt Google, wann immer ein Job angezeigt wird. In dem kurzen Listing in der normalen SERP, zählt die GSC die eingeblendeten Job-Ergebnisse. In der Google-for-Jobs-Übersicht alle Jobs in der Liste, unabhängig davon, ob sie zu sehen waren. Vermutlich zählen diese Impressionen nur für die Property, deren Seite im Job-Snippet als Quelle referenziert wird (“über ...”). Eine Aussage von Google, die das eindeutig klärt, gibt es nicht und die uns vorliegenden Daten reichen nicht aus, um das sicher sagen zu können.

Diese Zählweise sorgt bei Desktop-Nutzern dafür, dass ein Klick aus den SERPs auf ein Google-for-Jobs Ergebnis nicht nur den Job-Listing-Klick verursacht, sondern gleichzeitig auch die Impression für das Job-Listing in der Google-for-Jobs-Ansicht. Das macht, inklusive Job-Detail-Impression, drei Impressionen und einen Klick für das Ergebnis, bevor der Nutzer überhaupt die Möglichkeit hatte, auf die eigentliche Zielseite zu gelangen.

Listing Position:

Die Position wird überall ausgewertet, wo der jeweilige Job angezeigt wird. In der Google-for-Jobs-Ansicht wird die Position innerhalb des Listings gewertet. Im Gegensatz dazu wird bei den Impressionen der SERP-Einblendung für alle Jobs in der SERP Einblendung nicht die Position innerhalb der Einblendung gewertet, sondern für alle die Position in der gesamten Suchergebnisliste übernommen.

Das wäre nicht schlimm, aber die Impressionen aus der SERP Einblendung und dem Google-for-Jobs-Ansicht werden gemeinsam reportet und dadurch diese beiden Zählweisen der Position vermischt. Das bedeutet, die Listing-Position ist bestenfalls als Tendenz zu betrachten.

Listing CTR:

Da die Impressionen nicht klar abgegrenzt sind, das Snippet eigentlich überhaupt nicht selbst beeinflusst wird und die Seite die nach dem “Klick” erreicht wird lediglich die Job-Detail-Ansicht von Google ist, auf der auch andere Anbieter mit dem selben Jobangebot mitspielen, ist die CTR eine wenig zielführende Information.

Detail Click:

Der Klick auf Job-Details ist der Einstieg eines Nutzers auf eine URL der Property (oder eine kanonische URL). Wenn ein Nutzer sich in der Job-Detail-Ansicht dafür entscheidet auf einen der angezeigten Anbieter zu Klicken und das Google Universum verlässt, wird das hier gezählt. Das ist die einzige Metrik in diesem Bereich, die verlässlich ist.

Detail Impression

Das sind die angezeigten Job-Detail-Ansichten. Dabei ist es für die Zählung der Detail-Impressionen nicht relevant, von wo der Nutzer kommt, sei es aus der SERP, der Google-for-Jobs-Übersicht oder über einen geteilten Link zu der Job-Detail-Seite. Wenn mehr als ein Anbieter auf dieser Job Detailseite angezeigt wird, wird die Impression bei allen Anbietern gezählt.

Detail Position:

Die Dokumentation sagt: “For a details view, the position is always 1.” In der Realität gibt es Seiten die bei den Job- beziehungsweise Event-Details eine Positionen ">1" angezeigt bekommen. Wo kommt das her?

Detail CTR:

Auf der gleichen Job-Detail-Seite können mehrere Anbieter auftauchen. Die CTR ist hier ein halbwegs brauchbares Maß dafür, wie sich die eigene Marke als Jobanbieter im Konkurrenzumfeld und ohne relevantes Snippet durchsetzen kann. Abgesehen davon ist sie nur von begrenztem Nutzen.

Insgesamt ist die Art und Weise, wie verschiedene Darstellungsweisen in einen Topf geworfen und verquirlt werden, nicht hilfreich. Diese Berichte erscheinen zunächst hilfreich, sind bei genauerer Betrachtung jedoch wertlos.

Wir hoffen, dass die Vermischung von verschiedenen Bedeutungen einzelner Werte nur auf diese Zahlen zutrifft, und die hier gezeigten Zahlen sauber von den anderen Bereichen des Leistungsberichts getrennt sind.

🤔 Für die meisten kaum relevant. Für die, die damit arbeiten müssen die Hölle 👿.

Feedback an Google:

  1. In der Darstellung in der Suche fehlen die Daten für die "normal" dargestellten Snippets, ohne irgendwelche Besonderheiten.
  2. In der Google Search Console tauchen "AMP non-rich results" im "Darstellung in der Suche"-Bericht auf. In der Dokumentation ist nicht erwähnt, wie dieser Punkt definiert ist.
  3. In der Google Search Console tauchen "rich results" im "Darstellung in der Suche"-Bericht auf. In der Dokumentation ist nicht klar, welche Snippet-Variationen hierrunter fallen und welche nicht.
  4. Die Vermischung von job/event-Detail und job/event-Listing Daten zwischen der Darstellung in den SERPS und den speziellen job/event Suche-Features sorgt dafür, dass die dargestellten Daten keine Möglichkeit geben, die tatsächliche Leistung der eigenen Inhalte zu bewerten. Für die Auswertung der Daten muss bitte zumindest eine klare Unterteilung zwischen Klicks, die einen Einstieg auf der eigenen Domain bedeuten und Klicks, die lediglich eine Navigation innerhalb der Suche bedeuten, hergestellt werden. Außerdem müssen bitte Klicks/Impressionen in der SERP-Einblendung gegenüber den Klicks/Impressionen innerhalb des eigentlichen job/event Suche-Features klar getrennt werden.

Canonical Consolidation

Kennen Sie das? Ihre Google Search Console Property für die ".de" Domain bekommt massiv Traffic aus Österreich, während in der Property für ".at" ein Knäuel Tumbleweed vom Wind durchs Bild geweht wird.
Seit dem 10. April 2019 zeigt Google uns Klicks, Impressionen, Positionen und CTRs im Leistungsbericht auf von Google gewählten kanonischen URL zusammengefasst an, unabhängig davon, ob es die URL war die tatsächlich angezeigt wurde, oder eine der Kanonischen URLs.

Das ganze auch über GSC-Properties und sogar Domains hinweg. Das hat den Vorteil, dass Google AMP-Klicks einfach reporten kann. Das hat den Nachteil, das Google häufig Dinge zusammenfasst, die wir aus gutem Grund nicht mit einem Canonical als Kanonisch definiert haben, oder die wir auf eine andere URL zusammenfassen wollen.

Für die Auswertung ist das häufig ärgerlich. Zum Beispiel wenn man versucht, den Traffic einer Webseite, die mit Länderspezifischen URLs im DACH-Raum (oder anderen Ländern mit gleicher Sprache) aktiv ist, sauber auszuwerten. Bei funktionierenden Hreflang wird in jedem Land von Google zwar die korrekte URL ausgespielt, in der GSC werden die Klicks und Impressionen der AT und CH Properties aber leider allzu häufig der DE-Property zugeschlagen, da dies jeweils die von Google gewählte kanonische URL ist.

Neben verschiedenen Länderversionen von Inhalten gibt es analoge Probleme auch bei mobilen Subdomains, http-Migrationen oder sporadisch auch bei AMP-Seiten.

Nicht immer sind es dabei unterschiedliche Properties, sondern es ist oft auch innerhalb einer Property ein Problem. Denn die Nutzer landen nach wie vor auf der von Google angezeigten URL und nicht auf der kanonischen URL. Um die tatsächliche Trafficverteilung zu schätzen, kann in den meisten Fällen ein Abgleich zwischen der GSC und der Webanalyse helfen. Also der Vergleich von Klicks der GSC und Einstiege in der Webanalyse auf den jeweiligen Landingpages (Natürlich gefiltert auf organische Einstiege von Google).

Da Google sich hier nicht an die Grenzen von Domains hält sondern auch Traffic munter völlig anderen Domains zuschlägt, ist es in der Theorie auch möglich, dass nicht nur eigene URLs als Kanonisch zusammengefasst werden, sodass eine mögliche URL eines böswilligen Scrapers von Google in den gleichen Topf geworfen wird. Das würde bedeuten, dass entweder die Klicks auf die eigenen URLs fehlen oder irreführend Klicks auf fremde Inhalte reportet werden können. So oder so wäre es fatal.

Wir wünschen uns, dass die Google Search Console uns wieder ermöglicht, die tatsächlich angezeigten URLs zu sehen. Es gibt einfach Situationen, in denen es auch heute noch mehrere ähnliche URLs für einen kanonischer Inhalt geben muss. Die Zusammenfassung als kanonisch kann dann sinnvoll sein (spätestens bei funktionierender hreflang-Auszeichnung ist das allerdings nicht mehr nachvollziehbar), aber das Zusammenfassen des Traffics ist es nicht.

Feedback an Google:

Die Zusammenfassung von URLs führt bei Mobilen Subdomains, Hreflang-Versionen für verschiedene Länder in einer Sprache und z.T. bei HTTP und HTTPS zu fehlerhaften Zuordnungen des Traffics, zum großen Teil über verschiedene Properties hinweg. Um in solchen Daten auszuwerten ist es notwendig, die tatsächlich angezeigten und geklickten URLs auswerten zu können.

Bitte schafft daher die Möglichkeit auf die tatsächlich angezeigten und geklickten URLs umzuschalten. Außerdem wäre es praktisch für jede URL zuordnen zu können, welche anderen URLs dieser von Google als kanonisch zugeordnet werden.

Bloom-Filter

In einer Episode der Google SEO Office Hours aus dem September 2023 gab Gary Illyes Auskunft über Googles Verwendung von Bloom-Filtern. (Mal wieder ohne die konkrete Frage wirklich zu beantworten. Aber das ist auch eine Kunstform, die Googles Search Relations Team nun einmal beherrschen muss.)

Was sind Bloom-Filter?

Bloom-Filter nutzen arkane Hash-Magie, die sich auch mir bislang entzogen hat (Frag einen Informatiker, wenn Du mehr wissen willst). Was ich verstanden habe und der für die Verwendung der GSC relevante Teil ist:

Aus den Strings in einem Datensatz und den Strings, die ich prüfen will, werden Hashes gebildet. Ein Beispiel für einen Datensatz sind alle anonymized Queries von Google. Ein Beispiel für Strings, die ich prüfen möchte, ist eine Liste von Keywords.

Je aggressiver das Hashen, desto schneller wird der Filter. Dabei kann ein Bloom-Filter keine falsch negativen Antworten liefern. Wenn also ein Keyword nicht zu den anonymized Queries gehört, dann filtert Google das Keyword auch nicht aus.

Bloom-Filter führen zu Overblocking

Umgekehrt kann es aber falsch positive Ergebnisse geben. Das bedeutet, Google springt bei Hashes auf Keywords an, obwohl diese gar nicht im Datensatz der anonymized Queries enthalten sind.

Je größer der Datensatz (und Googles Datensätze sind ziemlich groß), desto wahrscheinlicher werden falsch positive Abgleiche. Wenn Google also zum Beispiel anonymized Queries rausfiltert, und sicher gehen will, dass Keywords wirklich nicht in die Antwort kommen, dann fliegen auch einige Keywords mit raus, die eigentlich nicht zu filtern wären.

Bloom-Filter sind verlässlich

Ein weiterer Vorteil von Bloom-Filtern ist, dass sie stabil sind. Manche anderen Algorithmen erkaufen Geschwindigkeit mit zufälliger Ungenauigkeit. Ein Bloom-Filter wird (solange ich den Datensatz oder die Hash-Berechnung nicht ändere) immer das gleiche Ergebnis liefern. Nutzer werden also nicht durch leicht variierende Ergebnisse irritiert.

Sind darum meine Search-Console-Daten falsch?

Ja, aber Du kannst trotzdem wunderbar damit arbeiten. Minimale Abweichungen zur Realität gibt es immer. Das gibt es in jeder Datenbank. Man kann davon ausgehen, dass Google für Keywords mit hohem Suchvolumen genauer arbeitet und eine größere Menge falsch positive Suchbegriffe, wenn überhaupt, nur den Longtail betreffen. Da Du aber nicht auf jedes einzelne Keyword des Longtail optimierst, mach Dir darum keine Sorgen.

Unsere Wunschliste für die GSC… und noch ein paar Tipps für Euch

Insgesamt bedeutet das: Die Google Search Console lügt nicht, wirklich nicht. Aber sie ist an einigen Stellen leicht in die Irre führend. Wenn man weiß, woran man ist, kann man Interpretationsfehler vermeiden und da, wo die GSC allein nicht die Möglichkeit bietet, für vieles die Rohdaten, damit man selbst einen Workaround zusammenbasteln kann.

Grundsätzlich sind die Daten in der Google Search Console - wie eingangs bereits erwähnt - sehr hilfreich und wir möchten sie nicht missen. Dennoch sei allen, die sich damit beschäftigen, nochmal ans Herz gelegt:

  1. Augen auf bei der Analyse!
  2. Lest Euch die Dokus durch!
  3. Gebt Feedback!

Punkt 1 und 2 helfen Euch dabei, nicht in Fallen zu tappen und Euch am Ende Schlüsse zusammen zu reimen, die nicht korrekt sind.

Punkt 3 ist eine wertvolle Informationsquelle für unsere Freunde bei Google. Wir alle sollten sie in unserem eigenen Interesse dabei unterstützen, die GSC weiter zu verbessern und so noch wertvoller für alle Nutzenden zu machen.

Wir haben zu den meisten genannten Punkten schon unser Feedback an Google gegeben. Gebt gerne auch entsprechendes Feedback an Google: Je mehr Nutzer die Verbesserung fordern, desto schneller wird die Google Search Console noch besser werden.

Sicherlich gibt es auch weitere Aspekte, wo noch Luft nach oben ist. Wenn Euch also noch etwas in unserer Aufzählung fehlt: Her damit!

Diese Punkte haben sich hauptsächlich auf den Leistungsbericht bezogen. Es gibt aber auch andere Bereiche, wie zum Beispiel den vergleichsweise neuen Geschwindigkeits Report, den wir auch schon genauer unter die Lupe genommen haben. Wir werden in Zukunft auch zu den weiteren Abschnitten der GSC unsere Meinung und unsere Feedback-Wünsche für Euch runterschreiben.

Die Slides zu Behrends Vortrag

Behrend machen diese Probleme übrigens so wütend, dass er sogar einen Vortrag gebaut hat, um noch mehr von Euch davon zu überzeugen, Google Feedback zu geben.

Hier sind die Slides zu seinem Vortrag via Slideshare:

--

Hat Dir der Artikel gefallen?

Neue Artikel, Updates zu unseren Artikeln und Artikel von anderen Stellen wir regelmäßig unserem Newsletter.

Beispielausgaben und Anmeldung findest Du unter Wingmen-Newsletter