GTM Kit: two persistent false positive alerts

Both of these are fixed or answerable in 2.19, released today.

The Google tag alongside your container

Your reading was right, and the plugin was overstating it. A Google tag next to the container is only a duplicate when the same tag also fires inside the container, which it does not in your case. Two things changed:

• The dashboard notice is no longer raised as a problem, and it no longer calls this duplicate tracking. Two containers, or the same container loaded twice, are still reported as problems, because those really do double-count.
• GTM Kit now recognises Google for WooCommerce as the source, so instead of “could not tell what adds the extra tracking code” you get the plugin named, with the advice to check that the same tag does not also fire inside your container. It no longer suggests removing a container, which was wrong for this case.

The Site Health entry stays as a recommendation rather than disappearing: a page loading both is worth stating, since the check cannot see inside your container to confirm what you confirmed by hand. With your setup there is nothing to do.

“Consent is not configured”

Tarteaucitron still is not auto-detected. Detection works off the active plugin list, and Tarteaucitron is usually loaded by the theme or a snippet, so there is nothing for GTM Kit to match on. 2.19 adds two filters so you can declare it yourself:

add_filter( 'gtmkit_active_cmp', function ( $detected ) {
return $detected ?? 'tarteaucitron';
} );

add_filter( 'gtmkit_cmp_display_name', function ( $name, $slug ) {
return 'tarteaucitron' === $slug ? 'tarteaucitron.js' : $name;
}, 10, 2 );

Add that in a code snippets plugin or your child theme’s functions.php. Site Health then reports consent as configured and names tarteaucitron.js as owning it.

Two things worth being clear about: the filter changes what GTM Kit reports, nothing else. It does not load tarteaucitron, send consent signals or touch how your container loads. And keep “Activate GCM settings” switched off as you have it, which is correct when your CMP sets the defaults itself, otherwise you get the double signals you were avoiding.

Update to 2.19 and let me know if either one still looks wrong. No need to send the system data unless it does.

You are welcome

Good suggestion, and it is a direction I want to take, but it is not straight forward.

The plugin cannot see inside your container. The container is fetched by the browser directly from Google, and its tag list never reaches WordPress at all, so there is nothing for a settings page to read. Getting at it means the Tag Manager API, which needs OAuth and each site owner granting GTM account access. That is a real integration rather than a panel, and it is not something I will add lightly.

What is realistic, and what I have been circling for a while: you export your container from GTM as JSON, which anyone can do from the container’s admin, and GTM Kit audits that export. It already knows exactly which events your configuration emits, so it can show which tags and triggers consume each one, name the events nothing consumes, and flag the case you actually hit: more than one tag firing a conversion on the same event, or two tags sharing a conversion ID. No OAuth, no account access, and it works the same whether your container was built by hand or generated by the Template Assistant.

Would an export-and-audit step serve you, or does it need to be continuous to be useful?