Start here
Before You Fix It: What This Check Means
Pre-consent controls prevent optional tracking from starting before a visitor makes a clear choice. In plain terms, optional tracking should stay off until a visitor gives clear consent. Scavo evaluates two runtime controls in a fresh browser context.
Why this matters in practice: this signal influences reliability, trust, and diagnosability of your production setup.
How to use this result: treat this as directional evidence, not final truth. This result reflects what was observable at scan time and should be verified in your own production context. First, confirm the issue in live output: verify directly in live production output with browser/network tools Then ship one controlled change: Default optional categories to denied before any optional scripts load. Finally, re-scan the same URL to confirm the result improves.
TL;DR: Analytics or ad scripts fire before users give consent, which is illegal under GDPR and actively enforced by regulators across the EU.
CNIL fined Google €150M in 2021 for making cookie rejection harder than acceptance, then escalated to a €325M fine in September 2025 for inserting ads without valid consent (CNIL enforcement records). These aren't just big-company problems — the EDPB's 2024 guidelines confirm that any storage or access to information on user devices (cookies, URL tracking, pixel tracking) requires prior consent. Every unconsented tracker impression is a violation.
What Scavo checks (plain English)
Scavo evaluates two runtime controls in a fresh browser context:
LC-S1: do non-essential request hosts fire pre-consent?LC-S2: do tracking-style cookie/storage identifiers appear pre-consent?
How outcomes are assigned:
Fail: either control detects high-confidence pre-consent trackingInfo/Inconclusive: browser probe could not verify evidence reliablyPass: no high-confidence non-essential request/storage signals observed
Demo mode note: static signals can be shown, but full runtime validation is limited.
How Scavo scores this check
Scavo assigns one result state for this check on the tested page:
- Pass: baseline signals for this check were found.
- Warning: partial coverage or risk signals were found and should be reviewed.
- Fail: required signals were missing or risky behavior was confirmed.
- Info: Scavo could not gather enough reliable evidence on this run to score pass/fail confidently.
In your scan report, this appears under What failed / What needs attention / What is working for legal_preconsent_tracking, followed by Recommended next steps and Technical evidence (for developers) when needed.
- Scan key:
legal_preconsent_tracking - Category:
LEGAL_COMPLIANCE
Why fixing this matters
If tracking starts before choice, users experience surveillance before trust is established. That is a UX and compliance problem at the same time.
Technically, this is often caused by startup-order mistakes: consent state initializes too late, while trackers initialize immediately.
If you are not technical
- Ask for a clean-session test that captures network + storage before any consent click.
- Prioritize key templates (home, pricing, signup, checkout/account routes).
- Require a short fix note describing exactly what moved behind consent.
- Re-run Scavo and confirm control outcomes improve.
Technical handoff message
Copy and share this with your developer.
Scavo flagged Pre-consent tracking controls (legal_preconsent_tracking). Please ensure optional tracker requests and tracking identifiers are blocked until explicit consent is granted, including first paint and first route transition. Share before/after evidence and re-run Scavo.If you are technical
- Default optional categories to denied before any optional scripts load.
- Gate GTM/container triggers by real consent state, not UI visibility.
- Remove or defer inline trackers in shared templates.
- Ensure SPA route transitions re-check consent state before firing optional tags.
- Align client and server event pipelines with the same consent contract.
How to verify
- Open incognito and load the page without interacting with consent UI.
- Inspect network for known non-essential hosts.
- Inspect cookies/localStorage/sessionStorage for tracking-style keys.
- Click accept and confirm optional tracking starts only after consent.
- Re-run Scavo and review
LC-S1andLC-S2evidence.
What this scan cannot confirm
- It is not legal advice.
- It is a high-signal runtime check, not a full legal/compliance audit of all journeys.
- It may miss custom tracker identifiers that do not match known patterns.
Owner checklist
- [ ] Assign owners for CMP logic and tracker runtime controls.
- [ ] Add pre-consent tests to release QA.
- [ ] Re-test after CMP updates, tag changes, or new vendor installs.
- [ ] Keep a tracker inventory with consent-category mapping.
FAQ
Why can this fail even when consent banner exists?
Because a visible banner does not guarantee optional trackers are actually blocked before choice.
What are common pre-consent leaks?
Inline analytics snippets, auto-loaded tag containers, and chat/replay widgets in base layout.
Does this cover server-side tracking too?
Only where runtime evidence exposes it. Server-side systems still need separate consent-aware controls.
What is the first fix to make?
Move optional tag initialization behind a strict default-deny consent state.
Sources
- EDPB Guidelines 05/2020 on Consent
- ICO: Cookies and similar technologies
- GDPR text (EU 2016/679)
- California AG: CCPA overview
- California Penal Code §631 (CIPA)
This guide is operational guidance, not legal advice.
