The pre-launch consent audit: 12 checks before your new site goes live
September 28, 2026 · ConsentVigil
Site launches and redesigns are the most common moment a working consent setup breaks. Tag managers get rebuilt from memory, vendors get re-added by the new agency, and the banner goes back up in its default configuration. Run these twelve checks before launch and you catch the failures while they are still cheap.
Why launches break consent
A consent setup is really three things glued together: the banner, the blocking logic that honors the visitor's choice, and the inventory of everything that tracks. A rebuild usually preserves the banner and loses the other two. The new site fires a different set of trackers, the old consent state mappings no longer match the new tag names, and nobody notices because the banner still looks right.
This is how sites end up with a compliant-looking banner sitting on top of trackers that never asked. Visitors cannot see the breakage. Regulators and automated scanners can. The fix is to audit consent the same way you audit a launch: against a checklist, before go-live, with someone responsible for each item.
The twelve checks
- Confirm the banner appears on every page template, not just the homepage. Test a blog post, a landing page, and the checkout or contact flow.
- Verify the reject path takes one click. If accepting is one click and rejecting is a journey through settings, fix it before launch.
- Scan the staging site with tracking detection and list every tracker that fires before any choice is made. Each one needs a consent category or a removal.
- Compare the pre-launch tracker inventory against the live one. Every tracker on the new site that was not on the old site needs a category assignment.
- Test consent state persistence across pages. Accept on the homepage, then check the preference is remembered on a product page and after a refresh.
- Confirm tag manager triggers actually read the consent state. Fire the analytics tag in the debugger and watch it stay blocked under "reject all."
- Check subdomains and localized versions. Consent given on the marketing site should carry to the app subdomain and the language variants.
- Review every embed: videos, maps, review widgets, chat tools, scheduling forms. Each loads third-party code and needs its own consent story.
- Audit the mobile templates separately. Mobile banners are often a different component with its own, older configuration.
- Confirm the preference center link works and loads the current settings. A dead preferences link is a finding in every enforcement action.
- Check that withdrawing consent actually stops tracking. Consent must be as easy to withdraw as to give, and the technical off-switch must work.
- Document everything. Save the scan, the category mapping, and the configuration. The audit trail is what turns a finding into a fix.
Who owns each check
Assign the banner and preference-center items to whoever configured them, the tag and tracker items to whoever owns the tag manager, and the embed inventory to whoever chose the vendors. Consent failures at launch are almost always ownership failures: everyone assumed someone else reconfigured the blocking logic. Put a name on each line of the checklist and the launch review becomes a real review.
After launch
Run the same scan in the first week after go-live and compare it to the staging scan. Launches have a way of reintroducing things: a marketing team member pastes a snippet on day three, a plugin update re-enables a tracker on day five. Consent is not a launch-day property; it is a maintained one. Schedule the scan monthly and you will never be surprised by your own site again.
The tooling for the audit
You do not need expensive tooling for the pre-launch audit. A tracker scan from any reputable scanner, your browser's developer tools, and the tag manager's preview mode cover most of the checklist. The scan gives you the inventory; the developer tools let you watch what fires under each consent state; the preview mode shows you which tags the consent logic actually gates. What matters is not the tool but the discipline of running the same scan the same way every time, so the results are comparable across builds.
Save every scan with the build number it tested. When a tracker appears in the production scan that was not in the staging scan, the first question is what changed between the two builds, and the saved scans answer it in minutes. Teams that keep this history resolve consent regressions in an afternoon. Teams that do not spend a week arguing about when the tracker appeared. The audit trail is the cheapest insurance in the whole checklist.