Stop WordPress setting cookies before consent (auto-blocking)

Code you paste into Omea Consent › Scripts always waits for consent. Code that your theme or another plugin adds is a different story – it runs as soon as the page loads, and that’s how cookies such as _ga or _fbp end up set before the visitor has chosen anything. Auto-blocking fixes that.

What auto-blocking holds

With auto-blocking on, Omea Consent holds known tracking code until the visitor consents to its category:

Type	Examples	Category
Analytics scripts	Google Analytics (analytics.js, ga.js), inline gtag(, ga(, dataLayer.push	Statistics
Tag containers	Google Tag Manager (gtm.js), gtag.js	Any optional consent
Advertising and behaviour scripts	Meta Pixel (fbevents.js, fbq(), Hotjar, Google Ads, snaptr(, ttq(, _pintrk(, LinkedIn lintrk(, twq(, clarity(	Marketing
Embeds	YouTube, Vimeo, Google Maps, Facebook plugins, DoubleClick	Marketing
Network calls	Requests to Google Analytics, Amplitude, Segment, Mixpanel (Statistics); Facebook, DoubleClick, Hotjar, Clarity, Snapchat, TikTok, LinkedIn, Bing, Twitter ads (Marketing)	By provider
Cookie and storage writes	Names like _ga, _gid (Statistics) or _fbp, _fbc, li_, clarity (Marketing)	By name

WordPress’s own cookies (wp-…), WooCommerce cookies (woocommerce_…, wc_…) and Omea’s own consent cookie are always allowed.

Google tags in advanced Consent Mode: gtag.js and Google Analytics are not auto-blocked when you use advanced Consent Mode – they load with denied consent and send cookieless pings, which is what advanced mode is for. In basic mode they are held. See advanced vs basic.

Turn it on

1. Scan first Run a cookie scan so you know what is set before any choice.
2. Turn on auto-blocking Go to Omea Consent › Settings › Advanced and switch on the Auto-blocking · Beta card. Click Save changes.
3. Test your site Open the site in a private window. Check that forms, menus, sliders and checkout still work before you accept anything.
4. Scan again Run the scan again. The Before any choice list should now only contain necessary cookies.
5. Add rules for anything left over If a cookie or script from your theme still slips through, add a line under Script URL rules, Script handles, Cookie rules or Storage key rules in the same card.

Auto-blocking is labelled Beta and is off by default, because holding other plugins’ code can change how they behave. Test your site after turning it on.

Rules for code Omea doesn’t know

The auto-blocking card has four rule boxes. Each line maps something to a category:

Rule box	Format	Example
Cookie rules	name=category	pll_language=functional
Script URL rules	regex=category	googletagmanager\.com/gtm\.js=statistics
Script handles	handle=category	google-analytics=statistics
Storage key rules	regex=category	^wpEmojiSettingsSupports$=functional

Two more switches in the card:

• Block scripts that write blocked storage (on by default) – also holds a script that tries to write a blocked cookie or storage key.
• Log blocked writes for debugging (off by default) – records what was blocked. The log is under Settings › Maintenance › Debug events, where Add rule turns a row into a rule.

There is also Allow Google Tag Manager before consent – see Google Tag Manager consent mode on WordPress.

Troubleshooting a page that breaks

Logged-in administrators can add ?omea_consent_noguard=1 to any URL to load that page without the guard. If the problem goes away, the guard was holding something the page needs: turn on debug logging, reproduce the problem and add a rule that maps that script or cookie to the right category – often Functional.

The alternative: move the code into Omea

If a theme option or plugin only adds a tracking snippet, you can often switch it off there and paste the snippet into Omea Consent › Scripts instead. That gives you exact control without auto-blocking. With Omea Consent Pro you can replace eight common tags with one-click integrations.