Sofort erfahren, wenn ein Marketing-Tag verschwindet (GA4, GTM, Meta Pixel)

Ein Tool für Marketing-Tag-Monitoring prüft deine Seiten nach Zeitplan und meldet dir, wenn ein Tag wie GA4, Google Tag Manager oder das Meta Pixel nicht mehr da ist oder nicht mehr dem entspricht, was vorher da war. Tracking geht selten mit einer Fehlermeldung kaputt. Ein Deploy, ein Theme-Update oder ein neues Cookie-Banner entfernt das Snippet, und das erste Anzeichen ist Tage später eine flache Linie in GA4 oder eine Kampagne, die null Conversions meldet.

Fehlende Daten lassen sich nicht nachträglich auffüllen. Wenn GA4 eine Woche Sitzungen verpasst, bleibt diese Woche in jedem Bericht leer, und jede Werbekampagne, die auf Conversions optimiert, hat eine Woche lang auf nichts optimiert.

Woran du GA4, GTM und Meta Pixel im Quelltext erkennst

Jedes gängige Tag hinterlässt erkennbare Spuren im HTML. Darauf stützen sich sowohl die manuelle als auch die automatische Prüfung.

Tag	Worauf du im Quelltext achtest	ID-Format
GA4 (gtag.js)	Ein Skript von googletagmanager.com/gtag/js?id= und ein Aufruf gtag('config', ...)	G- gefolgt von Buchstaben und Ziffern
Google Tag Manager	Ein Skript, das googletagmanager.com/gtm.js?id= lädt, plus ein <noscript>-iframe direkt nach <body>	GTM- gefolgt von Buchstaben und Ziffern
Meta Pixel	connect.facebook.net/en_US/fbevents.js und ein Aufruf fbq('init', ...)	Eine lange numerische Pixel-ID

Wird GA4 über GTM ausgespielt, steht keine G--ID im Quelltext, sondern nur der Container. Das ist normal, und es ist einer der Wege, wie eine Seite vollständig getaggt aussehen kann, während bei GA4 nichts ankommt: Die GA4-Konfiguration steckt im Container und nicht auf der Seite. Eine Schritt-für-Schritt-Anleitung für die manuelle Prüfung findest du unter so prüfst du, ob GA4 installiert ist.

Wie Marketing-Tags verschwinden

Auf WordPress wird GA4 oft über ein Plugin wie Site Kit eingebunden oder direkt in die header.php des Themes kopiert. Wer das Plugin deaktiviert, während er etwas anderes debuggt, oder das Theme wechselt, nimmt das Tag mit. Auf Shopify gehört Code, der in theme.liquid eingefügt wurde, zu diesem Theme. Wird ein neues Theme veröffentlicht, fehlt er, sofern ihn niemand rüberkopiert. Pixel, die über die App Facebook & Instagram oder den Bereich Kundenereignisse eingerichtet wurden, überstehen einen Theme-Wechsel dagegen. Individuell entwickelte Websites verlieren Tags bei Rebuilds, Rollbacks und Merges, die einen früheren Hotfix rückgängig machen, und bei Migrationen landet manchmal die Container-ID aus dem Staging in der Produktion.

Eine geänderte ID ist der am schwersten zu erkennende Fall. Das Snippet ist vorhanden und Daten fließen, aber in eine Test-Property oder in das Konto eines anderen Kunden, weil ein Template aus einem anderen Projekt kopiert wurde. Es fehlt nichts, also sieht auch nichts kaputt aus.

Die zweite große Ursache ist Consent. Mit einer Consent-Management-Plattform (CMP) wie Cookiebot, OneTrust oder iubenda werden Tags blockiert, oder sie laufen im Google Consent Mode mit analytics_storage und ad_storage auf denied, bis der Besucher zustimmt. Wird die CMP ausgetauscht oder ihre Konfiguration geändert, senden Tags, die noch im HTML stehen, womöglich keine Daten mehr. Das Gegenteil kommt auch vor: Tags feuern vor der Einwilligung. Das ist dann ein Compliance-Problem und kein Datenproblem.

Tags von Hand prüfen, und wo das an Grenzen stößt

Für eine einzelne Website sind die Werkzeuge kostenlos. Der Vorschaumodus von GTM (Tag Assistant) zeigt, welche Tags auf jeder Seite feuern, DebugView in GA4 zeigt eingehende Events, und die Chrome-Erweiterung Meta Pixel Helper listet Pixel-Events auf. Der Network-Tab der DevTools, gefiltert nach collect oder facebook, funktioniert in jedem Browser.

Einmal ist das in Ordnung. Bei zwanzig Kunden-Websites bricht es zusammen. Du prüfst die Startseite, verschwunden ist das Tag aber im Produkt-Template. Du prüfst am Montag, kaputt ging es am Dienstag, und repariert hat es jemand am Freitag, nachdem die Kampagne ihr Budget verbraucht hatte. Es ist dasselbe Muster wie bei jeder anderen stillen SEO-Änderung: Ein Prozess, der davon abhängt, dass jemand ans Nachschauen denkt, übersieht irgendwann etwas.

Wenn ein Tag-Alert kommt

1. Klär den Umfang. Fehlt das Tag in einem Template, liegt es an diesem Template. Fehlt es auf allen URLs, deutet das auf das globale Header-Include, das Plugin oder das Snippet des GTM-Containers.
2. Vergleich das Datum mit dem letzten Release, der letzten Theme-Veröffentlichung oder dem letzten Plugin-Update. Oft ist die Sache damit schon geklärt.
3. Ist der Container noch auf der Seite, öffne den Versionsverlauf in GTM. Ein Tag, das beim Debuggen pausiert und dann versehentlich veröffentlicht wurde, taucht dort auf. Danach prüfst du die Einstellungen der CMP.
4. Markiere die betroffenen Tage im Kundenreporting und betrachte Kampagnendaten aus diesem Zeitraum mit Vorsicht.
5. Verschieb das Snippet an eine Stelle, die ein Theme-Update nicht erreicht, etwa in ein Child-Theme, ein Plugin oder die native Integration der Plattform.

Tag-Checks in Deltio

Deltio prüft die überwachten Seiten auf GA4, Google Tag Manager und das Meta Pixel und vergleicht jeden täglichen Check mit dem vorherigen. Ein verschwundenes oder geändertes Tag wird dir also per Slack oder E-Mail für die betreffende Website gemeldet. Deltio beobachtet außerdem das Cookie-Banner, sodass eine CMP, die verschwindet oder ausgetauscht wird, direkt neben der Tag-Änderung auftaucht, die sie vermutlich verursacht hat. Was Deltio nicht sehen kann, ist, ob ein im GTM-Container konfiguriertes Tag veröffentlicht ist und feuert. Dafür bleibt der Vorschaumodus das richtige Werkzeug.

Diese Checks laufen neben den SEO-Checks, die unter SEO-Änderungsalerts beschrieben sind. So überwachen Agenturen Kunden-Websites auf Änderungen, ohne jeden Montag dreißig Tabs zu öffnen. Jeden Plan kannst du 14 Tage kostenlos testen.