A website can display a polished cookie banner and still contact Google, Meta, a video platform, or another third party before the visitor makes a choice. The banner is only the interface. The real test is the site’s behaviour underneath it.
For a German audience, the starting point is not whether a particular cookie exists. Section 25 TDDDG addresses storing information on, or accessing information from, a user’s device. Consent is generally required unless the operation is used solely to transmit a communication or is strictly necessary to provide a service explicitly requested by the user.
This article explains what a developer can verify. It is technical guidance, not a legal opinion on a specific website.
Executive Summary
- A consent banner is not evidence that consent-dependent scripts are blocked.
- Test the first page load, Reject, Accept, withdrawal, and a returning visit as separate states.
- Requests, pixels, local storage, fingerprinting, and embeds matter, not only cookies.
- Necessary services should be documented individually. “We need analytics” does not make analytics technically necessary.
- A useful audit produces reproducible network evidence and a remediation list, not a generic compliance score.
The banner and the website are two different systems
Compliance depends on whether the implementation respects the choice, not whether the page contains a modal. The German data protection authorities’ cookie-banner guidance says consent-dependent scripts should be blocked while the banner is shown and should run only after an active consent action.
That creates a simple engineering requirement: the consent state must control script and resource loading. Hiding a banner, recording a button click, and loading every integration regardless is not consent management.
What to test before any click
Open a clean browser context and record every external request before interacting with the banner. This catches the most common implementation failure: scripts that start before the consent manager is ready.
Check:
- network requests to analytics, advertising, session-replay, chat, maps, video, font, and CDN domains;
- cookies created by first and third parties;
- localStorage, sessionStorage, IndexedDB, and other browser storage;
- pixels and server-side tracking calls;
- preconnect, preload, and iframe activity;
- identifiers or full page URLs sent in request parameters;
- whether a tag manager is present and which tags it fires.
External fonts deserve attention even when they set no marketing cookie. Loading a font from a third party still makes a network request and discloses connection data such as the visitor’s IP address to that provider. Self-hosting a licensed font is often the simpler engineering choice.
Reject must produce a different result
A working Reject action changes the site’s observable behaviour. Repeat the same capture after rejecting optional purposes and compare the request log and storage state.
| Test state | Expected technical result |
|---|---|
| Fresh visit | Consent-dependent services remain blocked |
| Reject all optional | Optional services remain blocked and the preference persists |
| Accept analytics only | Analytics may load, advertising and other unselected services do not |
| Accept all | Approved optional services may load |
| Withdraw later | New optional processing stops and the stored choice changes |
The comparison should be provider-specific. A single green badge saying “passed” hides too much. The audit should show which domain was contacted, at what stage, by which page component, and under which consent state.
Cookies are not the full scope
A scanner that checks only document.cookie will miss important activity. Section 25 TDDDG refers more broadly to storing information in, or accessing information from, terminal equipment. The DSK guidance also notes that consent-dependent processing can include pixels and fingerprinting methods, not just cookies.
For developers, this means inventorying technologies by behaviour:
- browser storage;
- request beacons and tracking pixels;
- device or browser characteristics used for recognition;
- embedded media that connects directly to another provider;
- SDKs and scripts that transmit page, referrer, or device data;
- server-side forwarding triggered by the browser event.
The word “cookie” survives because users recognise it. The technical audit must look past the label.
Strictly necessary is a narrow technical claim
A service is not strictly necessary merely because the business finds it useful. The German statute provides an exception when access or storage is strictly necessary to provide a digital service expressly requested by the user.
A practical inventory should record for every technology:
| Field | Example of useful evidence |
|---|---|
| Service | Contact-form session protection |
| Purpose | Prevent duplicate or forged submissions |
| Device access or storage | First-party session token |
| Trigger | User opens and submits the form |
| Claimed basis | Strictly necessary for the requested form function |
| Retention | Session only |
| Provider | First party or named processor |
This does not settle the legal analysis, but it forces the implementation claim to become specific and reviewable.
The privacy policy must match runtime behaviour
A technically correct banner can still coexist with incomplete documentation. Compare the live request inventory with the privacy notice and consent interface.
Look for mismatches:
- a provider loads but is not disclosed;
- the notice describes analytics as disabled by default, but the request fires immediately;
- one language lists different services or retention periods from another;
- a policy names an old vendor that is no longer in the code;
- the banner groups unrelated purposes into a single choice;
- there is no usable way to change the decision later.
For multilingual sites, treat every language version as part of the same system. Translating an outdated privacy notice reproduces the mismatch instead of solving it.
A repeatable developer audit
The result should be a test record another person can reproduce. A useful workflow is:
- Start with a new browser profile and disabled extensions.
- Preserve the network log and capture the first load without clicking.
- Export requests, response headers, cookies, and browser storage.
- Repeat after Reject, selective consent, Accept all, and withdrawal.
- Map each external request to its initiating script or component.
- Compare runtime behaviour with the banner and privacy policy.
- Record the exact page, timestamp, region, browser, consent state, and test version.
- Retest after remediation and retain both evidence sets.
Do not call the result a legal certification. A browser test can find technical evidence and documentation mismatches. It cannot determine every lawful basis, organisational measure, contractual term, or fact about offline processing.
What an automated scanner can and cannot tell you
Automation is excellent at observing repeatable browser behaviour, but weak at legal conclusions without context.
| Scanner can detect | Scanner cannot prove by itself |
|---|---|
| Requests before consent | That every processing purpose is lawful |
| Cookies and browser storage | That a contract or DPA is adequate |
| Differences between Reject and Accept | That consent wording is valid in every context |
| Undisclosed or unexpected domains | The organisation’s complete data lifecycle |
| Missing withdrawal controls | That the whole company is GDPR-compliant |
The honest output is an evidence report: observed facts, likely issue, source, severity rationale, and a manual-review note where context is required.
Frequently asked questions
Does every German website need a cookie banner?
No. If the site does not perform consent-dependent storage or access and has no other consent-dependent processing requiring that interface, adding a banner can be unnecessary. The implementation should follow the actual technology inventory.
Can Google Analytics load before the visitor clicks Accept?
Do not assume that it can. Determine which storage, access, and personal-data processing occurs, which configuration is used, and whether a valid non-consent basis genuinely applies. The safer implementation default is to block optional analytics until the required consent exists.
Is a Reject button required on the first layer?
Consent must be freely given and refusing it should not be made misleadingly difficult. Interface details should be reviewed against current regulator guidance and the site’s exact processing. From an engineering perspective, provide an immediate, testable way to continue without optional services.
Is loading Google Fonts a cookie issue?
It may involve no cookie, but the browser still contacts an external server. Audit it as an external data flow. In many projects, self-hosting removes that request and simplifies both performance and privacy review.
Can a scanner certify GDPR compliance?
No. It can document observable technical behaviour and flag discrepancies. A credible service clearly separates automated findings from legal and organisational review.
Official sources
- Section 25 TDDDG: protection of privacy in terminal equipment
- Full TDDDG text
- German supervisory-authority guidance on cookie banners and consent tools
- DSK guidance for providers of telemedia, version 1.1
- GDPR on EUR-Lex
If you want to know what your banner actually controls, start with evidence from a clean browser session. Run the free website check: it opens your homepage with no choice made and after Reject, and lists every request and cookie it sees. For all pages and consent states, ask ILF Studio for a full technical audit.
