Testing & Verification

Verify your ConsentStack setup with debug mode, test geo-detection, and run through the pre-launch checklist.

Before going live, you want to be confident that your consent banner works exactly as configured: scripts are blocked, consent signals reach your analytics platforms, and logs appear in your dashboard. This guide walks you through every step.

Enable debug mode

ConsentStack includes two levels of debugging that you can activate on the core script tag.

Console logging adds data-debug="true" to your embed snippet. This prints every SDK event (config loaded, consent set, scripts blocked, platform signals) directly to your browser's developer console, prefixed with [ConsentStack].

<link rel="preconnect" href="https://cdn.consentstack.io" />
<script src="https://cdn.consentstack.io/consent.js?k=<YOUR_SITE_KEY>"></script>
<script
  src="https://cdn.consentstack.io/consent-core.js?k=<YOUR_SITE_KEY>"
  data-debug="true"
></script>

Visual debug panel adds data-debug-panel="true" for a real-time overlay on your page. The panel shows your current config, detected region, consent state, blocked and activated scripts, platform adapters, and a live event log, all updating as you interact with the banner.

<link rel="preconnect" href="https://cdn.consentstack.io" />
<script src="https://cdn.consentstack.io/consent.js?k=<YOUR_SITE_KEY>"></script>
<script
  src="https://cdn.consentstack.io/consent-core.js?k=<YOUR_SITE_KEY>"
  data-debug="true"
  data-debug-panel="true"
></script>

Toggle the panel with Ctrl+Shift+D or click the collapse button on the panel header.

Remove both debug attributes before going live. They are development tools and should not be present in production.

With debug mode on, load your page and confirm:

The banner appears in the layout and position you configured (bottom bar, modal, etc.).
Text and buttons match your config: check the headline, body copy, and button labels.
Buttons work: click Accept All, Reject All, and open the preferences center. Each interaction should dismiss the banner and update consent state in the debug panel or console.

Verify script blocking

Open your browser's developer tools and go to the Elements tab.

Before consent: Third-party scripts that require consent should show type="application/cs-blocked" on their <script> tags. This means ConsentStack has intercepted and blocked them. (The legacy ScriptBlocker class still uses text/plain for the tracker-sync detection beacon; the request-blocking stub uses application/cs-blocked.)
After consent: Accept all categories, then check the same scripts. They should now have their original type restored and be executing normally.

The debug panel's Scripts section gives you a quick count of detected, blocked, and activated scripts, so you can confirm the numbers match what you see in the DOM.

If you use Google Analytics or Google Ads, ConsentStack automatically sends Google Consent Mode v2 signals. To verify:

Install the Google Tag Assistant browser extension.
Load your page and open Tag Assistant.
Before consent, confirm that analytics_storage, ad_storage, ad_user_data, and ad_personalization show as denied.
Accept consent, then check that the relevant signals update to granted.

The debug panel's Platforms section also shows which adapters are active and whether native consent signals are being sent.

For what each signal controls, the difference between basic and advanced mode, and the June 15, 2026 change that made Consent Mode the single control over Google Ads data, see the Consent Mode v2 setup guide.

Test geo-detection

ConsentStack detects visitor location automatically using Cloudflare's geo-detection headers. To verify the banner behaves correctly for different regions, use a VPN or your browser's location override to simulate visitors from different locations.

Test a few key scenarios:

Visitor location	Expected behavior
EU country	Opt-in banner (GDPR); scripts blocked until consent
California (US-CA)	Opt-out banner (CCPA/CPRA); scripts run, visitor can opt out
Other US states	Notice-only or no banner, depending on your config

The debug panel's Resolution section shows the resolved region, consent model, and language for the current session; use it to confirm the SDK detected the correct location.

After interacting with the banner, open your ConsentStack dashboard and navigate to the Activity page. You should see consent events appearing within a few seconds. Verify:

The consent categories match what you selected.
The region matches where you are testing from.
The event type reflects the interaction (accepted, rejected, or custom preferences).

If logs are not appearing, check that your site's domain is registered in your dashboard settings and that your site key matches.

Pre-launch checklist

Run through this list before removing debug mode and going live:

Open the site in a fresh browser profile, open the network tab before the page loads, and answer nothing. Every request to a third-party analytics or advertising domain that appears while the banner is still sitting there is a request that happened without consent. The test takes about two minutes and works on any consent tool, including ones that are not ConsentStack.

This is worth doing yourself rather than reading it off a feature list. Vendor pages describe tag rewriting, request interception, and consent signalling with the same phrases ("prior blocking", "auto-blocking", "blocks third-party scripts"), and those mechanisms behave differently. See script blocking for what separates them.

The test

Start clean. Open a private or fresh browser profile so no consent cookie from a previous visit is present. An existing consent record makes any tool look like it is behaving.
Open devtools first, then load the page. Go to the Network tab and make sure recording is on before you navigate. Requests fired during initial load are the ones that matter, and they are gone if you open devtools late.
Answer nothing. Leave the banner untouched and read the request list. Filter out your own domain and the consent tool's own SDK, which is allowed to load.
Then click Reject and keep watching. Some tools block cleanly on load and then fire anyway once a decision is recorded.

What the results mean

What you see	What it means
Requests to analytics or ad domains before you answer	Not blocking. Whatever the tool is doing, those third parties already have your visitor's IP address.
Nothing before you answer, but requests after you click Reject	The tool is treating a rejection as permission to load anyway, or a tag escaped its blocking rules.
Requests present, but carrying a "consent denied" parameter	Consent signalling, not blocking. The connection was still made.
No third-party requests until you opt in	Blocking. This is the behaviour to look for.

The consent tool's own SDK loading before consent is normal and expected. It has to load in order to ask the question. Exclude it, and judge everything else.

Why this matters more than it sounds

We scanned 912 sites running four major consent tools in July 2026. 829 of them, 91%, fired a genuine third-party request before the visitor answered the banner, excluding the consent tool's own SDK. Of the sites where Reject was actually clickable, 24% kept firing an analytics or marketing tracker after the visitor clicked it.

The four tools clustered closely, so this is not one bad vendor. Blocking depends on how a tool is deployed and on how much of the request surface it covers, which is why the test above is worth running on your own site rather than assumed from a feature list. Full method and per-tool numbers are in the cookie compliance by consent tool study.

If you would rather not do it by hand, the free cookie checker runs this same test automatically and reports what fired before consent.

What's next

Once everything checks out, remove the debug attributes from the core script tag and deploy. Your consent banner is live.

If you run into issues, the JavaScript API reference covers programmatic access to consent state, and the SDK Installation guide has troubleshooting tips for common setup problems.

Migration from Other CMPs

Switch from Cookiebot, OneTrust, CookieYes, Termly, or Osano to ConsentStack. What transfers, what does not, and the steps for each platform.

API Reference

Technical reference for ConsentStack's edge function API endpoints.