Consentinel

Verify your install

Do not take our word for it, and do not take the dashboard's word for it either. Everything below runs in your own browser against your own site, and takes about two minutes.

There is a specific mistake that makes a perfectly working install look completely broken. It is the first section, because it has caught us.

If you have ever accepted the banner on your own site, your browser is carrying a consent cookie. Every gated tracker is then correctly restored and firing, and a network panel full of tracker requests looks like total failure when it is actually the product working.

Before measuring anything, in the DevTools console:

document.cookie.split('; ').filter(c => c.startsWith('consentinel'))

If that returns anything, you are in a post-consent state. Clear site data (DevTools → Application → Storage → Clear site data), reload, and start again.

A screenshot taken before doing this would show every tracker firing. We know because that is exactly what happened the first time we measured a site internally, and it was misread as a failure.

1. Is the snippet first, and synchronous?

View the rendered page source (view-source: or DevTools → Elements) and find the Consentinel tag. Three things must be true:

  • it appears inside <head>;
  • it is the first <script> on the page — nothing above it, inline or not;
  • it has no async and no defer attribute.

In the console, this reports all three at once:

const scripts = [...document.querySelectorAll('script')];
const i = scripts.findIndex(s => s.src.includes('bundles/s/cs_'));
console.log({
  found: i !== -1,
  position: `${i + 1} of ${scripts.length}`,
  inHead: scripts[i]?.closest('head') !== null,
  async: scripts[i]?.async,
  defer: scripts[i]?.defer,
});

You want position: "1 of N", inHead: true, and both async and defer false.

Beware of checking async by searching the HTML text for the word. The attribute data-cfasync="false" contains the string "async" and data-no-defer contains "defer" — a naive text search reports a synchronous tag as asynchronous. Read the DOM properties, as above.

If the position is not 1, find what is above it. That thing is not being blocked. Common causes are a script optimizer moving the tag (see Install) or a platform inserting its own tags above all custom code (see platform limits).

2. Exactly one copy

document.querySelectorAll('script[src*="bundles/s/cs_"]').length

This must be 1. Two copies means two banners, two blockers patching the same APIs, and consent evidence split across two stores. On WordPress this happens when a hand-pasted snippet is left in place after connecting the plugin — remove the manual one.

3. Are trackers actually blocked?

With consent cleared, open DevTools → Network, filter to a tracker's domain, and reload. For a Tier 1 tracker you should see no requests at all before you interact with the banner.

You can also see the blocker's marks directly in the DOM:

[...document.querySelectorAll('[data-consentinel-blocked]')]
  .map(s => s.dataset.consentinelBlocked)

Each entry is a tracker the blocker neutralized. A neutralized script carries type="javascript/blocked" and has had its src stripped.

Then accept consent and confirm the same trackers now load. Blocking that never releases is its own bug, and it is the half people forget to check.

Accept the banner with the Network panel open. You should see a POST to api.consentinel.co. The event appears in the dashboard's consent log for that site.

5. What does a real browser see across the whole site?

The checks above cover one page. Run a deep crawl from the site's Scan tab: it visits your pages twice — once with no consent, once with consent granted — and the difference is the evidence. It records every outbound request and every cookie, so it surfaces vendors that no signature list knows about.

That is the part you cannot do by hand, and it is where trackers you did not know were installed tend to appear.

Reading the result honestly

A few things that look like problems and are not, and one that looks fine and isn't:

  • An aborted request still appears in the crawl. Our blocker can stop a server-rendered tag from executing but the browser may already have started the fetch. The scan reports the request, because a request was genuinely observed. See Tier 3.
  • Font and icon CDNs will show up pre-consent, even with a rule set. They arrive as stylesheets, which no client-side tool can intercept. This is explained in full and is not something to debug.
  • Platform-native tags on locked builders will show up pre-consent. Also expected, also unblockable by anyone.
  • A "clean" result from a crawl that only visited one page is not clean. If the page count looks implausibly low, something limited discovery. Check the page count before trusting the verdict.

Getting help

If the placement checks pass and trackers still fire pre-consent, the scan report's evidence — the specific hosts, the pages, and the request counts — is what to send us. It tells us in one step what a description cannot.