What one UK retailer's basket page taught us about single-page cookie audits

Most cookie-banner checks stop at the homepage. UK law doesn't: non-essential cookies can't be set before the visitor has consented anywhere on the site, not just on the page a scanner happens to load first. We ran a three-page audit — homepage, basket, one product page — against a UK homeware retailer to see what that difference actually looks like in practice.

The result wasn't the leak we expected

Going in, this slot was meant to be a "reject-all is decorative" story. It isn't one this time: the site scored 96/100 with zero non-essential vendors observed before consent, and nothing fired again after the visitor clicked reject. That's a real pass, not a technicality — the two-pass test (load untouched, then load-and-reject) found nothing to fail.

We're reporting that straight rather than reaching for a leak that isn't there. What the three-page crawl did catch is more useful anyway.

The vendor the homepage never showed

Google Maps didn't appear anywhere on the homepage in any of the three consent states we tested. It appeared only on the basket page, and only after the visitor had made a consent choice. A single-page scanner — which is what most free "is my cookie banner working" tools are — would have reported this site as running exactly one functional vendor (Google Fonts) and missed the second one entirely, simply because it never loaded the page where that vendor lives.

Both Fonts and Maps were classified as essential/functional here, not as a consent failure — loading a typeface or a map isn't the same as tracking a visitor, and Google Tag Manager's own consent settings are configured per tag, not once for a whole container, which is exactly why a vendor can behave correctly on one page and still need its own, separate consent configuration checked on every other page it appears on.

The failure mode that actually matters here

The one finding worth fixing wasn't a consent defect. The audit's browser session logged five console errors on page load — CORS-blocked font requests and a couple of failed resource loads — and that matters for reasons beyond page polish: a thrown JavaScript error stops the rest of that script from running, including whatever tracking call was supposed to fire after it. A site can look clean in an audit not because its tags are correctly gated, but because a broken script upstream never got the chance to fire at all. The fix here is unglamorous — resolve the CORS errors, then re-run the two-pass consent test — but it's the difference between "compliant" and "we got lucky this time."

One more finding: a single third-party host we couldn't attribute to a declared vendor. Not a violation on its own, but on any site, an unclassified host is one nobody has decided whether to keep.

Why six other names never got tested

Setting this up, we tried six other large UK retailers first. All six answered the audit with a bot-management block — Akamai on some, Imperva/Incapsula on others — rather than serving the actual page. That's not a consent finding either, but it's worth knowing: if your own monitoring tooling gets the same 403 a browser wouldn't, you may be flying blind on exactly the pages you most need visibility into.

And a genuine limit of this run, stated plainly: it came from one data-centre IP, once. A site that varies its banner by visitor geography — which several large retailers do — will look different to a real UK visitor than it did to us today. Test from the market you actually sell into before you conclude anything from a single run.

A one-page scan can't tell you whether a vendor like this shows up only on your basket or checkout page — that needs a crawl across the pages that actually matter. The free scan at tagpatrol.app checks your homepage's pre-consent state in about a minute; if that's clean, the next question is whether the rest of your site is too.

Written by TagPatrol's AI content team and reviewed under human direction.