Als uw site Google Tag Manager gebruikt, verandert Google hoe Tag Manager op uw pagina’s start. In een release note van 8 oktober 2026 zegt Google dat elke Tag Manager-container (de plek in Tag Manager waar de tags van uw site staan) start zodra hij geladen is, in plaats van te wachten op een gtag('config')-opdracht op de pagina. Deze wijziging in Google Tag Manager rond gtag config doet er vooral toe voor sites die Tag Manager combineren met losse Google tag-code, en voor containers met regels (triggers) die tags bij elke gebeurtenis laten afgaan.
Google heeft de eigenaren van containers die volgens Google verkeerd zijn ingesteld per e-mail ingelicht. Hoeveel dat er zijn, heeft Google niet bekendgemaakt, en de helppagina over de oplossing zegt nog steeds dat de update “binnenkort” komt.
Wat is er op 8 oktober in Google Tag Manager veranderd?
Google zegt dat Tag Manager-containers niet meer wachten op de regel gtag('config'), de opdracht die een Google tag vertelt naar welk account de gegevens gaan en met welke instellingen. De release note van 8 oktober, voorlopig alleen in het Engels, zegt (onze vertaling): “alle containerfragmenten van Google Tag Manager (gtm.js) worden geïnitialiseerd bij het laden van de container, ongeacht eventuele gtag(‘config’)-opdrachten.”
Een fragment (snippet) is het korte stukje code dat op elke pagina van uw site is geplakt. Een tag is een klein stukje code dat bijhoudt wat er op uw site gebeurt, zoals een paginaweergave of een verstuurd formulier, en die informatie doorstuurt naar een tool als Google Analytics of Google Ads. Een website kan de tags van Google met een van twee fragmenten laden:
| Tag Manager-fragment | Google tag-fragment | |
|---|---|---|
| Bestand dat het laadt | gtm.js | gtag.js |
| ID dat het gebruikt | Begint met GTM- | Een product-ID, zoals G- of AW- |
Beide fragmenten schrijven naar de dataLayer, een wachtrij met berichten op de pagina die Tag Manager uitleest. Tot nu toe kon een container een gtag('config')-regel elders op de pagina opmerken en daarop wachten, en sommige sites rekenden daarop. De release note verandert ook wat de container ziet (onze vertaling): “config-opdrachten verschijnen nu in de dataLayer als zichtbare gtag.config-gebeurtenissen.”
Welke sites raakt de wijziging in Google Tag Manager rond gtag config?
Het gaat om twee groepen sites. De e-mails van Google gingen naar de eerste groep, die gebruikmaakt van wat Google een “niet-ondersteunde implementatie” noemt. De tweede groep kan een setup hebben die Google correct vindt, maar met regels (triggers) die tags bij elke gebeurtenis laten afgaan.
Gemengde setups. De helppagina van Google over de gtag.js-setup beschrijft sites die een G-, AW- of DC-ID laden via het fragmentpad van Tag Manager. Het voorbeeld van een verkeerde setup is het standaard GTM-fragment gevolgd door een losse gtag('config')-regel. Over deze sites zegt Google dat ze “onverwachte wijzigingen in het taggedrag” kunnen ondervinden en dat gebruikers van zulke containers “een e-mailmelding gekregen” hebben.
Wildcard-triggers. Een trigger is de regel die een tag vertelt wanneer hij moet afgaan. Een trigger voor aangepaste gebeurtenissen kan gebeurtenisnamen herkennen met het patroon .*, dat op elke gebeurtenis in de dataLayer past. De release note van Google waarschuwt (onze vertaling): “Als uw Google Tag Manager-containers wildcard-triggers voor aangepaste gebeurtenissen gebruiken, kan deze wijziging ervoor zorgen dat die tags afgaan.”
De hulp van Google over triggers voor aangepaste gebeurtenissen raadde al een smaller patroon aan, omdat .* ook de gebeurtenissen oppikt die Tag Manager en de Google tag automatisch versturen. PPC Land wijst erop dat het risico van wildcard-triggers ook geldt voor sites waarvan Google de setup correct vindt, omdat het standaard gtag.js-fragment zelf een config-aanroep bevat.
Wanneer heeft Google de gtag config-wijziging aangekondigd?
De waarschuwing kwam weken voor de release note. PPC News Feed meldde de mededeling op de helppagina van Google op 27 augustus 2026. Op 20 augustus had een gebruiker van de supportforums van WordPress.org de e-mail geplaatst die een klant van Google had gekregen. Daarin stond (onze vertaling): “Vanaf 2 oktober 2026 worden alle gtm.js-fragmenten geïnitialiseerd bij het laden van de container”.
De release note is gedateerd 8 oktober. De helppagina van Google over de oplossing zegt nog steeds dat de update van Tag Manager-fragmenten “binnenkort” komt. Zoals PPC Land en Relevant Audience allebei opmerken, heeft Google niet gezegd of de wijziging alle containers op één dag bereikte of geleidelijk wordt ingevoerd.
Wat Google niet heeft gezegd
Google heeft geen definitieve deadline genoemd en geen inschatting gegeven van hoeveel gegevens de wijziging kan verstoren. Relevant Audience merkt op dat de release note “geen land of regionale beperking noemt”, en ook de helppagina over de oplossing noemt er geen.
Er is ook een praktisch gat. De e-mail ging naar wie bij de container vermeld staat. Relevant Audience wijst erop dat als die persoon een oud-medewerker of een eerdere webontwikkelaar is, “de waarschuwing misschien nooit is aangekomen bij wie de site vandaag beheert”.
Wat dit betekent voor uw bedrijf
Volgens ons vraagt dit om een zorgvuldige controle van uw tracking. Het gaat erom na te gaan wat uw pagina’s laden, bij een gemengde setup een van de twee oplossingen van Google te kiezen, en te testen of elke aanvraag één keer wordt geteld. Wij zouden deze stappen in deze volgorde zetten, voordat u iets verandert in uw advertentieaccounts.
- Zoek uit wie eigenaar is van de container. U hebt toegang tot Tag Manager nodig om iets te controleren, en het bedrijf hoort eigenaar te zijn, met een eventueel bureau als gebruiker toegevoegd. In onze gids over een marketingbureau beoordelen leggen we uit waarom de accounts bij u horen.
- Kijk welk fragment uw pagina’s laden. Open uw site, bekijk de paginabron en zoek naar “googletagmanager.com”. Bevat de URL gtm.js met een ID dat begint met GTM-, dan is uw containerpad het ondersteunde. Staat er in gtm.js een G-, AW- of DC-ID, of staat er naast het Tag Manager-fragment een losse
gtag('config')-regel, dan hebt u de setup waarvoor Google waarschuwde. - Kies een van de twee oplossingen van Google. Gebruik het Google tag-fragment (gtag.js) op elke pagina en verwijder het gtm.js-fragment en losse config-regels. Of, als Tag Manager uw andere tags aanstuurt, houd het fragment met uw GTM-ID en stel de Google tag in binnen de container. Neem de instellingen over die de oude config-regel doorgaf en laat uw cookietoestemming staan, zodat tags de keuze van de bezoeker in uw cookiebanner blijven volgen.
- Zoek in de container naar
.*-triggers. Open de lijst met triggers en zoek naar triggers voor aangepaste gebeurtenissen die op alle gebeurtenissen reageren. Beperk elke trigger tot de gebeurtenisnamen die hij nodig heeft, want een tag die op gtag.config afgaat, kan dezelfde gegevens opnieuw versturen en bijvoorbeeld één aanvraag als twee tellen. - Test met Tag Assistant en een echte aanvraag. Tag Assistant is de tool van Google om de tags op uw website te controleren, en volgens de helppagina van Google hoort uw tag-ID daar te verschijnen “met een groen of blauw statusicoon”. Stuur daarna vanaf uw telefoon een testaanvraag en controleer of die één keer wordt geteld, zoals we beschrijven voor als Google Ads niet werkt en wel klikken maar geen aanvragen oplevert. Bij ons Google Ads-beheer controleren we de tracking voordat we biedingen aanpassen.
- Vergelijk de aantallen met uw inbox of CRM. Zet de aanvragen in uw inbox of CRM naast de conversies die Google voor dezelfde dagen rapporteert, voor en na 8 oktober. Dezelfde controle gebruiken we in ons werk aan CRM en data-analyse, en als de cijfers niet meer kloppen, zijn de tags de eerste plek om te kijken.
