Das Wichtigste vorweg
Seit dem 8. Oktober 2026 wartet der Google Tag Manager nicht mehr auf gtag('config')-Befehle, und jeder dieser Befehle erscheint als eigenes Ereignis „gtag.config“ im dataLayer [1]. Tags mit einem Platzhalter-Trigger, der auf alle Ereignisse reagiert, können dadurch zusätzlich auslösen [1]. Wer den Tag-Manager-Code mit losen gtag('config')-Zeilen kombiniert, nutzt laut Google eine nicht unterstützte Einbindung und muss umstellen [2].
01 / Die Änderung
Was Google am 8. Oktober geändert hat.
Google hat in den Release Notes des Tag Managers einen kurzen Eintrag mit dem Titel „Standardizing gtag('config') command behavior for Google Tag Manager“ veröffentlicht [1]. Der Kern laut Google: Alle Container-Snippets des Tag Managers (gtm.js) starten jetzt beim Laden des Containers, unabhängig von gtag('config')-Befehlen [1].
Zur Einordnung: Auf vielen Websites stecken zwei verschiedene Google-Codes. Der Tag-Manager-Code lädt gtm.js und hat eine ID, die mit GTM- beginnt. Der Google-Tag lädt gtag.js und nutzt IDs wie G- für Google Analytics oder AW- für Google Ads [1]. Bisher konnte ein Tag-Manager-Container einen gtag('config')-Befehl erkennen, der irgendwo anders auf der Seite stand, und darauf warten [1]. Diese Wartefunktion ist weg.
Die zweite Folge betrifft mehr Websites: Config-Befehle tauchen jetzt als sichtbares Ereignis „gtag.config“ im dataLayer auf. Google schreibt selbst, dass Tags mit Platzhalter-Triggern für benutzerdefinierte Ereignisse dadurch auslösen können [1].
Die Änderung kommt nicht überraschend. Google hat im Mai angekündigt, Tag Manager und Google-Tag zusammenzuführen; neue Code-Snippets sollen dabei keinen gtag('config')-Befehl mehr enthalten [4]. Was das für deinen Container bedeutet, steht in Google-Tag wird zum Container.
02 / Doppelte Auslösung
Warum Platzhalter-Trigger jetzt öfter feuern.
Ein Platzhalter-Trigger ist ein Trigger vom Typ „Benutzerdefiniertes Ereignis“ mit dem Ereignisnamen „.*“ und aktivierter Regex-Prüfung. Er reagiert auf jedes Ereignis im dataLayer. Solche Trigger stecken oft in älteren Containern, in Debug-Setups oder in Tags, die jedes Ereignis an ein anderes Tool weiterreichen [3].
Seit dem 8. Oktober kommt pro gtag('config')-Befehl ein Ereignis dazu. Ein Tag an einem solchen Trigger löst also pro Config-Befehl einmal mehr aus [3]. Steht im Quelltext je ein Config-Befehl für Google Analytics und Google Ads, sind es zwei zusätzliche Auslösungen pro Seitenaufruf (Einschätzung, abgeleitet aus [1] und [3]).
Kritisch wird das, wenn an so einem Trigger ein Conversion- oder Remarketing-Tag hängt. Dann zählen Google Ads oder andere Werbekonten mehr Conversions, als es gab, und die automatische Gebotsstrategie arbeitet mit falschen Zahlen [3]. Die Analyse-Seite Notice Me Senpai erwartet, dass sich das binnen weniger Tage in den Geboten zeigt [3].
03 / Nicht unterstützt
Welche Einbindung Google nicht mehr unterstützt.
Google beschreibt auf einer eigenen Hilfeseite, welche Einbindung problematisch ist: der Tag-Manager-Code (gtm.js) plus ein separater Befehl gtag('config', 'G-…') oder gtag('config', 'AW-…') für eine Nicht-GTM-ID [2]. Das ist laut Google nicht unterstützt, und bei solchen Websites kann sich das Verhalten der Tags unerwartet ändern [2]. Inhaber betroffener Container hat Google per E-Mail informiert [2].
Google nennt zwei Wege heraus [2]:
- Nur Google-Tag: den Tag-Manager-Code und die losen Config-Zeilen entfernen und stattdessen das vollständige gtag.js-Snippet direkt nach dem öffnenden head-Tag auf jeder Seite einsetzen.
- Tag Manager behalten: Wenn du den Tag Manager auch für andere Tags nutzt, bleibt der gtm.js-Code mit deiner GTM-ID auf der Seite. Den Google-Tag richtest du dann im Container ein statt im Seitenquelltext.
Für die meisten kleinen Firmen, die ohnehin mit dem Tag Manager arbeiten, ist der zweite Weg der saubere (Einschätzung). Dann gibt es nur noch eine Stelle, an der Tracking gepflegt wird.
04 / Prüfliste
So prüfst du deine Website in 20 Minuten.
- Quelltext durchsuchen: Öffne eine Seite, lass dir den Quelltext anzeigen und suche nach „gtm.js“ und nach „gtag('config'“. Findest du beides, prüf, ob der Config-Befehl ohne eigenes gtag.js-Snippet dasteht. Das ist das Muster, das Google als nicht unterstützt einstuft [2].
- Doppelte Quellen finden: Bei WordPress kommen Tracking-Codes oft aus mehreren Stellen gleichzeitig, etwa aus einem Plugin, aus dem Theme und aus einem eingefügten Header-Code. Bei Shopify können eine Google-App und ein im Theme eingebauter Tag-Manager-Code parallel laufen (Einschätzung). Lass am Ende nur eine Quelle übrig.
- Platzhalter-Trigger suchen: Im Tag Manager unter Trigger nach benutzerdefinierten Ereignissen mit „.*“ suchen und notieren, welche Tags daran hängen.
- Ausnahme einbauen: Für diese Tags eine Ausnahme ergänzen, die beim Ereignis „gtag.config“ greift. Diese Lösung empfiehlt GA Optimizer [5]. Alternativ den Platzhalter durch eine Liste der Ereignisse ersetzen, die du wirklich brauchst (Einschätzung).
- Im Vorschaumodus testen: Mit der Vorschau des Tag Managers eine Seite laden und prüfen, ob „gtag.config“ in der Ereignisliste erscheint und welche Tags dabei ausgelöst haben.
- Zahlen vergleichen: In Google Ads und Google Analytics die Conversions ab dem 8. Oktober mit den Wochen davor vergleichen. Ein Sprung ohne erklärbaren Grund ist ein Warnsignal.
Wenn du Werte aus dieser Zeit in Berichten nutzt, zum Beispiel in Looker Studio, vermerke den Zeitraum. Sonst vergleichst du später echte Zahlen mit aufgeblähten.
gtag.config prüfen
01
Quelltext
durchsuchen
02
Trigger
absichern
03
Conversions
vergleichen
Eine Tracking-Quelle pro Website reicht.
Tracking-Check
Sollen wir deinen Tag Manager einmal durchsehen?
Ich prüfe Quelltext, Container und Trigger deiner WordPress- oder Shopify-Website, räume doppelte Codes auf und vergleiche die Conversions vor und nach dem 8. Oktober.
FAQ
Häufige Fragen zum gtag.config-Ereignis.
Bin ich betroffen, wenn ich keine Mail von Google bekommen habe?
Möglicherweise trotzdem. Die Mail ging an Inhaber von Containern mit der nicht unterstützten Einbindung [2]. Das zusätzliche Ereignis bei Platzhalter-Triggern betrifft aber jede Seite, auf der gtag('config') aufgerufen wird [1].
Ich nutze nur den Tag Manager, ohne gtag-Zeilen. Muss ich etwas tun?
Wenn im Quelltext kein gtag('config') steht, entsteht auch kein gtag.config-Ereignis (Einschätzung, abgeleitet aus [1]). Ein Blick in den Vorschaumodus schadet trotzdem nicht, weil Plugins und Apps solche Zeilen unbemerkt einfügen können.
Kann ich die Änderung abschalten?
Eine Option dafür nennt Google nicht. Der Weg führt über eine unterstützte Einbindung [2] und angepasste Trigger.
Quellen
Quellen
- PPC Land (Luis Rijo): „Google forces sites mixing GTM snippets and gtag('config') onto gtag.js“, 9. Oktober 2026, mit Zitaten aus den Tag-Manager-Release-Notes vom 8. Oktober 2026 – ppc.land · abgerufen 11.10.2026. Release Notes: support.google.com.
- Google Tag Manager Hilfe: „Set up your Google tag installation correctly for gtag.js“ – support.google.com · abgerufen 11.10.2026.
- Notice Me Senpai: „GTM’s New gtag.config Event Quietly Double-Fires Wildcard Triggers“, 9. Oktober 2026 – noticemesenpai.com · abgerufen 11.10.2026.
- PPC Land: „Google Tag Manager and Google tag are merging – what actually changes“, Mai 2026 – ppc.land · abgerufen 11.10.2026.
- GA Optimizer: „GTM Update: Why the New gtag.config Event Breaks Wildcard Tags“, Oktober 2026 – gaoptimizer.com · abgerufen 11.10.2026.
Alle Quellen am 11. Oktober 2026 abgerufen. Aussagen ohne belastbare Quelle sind im Text als Einschätzung gekennzeichnet; die Ziffern in eckigen Klammern verweisen auf die Nummern dieser Liste.

