Die Google-Suchleistung einer Eventseite mit Search Console und GA4 prüfen

Frage und Seitenumfang festlegen

Prüfblatt für die Eventseitensuche herunterladen (englisches Markdown)

Beginne mit einer konkreten Frage: Finden Gäste Termin, Ort, Programm oder Ticketinformationen der aktuellen Ausgabe? Lege die veröffentlichte Haupt-URL fest und trenne Standort-, Programm- und Archivseiten mit anderen Aufgaben. Notiere Veröffentlichung, Verkaufsstart und größere Kampagnen vor dem Periodenvergleich. Suchanfragen zur Vorjahresausgabe gehören nicht stillschweigend zur aktuellen. Das Arbeitsblatt bietet eine Zeile je URL und ein Feld für Verantwortliche. Entscheide, ob du Auffindbarkeit, Ankunft oder eine spätere Aktion untersuchst. Eine Impression ist eine Darstellung in Suchergebnissen, kein Seitenaufruf. Ein Suchklick ist keine Anmeldung, eine Sitzung nicht zwangsläufig eine Person und eine Bestellung stammt aus dem Ticketsystem. Schreibe diese Grenzen in den Bericht.[1]

Zugriff und Erfassung prüfen

Prüfe, ob die Search-Console-Property die öffentliche URL enthält und du Leserechte besitzt. Search Console und GA4-Tagging sind verschiedene Einrichtungen. Eine Domain-Property kann mehrere Hosts umfassen, eine URL-Präfix-Property nur einen Teil. Suche in GA4 denselben Host und Pfad im Landingpage-Bericht. Wird das Event anderswo gehostet, kläre zuerst, ob dieser Betreiber Daten bereitstellt; dein eigenes GA4 erfasst dessen Seite nicht automatisch. Öffne die veröffentlichte Seite auf Desktop und Mobilgerät und prüfe kanonisches Ziel, Titel, Termin, Kerndaten und Ticketlink. Weiterleitungen, Sprachvarianten und Archivseiten können einen plausiblen Filter irreführend machen. Notiere Property und URL-Regel, ohne private Kennungen öffentlich zu teilen.[1][2]

Eventseite in Search Console auswerten

Öffne in Search Console den Leistungsbericht für die Google-Suche, wähle abgeschlossene Tage und filtere die Event-URL. Lies Klicks, Impressionen und Klickrate mit gleichbleibenden Filtern für Suchtyp, Land und Gerät. Vergleiche gleich lange Zeiträume und vermerke Programm- oder Verkaufsankündigungen als mögliche Nachfrageänderung. Kontrolliere die Tabelle Seiten: Ist es wirklich die erwartete URL? Daten können der kanonischen URL zugerechnet werden, wodurch ein Filter auf eine Variante leer wirkt. Summen auf Property- und Seitenebene werden verschieden aggregiert, neue Daten können vorläufig sein. Speichere Datum, Filter und URL statt nur einen Kennzahlen-Screenshot. Bei fehlenden Daten prüfe Property, Zeitraum, URL-Filter und Indexierung getrennt.[2][3]

Suchanfragen lesen

Lass den Seitenfilter aktiv und wechsle zu Suchanfragen. Ordne Formulierungen nach Gästeaufgabe: Datum und Ort, Programm, Vortragende, Eintritt oder eine andere Bedeutung des Eventnamens. Beurteile Veränderungen bei Impressionen und Klicks, nicht nur eine durchschnittliche Position an einem Tag. Viele Impressionen und wenige Klicks sind ein Anlass zu prüfen, ob sichtbarer Titel und Seite die Frage beantworten; sie beweisen keinen Gewinn durch Umschreiben. Führt eine Anfrage auf eine andere Seite, könnte ein klarer Querverweis helfen. Search Console zeigt nicht jede einzelne Suchanfrage; eine fehlende Zeile bedeutet nicht null Nachfrage. Notiere drei datenbasierte Inhaltsfragen und die mögliche Antwortstelle. Lass Eventfakten vom Programm- oder Standortverantwortlichen bestätigen.[2]

