Why There Is No Cookie Banner on Our Website

Cookie banners have become a standard feature on almost every corporate website today. They are so ubiquitous that few question why they are necessary in the first place.

The ongoing discussion around the ePrivacy Regulation highlights how entrenched the debate has become. As reported by netzpolitik.org, both Germany and Google, among others, oppose the idea of managing consents centrally in the browser. Instead of a one-time decision, users will continue to face the same dialogues on every individual website.

Whether browser-based consents will be implemented or not is undoubtedly a relevant regulatory question.

From our perspective, however, the debate misses the root cause.

Cookie banners do not arise from regulatory arbitrariness. They arise because operators consciously choose a technical architecture that involves extensive data collection and therefore requires consent.

The crucial question is not how consents will be obtained in the future.

The crucial question is whether the underlying data collection is necessary at all.

A Corporate Website Is Not an Analytics Tool

When developing our website, the focus was never on how to gather as much information as possible about visitors.

Instead, we considered the opposite:

What data do we actually need to operate a corporate website effectively?

The answer was surprisingly straightforward.

We want to know which articles are read, which topics interest our visitors, and which content clearly offers no value.

What we do not need, however, are personal movement profiles, cross-device recognition, detailed conversion funnels, or the complete navigation behavior of individual visitors.

These pieces of information may have economic value for ad-funded platforms.

For a website whose primary purpose is to provide information and build trust in a company’s technical competence, we do not see this added value.

Architecture Is Always a Privacy Decision

Data protection is often seen as a legal discipline.

Privacy policies, records of processing activities, data processing agreements, consent management.

All these aspects are undoubtedly important.

However, they only come into play after the actual architecture has been established.

The more fundamental decision is made much earlier.

Which external services are integrated?

Which systems have access to usage data?

What information leaves the internal system?

Which third-party providers become part of the infrastructure?

With every additional marketing platform, tracking pixel, and external analytics tool, new technical dependencies arise. At the same time, the number of data flows that must be controlled, evaluated, and secured permanently increases.

Therefore, from our perspective, data protection is primarily an architectural issue.

The fewer data processed, the fewer data need to be protected.

Fewer Components Mean More Control

In software development, a well-established principle has prevailed for decades:

Every additional dependency increases the complexity of a system.

This principle does not stop at the boundary of a corporate website.

Every embedded JavaScript, every external library, and every marketing platform expands the scope of responsibility with components that are neither self-developed nor fully controlled.

This affects not only performance and maintainability.

It also concerns security updates, supply chain risks, data protection, and long-term vendor dependencies.

For this reason, our website is deliberately built with statically generated HTML based on Hugo.

For reach analysis, we use Plausible Analytics because it provides exactly the information we need—without cookies, without personal user profiles, and without the need for a cookie banner.

Not because analysis is unimportant.

But because we distinguish between necessary information and maximum possible data collection.

Privacy by Design Also Means Consciously Forgoing Opportunities

The term Privacy by Design is often reduced to a privacy-friendly configuration of existing systems.

Our understanding goes further.

Privacy by Design means questioning during the conception phase which functions should even have a place in the architecture.

Not every technically possible data collection creates business value.

Not every metric improves decisions.

Not every optimization justifies additional complexity.

Especially in IT, we often observe the tendency to continuously expand systems because additional tools can be quickly integrated. The long-term costs of these decisions, however, are rarely considered.

They do not arise only in the licensing model.

They arise from higher maintenance efforts, additional security assessments, more complex compliance processes, and an increasing number of technical dependencies.

Perhaps We Are Discussing the Wrong Level

The current political debate revolves around the future of cookie banners.

Browser or website.

One-time consent or recurring dialogues.

This discussion is important.

However, it does not answer the more fundamental question.

What data does a corporate website actually need to collect to fulfill its purpose?

Our answer to this has remained unchanged for many years:

Significantly less than is commonly assumed today.

From our perspective, trust is not built by a website knowing as much as possible about its visitors.

Trust is built by making technical decisions that are transparent, proportionate, and aligned with the actual purpose of a system.

That is precisely why there is no cookie banner on our website.

Not because we found a regulatory loophole.

But because we have designed our architecture in such a way that we simply do not need one.