The GDPR Cookie Consent Checklist: What Your Website Actually Needs in 2026

Cookie compliance is not governed by one law — it sits at the intersection of two. The General Data Protection Regulation (GDPR) governs how personal data is processed once it has been collected. The ePrivacy Directive (sometimes called the "Cookie Directive") governs the act of storing or accessing information on a user's device — which includes setting a cookie. Together, they create a layered obligation: the ePrivacy Directive requires prior consent before a non-essential cookie can be set, and GDPR governs everything that happens with the data after that.

For website operators, this means getting a cookie banner up is not enough. The consent you collect has to meet specific legal standards, the cookies have to be actually blocked until consent is given, and the whole system has to be auditable. Here is what that looks like in practice.

Which cookies are exempt

Not every cookie requires consent. Cookies that are "strictly necessary" for the service the user has explicitly requested are exempt under the ePrivacy Directive. This covers a narrow set of use cases: session identifiers that keep you logged in, security tokens (CSRF protection), load balancer cookies that route you to the right server, and shopping cart cookies on an e-commerce site. That is broadly it.

Everything else requires consent before the cookie is set. This includes:

• Analytics cookies — Google Analytics 4, Matomo, Adobe Analytics
• Advertising and retargeting cookies — Meta Pixel, Google Ads, LinkedIn Insight Tag
• Personalisation and A/B testing cookies — Optimizely, VWO
• Heatmap and session recording tools — Hotjar, Microsoft Clarity, FullStory
• Live chat widgets that set persistent tracking cookies — Intercom, Drift, HubSpot Chat
• Social media embeds — YouTube, Twitter/X, Facebook Like buttons

The key question is not what the cookie is called — it is whether the cookie is necessary for a function the user has actively requested. If the answer is no, you need consent.

What valid consent actually means

GDPR Article 4(11) defines consent as "freely given, specific, informed and unambiguous". Under ePrivacy, consent must be given before the cookie is set — not after. Unpacking this for cookie banners:

• Freely given means users cannot be forced to consent. Cookie walls — "accept cookies or you cannot use this site" — are generally unlawful unless the site offers a paid cookie-free alternative.
• Specific means consent must be given per purpose. Blanket "I agree to cookies" is not specific enough; users should be able to accept analytics without accepting advertising.
• Informed means the user must understand what they are consenting to — which cookies, set by whom, for what duration, and for what purpose.
• Unambiguous means an active action is required. Pre-ticked boxes, silence, or scrolling do not constitute consent.
• Withdrawable means users must be able to change or revoke their consent as easily as they gave it.

The 8-point compliance checklist

1. No non-essential cookies fire before the banner appears. This is the most commonly violated point. Analytics, advertising, and tracking scripts must be blocked at the network level until consent has been given. A banner that appears while scripts are already loading in the background is not compliant.
2. The banner has a genuine Reject option at the same visual level as Accept. If "Accept all" is a large, bright button and "Reject" is a small grey link buried in a settings panel, that is a dark pattern. Reject must be as prominent as Accept.
3. No pre-ticked boxes. Any toggle or checkbox for non-essential categories must be off by default. Ticking analytics or advertising by default — even with a label — does not constitute valid consent.
4. Purposes are described in plain language. "Improve your experience" or "enhance our services" tells users nothing. Each category should explain which specific tools are used, what data those tools collect, and why. "We use Google Analytics to count page visits; data is stored by Google for 26 months" is the kind of specificity required.
5. Granular consent by category. Users should be able to accept strictly necessary cookies only, accept analytics but not advertising, or accept all. Forcing users to pick between "accept all" and "reject all" with no middle ground fails the specificity requirement.
6. A withdrawal mechanism is easily accessible. A "Cookie settings" or "Manage consent" link must appear somewhere permanent — typically the footer — so users can revisit their choices without needing to clear their cookies. Regulators have specifically called out sites where withdrawal is buried or non-functional.
7. Consent is logged with a timestamp and version. Under GDPR Article 7(1), you must be able to demonstrate that consent was obtained. Your CMP should record when consent was given, what version of your privacy notice was shown, what categories were accepted, and the user identifier. This is your evidence if the DPC or any other regulator asks.
8. Third-party scripts are blocked until their category is consented to. If a user only consents to analytics, advertising scripts — Meta Pixel, Google Ads, LinkedIn — must remain completely blocked. A CMP that sets cookies but does not actually prevent scripts from loading is cosmetically compliant at best.

The most common failures in the wild

Running automated scans across hundreds of websites reveals the same failures appearing repeatedly. The three most common are:

• GA4 loading before consent via GTM. A CMP is installed, but Google Tag Manager fires GA4 on its default "All Pages" trigger before the CMP has loaded and before any user interaction. The banner appears, but GA4 has already set its cookies.
• The Meta Pixel hard-coded in the page source. Marketing teams often add the Meta Pixel directly to a page template outside of GTM, bypassing the CMP entirely. No matter what the user selects in the banner, the Pixel fires on every page load.
• The LinkedIn Insight Tag firing on page load. LinkedIn's Insight Tag is commonly added as a site-wide snippet in a tag manager or directly in the HTML, and is rarely included in cookie consent category blocking. It sets its own persistent cookies silently.

All three failures share the same root cause: a disconnect between what the CMP is configured to block and what the site is actually sending. The banner may look correct, but the underlying scripts are not gated.

Find out how many of these eight points your site passes

ConsentScan audits your cookie setup in a fresh browser session and tells you exactly what is firing before consent and what your banner is failing to block.