The Consent Trail: Auditing Your CMS for Cookie Leaks in 2026
Photo: cookie consent banner audit on laptop browser in UK office, via www.modernhoney.com
Most UK web teams have a cookie banner. Far fewer have a reliable answer to a simple question: what does the CMS load before someone clicks accept?
That gap matters because the banner is only the front door. The CMS is the building behind it. Themes, plugins, embeds, tag manager containers and third-party widgets can all fire scripts, set cookies or write to local storage without passing through the consent plugin. Under PECR, non-essential cookies and similar technologies generally need consent, and the ICO expects organisations to be able to explain what is happening and why. In 2026, a banner that looks compliant is not the same as a site that behaves compliantly.
Treat the banner as a claim, not proof
A consent management platform may claim to block categories of tracking. But if a developer adds an embed directly to a template, the platform may never see it. The same goes for a tag added inside a page builder block or a script pasted into a global header.
The audit should test the site as a visitor experiences it, not as the settings screen describes it. Use a clean browser profile, reject all, then browse the pages that matter: homepage, article template, contact page, product or service page, and any page with a form or embed.
Build a script and cookie inventory
Start with a simple inventory. For every cookie and local storage entry, record the name, domain, expiry, whether it is first or third party, its purpose, the consent category it belongs to, and where it is loaded from.
Browser developer tools will show you the network requests and storage. A tag manager preview can show which tags fire and when. Cookie scanners can speed up discovery, but they are a starting point, not the final answer. Document what you find with screenshots and the date of the test.
Check the tag manager container first
Tag manager is the usual suspect. Test with consent rejected and watch the network tab. If analytics, advertising or session recording tags still fire, the container is not doing what the banner promises.
Consent Mode can adjust how Google tags behave, but it does not create consent by itself. Check that default consent states are set before tags load, that the banner updates them correctly, and that custom HTML tags are not quietly bypassing the whole setup. If you use a server-side container, test that too — the same rules apply.
Embeds are the quiet offenders
Video, maps and social embeds are common on UK CMS sites, and many of them set cookies or contact third-party domains before a visitor interacts. Privacy-enhanced video modes help, but they are not a complete answer for every embed.
Test each embed after rejecting consent. Better still, use a click-to-load wrapper so the third party is only contacted when the visitor chooses to play the video or load the map. That is usually easier to explain in a privacy notice than a hopeful note about embedded content.
Form plugins and CRM handoffs
Forms can pull in spam protection, analytics and CRM connectors. Some of those scripts load on page view, not on submission. Check each form after rejecting consent, then submit a test entry and watch what fires.
Keep marketing consent separate from form submission. A contact form is not a licence to drop advertising cookies. If the CRM needs to receive the enquiry, make sure the data flow is documented and the privacy notice explains it.
Cookie expiry, withdrawal and re-consent
Look at the consent cookie itself. How long does it last? Can a visitor change their mind? Does rejecting all actually prevent non-essential cookies from being set?
There is no magic expiry period that fits every site, but consent should be kept current and withdrawal should be as easy as giving consent. Version your consent records so you can show what a visitor agreed to and when. Test the manage preferences route on mobile as well as desktop; it is often where the cracks appear.
Document the audit so it stands up
Write down the date, tester, browser, URLs tested, cookie table, screenshots, tag manager container version, changes made and who owns the next review. Link the audit to the privacy notice and keep a changelog.
This is not about producing a beautiful PDF for its own sake. It is about being able to show a process if a DPO, procurement team or regulator asks how consent is handled. If the CMS or a plugin updates, the audit needs a quick retest.
Put consent on the release checklist
Add a consent test to every CMS release. Check the banner, tag manager, embeds, forms and top templates before launch. Train editors not to paste third-party widgets into pages without a consent-aware wrapper.
A quarterly rhythm works for many UK teams, with an extra check after major plugin or theme updates. The aim is simple: when someone asks what the CMS loads before consent, you can point to a dated record, a tested setup and a named owner.