What can and cannot be blocked

Most consent tools describe blocking as one thing you either have or don't. It isn't. Blocking capability is a property of where your platform lets our script run, and on some platforms certain tags cannot be blocked by anyone — including that platform's own consent banner.

This page is the honest version. Everything on it is measured in a real browser, not estimated. We publish it because you will find out eventually, and it is better that you find out from us.

Nothing here is legal advice.

Blocking is three separate things

This is the single most useful idea on this page. "Blocking a tracker" is actually three layers, and they fail independently:

Almost every confusing result about consent tools resolves once you hold these apart. Google Consent Mode set to denied, for example, suppresses storage — it does not stop transmission. Analytics tags with consent explicitly denied still send the page URL, title, scroll depth, screen size and a freshly generated client identifier. If your concern is a wiretapping-style claim, the transmission is the exposure, so that distinction matters a great deal.

The three tiers of tracker

The headline claim — block-until-consent — holds fully for Tier 1 everywhere. That is the tier that contains session recorders, heatmaps, and most of what a privacy complaint is actually about.

Tier 1 — measured

A controlled A/B test on a live Wix site: same browser, same tab, identical storage clear between arms, identical settle time, with Consentinel entirely absent in the control arm.

The platform's own consent banner allowed the session recorder to load and set cookies. We blocked it completely. The last row is Tier 2, and it is identical in both arms — which is the point of the next section.

(Cookie counts from document.cookie are a floor, since it cannot see HttpOnly cookies. A devtools reading of the same site showed 8 where the script counted 4. The comparison holds because both arms were measured identically.)

Tier 2 — nobody can block these, and we will tell you so

On locked site builders, the platform renders its own marketing tags above all customer custom code. Byte offsets from a live Wix page:

36,196  <script async src="googletagmanager.com/gtag/js?id=…">   ← Wix Marketing Integration
43,206  <script src="…/bundles/s/cs_….js">                       ← Consentinel (custom code)

By the time our code runs, the browser has already begun fetching the tag 7,000 bytes above it. Patching network APIs afterwards cannot retract a request the parser has already made. This is structural, not a bug, and it applies to every client-side consent tool equally.

What we deliver on Tier 2: cookie suppression, correct Google Consent Mode signals, and — on Wix — writing the platform's own consent policy so its tags behave. What we do not deliver: stopping the transmission. Your scan report says so plainly rather than showing you a green check.

If your site's scan reports platform-native tags firing pre-consent, that is an accurate finding, not a product failure. The remediation, where the platform permits it, is to remove the tag from the platform's marketing integrations and add it as custom code below the Consentinel snippet — which converts an unblockable Tier 2 tag into a Tier 1 tag we control completely. Whether a given platform lets you reach that setting varies, and on Wix specifically it may be platform-managed and not removable at all.

Tier 3 — why a tag below our snippet is still fetched

For a <script src> already present in the server-rendered HTML, our last line of defense is a MutationObserver. Its callbacks are delivered as microtasks — after the current task finishes. The parser inserts the element and the browser starts the request within that task:

parser inserts <script src=…>  →  browser starts fetch      ← too early for us
                               →  [microtask] src stripped,
                                  type="javascript/blocked"
                               →  script never executes      ← we win here

So the honest sentence for the Cloud SDK on any platform is:

The browser fetches the loader, but the script is neutralized before it runs — no cookies, no identifier, no measurement payload. The request itself still exposes the visitor's IP address and referring URL to the vendor.

Both halves matter. The first is the substance — stopping execution is what kills the data. The second is what makes the first credible.

On WordPress, the mechanism decides

WordPress is the exception, and it is our strongest deployment. Because the tag is emitted by PHP, the Consentinel plugin can rewrite it before the page is ever sent — so the file is never fetched at all.

Measured on a WordPress site carrying the same analytics property loaded two different ways on a single page:

Re-verified nine releases later on the same site: zero pre-consent requests to the tag manager, analytics, the social pixel, and a session recorder's script and its collect beacons. A high-risk session recorder live on 11 pages, making zero network contact before consent.

What decides whether a fix exists is how the tag is emitted:

Two scope limits that travel with this:

• Output-buffer gating is opt-in and off by default, because it filters every byte of every page response. Without it, tags printed directly into wp_head by another plugin are not gated.
• Page caches are not automatically fine. One cache plugin was measured storing post-rewrite HTML correctly, because our buffer runs early. A cache that captures output earlier, or a server-level cache populated while the setting was off, can still serve ungated HTML — and nothing detects that. Purge after enabling, then confirm on a cached page.

Cloudflare's edge injection lands after PHP has finished, so no version of any WordPress plugin reaches it. That is the real floor on this platform.

Web fonts and icon kits cannot be blocked client-side. Anywhere.

This one deserves its own section because the dashboard lets you set a rule for these trackers, and the rule does not do what it looks like it does.

A font or icon CDN normally arrives as <link rel="stylesheet">. The browser's CSS pipeline fetches it, and that pipeline touches none of the JavaScript network APIs a blocker can patch. A MutationObserver only sees nodes inserted after parse, and a <link> already in the HTML is fetched with no JavaScript involvement at all.

We traced this in a real browser rather than reasoning about it. One page load, resource timings:

The font request completed 344.6 ms before our bundle had finished downloading — before the blocker could execute a single line. The cause is the browser's preload scanner, which finds <link> hrefs while the parser is still blocked on our synchronous script and fetches them in parallel.

Being the first synchronous script does not help here, and it would not help any competitor either. This is a fact about how browsers work, not a limitation of our implementation.

What actually exists today:

The Block until consent case is deliberate, not an oversight: nothing can restore a <link> after consent, so gating a recoverable stylesheet would leave the font permanently dead on the page — worse than the exposure it fixes. Always block is safe only because "never load" has nothing to restore.

So: we detect and report pre-consent font-CDN contact, and on WordPress we drop the early connections and can block a font CDN outright when you set it to Always block. We do not claim to block web fonts before consent, on any platform. The dashboard now labels this inline wherever you can set it, so the control cannot imply an enforcement that is not happening.

Scope: fonts and icon kits transmit an IP address and a referrer, not behavior. They do not touch analytics, advertising, or session-recording tags, which arrive as scripts and are gated normally.

Server-side tracking is invisible to everyone

Tracking that happens on your server rather than in the browser — conversions APIs, server-side tag managers — cannot be observed by any client-side tool or any browser-based crawler, ours included. Our scan reports say this in their methodology rather than leaving you to assume the absence of a finding means absence of tracking.

What we will not tell you

For completeness, here is what we consider unsupportable, so you can hold us to it:

• "Blocks all trackers before consent on any platform." False on Tiers 2 and 3.
• "Nothing loads until consent" on a locked site builder.
• Any suggestion that Consent Mode denied means no data reaches Google.
• "We block web fonts before consent" — on any platform.
• The WordPress zero-fetch result described as a general Consentinel result. It is specific to the WordPress plugin; everywhere else the loader is still fetched.
• That we are the only tool that blocks pre-consent tracking on a locked builder. For platform-native tags nobody does.

The frame we would rather compete on

Our differentiator is detection and proof, which works on every platform, plus enforcement that is complete on Tier 1 and reaches server-side on WordPress. That is a more defensible position than an absolute blocking claim anyone can disprove with a single page load — including on their own site, in thirty seconds, using our own verification guide.