Ankünfte und Aktionen in GA4 prüfen

Nutze in GA4 den Landingpage-Bericht für Sitzungen, die auf der Eventseite begannen. Ergänze oder filtere Sitzungsquelle/-medium auf Google organisch, damit E-Mail, Anzeigen und direkte Zugriffe getrennt bleiben. Prüfe Pfad und Query-Variante: Ein Gast kann erst auf einer anderen Seite landen und später zum Event wechseln. Die Landingpage ist sitzungsbezogen und zählt nicht einfach alle Seitenansichten. Bei gemessenen Aktionen verwende die tatsächlichen Definitionen, etwa Ticketlink-Klick, Anmeldebeginn oder eine im eigenen System bestätigte Aktion. Der Klick zum Checkout ist nur eine Übergabe; Bestellungen prüfst du beim Anbieter. Halte GA4-Zeitraum und Filter neben denen der Search Console fest. GA4 liefert keine individuelle Zuordnung einer Suchanfrage zu jeder Sitzung.[1][4]

Eine gemeinsame Ansicht bei Bedarf bauen

Für wöchentliche Teamsitzungen kann eine parallele Ansicht helfen. Googles Looker-Studio-Beispiel verbindet Search Console und GA4 als getrennte Datenquellen und verwendet URL Impression für Seitenebene. Verbinde nur freigegebene Properties, kennzeichne jede Datenquelle und gleiche Datum, Land und Gerät auf beiden Seiten ab. Für organische Google-Suche filtere die GA4-Seite auf Sitzungsquelle `google` und Medium `organic`. Zeige Suchklicks und Sitzungen in getrennten Reihen; addiere sie nicht und teile sie nicht als vermeintliche Conversion-Rate. Verknüpfe auch keine einzelnen Anfragen mit GA4-Ereignissen wie bei einer personenbezogenen Verbindung. Bei nur einem Event können zwei beschriftete Tabellen-Spalten einfacher sein. Das Arbeitsblatt hält abweichende Filter explizit fest.[1][5]

Muster vor Änderungen deuten

Deute ein Muster, bevor du Text änderst. Mehr Impressionen bei konstanten Klicks können neue Anfragen, veränderte Nachfrage oder eine nicht passende Ergebnisdarstellung bedeuten; lies konkrete Anfragen und Seiten. Mehr Klicks ohne mehr Sitzungen können an der Messung liegen. Mehr organische Sitzungen ohne Ticketübergaben können Gäste mit Anfahrtsfragen, eine fehlende Klickmessung oder ein ungeeignetes Angebot bedeuten; prüfe Seite und Bestellungen gesondert. Presse, Terminankündigung oder eine andere Ausgabe können einen Sprung erklären. Segmentiere nach Land und Gerät nur, wenn die Stichprobe sinnvoll bleibt. Schreibe zu jedem überraschenden Verlauf eine normale und eine messtechnische Erklärung. Trenne beobachtete Werte, Vermutungen und bestätigte Korrekturen.[1][2]

Abweichungen zwischen Klicks und Sitzungen prüfen

Erwarte keine identischen Klick- und Sitzungszahlen. Der Klick entsteht im Google-Ergebnis; eine GA4-Sitzung hängt von Tag und Erfassungsbedingungen ab. Google nennt unter anderem Einwilligungsentscheidungen, fehlende Tags, Zeitzonen und kanonische URLs als Gründe. Search Console kann der kanonischen Adresse zuschreiben, während GA4 den besuchten Pfad erfasst. Gleiche Zeitraum, Gerät, Land und Seitenumfang ab; prüfe dann Tag und Weiterleitungen der getesteten Seite. Vermerke datenschutzbedingte Grenzen, ohne die Entscheidung eines Besuchers zu umgehen. Eine große ungeklärte Lücke gehört zur Analyseverantwortlichen Person und ist kein Beweis, dass Gäste die Seite verlassen haben. Halte Unsicherheit fest.[1][3]

Ein fiktiver Vergleich

