Container settings reference
Every option in the Google Tag Manager container section of the GTM4WP settings, what it changes on your pages, what it is set to before you touch it, and when it is worth changing.
This page describes GTM4WP 2.0.0 and newer. Where the legacy 1.x versions of the plugin behaved differently, the older behavior is marked with a bold GTM4WP 1.x: lead-in.
Where these settings live
Open the GTM4WP plugin settings page and go to the Google Tag Manager container section. The options are split into two groups: General and Advanced. This page follows the same order.
GTM4WP 1.x: the same options live on the General and Advanced tabs, and there is one container ID field rather than a table.
General
Google Tag Manager containers
Default: empty.
One row per container you want to load. Only the container ID is required, and it looks like GTM-XXXXXX. Everything else on the row is optional and applies to that container alone.
- Environment gtm_auth and Environment gtm_preview load a specific container environment instead of the live version. Both values are required for an environment to be applied, so leave both empty to load the live container. The environments guide covers where to find them
- Custom domain loads the container from your own server side tagging domain instead of www.googletagmanager.com
- Custom path replaces the /gtm.js path, for a server side setup that serves the container from somewhere else
- Omit container ID drops the container ID from the loader URL entirely. It only takes effect when a custom path is set, because it exists for server side setups where the path alone selects the container
Every container in the table is loaded on every page. GTM4WP 1.x: with environment parameters configured, only the first container was loaded.
If the table is shown read-only, the container setup is fixed in wp-config.php. The field description on the settings screen names the constant that is doing it, and your saved table is kept untouched behind it and used again as soon as the constant is removed. The wp-config.php page lists the constants.
Container code placement
Default: Footer of the page.
This decides where the second, <noscript> part of the container code goes. The main container script always goes into the <head> section, whichever option you pick here.
- Footer of the page works with every theme and needs no template editing. The one thing it does not support is verifying your site in Google Search Console through the Tag Manager container, which requires the <noscript> part to sit directly after the opening body tag
- Automatically after the opening body tag puts it in the right place without editing anything, provided your theme calls wp_body_open. Most themes written in the last few years do
- Manually coded after the opening body tag is for a theme that does not. Add this to your template right after the opening body tag:
<?php if ( function_exists( 'gtm4wp_the_gtm_tag' ) ) { gtm4wp_the_gtm_tag(); } ?> - Off removes both parts of the container code and leaves the data layer working, for a setup where your own code or another plugin loads the container
On “Off” the plugin writes a short console.warn note into the page saying the container was left out deliberately, so the missing container does not read as a fault. The “please enter your GTM ID” admin notice is not shown on this setting either, because there is no container ID to enter.
Advanced
dataLayer variable name
Default: empty, which means the standard name dataLayer.
Renames the JavaScript variable the plugin writes its data into. Change it only if something else on the site already owns the name dataLayer, and remember that the container in Google Tag Manager has to be told the new name as well, under Admin, Container Settings.
The value has to be a valid JavaScript variable name: a letter, an underscore or a dollar sign, followed by letters, digits, underscores or dollar signs. A hyphen is not allowed, because JavaScript reads it as a minus sign.
GTM4WP 1.x: a name containing a hyphen was accepted and then written to the page as a syntax error, which silently took down the whole GTM4WP script block. A stored name that does not qualify is now ignored in favour of dataLayer, and the settings screen names the rejected value.
Load GTM container as early as possible
Default: off.
Moves the container script towards the top of the <head> section instead of leaving it in its normal position there. Tags fire slightly earlier, which matters for a consent tool or an A/B testing tool that has to run before the page renders.
The trade-off is that anything loaded later is not available yet. A Custom HTML tag firing on Page View that uses jQuery is the usual casualty, because jQuery has not loaded at that point. If tags that worked before start reporting errors after turning this on, that is the reason.
Do not use console.log() messages on frontend
Default: off, which means the messages are shown.
GTM4WP writes short notes into the browser console explaining why the container code is missing from a page: the placement is set to Off, the environment kill switch suppressed it, or the visitor has an excluded user role. They are there so that a deliberately absent container is not mistaken for a broken one, and they are the first thing to read when the container does not appear.
Turn this on to keep them out of the console on a live site. It changes nothing about what is tracked.
Only output the container on production environments (experimental)
Default: off.
A kill switch for staging and development copies. With it on, the container code is emitted only when WordPress reports the environment type as “production”. The data layer stays active either way, so only the container script and its <noscript> part are suppressed, exactly as on the “Off” placement.
The environment type comes from the WP_ENVIRONMENT_TYPE setting in wp-config.php or your server configuration, which is invisible from the WordPress admin. There is a trap in it: when nothing sets it, WordPress answers “production”, so a staging copy that was never configured keeps loading the container. Because of that the option’s description on the settings screen reports the environment type WordPress actually returns on the site you are looking at, and whether the container would therefore be loaded or suppressed. Read that line rather than assuming.
For control that does not depend on the environment type, for example by hostname, the gtm4wp_output_container filter can veto the container from PHP. It defaults to true and is documented on the actions and filters page.
User roles to exclude
Default: nothing selected.
Leaves the container code out on the front end when the logged-in user has any of the checked roles, which is how you keep your own team out of your analytics. Both parts of the container code are suppressed, and the data layer stays active. The guide on excluding admin users covers the setting and its alternatives in full.
Checking what an option actually did
For the container itself, open Google Tag Manager preview mode and check that it connects. If it does not, view the page source and search for GTM4WP: the plugin marks its own block with an HTML comment, and any console.warn note inside it tells you which of the settings on this page removed the container.
For the data layer, open the browser console and type the name of your data layer variable, which is dataLayer unless you changed it above.
