Your WordPress site is not sending the correct consent signals to Google, so your analytics and ads data is incomplete or missing. This usually happens because the configuration in Google Tag Manager is missing the v2 parameters, a plugin is conflicting with the tag, or your consent banner is not firing the update command correctly. You do not need to rebuild your entire tracking stack. You need to check five specific settings in order. Most fixes take less than a minute once you know where to look.
Why is consent mode v2 not working on wordpress
You are likely seeing one of three symptoms. First, Google Tag Manager reports that consent is not defined. Second, your GA4 or Google Ads reports show a drop in data from EU and UK users. Third, the consent status in the Tag Assistant extension remains stuck on "denied" even after a user clicks accept. These symptoms point to the same root cause: the bridge between your cookie banner and Google’s tags is broken. The good news is that this is almost always a configuration error, not a server issue. You can diagnose and fix it yourself without hiring a developer, provided you follow the steps below in order.
Before you start digging into code or plugin settings, you need to confirm whether the consent mode is actually installed on your site. It is easy to assume it is there because you installed a plugin, but the plugin might not have written the necessary JavaScript to the page. You need to see the raw output.
Open your website in a Chrome browser. Right-click on the page and select "View Page Source". Press Control and F on your keyboard to open the search bar. Type gtag('consent' into the search box. If you see results, the base code is present. If you see zero results, the code is missing entirely, and no amount of tweaking settings will help. You need to add the snippet first.
If you are unsure whether the snippet is present or if it is firing correctly, you can run a quick diagnostic. Visit the consent mode checker to see exactly what signals your site is sending to Google right now. It tells you if the default state is set correctly and if the update commands are firing when a user interacts with the banner.
The default state is missing or incorrect
The most common reason Consent Mode v2 fails is that the default state is not defined in your code. Google requires that you set a default state before any user interaction happens. If this is missing, Google treats the visit as having no consent, and it blocks all data collection.
Check your Google Tag Manager container. Go to the "Tags" section and find your Google Tag Manager Configuration Tag. If you do not have one, create a new one of type "Google Tag Manager Configuration". Inside this tag, look for the "Consent Initialization" section.
You must set the default values for all four parameters. They should look like this:
analytics_storage:deniedad_storage:deniedad_user_data:deniedad_personalization:denied
If any of these are missing, or if they are set to granted, your setup is broken. Setting them to granted by default is a compliance violation and will cause Google to ignore the signal if it detects a mismatch with your banner. Change all four to denied. Save and publish the container.
This fix takes thirty seconds. If your default state was missing, this single change will often resolve the issue immediately. After publishing, wait five minutes for the changes to propagate, then test again.
The update command is not firing
Even if your default state is correct, Consent Mode v2 will not work if the update command never fires. This command tells Google that the user has made a choice. It must be triggered by your cookie banner.
Most WordPress sites use a plugin to handle the cookie banner. Popular options include CookieYes, Complianz, and Cookiebot. Each of these plugins has a specific field where you paste the Google Consent Mode update code.
Go to your plugin settings in the WordPress dashboard. Look for a section labeled "Google Consent Mode", "Custom Code", or "Advanced Settings". You will see a text box. It should contain a script that looks like this:
gtag('consent', 'update', {
'analytics_storage': 'granted',
'ad_storage': 'granted',
'ad_user_data': 'granted',
'ad_personalization': 'granted'
});
Note that the values here are granted. This script runs only when the user clicks "Accept". If the user clicks "Reject", a different script with denied values should run.
If this code is missing, copy it from your Google Tag Manager container or from the plugin’s documentation. Paste it into the "Accept" action field. If your plugin has a separate field for "Reject", ensure the denied version is there. If your plugin does not have these fields, you may need to add the code to your theme’s header.php file, which requires a developer.
Check the plugin logs. Many consent plugins have a debug mode. Enable it, click "Accept" on your banner, and look at the console in your browser’s developer tools. You should see the gtag('consent', 'update') command appear. If it does not appear, the plugin is not triggering the code. In that case, switch to a different plugin that supports Consent Mode v2 natively.
A plugin is blocking the script
WordPress runs on a foundation of plugins, and sometimes one plugin blocks another. This is the most frustrating cause because the code is there, the settings are correct, but the script never executes.
The usual culprits are security plugins, caching plugins, and other consent plugins. If you have two consent plugins active, they will fight over the banner and the JavaScript execution. Deactivate all but one consent plugin. If you are using a security plugin like Wordfence or iThemes Security, it may be stripping out inline scripts that it deems suspicious.
To test this, create a staging copy of your site. On the staging site, deactivate all plugins except your consent plugin and Google Tag Manager. Load the page. Check the browser console for errors. If the consent mode works on the clean staging site, the problem is a plugin conflict.
Re-enable plugins one by one. After each one, refresh the page and check the console. When the error reappears, you have found the conflicting plugin. Contact the plugin developer to report the issue, or look for a setting in that plugin to allow inline scripts.
If you cannot identify the conflict, you may need to move your Google Tag Manager snippet from the header to the footer, or use a server-side tagging solution to bypass client-side restrictions. For now, the staging test is your fastest path to diagnosis.
The tag is not configured for consent
You can have the correct code on your page, but if your Google Analytics or Google Ads tag in Google Tag Manager is not set to respect the consent state, it will ignore it. This is a common oversight.
Go to Google Tag Manager. Open your Google Analytics 4 Configuration Tag. Look for the "Settings" section. There should be a toggle or a field labeled "Consent Mode" or "Respect Consent". Ensure it is enabled.
If you are using a Google Ads Conversion Tag, open that tag. Look for the "Consent" section. It must be set to "Use Consent Mode". If it is set to "Ignore Consent", the tag will fire regardless of the user’s choice, which is a compliance risk and will cause data discrepancies.
Check your Google Ads Linker tag as well. It must also respect the consent state. If any of your Google tags are set to ignore consent, the entire system is compromised. Fix this by enabling the consent settings on every Google tag in your container.
After making these changes, publish the container. Wait five minutes. Test again. The tags should now pause when consent is denied and fire when consent is granted.
The browser is blocking the request
Sometimes the code is perfect, the plugins are fine, and the tags are configured correctly, but the user’s browser is blocking the request. This is not your fault, but it affects your data.
Privacy-focused browsers like Safari and Brave aggressively block third-party cookies and scripts. If you are testing on one of these browsers, you may see Consent Mode v2 as "not working" when it is actually being blocked by the browser’s privacy features.
To test this, use Chrome in an Incognito window. Disable any ad-blocker extensions. Load your site. Click "Accept". Check the Network tab in the developer tools. Look for requests to google-analytics.com or googleadservices.com. If you see them, the consent mode is working.
If you see no requests, the issue is likely with the user’s browser settings, not your site. You can still track some data using IP anonymization and other techniques, but you cannot force the browser to accept cookies. This is a limitation of the platform, not a bug in your setup.
When you need a developer
If you have checked all five points above and Consent Mode v2 still does not work, you likely have a custom implementation issue. This happens when the site uses a custom theme, a headless WordPress setup, or a complex JavaScript framework that interferes with standard tag loading.
In these cases, you need a developer who understands both WordPress and Google Tag Manager. They can inspect the DOM, trace the script execution, and identify where the chain breaks. Do not try to fix this by adding more code snippets. That will only make the problem worse.
If you are running a serious business and rely on accurate data for decision-making, consider moving to server-side tracking. This approach sends data from your server to Google, bypassing many browser restrictions and improving data accuracy. You can learn more about how this works in our guide to server-side tracking.
How to verify the fix
Once you have made your changes, you need to verify that everything is working. Do not rely on the dashboard. Use the Google Tag Assistant extension.
Install the Google Tag Assistant extension for Chrome. Open it on your website. Look for the Consent Mode section. It should show the current consent state. It should start as "denied". Click "Accept" on your banner. The state should change to "granted". Click "Reject". The state should change back to "denied".
If the state changes correctly, your setup is working. If it does not, check the "Errors" tab in Tag Assistant. It will tell you exactly which tag is failing and why.
Also check your GA4 Realtime report. Load your site in a new tab. Watch the Realtime report. You should see a new user appear. If you do not see a user, the tag is not firing. If you see a user but no consent signal, the consent mode is not connected to the tag.
Common mistakes to avoid
- Setting default state to granted. This is a compliance violation. Always set the default to denied.
- Forgetting the new v2 parameters. If you only set
analytics_storageandad_storage, you are missingad_user_dataandad_personalization. Your setup is incomplete. - Using an outdated plugin. Some older versions of consent plugins do not support v2. Update your plugin to the latest version.
- Testing on a cached page. Clear your cache or use a staging site. Cached pages may not reflect your latest changes.
- Ignoring the reject flow. Many people only test the "Accept" button. You must test the "Reject" button to ensure the tags stop firing.
Summary
Consent Mode v2 is not working on your WordPress site because of a specific configuration error. It is almost always one of the five causes listed above. Start with the default state. Then check the update command. Then look for plugin conflicts. Then verify your tag settings. Finally, consider browser restrictions.
Most of these fixes take less than a minute once you know what to look for. You do not need to be a developer to fix this. You just need to follow the steps in order. If you get stuck at any point, use the consent mode checker to see exactly what is happening.
If you want to ensure your tracking is robust and compliant, consider a professional audit. You can contact us to discuss your specific setup. Or, if you want to learn more about the tools we use, check out our pricing page.
Remember, accuracy in your data is not optional. It is the foundation of your marketing strategy. Fix the consent mode, and you will see a clearer picture of your audience.