Technical compliance
Cookie banner GDPR requirements
When German websites need a consent banner, what equal reject means, and how to stop tags firing before accept. TTDSG plus GDPR, written for operators.
TL;DR
- In Germany, storing or accessing information on a device (cookies, localStorage, pixels, SDKs) usually needs prior consent unless the storage is strictly necessary for a service the user requested.
- GDPR covers the personal data processing that follows. TTDSG/ePrivacy-style rules cover the device access. Both frames matter for a live banner.
- Reject must be as easy as accept. Pre-ticked marketing boxes fail. Analytics and ads must stay silent until the user opts in.
- A banner alone is incomplete. Pair it with an accurate privacy policy, processor contracts, and a retest after every new pixel. See the GDPR website checklist and GDPR audit.
Why this page exists
Most banner failures are technical: tags load before anyone clicks.
Teams often ask for a “GDPR cookie banner” as if the UI text were the whole job. On production sites, the failure mode is different: Google Analytics, Meta, LinkedIn, Hotjar, or a chat widget already talk to the network on first paint, while the banner is still asking for a choice.
This article covers Germany-facing business sites: marketing WordPress builds, B2B lead-gen pages, and product marketing sites that run analytics or ads. It supports the commercial GDPR audit service. For cost context, see GDPR audit cost.
This is operator guidance for implementation checks. It is educational. Entity-level legal bases and counsel review stay with your advisers.
A cookie banner without blocked tags is decoration. Consent requires blocked tags until accept.
TTDSG + GDPR
Two layers: device access, then personal data processing.
Device layer (TTDSG / ePrivacy-style rules in Germany): storing or reading information on the end user’s device generally requires prior consent, unless the storage is strictly necessary to provide a service the user explicitly requested (for example, a load-balancer cookie that keeps a logged-in session alive).
Processing layer (GDPR): once identifiers or behavioural data qualify as personal data, you need a lawful basis, transparent notices, and the usual controller duties. For marketing and most analytics, that basis is typically consent.
In practice for German websites: treat non-essential cookies, pixels, and similar tech as consent-gated. Necessary tech stays on; everything else waits. Your privacy policy must describe what actually runs after accept.
When a banner is required
Quick map: necessary storage vs consent-gated tools.
| Situation | Typical treatment | Banner / consent note |
|---|---|---|
| Session / security cookies needed to run the site the user asked for | Often necessary | May run without a marketing-style opt-in; still document them |
| GA4, Meta Pixel, LinkedIn Insight, Hotjar, A/B tools | Consent-gated | Do not load scripts or set IDs until accept |
| Embedded YouTube / maps that set third-party cookies | Usually consent-gated or privacy-friendly embed | Block or use a consent-aware embed pattern |
| Chat widgets that set visitor IDs on first load | Often consent-gated | Load after accept, or use a mode that avoids non-essential storage |
| Strictly first-party preference cookie for “language = DE” after a user choice | Case-by-case; keep minimal | Document purpose; avoid piggy-backing marketing IDs |
Practical checklist
Eight cookie-banner checks before you call the site ready.
01
Inventory every cookie and similar tech
List cookies, localStorage keys, pixels, and SDKs by purpose (necessary, functional, analytics, marketing). Note who sets them. If it is missing from the inventory, it will be missing from the privacy policy.
02
Block non-essential tags until accept
In a fresh private window, reject all. Confirm GA, ads, and heatmaps make no network calls and set no IDs. Accept analytics only and confirm marketing stays off if it was declined.
03
Equal ease for reject and accept
Reject-all must be visible on the first layer with comparable effort to accept-all. Buried “reject” behind three menus fails the UX test operators use in reviews.
04
No pre-ticked marketing or analytics
Optional categories start unchecked. Silence or a closed banner must mean non-essential tools stay off. Pre-ticked boxes are a classic fail.
05
Consent record and withdraw path
Store what was chosen and when. Offer a clear way to change or withdraw consent later (footer link is normal). Withdrawal should unload or stop non-essential tags on the next load.
06
Privacy policy matches the live stack
Every tool that runs after accept must appear with purpose, categories of data, and recipients. Update the policy when marketing adds a pixel.
07
CMP vs custom: pick what you can maintain
A maintained Consent Management Platform (CMP) with auto-blocking often beats a hand-rolled script that breaks on the next GTM publish. Custom is fine if engineering owns blocking tests in CI or a release checklist.
08
WordPress: plugins, GTM, and theme footers
Audit plugins that inject analytics on their own. Wire GTM so tags respect the CMP signal. Remove duplicate hard-coded GA snippets from the theme. Retest after every plugin update.
Common failures
What we see when tags ignore the banner.
Tags fire before accept: scripts in the `<head>`, theme footers, or GTM “All Pages” tags that ignore the consent signal. Fix: hard-block or Consent Mode / CMP auto-block until grant.
Reject is harder than accept: accept-all as a big button, reject buried under “settings”. Fix: same layer, same effort.
Banner UI without a processor story: the CMP vendor itself may process consent logs. Put them in the privacy policy and keep a DPA where required.
WordPress double-loading: MonsterInsights / Site Kit / theme code plus GTM all fire GA. Fix: one injection path, consent-gated.
Fifteen-minute smoke test
Run this in a private window on production.
✓
Clear site data. Load homepage. Do nothing on the banner: non-essential network calls stay absent.
✓
Click reject all: still no analytics/ads IDs or requests.
✓
Click accept analytics only: only those tools appear; marketing stays quiet if declined.
✓
Reopen preferences from the footer and withdraw: next load keeps non-essential tools off.
✓
Open the privacy policy: every live tool from the network panel is described.
Next steps
Banner fixed. Widen the lens to the full website stack.
Use the GDPR website compliance checklist for privacy copy, DPAs, forms, and DSAR paths. When stakes are high (enterprise review, years of unmanaged pixels), commission a technical GDPR audit. Pricing context: GDPR audit cost.
If Google Analytics is in scope, read Google Analytics and GDPR next: consent before load, contracts, and configuration choices.
Common questions
What people ask about cookie banners in Germany.
Is a cookie banner mandatory in Germany?
If your site stores or accesses non-essential information on the user’s device (typical analytics, ads, many embeds), you generally need prior consent before that happens. Strictly necessary storage for a requested service is treated differently. Most marketing sites need a real consent mechanism, plus GDPR-compliant processing for the personal data that follows.
What is the difference between TTDSG and GDPR for cookies?
TTDSG-style rules focus on accessing or storing information on the device. GDPR focuses on processing personal data. A compliant setup addresses both: consent before non-essential device access, and lawful, transparent processing afterward.
Must “Reject all” be as easy as “Accept all”?
Yes in practice for a valid consent UX: users must be able to refuse as easily as they accept. Hiding reject behind nested settings while accept is one click is a common finding in reviews.
Can marketing checkboxes be pre-ticked?
No. Consent must be freely given and unambiguous. Pre-ticked analytics or marketing options do not meet that standard.
Is a CMP required, or can we build a custom banner?
Neither law requires a specific brand of CMP. You need valid consent and effective blocking. Many teams use a CMP because auto-blocking and logs are easier to maintain. Custom works if you own the blocking tests and keep them current after every GTM or plugin change.
Does a cookie banner alone make a German website GDPR compliant?
No. You still need an accurate privacy policy, processor agreements, a DSAR path, and forms that match your notices. The banner is one control. See the full website checklist or book a GDPR audit.
Start here
Ready to talk.Send us the brief.
or book a 15-minute call →or email us directly →
Not sure where to start? Send the page, workflow, or backlog causing the problem. We will tell you whether it needs a scope call, a short diagnostic, or a different first step.