Website problems

Cookies and trackers set before consent

Under the EU ePrivacy Directive and the national laws implementing it, storing or reading information on a user's device requires prior consent unless the storage is strictly necessary to provide the service the user requested. A page that loads analytics, advertising or heat-mapping scripts before the visitor has answered the banner has already done the thing consent was required for — and the banner that appears afterwards consents to nothing, because the action is complete.

What needs consent and what does not

Strictly necessary storage is exempt: a session identifier, a shopping basket, a load-balancing cookie, a security token, and the cookie recording the consent choice itself.

Everything else requires prior consent. Analytics is not exempt in most EU jurisdictions, although several regulators publish conditions under which a narrowly configured, first-party audience measurement may be treated as exempt.

The rule covers storage and access generally, not only cookies. Local storage, IndexedDB and device fingerprinting are all within scope, which is why removing cookies while keeping the fingerprinting changes nothing legally.

Consent must be prior, specific, informed and freely given, and it must be as easy to refuse as to accept.

A cookie wall that makes refusal impossible, or a banner where accepting is one click and refusing takes three, does not meet the freely-given standard.

Why banners so often consent to nothing

The most common implementation loads the analytics tag in the page head and the consent banner as a component. The tag runs first, the banner appears second, and the sequence is already wrong.

A tag manager makes this worse: the manager loads, fires everything configured, and the consent integration only governs tags added after someone set it up.

Server-side tracking moves the request off the page and does not remove the obligation — the pixel fired on the server is still processing the visitor's data.

Embedded third-party content is frequently forgotten entirely. A video embed, a map, a social widget and a font service may each set cookies or make identifying requests before anyone has agreed to anything.

And rejecting frequently does less than accepting: a banner whose 'reject' path leaves several tags running is a common finding, and it is the one regulators have penalised.

How to check it yourself

Open the site in a private window with developer tools open before the page loads. In the Application panel, clear all storage, then reload and look at what is set before you touch the banner.

Anything beyond the strictly necessary set is the finding, and the cookie names usually identify the service directly.

Check `localStorage` and `sessionStorage` too, not only cookies. The obligation covers storage generally.

In the Network panel, look at requests to third-party domains made before the banner is answered. A request carrying an identifier is processing even if nothing is stored.

Then click reject and repeat. Tags that continue after a refusal are a more serious finding than tags that fire before a choice.

How to fix it

Load nothing non-essential until consent is recorded. The consent state has to be a gate that scripts pass through, not a preference they consult afterwards.

Move every non-essential tag behind the consent manager, including the ones added through a tag manager interface — those are the ones most likely to be outside the gate.

Treat embeds as tags. A video or map embed should be replaced by a placeholder until consent is given, which is also a performance improvement.

Make reject as prominent and as immediate as accept, and make it actually stop the tags rather than recording a preference.

Keep a record of consent, and re-ask when the purposes change rather than treating a past agreement as permanent.

Audit after every marketing change. Tags are added through interfaces that do not go through code review, so the gate is bypassed by ordinary work rather than by mistake.

How VeriFixScan detects it

`cookies.pre_consent` records the cookies set on a first, untouched page load — before any banner has been answered — and reports those that appear.

`privacy.trackers_before_consent` reports the tracking requests made in that same window, which covers the case where nothing is stored and an identifier is still transmitted.

`privacy.cookie_banner` and `privacy.reject_option` report whether a banner is present and whether a refusal path is offered, which is the other half of the requirement.

`privacy.tracker_inventory` and `cookies.third_party` list what was observed, so the finding is evidence rather than a verdict.

The scan observes an untouched load from outside the EU or inside it depending on where it runs, and a site that varies its behaviour by geography may behave differently for a real visitor.

Frequently asked questions

Does analytics need consent?
In most EU jurisdictions yes, because it is not strictly necessary to deliver the service. Several regulators publish narrow conditions under which first-party audience measurement may be exempt; those conditions are specific and worth reading rather than assumed.
Is localStorage covered by the same rule?
Yes. The ePrivacy requirement covers storing or accessing information on a user's device generally, so localStorage, IndexedDB and fingerprinting are within scope alongside cookies.
Does a banner make the site compliant?
Only if nothing non-essential runs before a choice is made, refusing is as easy as accepting, and refusing actually stops the tags. A banner that appears after the trackers have loaded consents to nothing.

Sources

Related

VeriFixScan crawls a site and applies its checks to every page it reaches, keeping the evidence behind each finding. Scanning one website is free.

Scan a website