Startseite » Blog » Digital Analytics

12.01.2017

Zugegeben... zu diesem Thema scheint es schon reichlich Beiträge zu geben. Implementierung mit Tag Manager, ohne Tag Manager... warum also noch eine? Antwort: Weil viele davon nicht mehr aktuell sind und vor allem i. d. R. Events statt Pageviews verwenden, was ich nicht für die ideale Lösung halte.

Aber von vorn: Zu wissen, welche fehlerhaften URLs auf der eigenen Website wirklich aufgerufen werden, woher der fehlerhafte Verweis kam und was man ggf. reparieren sollte, ist praktisch für jeden Webmaster eine interessante Information. Daher befassen sich Websitebetreiber auch gern mit Quellen wie den Fehlern in der Google Search Console oder Berichten externer Crawler und / oder untersuchen die eigene Site regelmäßig auf Fehler in der internen Verlinkung mit Tools wie dem Screaming Frog SEO Spider. Wer sich gern ein vollständiges Bild macht, zieht zudem die Logfiles des Servers zu Rate und deckt so regelmäßig fehlgeschlagene Anfragen auf, die aus unterschiedlichsten Grunden stattfinden und nicht nur reale Besucher, sondern auch alle herzlosen Bots beinhalten.

Warum überhaupt Fehler in Analytics messen?

Während die eine Methode (Crawling) nur auf interne Links schaut und Fehlerberichte aus der Google Search Console sowie vieler SEO-Tools zwar auch veraltete externe Links aufdecken, ist dabei i. d. R. eine ganze Menge Schrott. Sei es, dass Google sich mal wieder (schlecht) ungültige URLs aus Scripts zusammengereimt hat oder die angegebene Quelle des falschen Verweises vollkommen irrelevant, veraltet oder bereits "verstorben" ist (Scraper kommen und gehen...). Daher liefert die Analyse "echter aufgerufener" falscher URLs einen guten Ansatzpunkt, wenn man sich primär um die ferhlerfreie Nutzung durch Besucher statt Bots konzentrieren will... und auch nur auf die Fehler bei Inhalten, die auch wirklich besucht werden.

Verschiedene Methoden

Grundsätzlich ist - mit etwas Glück - in jeder Datenansicht auch ohne Anpassung etwas über fehlerhafte URLs herauszufinden. Je nachdem also, ob man Einfluss auf die Implementierung hat oder nicht, stellen sich daher drei Möglichkeiten:

  1. Ohne Anpassung der Implementierung
  2. Anpassung bei direkter Implementierung
  3. Fehlertracking bei Verwendung des Tag Managers

Option 1: Analyse ohne Anpassung der Implementierung

Ist der Trackingcode auf allen Seiten eingebunden und betrifft dies auch die Fehlerseite, landen alle Aufrufe von falschen URLs im gleichen Bericht wie korrekte Seiten und sind auf den ersten Blick nicht davon zu unterscheiden. Dennoch haben bei den meisten Websites - sei es über eine "handverlesene" explizite Fehlerseite oder gesteuert vom CMS - Fehlerseiten eine Gemeinsamkeit - nämlich den Titel. Eine korrekte URL wie https://www.gandke.de/kontakt.html landet daher als /kontakt.html ebenso im Seitenbericht wie der Aufruf einer falschen URL wie https://www.gandke.de/kontak.html (als /kontak.html) und ist je nach Übersichtlichkeit des Berichts bestenfalls zufällig zu finden. Aber während im ersten Fall der korrekte Titel zu sehen ist, beginnt dieser im zweiten Fall mit "Fehler 404: Seite nicht gefunden". Wählt man den Seitentitel daher z. B. im Bericht "Alle Seiten" als primäre Dimension in Analytics aus, kann man als sekundäre Dimension die "Seite" einblenden, um die fehlerhaften URLs zu sehen.

Fehlerseitenaufrufe in Google Analytics

Ebenso kann die sekundäre Dimension genutzt werden, um den Referrer darzustellen, was genutzt werden kann, um die Fehlerquelle zu finden und den falschen Link ggf. zu korrigieren - oder bei externen Links mit entsprechend vielen Aufrufen über eine falsche URL diese zur Not auch (freilich per 301 ;)) auf eine passende Seite weiterleiten, um den eintreffenden Besuchern die Ansicht einer Fehlerseite zu ersparen. Diese Methode hat zwar den Vorteil, dass man i. d. R. gar nichts tun muss - dafür ist die Auswertung aber auch eher mühselig.

Option 2: Erweiterung bei direkter Implementierung

Ist Analytics nicht mit dem Tag Manager implementiert, sondern direkt im Template des CMS oder statischen Seiten implementiert, kann man sich die Arbeit durch Anpassung des Templates oder Inhalts der Fehlerseite einfacher machen, indem die Informationen des Seitenaufrufs angereichert werden. Andere Lösungen verzichten auch auf die Anpassung des Seitenaufrufs und lösen statt dessen ein Event aus. Ich finde es "richtiger", wenn statt eines falschen Seitenaufrufs und eines Events nur ein Seitenaufruf generiert wird, der wie im ersten verlinkten Beispiel dann einen eigenen Dateinamen oder Pfad bekommt und die falsche URL sowie die Quelle des Verweises als Parameter zur Info angefügt werden... aber das ist vermutlich Geschmackssache. Dabei muss der Trackingcode auf der Fehlerseite lediglich eine selbst definierte URL als weiteren Parameter übertragen.

Anstelle von ga("send", "pageview") steht dann dort etwas wie

ga("send", "pageview", "/seite-nicht-gefunden.html?page=" + document.location.pathname + document.location.search + "&from=" + document.referrer)

