Having a cookie banner is not the same as being compliant. The rules care about what actually happens in the visitor's browser — before consent, after reject, and after accept.
Most websites with consent problems have a banner. The banner is the visible part; the compliance question is whether the trackers behind it actually wait for permission, and whether "reject" actually means reject. This guide covers what the rules require in plain terms, the failure patterns that show up again and again, and a simple three-phase method for auditing your own site. One note up front: this is educational content about how the rules work in practice, not legal advice — for decisions about your specific situation, talk to a lawyer.
Does GDPR require consent before cookies are set?
Yes, for anything that is not strictly necessary for the site to work. The prior-consent rule for cookies comes from the ePrivacy rules, and the GDPR defines what valid consent looks like: freely given, specific, informed and unambiguous. In practice this means analytics, marketing and social media trackers must stay silent until the visitor actively agrees — a banner that appears while those trackers are already firing does not count.
"Strictly necessary" is narrower than most site owners hope. A session cookie that keeps a shopping basket together, or the cookie that remembers the consent choice itself, qualifies. Analytics does not — however harmless it feels — and neither do marketing pixels, A/B-testing tools or personalisation scripts. The timing is the whole point: consent given after the data has already been collected protects nobody.
Does rejecting cookies have to be as easy as accepting?
Yes. European data protection authorities have made clear that refusing consent must not be made harder than giving it. A banner with a prominent accept-all button and a reject option buried behind several clicks of settings menus fails that test — and consent obtained that way is not valid consent, because it was not freely given.
The practical benchmark is symmetry. If accepting takes one click on the first layer of the banner, rejecting should take one click on the same layer. Designs that make "Accept all" a bright button and hide refusal behind "Manage preferences", pre-ticked boxes, or walls of toggles are exactly the patterns regulators have pushed back on.
What are the most common cookie consent mistakes?
The three most common failures are trackers that load on page load before the visitor has chosen anything, banners where clicking reject makes the banner disappear but the trackers fire anyway, and third-party embeds — video players, maps, social widgets — that set cookies the site owner never knew about. All three are invisible from the outside: the site looks compliant because the banner is there.
- Trackers firing on page load. The most frequent failure by far. Analytics or marketing tags are added directly to the page template instead of behind the consent tool, so they run the instant the page loads — before the banner has even rendered. The banner then asks a question whose answer no longer matters.
- "Reject" that only hides the banner. The consent tool is installed, but the tags are not wired to it. Clicking reject dismisses the banner and the visitor believes they have refused — while every tracker continues exactly as if they had accepted. This is worse than no banner, because it documents a choice the site then ignores.
- Third-party embeds nobody audited. An embedded video player, a map, a social feed or a chat widget can set its own cookies and call its own trackers the moment it loads. The site owner never wrote that code and often has no idea it happens — but it happens on their pages, under their responsibility.
What these have in common is that they are invisible in normal use. The site owner sees a professional-looking banner and assumes the job is done. The gap only shows up when someone actually watches the browser traffic — which is exactly what an audit does.
How do I audit my own website's cookie behaviour?
Test the site in three phases. First, load a page in a fresh private browser session and note every cookie and tracking request that appears before you touch the banner. Second, start a new session, click reject and browse a few pages — nothing non-essential should be added. Third, do the same with accept and compare: the difference between the phases shows exactly what your consent banner actually controls.
The mechanics: open a private window, open the developer tools, and watch two places — the cookies list under the storage or application tab, and the outgoing requests in the network tab. In phase one, anything beyond strictly necessary cookies is a finding. In phase two, the picture should look essentially the same as phase one. If phases two and three look identical, your reject button is decorative. Repeat on a few representative pages, especially ones with embeds — the homepage alone rarely tells the whole story.
Where SiteControl fits
Doing this by hand across a whole site is tedious, and it goes stale the next time someone adds a tag. SiteControl's on-demand privacy scan runs exactly this three-phase audit — before consent, after reject, after accept — in a real browser, classifies the trackers it finds, counts the cookies set before consent, and turns the gaps into findings with remediation steps referenced to the relevant GDPR articles. It runs when you ask it to, so you can re-check after every change to your tags or banner.
The privacy scan is part of the same product that crawls your site for security headers, Core Web Vitals, accessibility and technical SEO — so consent behaviour sits in the same prioritised list of findings as the rest of your site's health, in plain language for owners and full detail for developers.