TL;DR
- Consent compliance is determined by what hits the network — not what the code looks like or what the banner says
- A 3-minute DevTools protocol gives you a pass/fail answer for any single URL, no login or CMS access required
- The manual method doesn't produce evidence — an automated scan does, with timestamps and shareable results
- The only thing you need from the client is the URL
Verdict
A consent banner is a technical configuration. Its compliance or non-compliance is observable entirely from the outside — through the network requests a new visitor’s browser generates on page load. You do not need GTM access, CMS access, or even the ability to view source. The network trace is the ground truth.
What you’re actually measuring
The question “is this consent banner compliant?” reduces to one specific observable fact: do any requests reach tracking domains before the user interacts with the banner?
Not: does the banner look correct? Not: does the CMP settings panel show “configured”? Not: does the privacy policy say the right things?
The DPAs who issue fines for pre-consent violations are looking at network logs. CNIL’s enforcement methodology for its cookie investigations involves automated network interception tools that capture requests before any user interaction. The Datatilsynet uses the same approach. They are measuring the same thing you can measure from a browser.
This is the only audit that matters. Everything else — banner UX, cookie policy text, CMP configuration screenshots — is secondary evidence. The network trace is primary.
The 3-minute manual protocol
You need: Chrome or Firefox. No extensions. No login to anything.
Step 1 — Open a clean session
Open a new Private/Incognito window. This clears any stored consent from previous visits. Consent stored from a prior session could suppress the banner and show a false-pass result.
Step 2 — Open DevTools before navigation
Open DevTools (F12) and go to the Network tab before typing the URL. Enable “Preserve log” and disable cache. This ensures you capture requests from the first byte of the page load, not just after DevTools is initialised.
Step 3 — Load the URL and stop
Navigate to the client’s URL. Let the page fully load. Do not click the consent banner. Do not scroll. Do not interact with anything. You are recording the pre-interaction state.
Step 4 — Filter the network log
In the Network tab filter bar, search for known tracking domains: google-analytics, facebook.net, tiktok.com, bat.bing.com, doubleclick.net. Any matches that appeared before you touched the banner are pre-consent violations. The timestamp column shows when each request fired.
Step 5 — Test the decline path
Clear the network log. Click “Decline All” or “Reject” on the banner. Watch for 3–5 seconds. Any tracking requests that appear after rejection are post-decline violations — a second category of enforcement risk, independent of the pre-consent findings.
Your site is leaking data before consent.
Free headless-browser scan. Catches GA4, Meta Pixel, TikTok and more firing before the click. Results in 10 seconds.
Run a free scan →What the results mean
Pass: No tracking requests visible before interaction. No tracking requests visible after decline. The consent configuration is performing as required.
Pre-consent fail: Tracking requests appear before any banner interaction. The site is processing data without a lawful basis. This is the most common finding — see the full pre-consent tracker breakdown for what each offender looks like and how to classify it.
Post-decline fail: Tracking requests appear after clicking Reject. The CMP is not wired correctly to block tags on rejection. This is a separate violation and requires a separate fix — typically a missing consent-state check in GTM triggers.
No banner detected: The page loads with no CMP script initialising. If the site runs any analytics or advertising, this is a structural compliance failure — not a misconfiguration, but an absent configuration. The CMP setup checklist covers what a correct implementation requires.
When the manual method isn’t enough
The DevTools protocol answers the compliance question but doesn’t produce anything you can hand to a client. There is no timestamp record, no tracker classification, no GDPR article citation, and no evidence that a specific URL had a specific issue on a specific date.
For client-facing work, you need something that produces a document. A screenshot of DevTools is not a document — it can be challenged, it has no chain of custody, and it requires the client to trust your interpretation of what they’re looking at.
The manual method is also rate-limited by time. If you manage ten client sites, running a DevTools audit on each is a half-day of work. If a new GTM deployment goes out on Tuesday, you won’t know it introduced a violation until the next manual audit.
The automated scan runs the same network interception in a headless browser — clean state, no stored consent, complete pre-interaction log — and returns a timestamped result with tracker classification and a shareable link. It also simulates clicking Decline and captures the post-decline state. For agency use, each result is a dated evidence record you can include in a client report.
For the full GTM-level audit workflow, see how to read a GTM container audit for GDPR leaks.