GDPR Cookie Consent for Developers: What You Actually Need to Build
Most developers know they need a cookie banner. Fewer know what it actually has to do. Showing a banner isn't enough. GDPR compliance means blocking non-essential scripts before they fire, storing a consent record for each visitor, and giving users a clear path to change their mind at any time.
This guide covers exactly what you need to build, the mistakes that trigger enforcement, and how to ship it without writing everything from scratch.
What Does GDPR Actually Require for Cookie Consent?
Two EU laws work together here. The ePrivacy Directive (Article 5(3)) says you need consent before storing or accessing information on a user's device. GDPR (Article 6(1)(a)) defines what that consent must look like: freely given, specific, informed, and unambiguous. Non-essential scripts must not fire until a user actively says yes.
In practice, that means four things: blocking non-essential scripts by default, offering granular consent categories, giving equal visual weight to accept and decline, and providing a way for users to revoke consent later.
What Counts as Non-Essential?
Non-essential cookies are anything not strictly required for your site to function. Google Analytics, Meta Pixel, HotJar, LinkedIn Insight Tag, and most third-party embeds are non-essential. Session cookies, login state, and shopping cart data are generally exempt.
If you're not sure about a script, treat it as non-essential and require consent for it. The cost of over-blocking is minor. The cost of under-blocking is a compliance gap.
The Most Common Developer Mistake
The biggest compliance gap isn't a missing banner. It's a banner that appears while scripts run underneath it. Many developers add GA4 or Meta Pixel in the <head> during development, then add a consent banner later as a separate step. The banner appears. The scripts fire. Nothing is actually blocked. That's non-compliant, regardless of how good the banner looks.
Enforcement in France, Germany, and the Netherlands has specifically targeted sites where tracking fired before consent was confirmed. The focus in 2025 and 2026 has shifted from visual compliance to technical compliance.
How Script Blocking Has to Work
Compliant script blocking means non-essential scripts don't initialize before consent. Not deferred. Not lazy-loaded. Not softened with a timeout. Completely blocked until the user makes an explicit choice.
If you use Google Tag Manager, note that GTM alone doesn't block scripts. It controls when tags fire, but if your GTM container loads before consent logic runs, triggers can fire by default. You need a consent-aware GTM setup or a tool that handles blocking before the container initializes.
Consentify handles this by embedding integration scripts inside the consent snippet itself. They run only after a confirmed consent signal. See the Consentify documentation for the full technical breakdown.
What Valid Consent Looks Like in Practice
Consent must come from an affirmative action. Pre-ticked boxes, "By using this site you agree" notices, and cookie walls that block access unless the user accepts are all non-compliant. European regulators are coordinating enforcement specifically around these UX patterns in 2026.
The accept and decline options must be visually equal. A large "Accept all" button next to a small grey text link for "Reject" is a dark pattern. Both choices need equal prominence and equal accessibility on every screen size.
Storing Consent: What the Audit Trail Needs
You need to demonstrate that consent was obtained. That means storing a record per session that includes a timestamp, the policy version the user consented to, and which categories they accepted or declined.
You don't need names or email addresses. A hashed identifier, a timestamp, and a category breakdown is enough. Regulators increasingly expect proof of consent, not just a consent mechanism. If an authority asks, you need records you can produce.
Consentify stores this automatically in EU-hosted infrastructure and ties each record to a policy version. When you add a new integration, the policy version bumps and returning visitors are prompted to re-consent.
The Revoke Requirement
Users must be able to withdraw or change their consent after the first visit. That means adding a visible button or link on your site that reopens the consent panel. The footer and privacy policy page are the most common places.
In Consentify, any element with the ID revoke-consent-btn triggers the consent panel automatically. Without this element, your setup is legally incomplete. The full setup guide walks through what a complete, compliant installation looks like from start to finish.
Single-Page Apps: What's Different
SPAs don't fully reload on navigation. Consent logic needs to re-evaluate on route changes, not just on initial page load. If you're building with React, Next.js, or Nuxt, your consent tool needs to intercept history.pushState and replaceState events and re-check consent state on each route change.
Consentify handles this via native History API interception. If you're building a custom solution, dispatch a custom event on route changes and listen for it in your consent logic. The Consentify docs cover SPA-specific configuration in detail.
Building It Yourself vs Using a Tool
Building a compliant consent flow from scratch is doable, but it takes longer than most developers estimate. You need script blocking, consent storage, a dark-pattern-free UI, version tracking, a revoke mechanism, and audit log export. That's a week of work at minimum, and it needs ongoing maintenance each time you add or change an integration.
For most projects, embedding one script tag from a dedicated consent tool is faster and more reliable. The Consentify free plan covers one domain with no watermark and no time limit. Paid plans start at 39 NOK per month for developers managing multiple client sites from a single dashboard.