Der Vorteil dieser Lösung ist, dass man in allen Seitenberichten einfach per Filter auf "seite-nicht-gefunden" eine Übersicht erhält, aus der alle falschen URLs - und direkt auch deren Verweisquellen - abgelesen werden können.

Fehlerseitenaufrufe im Seitenbericht

Auch für diese Methode lassen sich sinnvolle Benachrichtigungen einrichten (siehe unten), um korrigierbare Fehler per Mail gemeldet zu bekommen.

Option 3: Umsetzung via Tag Manager

Unter der o. a. Voraussetzung eines eindeutigen Titels bei Fehlerseiten ist das separate Fehlertracking in Analytics leicht umzusetzen, wenn man mit dem Tag Manager arbeitet. Es muss nur eine Variable für den Seitentitel angelegt und ein Trigger erzeugt werden, der beim passenden Titel genutzt werden kann, um eine Messung vorzunehmen. Eine prima Anleitung dazu findet sich z. B. bei Christian Ebernickel, wobei allerdings auch hier auf ein Event statt eines Pageviews gesetzt wird. Auch landen die falschen URLs so nach wie vor verstreut in den Berichten und müssten per Seitentitel identifiziert werden, wenn man diese dort gesondert betrachten, filtern und / oder segemtieren möchte.

Sollen statt dessen wie in der direkt implementierten Variante angepasste Seitenaufrufe erzeugt werden, kann man z. B. eine zusätzliche Variable dazu nutzen, die im "Fehlerseitenfall" nicht nur die normale URL beinhaltet und diese als "page" im Universal-Pageview-Tag nutzen, welcher auch für das Tracking aller Seiten genutzt wird. Einfacher erscheint es aber, den neuen Trigger als ausschließenden Trigger für den "normalen Pageview" zu nutzen und damit ein neues Tag anzusteuern, welches nur für Fehlerseitenaufrufe genutzt wird.

Wer keine Lust hat, dem Link zur obigen Anleitung zu folgen, findet hier in aller Kürze auch die ersten beiden Schritte zur Implementierung (bis Schritt 3 bleibt die verlinkte Anleitung auf dem gleichen Weg):

Variable für Seitentitel anlegen

Warum auch immer: Der GTM bietet keine vorgefertigte Variable für den Seitentitel. Diese muss daher manuell erzeugt werden, als Typ dient eine "Java Script Variable" und als Inhalt "document.title".

Seitentitel als Variable im GTM

Trigger für Fehlerseiten

Mit der Variable kann nun ein neuer Trigger erzeugt werden, der dann aktiv wird, wenn eine Fehlerseite aufgerufen wird. Dazu wird der Titel der Fehlerseite in der Bedingung verglichen.

Trigger für Fehlerseiten im GTM

Pageview Tag verwenden

Abweichend von der o. a. Anleitung sieht es dann im nächsten Schritt (dort Schritt 3) passend zum Aufbau der Fehler-URLs aus dem obigen Beispiel so aus:

Google Analytics Tag zur Fehlerseitenmessung

Dazu kopiert man das "normale" Pageview-Tag, trägt als zusätzliches Feld den Wert

/seite-nicht-gefunden.html?page={{Page URL}}&from={{Referrer}}

ein und nutzt den neu angelegten Trigger für Fehlerseiten als Auslöser. In Berichten lassen sich dann Fehlerseitenaufrufe einfach identifizieren und weisen direkt die falsche URL und deren Verweisquelle auf. Die erste URL in diesem Beispiel zeigt so direkt an, an welcher Stelle ein falscher Link zu korrigieren ist.

Damit nur noch dieses Tag feuert, wenn eine Fehlerseite aufgerufen wird, sollte der neue Trigger zudem aus blockierender Trigger im "normalen Seitenaufruf Analytics-Tag" zugeordnet werden.

Alert einrichten

Für jede der drei Varianten - unverändert, direkt implementiert oder per Tag Manager - kann und sollte man sich Benachrichtigungen senden lassen, wenn bestimmte Schwellwerte erreicht wurden. Dazu sind in der Verwaltung von Analytics schnell passende Alerts eingerichtet, mit denen man sich bei Häufung von Fehlerseiten - oder ausschließlich dem Auftreten von "behandelbaren" Fehlern - informieren lassen kann. "Behandelbar" meint dabei, dass die Verweisquelle bekannt ist, so dass man einen internen Link korrigieren oder einen externen Link weiterleiten kann. Die Alerts lassen sich bei der gewünschten Datenansicht unter "Verwalten -> Benutzerdefinierte Benachrichtigungen" definieren. Dabei kann man dann entweder alle Aufrufe von Fehlerseiten ab einem bestimmten Schwellwert als Auslöser nehmen oder nur die Aufrufe betrachten, bei denen im Parameter "from" (ausgehend von den obigen Beispielen) wirklich ein Referrer übergeben wurde. Der entsprechende Alarm würde dann so aussehen:

Analytics Alert bei 404-Fehlerseiten

Das Muster ^(/seite-nicht-gefunden)(.*)([^(from=)]$) muss dabei ggf. angepasst werden, wenn man eine andere Struktur oder Seite gewählt hat. Auf diese Weise ist man schnell informiert, wenn auf der eigenen Site Fehlerseiten aufgerufen werden - und kann dann entsprechend reagieren.



Warum mit uns?

Langjährige Erfahrung
im Onlinemarketing:
Suchmaschinen-Marketing
erfolgreich seit 1996

Angebot anfordern

Stolzer Partner ohne Logo
Warum? | Google Partner Profil

Alle Kontenmanager unserer Google AdWords Agentur sind qualifizierte und durch Google zertifizierte AdWords Experten.

Faire Festpreise
jederzeit kündbar
seriöse Optimierung.