Wenn Ihre Website Google Tag Manager nutzt, ändert Google, wie Tag Manager auf Ihren Seiten startet. In einer Release Note vom 8. Oktober 2026 schreibt Google, dass jeder Tag Manager-Container (der Bereich in Tag Manager, in dem die Tags Ihrer Website liegen) sofort beim Laden startet, statt auf einen gtag('config')-Befehl auf der Seite zu warten. Diese Google Tag Manager gtag config Änderung trifft vor allem Websites, die Tag Manager mit separatem Google-Tag-Code mischen, und Container mit Regeln (Triggern), die Tags bei jedem Ereignis auslösen.
Google hat die Inhaber von Containern angeschrieben, die aus Googles Sicht falsch eingerichtet sind. Wie viele das sind, hat Google nicht veröffentlicht, und die Hilfeseite zur Lösung sagt weiterhin, die Snippets würden “bald aktualisiert”.
Was hat sich am 8. Oktober bei Google Tag Manager geändert?
Laut Google warten Tag Manager-Container nicht mehr auf die Zeile gtag('config'), also den Befehl, der einem Google-Tag sagt, an welches Konto er Daten mit welchen Einstellungen sendet. In der Release Note vom 8. Oktober heißt es sinngemäß, dass alle Container-Snippets von Google Tag Manager (gtm.js) beim Laden des Containers initialisiert werden, unabhängig von gtag(‘config’)-Befehlen.
Ein Snippet sind die wenigen Codezeilen, die in jede Seite Ihrer Website eingefügt werden. Ein Tag ist ein kleines Stück Code, das meldet, was auf Ihrer Website passiert, etwa einen Seitenaufruf oder ein abgeschicktes Formular. Der Tag sendet diese Information an ein Tool wie Google Analytics oder Google Ads. Eine Website kann die Tags von Google mit einem von zwei Snippets laden:
| Tag Manager-Snippet | Google-Tag-Snippet | |
|---|---|---|
| Geladene Datei | gtm.js | gtag.js |
| Verwendete ID | Beginnt mit GTM- | Eine Produkt-ID, etwa G- oder AW- |
Beide Snippets schreiben in den dataLayer, eine Warteschlange von Nachrichten auf der Seite, die Tag Manager liest. Bisher konnte ein Container eine gtag('config')-Zeile an anderer Stelle auf der Seite erkennen und auf sie warten, und manche Websites haben sich darauf verlassen. Die Release Note ändert auch, was der Container sieht: config-Befehle erscheinen laut Google künftig im dataLayer als sichtbare gtag.config-Ereignisse.
Welche Websites betrifft die Google Tag Manager gtag config Änderung?
Betroffen sind zwei Gruppen. Googles E-Mails gingen an die erste Gruppe, die eine Implementierung nutzt, die laut Google “nicht unterstützt” wird. Die zweite Gruppe kann ein Setup haben, das Google für korrekt hält, nutzt aber Regeln (Trigger), die Tags bei jedem Ereignis auslösen.
Gemischte Setups. Googles Hilfeseite zur Einrichtung von gtag.js beschreibt Websites, die eine G-, AW- oder DC-ID über den Snippet-Pfad von Tag Manager laden. Als Beispiel für eine falsche Implementierung zeigt sie das Standard-Snippet mit GTM- und danach eine einzelne gtag('config')-Zeile. Bei diesen Websites “kann es zu unerwarteten Änderungen beim Tag-Verhalten kommen”, schreibt Google, und die Nutzer solcher Container “haben eine E-Mail-Benachrichtigung erhalten”.
Platzhalter-Trigger. Ein Trigger ist die Regel, die einem Tag sagt, wann er ausgelöst wird. Ein Trigger für benutzerdefinierte Ereignisse kann Ereignisnamen mit dem Muster .* abgleichen, das auf jedes Ereignis im dataLayer passt. Googles Release Note warnt sinngemäß: Wenn Ihre Container Platzhalter-Trigger für benutzerdefinierte Ereignisse nutzen, kann diese Änderung dazu führen, dass diese Tags ausgelöst werden.
Googles Hilfe zu Triggern für benutzerdefinierte Ereignisse hat schon vorher ein engeres Muster empfohlen, weil .* auch Ereignisse erfasst, die Tag Manager und das Google-Tag automatisch senden. PPC Land weist darauf hin, dass das Risiko der Platzhalter-Trigger auch Websites betrifft, deren Setup Google für korrekt hält, denn das Standard-Snippet von gtag.js enthält selbst einen config-Aufruf.
Wann hat Google die gtag-config-Änderung angekündigt?
Die Warnung kam Wochen vor der Release Note. PPC News Feed berichtete am 27. August 2026 über den Hinweis auf Googles Hilfeseite. Am 20. August veröffentlichte ein Nutzer der Support-Foren von WordPress.org die E-Mail, die ein Kunde von Google erhalten hatte. Darin stand: “Ab dem 2. Oktober 2026 werden alle gtm.js-Snippets beim Laden des Containers initialisiert”.
Die Release Note ist auf den 8. Oktober datiert. Googles Hilfeseite zur Lösung sagt weiterhin, dass Tag Manager-Snippets “bald aktualisiert” werden. Wie PPC Land und Relevant Audience beide anmerken, hat Google nicht gesagt, ob die Änderung alle Container an einem Tag erreicht hat oder schrittweise eingeführt wird.
Was Google nicht gesagt hat
Google hat weder eine endgültige Frist genannt noch eingeschätzt, wie viele Daten die Änderung stören kann. Relevant Audience merkt an, dass die Release Note “keine Beschränkung auf Länder oder Regionen erwähnt”, und auch die Hilfeseite zur Lösung nennt keine.
Dazu kommt eine praktische Lücke. Die E-Mail ging an die Person, die beim Container eingetragen ist. Relevant Audience weist darauf hin: Ist das ein ehemaliger Mitarbeiter oder ein früherer Webentwickler, “hat die Warnung die Person, die die Website heute betreut, vielleicht nie erreicht”.
Was das für Ihr Unternehmen bedeutet
Aus unserer Sicht ist jetzt eine sorgfältige Prüfung Ihres Trackings angebracht. Die Aufgabe: prüfen, was Ihre Seiten laden, bei einem gemischten Setup einen der beiden Wege von Google wählen und testen, dass jede Anfrage genau einmal gezählt wird. Wir würden diese Schritte in dieser Reihenfolge gehen, bevor Sie in Ihren Werbekonten etwas ändern.
- Klären Sie, wem der Container gehört. Für jede Prüfung brauchen Sie Zugang zu Tag Manager. Inhaber sollte das Unternehmen sein, eine Agentur wird als Nutzer hinzugefügt. Unser Ratgeber, wie Sie eine Marketingagentur bewerten, erklärt, warum die Konten bei Ihnen liegen sollten.
- Sehen Sie nach, welches Snippet Ihre Seiten laden. Öffnen Sie Ihre Website, rufen Sie den Seitenquelltext auf und suchen Sie nach “googletagmanager.com”. Enthält die URL gtm.js mit einer ID, die mit GTM- beginnt, nutzt Ihr Container den unterstützten Weg. Trägt gtm.js eine G-, AW- oder DC-ID, oder steht eine einzelne
gtag('config')-Zeile neben dem Tag Manager-Snippet, haben Sie das Setup, vor dem Google gewarnt hat. - Wählen Sie einen der beiden Wege von Google. Verwenden Sie auf jeder Seite das Google-Tag-Snippet (gtag.js) und entfernen Sie das gtm.js-Snippet und alle einzelnen config-Zeilen. Oder, wenn Tag Manager Ihre anderen Tags steuert, behalten Sie das Snippet mit Ihrer GTM- ID und richten Sie das Google-Tag im Container ein. Übernehmen Sie alle Einstellungen, die die alte config-Zeile übergeben hat, und lassen Sie Ihre Einwilligungseinstellungen bestehen, damit die Tags weiter der Auswahl der Besucher im Cookie-Banner folgen.
- Durchsuchen Sie den Container nach
.*-Triggern. Öffnen Sie die Liste der Trigger und suchen Sie nach Triggern für benutzerdefinierte Ereignisse, die auf alle Ereignisse passen. Beschränken Sie jeden auf die Ereignisnamen, die er wirklich braucht, denn ein Tag, der bei gtag.config auslöst, kann dieselben Daten erneut senden und zum Beispiel eine Anfrage doppelt zählen. - Testen Sie mit Tag Assistant und einer echten Anfrage. Tag Assistant ist Googles Werkzeug zur Fehlersuche bei den Tags Ihrer Website, und laut Googles Hilfeseite sollte Ihre Tag-ID dort mit einem grünen oder blauen Statussymbol erscheinen. Senden Sie danach eine Testanfrage vom Smartphone und prüfen Sie, dass sie einmal gezählt wird, so wie wir es für Google Ads mit Klicks, aber ohne Anfragen beschreiben. Bei der Betreuung von Google-Ads-Konten prüfen wir das Tracking, bevor wir Gebote ändern.
- Vergleichen Sie die Zahlen mit Ihrem Posteingang oder CRM. Legen Sie die Anfragen aus Ihrem Posteingang oder CRM neben die Conversions, die Google für dieselben Tage meldet, vor und nach dem 8. Oktober. Dieselbe Prüfung nutzen wir in unseren CRM- und Analytics-Projekten, und wenn die Zahlen nicht mehr übereinstimmen, sind die Tags die erste Stelle, an der wir suchen.
