The cookie banner has become the emblem of the modern web: barely a page opens without a dialogue first blocking the view of the content. Many owners treat it as an unavoidable duty, a necessary evil that simply comes with the territory. That is a misconception. A consent banner is not the standard legal equipment of every website; it is the consequence of a specific technical decision. It is triggered as soon as a page embeds services that require prior consent. Anyone who does not load those services in the first place needs no banner in many cases. This article explains why the tiresome dialogue is often avoidable, which cookies genuinely stay consent-free, what actually forces a banner, and what a data-minimal page looks like that spares its visitors the click maze. It complements the guide on setting up a consent dialogue correctly: because not every site needs this dialogue at all.
Why the cookie banner is often avoidable
It starts with a simple observation: the banner is a symptom, not a cause. It does not appear because some law categorically demands that every website show a consent dialogue. It appears because something happens on the page that is not allowed to happen without consent, typically the storing or reading of information on visitors' devices for purposes that go beyond simply running the site. An analytics script that recognises users across pages, an embedded map that sends the IP address to a third-party server on load, a video player that sets marketing cookies, a font service that reports every page view: each of these building blocks brings its own need for justification. Remove them, and the reason for the dialogue disappears with them. That is exactly where the leverage sits. Most company websites need not a single one of these services to do their job; they were built in over the years without anyone deliberately weighing the price they carry in the form of a consent requirement.
The Datenschutzkonferenz, the joint body of the German supervisory authorities, is unambiguous on this point: anyone who uses only strictly necessary cookies and avoids external tracking services generally needs no consent banner (Datenschutzkonferenz). The reverse conclusion is decisive, because it is not the website in itself that creates the obligation, but what it additionally embeds. The route to a page without a banner therefore does not run through a better dialogue but through a shorter list of embedded services. That is no legal hair-splitting but a design question, decided as early as the concept phase. Anyone planning a new site can build data minimisation in from the start; the XICflow service overview is designed around exactly that. And if you are unsure whether your own site even falls within the stricter scope, the analysis of who is covered by the accessibility and privacy obligations offers a first orientation.
No banner does not mean no privacy
Section 25 TDDDG: when consent becomes necessary
The legal basis comes from the German Telecommunications Digital Services Data Protection Act, or TDDDG for short, which continues the earlier TTDSG regime. Its Section 25 governs access to end-user devices: storing information in the browser or reading information already stored is, in principle, permitted only with prior consent. There are two exceptions to this consent requirement. The first concerns the mere transmission of a message; the second, and the practically more important one, covers storage operations that are strictly necessary so that a service explicitly requested by the user can be provided at all. Those are precisely the strictly necessary cookies. Everything beyond that, namely reach measurement, marketing and embeddings of social networks, falls under the consent requirement (Datenschutzkonferenz). The section thus draws a clear line: necessary on one side, everything else on the other.
It matters that this assessment works in a technology-neutral way. The TDDDG deliberately speaks not only of cookies but of information stored on or read from the device in general. Whether a service uses a classic cookie, the browser's local storage or a digital fingerprint for that purpose makes no difference to the consent requirement. The Court of Justice of the European Union set the benchmark for that consent early on: it has to be active, and a pre-ticked box is not enough (Court of Justice of the European Union). Alongside the TDDDG sits the General Data Protection Regulation, which applies as soon as personal data is processed, which in practice is the case whenever an external service receives visitors' IP addresses. Looking at both frameworks together, one quickly sees that the most laborious part is not drafting a dialogue but managing the data flows that make it necessary. How these two assessments come together in a clean dialogue, where one cannot be avoided, is described in the guide to a legally sound consent dialogue.
Strictly necessary cookies need no consent
The consent-free cookies are not a small remainder; they cover the everyday work of a company site to a large extent. Consent-free is whatever the user strictly needs for the function they requested. That includes the shopping basket of a store that keeps a selection across several pages, the session cookie that holds a signed-in session together, the cookie that stores the cookie decision itself, a token to defend against form abuse, or the memory of the chosen language. A cookie that briefly distributes load across several servers belongs here as well. The common denominator is that without these storage operations the explicitly requested service does not work or works only in a limited way. Such cookies may be set without a dialogue; the Datenschutzkonferenz refers to exactly this (Datenschutzkonferenz). They still belong in the privacy policy, listed transparently, so that visitors can understand what is stored on their device.
Basket and session
Basket and session cookies hold a selection and a signed-in session together. Consent-free, because they are strictly required for the requested function.
Login and security
Sign-in and a token against form abuse protect operation. Without these storage operations the service could not be provided securely.
Language and choice
The chosen language and the cookie decision itself may be stored without any dialogue being necessary for it.
Reach measurement
Analytics scripts that recognise users across pages go beyond what is necessary and require prior consent.
Marketing
Retargeting and advertising cookies do not serve the operation of the page but its marketing, and are therefore subject to consent.
Social networks
Embedded buttons and content from social networks transmit data to third parties and trigger the consent requirement.
What actually triggers a banner
In practice it is almost always the same building blocks that turn a harmless company site into a consent-bound one. The scale is considerable: around 92 percent of websites embed at least one third party (Web Almanac), and 45 percent of all requests go to third parties (Web Almanac). Each of these building blocks is a potential trigger. The most common culprits fall into four categories: embedded maps that send location and IP address to a map provider on load; video players that set cookies for reach and advertising; web fonts that are fetched from a third-party server and report every page view in the process; and analytics tools that log behaviour across pages. Buttons of social networks, chat windows and icon libraries come on top of that. None of these services is required for the basic function of a website, and that is precisely why each of them triggers the consent requirement.
Scroll table sideways
| Building block | Forces a banner? | Data-minimal alternative |
|---|---|---|
| Embedded map from a map provider | Yes, sends IP to third parties | Static map image with a link to the route |
| Video from an external platform | Yes, sets marketing cookies | Self-hosted video or preview image with a link |
| Web fonts from a third-party server | Yes, reports every page view | Serve fonts locally from your own server |
| Reach measurement via analytics script | Yes, requires consent | Aggregated analysis with no access to the device |
| Basket and session cookies | No, strictly necessary | Allowed without a dialogue; name them in the privacy policy |
| Contact form on your own domain | No, no third parties | Process directly on your own server |
The table reveals the pattern: almost every banner trigger has a data-minimal counterpart that does the same job without bringing third-party servers into play. A route can be shown as a static image with a link to navigation instead of embedding an interactive third-party map. An explainer video can be self-hosted or replaced with a clickable preview image. Fonts sit on your own server instead of being fetched from outside on every page load. These alternatives are not only simpler in legal terms but usually faster too, because they save connections to third-party servers. How to embed external content such as maps, videos and fonts without leaking data is explored in a dedicated article.
Replace or drop external services
The practical route to a page without a banner begins with a stocktake: which external connections does the page open on load? That question can be answered with the developer tools of any browser in a few minutes. Every connection to a third-party domain is a candidate for review. For each service the same decision arises: replace, self-host or drop entirely. Map services can be replaced with a static map or a simple address field; if you genuinely need an interactive map, you can place it behind a click so that it only loads after a deliberate action. Videos move to your own server or are shown as a preview image with a link. Fonts are embedded locally, which is technically simple and saves load time at the same time. Icon libraries can be delivered as embedded graphics instead of an external font file. What remains is a page that gets by with its own server.
Maps
A static map image with a link to route planning instead of an embedded third-party map that transmits IP and location.
Videos
Self-host the video or show it as a preview image with a link, so that no marketing cookie is set on load.
Fonts
Serve web fonts locally instead of fetching them from a third-party server that reports the view on every load.
Reach
Aggregated analysis with no access to visitors' devices, so that the consent requirement is not triggered.
Marketing
Do without retargeting pixels and measure campaigns via tagged destination addresses rather than through cookies you set.
Chat and forms
Run the contact form and chat on your own domain, without loading a third-party script into the page.
- Open the browser developer tools and watch the network tab as the page loads; every third-party domain is a candidate for review.
- For each external connection decide: replace, self-host or remove without replacement.
- Serve web fonts and icons from your own server instead of fetching them externally.
- Place maps and videos behind a deliberate click or replace them with static alternatives.
- Switch reach measurement to a method that works without access to the device.
- After the rework, check again whether any consent-bound service is still being loaded.
When a banner is unavoidable: the rules
Not every site gets by without external services. A booking system, a payment service or an embedded map can be indispensable in individual cases. Then a consent banner is mandatory, and clear rules apply to that banner, rules the supervisory authorities enforce regularly. The most important concerns the equivalence of the choices: the option to reject all cookies has to be as easy and equally visible as the option to accept all (Datenschutzkonferenz resolution). A banner that shows a large, coloured accept button while hiding rejection behind a grey link or an additional layer counts as unlawful. Nor may boxes be pre-ticked, because the Court of Justice of the European Union has required active consent (Court of Justice of the European Union). And use of the site must not depend on consent being given, as long as non-necessary cookies are at stake.
Reject has to be equally visible
A cleanly built banner is, moreover, itself a piece of software that has to be maintained, tested and operable in an accessible way. It must not trap the keyboard focus, has to work with assistive technology and must store the decision reliably so that it is not asked again on every visit. Withdrawal, too, has to be as easy as consent. All of this is doable, but it costs effort, effort a data-minimal page does not create in the first place. The calculation is simple: every embedded third-party service perhaps saves an hour of implementation, but creates a permanent maintenance and testing burden for the banner it makes necessary. The guide to the legal notice, privacy policy and other legal texts shows how to keep the legal framework of the site lean overall.
A banner that is dropped saves twice
Data minimisation as a business advantage
Doing without third-party trackers is more than a legal convenience; it pays directly into the effect of the page. The first effect is speed: every third party saved means one connection fewer, one script fewer, one possible blockage fewer while the page is built. At a median of 24 third parties per page (Web Almanac), that adds up to noticeable load time. The second effect is the user experience: opening a page without a preceding dialogue shows the content straight away instead of a click maze. That lowers the bounce rate especially on the smartphone, where a banner quickly takes up half the screen. The third effect is trust: a page that does not pass data to third parties in the first place does not have to negotiate about it either. For many businesses, from the medical practice through the law firm to the trade, this visible respect for visitors' data is an argument that fits their own positioning. How static delivery lowers load time at the same time is shown in the article on PageSpeed 100 and static delivery.
Data minimisation is also robust against changes in the legal landscape. Anyone who embeds no third-party services need not track every new decision on how banners must be designed, maintain no data processing agreements with third parties and check no data transfers to non-EU countries. The surface for complaints shrinks to what the page itself does. That is a security gain as well, because every embedded third-party script is a piece of code you do not control yourself. Anyone planning a new site should record these points as early as the briefing for the AI website builder, because the decision for or against external services is cheapest right at the start. An online appointment booking can be designed to be data-minimal as well, without a third-party booking script forcing a banner.
How XICflow delivers without external trackers
XICflow is designed from the ground up for this data-minimal approach. Pages are delivered as static HTML without any connections to third-party servers being opened on load. Fonts sit locally on your own domain, icons are embedded as graphics, and where a map or a video makes sense, data-minimal variants are used that only load after a deliberate action or work entirely without a third-party service. The built-in reach measurement is designed so that it works without consent-bound access to the device. The result is that in many cases a page emerges that needs no consent banner at all, because it uses strictly necessary cookies only. A privacy policy and a legal notice are still supplied and can be extended with the details of the business. How this route runs from the idea to the finished page is described in the overview of how XICflow works; concrete examples are shown by the demo sites.
None of this replaces an individual assessment of the specific case: anyone who deliberately uses an external payment service, a booking system or an embedded third-party map still needs a banner and the appropriate legal basis. But the default posture is reversed. Instead of embedding services first and then laboriously organising consent, the page starts out data-minimal, and every third-party service has to justify itself before it is added. That order is the real difference. What the build costs and which services are included is shown by the pricing overview; further articles on law, technology and structure are collected in the XICflow blog.
The most laborious cookie banner is the one you could have spared yourself. If you load no third-party services, you need not obtain consent for them either.
How to approach it
- Run a network analysis in the browser and list all connections to third-party domains.
- Review every external service: replace, self-host or remove without replacement.
- Serve web fonts and icons locally and replace maps and videos with data-minimal variants.
- Switch reach measurement to a method with no access to the device.
- Check whether only strictly necessary cookies are set after the rework; then the banner obligation generally falls away.
- If a third-party service remains indispensable, set up a banner with equally visible rejection and enable withdrawal.
- List strictly necessary cookies transparently in the privacy policy, even without a dialogue.
- Record the assessment in writing and review it again after every larger change to the site.