A consent banner only works if every optional tracker waits for the visitor's choice. Scripts added directly to the page, injected by a plugin, or loaded by a tag manager can run before anyone clicks. Load the site as a new visitor, list every third-party request and cookie before a choice and after Reject, then block anything optional until consent is given.
This guide covers check 09: Compliance and audit surface in the Zenveus Production Readiness Standard.
For builders
A cookie banner asks visitors what they agree to, but it doesn't stop anything by itself. If a tracking script is pasted into the site or added by a plugin, it can run before anyone clicks, or even after they click Reject. Check what loads for a brand-new visitor and for someone who rejected, then make every optional tracker wait for consent.
A scoped repair request
Use this prompt in Lovable, Cursor, Replit, or Claude Code with the relevant server files available.
Audit my site's tracking and consent setup. List every third-party script and how it is loaded (theme, plugin, inline snippet, tag manager). For each, say whether it is necessary, analytics or marketing, and whether it currently waits for the matching consent. Show the smallest change that makes optional scripts inert until consent using my existing consent tool, without removing the trackers or changing what loads after the visitor accepts.The same failure may appear as
Find the failure layer
Each check removes a class of causes. Keep the first failing result, its timestamp, and the production log beside it.
Open a private window, clear site data, load a page and wait without touching the banner. In the browser's network panel, filter to third-party domains and note every request.
In the browser's storage panel, list cookies and local storage entries set by the page before a choice.
Click Reject, load another page, and repeat the request and cookie check.
Search the page source for each tracker's domain or global variable, then trace it to a theme file, plugin, tag manager container or header-script setting.
curl -s https://example.com/ | grep -oiE '<script[^>]*>[^<]{0,200}' | grep -iE 'track|analytics|pixel|insight'Ranked diagnosis
The consent tool only holds back scripts it recognises, so a tracker added later loads freely.
A small inline script creates the tracker's script tag at runtime, so the external URL never appears in the HTML the blocker inspects.
A plugin prints its own tracking code into the page head, outside the consent tool's control.
The container loads before consent, or its tags have no consent conditions.
Step-by-step repair
Work in the consent tool's configuration, the tag manager container, and any theme file, plugin setting or header-scripts box that prints tracking code.
Production safety ruleNever disable access controls, expose service keys, or add wildcard CORS as a routine shortcut.
For each third-party script, decide whether it is strictly necessary, analytics or marketing. Visitor-identification and advertising tools belong in marketing.
Render optional scripts as inert (for example type="text/plain" with a category attribute) and let the consent tool turn them into real scripts only after the matching choice.
Make sure a Reject choice, and a browser's Global Privacy Control signal where you honour it, keep marketing tags off on every later page.
Route future tracking code through the consent tool or tag manager consent rules, never straight into the theme or a header-scripts box.
Implementation example
<!-- Before: runs on every page load -->
<script>(function(){ /* tracker loader */ })();</script>
<!-- After: inert until the consent tool activates the marketing category -->
<script type="text/plain" data-consent-category="marketing">(function(){ /* tracker loader */ })();</script>The attribute name depends on your consent tool; use the one it documents. The tool must swap the type to a runnable script only after the visitor accepts that category.
Prove the repair
Run these checks with synthetic data in your test environment, then repeat the relevant acceptance checks after deployment.
When the built-in AI fix makes it worse
Pause generated changes, restore a known working branch, and capture one failing request with its logs. Change one layer and rerun the allowed and denied checks before proceeding.
Engineering handoff
We trace one production request through the complete path, isolate the failing boundary, and leave behind evidence your team can repeat.
Every third-party script, cookie and request, with where it is loaded from.
What runs before a choice, after Reject and with Global Privacy Control.
Whether the cookie and privacy policies list the tools that actually run.
How new tags are added so they can't bypass consent again.
Typical repair pattern
A fresh visitor and a visitor who rejected see no optional third-party requests or cookies, and accepted categories load as expected.
Before the next release
Clear answers
No. The banner records a choice; the site still has to stop optional scripts from running until that choice allows them.
It depends on the law where your visitors are and how the tool is configured. In the UK and EU, regulators generally treat analytics and advertising cookies as needing consent; check the guidance that applies to you.
Blocking the script stops new cookies. Existing ones stay until they expire or the visitor clears them, unless your consent tool removes them on Reject.
Run the verification checks on this page in a fresh private window, both before any choice and after Reject. Then accept marketing and confirm the trackers you still want do load.
Related symptoms
Official documentation and library references
Free next step
The free tool helps you inspect this symptom. Its result does not establish whether the whole app is production ready.
Take it further
This fix solves one symptom. A guided self-assessment walks you through the rest of the app, one session at a time, and ends with a report and a ranked fix list you can act on or hand to a developer.
Every fix breaks something else? Freeze what works, trace bugs to a few root causes, add guardrails and leave with a ranked plan.
See the sprint Preparing to launch · $997-Day Launch Readiness SprintTest the running system against the nine-area Production Readiness Standard and reach a Ready, Conditional release or Hold decision with a ranked fix list.
See the sprintPlanning more than one stage? Founder Bundles combine the guided products from $149 and save up to $405.
The Verdict
We can see the symptom from here. What we cannot tell you from outside is whether it is contained or structural. A scanner collects evidence. A named senior engineer makes the decision. For $299, a named senior engineer reads your code and signs a written Verdict against the nine checks in the Zenveus Production Readiness Standard. The 48-hour clock begins when the required access and context are available. If the report does not give your developer a list they can act on, you do not pay.
The 48-hour clock starts when the required access and context are available.
If each fix breaks something else, you probably have a few root causes, not dozens of bugs. Find out where you stand.
Free. No email needed. Close this and we won’t show it again during this visit.