Title: Tracking Scripts Not being blocked
Last modified: June 30, 2026
---
# Tracking Scripts Not being blocked
* Resolved [keelanj](https://wordpress.org/support/users/keelanj/)
* (@keelanj)
* [3 weeks ago](https://wordpress.org/support/topic/tracking-scripts-not-being-blocked/)
* I’m using Bricks Builder 2.3.7 and Kanslieri Cookie Consent 1.6.2.
* Google Analytics is added via Bricks → Settings → Custom Code → Header Scripts
using the standard GA4 gtag.js snippet.
* Microsoft Clarity is also added via Bricks Custom Code.
* In a fresh Incognito window before accepting cookies:
- `_ga` and `_gid` cookies are created.
- `https://www.google-analytics.com/g/collect` requests are sent.
- `page_view` and `scroll` events are recorded.
* The Script Blocking page says Google Analytics is auto-blocked. Is Bricks Custom
Code supported, or only WordPress-enqueued scripts?
Viewing 10 replies - 1 through 10 (of 10 total)
* Plugin Author [tapiokansleri](https://wordpress.org/support/users/tapiokansleri/)
* (@tapiokansleri)
* [3 weeks ago](https://wordpress.org/support/topic/tracking-scripts-not-being-blocked/#post-18953043)
* Hi. I will investigate and get back to you asap.
* Thread Starter [keelanj](https://wordpress.org/support/users/keelanj/)
* (@keelanj)
* [3 weeks ago](https://wordpress.org/support/topic/tracking-scripts-not-being-blocked/#post-18953131)
* Thank you!
* Plugin Author [tapiokansleri](https://wordpress.org/support/users/tapiokansleri/)
* (@tapiokansleri)
* [3 weeks ago](https://wordpress.org/support/topic/tracking-scripts-not-being-blocked/#post-18953225)
* Version `1.7.0` will be released to sites in about 24 hours. WordPress.org currently
delays plugin updates by 24 hours so moderators and security scanners can review
changes before they reach users.
* Bricks → Settings → Custom Code → Header Scripts was not covered in 1.6.2. That’s
fixed in 1.7.0, which is now available on WordPress.org.
* **What was going on in 1.6.2**
* The plugin only blocked scripts loaded through WordPress’s script API (`wp_enqueue_script`).
Anything pasted as raw HTML in Bricks Custom Code bypassed that, which is why
you still saw `_ga` / `_gid`, `g/collect` requests, and Clarity activity before
consent — even though the Script Blocking tab listed Google Analytics.
* **What changed in 1.7.0**
* There’s a new Custom Code blocking option on Settings → Cookie Consent → Script
Blocking (on by default). It scans the final page HTML and blocks known tracking
scripts — including GA4/gtag and Microsoft Clarity — when they’re added via Bricks,
Elementor, or similar Custom Code fields.
* **GA and Clarity should no longer run until the visitor accepts the matching
category.**
* Optional: [Google Site Kit](https://wordpress.org/plugins/google-site-kit/) is
still a good way to add GA4 if you prefer a plugin-based setup, but it’s no longer
required for Bricks Custom Code to work with consent blocking.
* If anything still slips through after updating, let me know which snippet you’re
using and I’ll take another look.
* Thread Starter [keelanj](https://wordpress.org/support/users/keelanj/)
* (@keelanj)
* [3 weeks ago](https://wordpress.org/support/topic/tracking-scripts-not-being-blocked/#post-18953385)
* Thank you so much for the quick response! I’ll look out for the update.
* Thread Starter [keelanj](https://wordpress.org/support/users/keelanj/)
* (@keelanj)
* [2 weeks, 6 days ago](https://wordpress.org/support/topic/tracking-scripts-not-being-blocked/#post-18954546)
* Hi, I’m not an expert in cookies, but I still don’t think it’s working. After
the update, I was still seeing collect? requests in the inspector before clicking
consent. I wasn’t sure if these were Consent Mode v2 pings or if they were in
violation. I went ahead and just moved the analytics to Google Site Kit, which
is supposed to be bomb proof per the documentation. I still see collect? requests.
And when inspecting actual cookies, I see 3 _ga cookies and 1 _gid cookie. My
understanding is that cookies should not show up at all before consent and the
site would be in violation.
* I do see the MS Clarity cookie and script being blocked. So that is working.
Issue just appears to be with GA.
- This reply was modified 2 weeks, 6 days ago by [keelanj](https://wordpress.org/support/users/keelanj/).
- This reply was modified 2 weeks, 6 days ago by [keelanj](https://wordpress.org/support/users/keelanj/).
* Plugin Author [tapiokansleri](https://wordpress.org/support/users/tapiokansleri/)
* (@tapiokansleri)
* [2 weeks, 5 days ago](https://wordpress.org/support/topic/tracking-scripts-not-being-blocked/#post-18955136)
* Hi, thanks for sticking with this and for the clear description, it helped me
track down the exact problem.
* **The GA issue is fixed in version 1.7.1, which is now live.**
* With Google Consent Mode v2 (which Site Kit uses), it’s normal to see some `google-
analytics.com/g/collect` requests before anyone clicks Accept. When analytics
consent is denied, Google still sends cookieless pings for modeling. No identifiers,
no storage.
* Why you were still seeing `_ga` cookies on the older version:
- Site Kit’s Google Tag Gateway scripts weren’t always blocked before consent
- Stale `_ga`/`_gid` cookies weren’t cleared after rejecting or withdrawing
consent
* All three are fixed in 1.7.1. Consent actions now also reload the page so blocking
and cookie cleanup apply reliably.
* To confirm it’s fixed on your end:
1. Update to 1.7.1 and clear all caches (WP Rocket / host / CDN)
2. Open an incognito window, clear the site’s cookies, and stay logged out
3. Load the page without clicking Accept, then check Application → Cookies: no `
_ga` / `_gid`
4. Click Accept, and now `_ga` / `_gid` should appear
* That’s the compliant behavior: nothing stored before consent, tracking only after.
* Thread Starter [keelanj](https://wordpress.org/support/users/keelanj/)
* (@keelanj)
* [2 weeks, 5 days ago](https://wordpress.org/support/topic/tracking-scripts-not-being-blocked/#post-18955305)
* Thanks so much for the quick action! I’ll take a look later today and report
back.
* Thread Starter [keelanj](https://wordpress.org/support/users/keelanj/)
* (@keelanj)
* [2 weeks, 5 days ago](https://wordpress.org/support/topic/tracking-scripts-not-being-blocked/#post-18955406)
* Hi, I’ve updated the plugin and retested. It’s not behaving like noted in #3
of your previous post. I think I have everything set up correctly, so not sure
what’s going on. Here is a video of what I’m seeing. [https://www.loom.com/share/7e76aa734a424c0aa22c0089d1b3b755](https://www.loom.com/share/7e76aa734a424c0aa22c0089d1b3b755)
* Plugin Author [tapiokansleri](https://wordpress.org/support/users/tapiokansleri/)
* (@tapiokansleri)
* [2 weeks, 1 day ago](https://wordpress.org/support/topic/tracking-scripts-not-being-blocked/#post-18958121)
* Hi. Sorry for the delay.
* Thanks the video helped a lot. I’ve also checked your website. I see you changed
the banner to CookieYes but it still loads the analytics even when everything
is denied.
* 
* **It seems like you have a second Google Analytics tag in the code:**
* Blocked correctly (GA4):
* ```wp-block-code
```
* This GA4 tag has the `data-cookieyes="cookieyes-analytics"` attribute, so CookieYes
_does_ hold it until consent. That part is working.
* **NOT blocked (legacy Universal Analytics):**
* ```wp-block-code
```
* I’m not sure where the Universal Analytics code is in the WordPress but that
seems to be the problem. I suggest you check :
- Bricks → theme settings / custom code (header scripts) — very common on Bricks
sites
- A header/footer injector plugin (“Insert Headers and Footers,” “WPCode,” “
GA Google Analytics,” etc.)
- The child theme’s `functions.php`
- A Google Tag Manager container that still fires a Universal Analytics tag
* Plugin Author [tapiokansleri](https://wordpress.org/support/users/tapiokansleri/)
* (@tapiokansleri)
* [1 week, 5 days ago](https://wordpress.org/support/topic/tracking-scripts-not-being-blocked/#post-18961658)
* Hey. Since it’s been a few days I will mark this as resolved.
Viewing 10 replies - 1 through 10 (of 10 total)
You must be [logged in](https://login.wordpress.org/?redirect_to=https%3A%2F%2Fwordpress.org%2Fsupport%2Ftopic%2Ftracking-scripts-not-being-blocked%2F%3Foutput_format%3Dmd&locale=en_US)
to reply to this topic.
* 
* [Kansleri Cookie Consent](https://wordpress.org/plugins/kansleri-cookie-consent/)
* [Frequently Asked Questions](https://wordpress.org/plugins/kansleri-cookie-consent/#faq)
* [Support Threads](https://wordpress.org/support/plugin/kansleri-cookie-consent/)
* [Active Topics](https://wordpress.org/support/plugin/kansleri-cookie-consent/active/)
* [Unresolved Topics](https://wordpress.org/support/plugin/kansleri-cookie-consent/unresolved/)
* [Reviews](https://wordpress.org/support/plugin/kansleri-cookie-consent/reviews/)
* 12 replies
* 2 participants
* Last reply from: [tapiokansleri](https://wordpress.org/support/users/tapiokansleri/)
* Last activity: [1 week, 5 days ago](https://wordpress.org/support/topic/tracking-scripts-not-being-blocked/#post-18961658)
* Status: resolved