Consent simulation

The deep scan drives the cookie banner automatically and compares the accept state with the reject state.

What we check

Drives the cookie banner automatically (Accept-all and Reject-all) and compares both states.

Why it matters

The deep scan drives the cookie banner automatically and compares the accept state with the reject state.

Common causes

The CMP renders the banner in an iframe or shadow root the scanner cannot reach (some Sourcepoint and custom builds).
The buttons carry neither known selectors nor unambiguous labels, custom UIs without standard wording stay undriveable.
Bot protection (a Cloudflare challenge, for instance) stops the headless browser before the banner appears.
The page loads slower than the scan's time budget, the simulation aborts in a controlled way.

The fix

If "not possible": check whether an interactive CMP exists, otherwise rely on the static-scan findings.

Matching template

CMP and GTM Consent QA Template

The repeatable test plan for default-denied, consent update and reject, across all four signals.

Get the QA template →

Check it yourself first

The Tracking Check tests this point along with all the others, in seconds.

Start the Tracking Check →

Asked often

What does a failing "Consent simulation" check mean?

The deep scan drives the cookie banner automatically and compares the accept state with the reject state. If "not possible": check whether an interactive CMP exists, otherwise rely on the static-scan findings.

How do you fix a failing "Consent simulation" check?

If "not possible": check whether an interactive CMP exists, otherwise rely on the static-scan findings.

The fix, delivered

Wired up in days, not sprints.

Findings from the Tracking Check go into a ranked sequence with effort estimates in the Audit Sprint, every module with an acceptance criterion.

To the service Request an Audit Sprint