Angenommen, die Eventseite hat vor einer Standortaktualisierung 800 Impressionen und 64 Klicks, danach 1100 Impressionen und 70 Klicks. GA4 beobachtet 52 beziehungsweise 59 organische Google-Landingsitzungen. Diese Zahlen sind ein Übungsbeispiel, keine Richtwerte. Gleiche zuerst URL, Suchtyp, Land, Gerät und abgeschlossene Tage ab. Mehr Impressionen beweisen nicht, dass die Aktualisierung die Nachfrage verursacht hat. Der Abstand von 70 Klicks zu 59 Sitzungen sind auch nicht elf verlorene Besucher: Die Systeme zählen Unterschiedliches. Lies Standortanfragen, prüfe die freigegebene Adresse und trenne Suchen zur Vorjahresausgabe. Meldet der Ticketanbieter 18 Bestellungen, zeige sie separat; die Berichte identifizieren keine Käufer aus Suchklicks. Eine vernünftige Maßnahme ist eine geprüfte Adressklarstellung mit späterer Kontrolle ohne Kausalbehauptung.[1][4]

Dashboard vor Freigabe prüfen

Verfolge eine Event-URL durch die gesamte Ansicht. Der Search-Console-Teil muss URL Impression, die richtige Property und den passenden Seitenfilter verwenden. Der GA4-Teil braucht die getaggte Website, Landingpage-Dimension und `google / organic` für Sitzungen; ein allgemeiner Organic-Kanal kann andere Suchmaschinen einschließen. Vergleiche Zeitraum, Länder und Geräte beider Seiten und kennzeichne bewusste Unterschiede. Markiere vorläufige Daten und den letzten verfügbaren Tag. Ändere einen Filter probeweise und prüfe die betroffenen Diagramme. Stehen Anfragen neben GA4-Aktionen, trenne sie sichtbar, damit keine personenbezogene Verbindung suggeriert wird. Lass eine zweite Person einen Wert in der Quellanwendung reproduzieren. Notiere Version, Redaktion und Veröffentlichungszeit. Eine überprüfbare Tabelle ist besser als ein hübsches Dashboard mit unklaren Filtern.[1][5]

Aus Daten eine redaktionelle Maßnahme ableiten

Ändere nur Inhalte, die eine belegte Gästefrage beantworten, und benenne einen Verantwortlichen. Suchen Menschen nach Event und Parken, verlinke geprüfte Ankunftsinformationen von der relevanten Seite. Ist die bestätigte Startzeit versteckt, gib ihr einen gut lesbaren Platz. Taucht eine alte Ausgabe auf, prüfe Datumsangaben, Links und Kennzeichnungen beider Seiten vor URL-Entscheidungen; der separate Leitfaden zu vergangenen Eventseiten behandelt diese Fälle. Verändere bestätigte Fakten nicht wegen einer Kennzahl. Notiere Hypothese, Abschnitt, Faktenquelle und Veröffentlichungszeit. Prüfe Mobilansicht, Tastaturbedienung und Ticketziel. Ein Änderungsprotokoll hilft, Maßnahmen von gleichzeitigen Kampagnen zu trennen.[1]

Prüfung dokumentieren und wiederholen

Wiederhole die Prüfung nach Start, wichtigen Änderungen, Verkaufsbeginn und Veranstaltung. Speichere Filter, Zeiträume und Definitionen beider Systeme; ein einzelner Screenshot reicht nicht für Vergleiche. Verwende ähnlich lange Fenster und erwähne Nachfrageschwankungen sowie vorläufige Daten. Bestimme Zuständige für Seitenfakten, Analysezugriff, Bestellzahlen und Bericht. Teile nur passende aggregierte Ergebnisse. Ist das Event auf Boletolibre.com gelistet, halte das Ticketziel klar, ohne Zugriff auf Search Console oder GA4 dieser getrennt gehosteten Seite anzunehmen. Schließe mit einer bestätigten Inhaltsänderung, einem Messauftrag oder bewusst keiner Änderung bei zu wenig Evidenz. Das Arbeitsblatt hat Felder für Unsicherheit und Folgetermin.[2][3]