GDPR on your website: cookies, consent, and data flows

A website is one of the places you process personal data without thinking of it as a system. An IP, a cookie id, a form, a chat window, a video that calls home. GDPR asks about purpose, lawful basis, minimisation, and the rights of the people you identify. Cookie rules — ePrivacy, as implemented in Denmark — also ask whether you may set or read something in the browser before there is valid consent, unless it is strictly necessary for the service the user asked for.

The two rules get mashed into "we need a banner". The banner is UI. It solves nothing if Tag Manager fires Facebook, LinkedIn, and a heat map before anyone has chosen. It also solves nothing if you claim legitimate interest for all analytics while the tool sets third-party cookies and builds a profile across sites.

This is a different problem from where the server lives. Hosting and cloud subprocessors are a residency and DPA conversation. Website GDPR is what leaves the browser for a foreign machine: who gets the URL, the user-agent, the form fields, the session recording. You can keep data in an EU region and still leak a browsing pattern to five US pixels. You must be able to explain both. They do not replace each other.

We write this because agencies love to sell a CMP as finished work. The CMP is a tool. The work is knowing your calls, gating them, and letting the policy describe reality. Without that you are compliant in Figma and in breach in production.

The first layer is the text. The privacy policy and cookie declaration must say who you are, what you collect, why, for how long, and who the processors are. It is boring, and it is necessary. It is also the layer people update last. A policy that still names a tool you turned off, or misses the chat product you turned on last week, is a signal that you do not have an inventory.

The second layer is cookies and similar techniques — localStorage, pixels, fingerprint-like signals. Necessary are those without which the service the user asked for does not work: cart, login session, load balancing, a consent choice you must remember. Anything that measures, retargets, personalises across properties, or records the session typically needs consent. "We use it to improve the site" is a purpose. It is not automatically a lawful basis.

The third layer is the network. Open DevTools. Reload. See what goes out before you click. That is your real data map. A call to an analytics domain, a double-click id, a CNAME that looks first-party but points at a vendor — that is processing. If the banner still says "awaiting choice" and the call already happened, the banner is decoration.

The three layers have to line up. Policy without calls is fiction. Calls without policy are what a supervisory case points at. Cookies without calls can be leftovers. Calls without cookies can still be personal data. Think in flows, not in "did we remember the cookie banner".

Necessary is what makes the action the user asked for work. A cart. A session after login. A load-balancer cookie. A consent cookie that remembers "no thanks". A security token. That is a short list. It does not get longer because marketing calls a tool "essential". If the site works without the call, the call was not necessary.

Analytics is the most common self-deception. First-party, cookieless, aggregated measurement can in some designs be defended without consent — that is a legal call, and it requires that you actually turned identifiers and sharing off. Classic pageviews with a client id that follows the user, mixed with ads, is not that design. Do not assume "statistics are legitimate interest" and leave GTM open. Build the measurement so you can explain it, or ask permission.

Marketing pixels, profiling A/B tools, session replay, most heatmaps, embedded social feeds, and "smart" chat that sends the URL and a snippet to a model are consent-land. Chat can be functional if it is yours, opens only after a click, and does not leak the page to a third party early. The chat that injects a script on every page and starts listening immediately is not.

Embeds are what people forget. YouTube, maps, a booking iframe, a review widget. They often set cookies you have not listed. An honest solution is a placeholder that loads the embed only after a yes — or after a deliberate "show map" click. That is more work than pasting an iframe. It is also what makes the policy true.

The technical requirement is simple to say and easy to fail: no consent-requiring script may evaluate before the choice is yes. Not "must not set a cookie". Evaluate. A script that runs and then "chooses not to set" has often already sent IP and URL. Server-side tagging moves the call. It does not delete it. If you still send the same events to the same vendor, you still have processing — you just made it harder to see in the browser.

On a Next.js site that means: third parties in a loader that reads consent state, not in the root layout as a default. Chat, analytics, pixels, embeds. Consent Mode and similar signals are useful once you already have an honest inventory. They are not a licence to load the tag anyway. A default-on tag with "consent unknown" is the pattern we see most — and it is the wrong default.

On WordPress that means: the theme and the plugins that inject in head, not only the CMP plugin. An SEO plugin, a chat plugin, and a pixel plugin can all ignore the banner. One place that decides what may load beats five plugins that each "support GDPR".

Withdrawal is what you forget afterwards. The user must be able to say no tomorrow. Then you must turn those tags off, delete the cookies you can, and let the policy say how. If "manage cookies" links to a dead anchor, you built a museum. Put it in the footer, and test that a no actually removes the call on the next load.