A website without a cookie banner: A practical privacy-conscious design

A website without a cookie banner is possible. The most useful route starts with its design: content that works without additional third-party services, restrained use of device storage and optional features that start only after an appropriate choice. What matters is what the website actually does. Removing a banner does not remove a consent requirement.

For a business website, this can make the experience considerably more pleasant. Visitors can read about services, find contact details and explore previous work without first making decisions about advertising partners. This does not require a plain or technically outdated design. Good typography, fast images, forms and clear navigation can all be implemented without automatically loading a collection of analytics, advertising and third-party embeds.

This practical article concerns Germany and the European data protection rules that apply alongside German law. Technical and legal assessments depend on the specific operations involved. It provides guidance for designing a website. The processes actually used need an appropriate assessment in each case.

When does a website actually need to ask for consent?

A cookie banner is an interface. The legal question starts earlier: is information being stored on a user's device, or is information already held there being accessed? Section 25 of Germany's TDDDG generally covers these operations regardless of whether they involve a conventional cookie. An entry in localStorage or sessionStorage does not become unproblematic simply because it has a different name.

The provision contains two exceptions to its consent requirement: the sole purpose of transmitting a communication over a public telecommunications network, and strict necessity for providing a digital service explicitly requested by the user. Either exception must fit the actual operation. An operator's interest in increasing sales does not make measurement technically necessary. Nor does an “essential” label in a plugin's administration screen settle the question.

A separate assessment concerns personal data. The GDPR can remain relevant even when an operation does not require consent for device access. An IP address in a server log or the transmission of a contact enquiry does not disappear from consideration because the browser stores no identifier. Equally, not every processing operation involving personal data necessarily requires consent. The European Data Protection Board's overview of legal bases explains that several grounds exist, each with its own requirements.

The practical consequence is that a website can operate without a general consent banner if its actual operations do not require the corresponding consent. Privacy information and, where appropriate, a specific choice for additional services can still be necessary. There is no blanket exemption for small websites, a particular content management system or a particular number of cookies.

Start with the core website: what must work immediately?

Consider a fictional trades business. Its website needs to explain services, show completed projects, list opening hours and allow people to make an enquiry. The first page view does not need an advertising network, a third-party video player or automatic visitor identification to perform those tasks. This description of the site's purpose becomes the starting point for its architecture.

The business can serve images from its own media collection, deliver suitable font files with the necessary usage rights and display its address as text. A contact form sends the information entered to its intended recipient. Whether a particular protective mechanism involving device access is needed requires its own assessment. Starting a session automatically on every static service page is not an unavoidable prerequisite for having a form.

A complete view of the initial visit matters. A theme may load external font files, an integrated chat window or a remote image. A tag manager may activate services later. Even a seemingly harmless video thumbnail may connect to the video provider as soon as it appears. The visitor may not have used the actual content feature at all.

A useful working question is: what would the visitor lose if this component did not load today? Losing an internal analytics report is different from losing a login that the visitor explicitly started. If only an interactive map is absent, a readable address may already meet the basic information need. This distinction reduces technical dependencies and makes the subsequent assessment more specific.

Common components and a more restrained implementation

The table describes design options rather than automatic legal clearance. Serving files yourself can avoid a third-party connection. It does not make an additional visitor identifier necessary. Similarly, a server's location alone says little about whether visitors are being recognised across multiple visits.

External fonts require careful wording. Connecting to a font provider can raise data protection questions. That does not automatically mean that a cookie banner is the required or appropriate solution. First establish what data flows and whether a relevant device access operation takes place at all. Then decide whether serving the font yourself is the simpler construction.

Preferences and sessions: the specific request matters

A deliberately selected language is different from a persistent visitor identifier set without being requested. For the initial view, a site can use its ordinary address and language information supplied by the browser, where that processing has been appropriately assessed. Switching languages can simply lead to another language-specific address. It does not automatically require a long-lived identifier.

If a choice is to be remembered across later visits, that particular storage operation needs a defensible assessment. What did the visitor explicitly request? What value is sufficient? How long is storage necessary? A simple language value and a random identifier usable for years serve very different purposes. The convenience of an existing plugin does not answer these questions either.

The same distinction applies to sessions. A login may need a session identifier so that subsequent requests can be associated with the signed-in account. This does not create a general exception for everything that happens during the same session. If the identifier is also used for marketing analysis, that purpose needs separate consideration. An object that lasts only until the browser closes is still a storage operation.

The German Data Protection Conference's Guidance on Digital Services, version 1.2 of November 2024, helps distinguish the user's explicit request from specific technical necessity. In implementation terms, avoid distributing storage technology across every page as a precaution. Describe the feature that is needed first and then justify the steps required to provide it.

Assess analytics beyond the marketing labels

“Cookieless”, “self-hosted” and “server-side” describe technical characteristics. None answers every legal question about analytics on its own. A tool without cookies may use other information from the device. A server you control can maintain personal visitor profiles. A server-side forwarding process can transmit data to another recipient even when the browser never requests that recipient's address directly.

A sensible selection therefore starts with the question the business wants to answer. Is it looking for broken links, interest in a service page or attribution of individual purchases to advertising contacts? Those objectives need different information. Checking operational errors does not automatically require a visitor who can be followed for months. An aggregate figure is not necessarily anonymous just because it is the only number displayed in the administration interface.

A specific assessment separates collection, processing and reporting. What data arises first? Which elements are immediately shortened or discarded? Are there identifiers or connections between several visits? Who can access raw data? What retention periods apply? Only the actual process supports a meaningful conclusion. The EDPB's final Guidelines 2/2023 on the technical scope also explain why the analysis cannot stop at conventional cookies.

If the desired analytics requires consent, there is a straightforward product decision to make: dispense with it, redesign it or implement suitable consent management. Quietly activating the analytics while removing the banner is not an additional compliant design option.

Connect external content only when it is needed

A map or video does not have to load when someone opens a service page. Initially, an own-hosted placeholder can explain the content. For a map, provide the address and a normal link to the mapping service. For a video, a summary and your own preview image may be enough. Visitors already receive useful information without having to choose the additional embed.

Before an activation that requires consent, the necessary information and a valid choice must be available. “Load content” is not a universally sufficient consent statement. The provider, purposes and relevant consequences must match the actual service. A choice must not be undermined by having already contacted that service through a preview image, script or connection setup.

The following technical component deliberately uses a fictional address. It demonstrates a testable boundary between the site's own presentation and an additional third-party connection. It does not contain a ready-made consent declaration for Google Maps, YouTube or another real provider. Its sandbox is also designed for a passive example view. Interactive services need their own technical and legal configuration.

  <section aria-labelledby="embed-title">
    <h2 id="embed-title">Additional view from a third-party provider</h2>
    <p id="embed-info">Your browser connects to embed.example.invalid only when you load the view.
      Connection data such as your IP address is then transmitted to this provider.
      This example address is fictional.
      You can continue using the page without the additional view.</p>
    <button type="button" id="load" aria-describedby="embed-info" hidden>
      Load the external example view once
    </button>
    <button type="button" id="remove" hidden>Close the external view</button>
    <p id="status" role="status"></p>
    <div id="host"></div>
    <noscript><p>You can open the
      <a href="https://embed.example.invalid/view" rel="noreferrer">external example view</a>
      using a link.</p></noscript>
  </section>
<script>
const loadButton = document.querySelector('#load');
const removeButton = document.querySelector('#remove');
const host = document.querySelector('#host');
const status = document.querySelector('#status');

loadButton.addEventListener('click', () => {
  if (host.querySelector('iframe')) return;
  const frame = document.createElement('iframe');
  frame.title = 'Additional external example view';
  frame.referrerPolicy = 'no-referrer';
  frame.setAttribute('sandbox', '');
  frame.src = 'https://embed.example.invalid/view';
  host.append(frame);
  loadButton.hidden = true;
  removeButton.hidden = false;
  status.textContent = 'The connection to the external view has been requested.';
});

removeButton.addEventListener('click', () => {
  host.replaceChildren();
  removeButton.hidden = true;
  loadButton.hidden = false;
  status.textContent = 'The view is closed. This does not retrieve data already transmitted.';
  loadButton.focus();
});

loadButton.hidden = false;
</script>

The essential property exists before the click: the document contains no external iframe yet. Only the event handler creates it. The component does not store the choice and does not automatically start the external view after a new page load. Closing it removes the embed. This does not retrieve data already transmitted or retrospectively undo a real provider's possible activity.

referrerpolicy="no-referrer" restricts transmission of the referring address. It neither hides the IP address from the requested server nor creates anonymity. The MDN iframe documentation describes the individual attributes. Adding loading="lazy" would not replace the choice: it delays loading according to visibility rather than waiting for an appropriate legal decision.

How to check the component in your browser

Open the network panel in your developer tools, enable recording and start with a fresh browser state. Filter for the provider concerned. Also inspect stored data and the elements actually created. Looking at the placeholder alone is insufficient: an invisible embed might already be active in the background.

The fictional example address is not an available map or video service. The table describes the technical boundary you need to check with your intended provider. That provider's device access, redirects and additional recipients also need consideration. A successful request check establishes neither valid consent nor complete accessibility. Broader consent management may still require a suitably equipped solution.

A practical implementation checklist

1. Define the core website's task: Which information and actions must remain available without optional services?
2. Inspect the first visit: Open a browser in a fresh state and record requests, storage operations and subsequently loaded content.
3. Reduce dependencies: Replace external font sources, preview images and additional libraries with suitable own resources where appropriate.
4. Describe each storage purpose: Record its content, trigger, duration and recipients. Feature names alone are insufficient.
5. Answer both legal questions: Assess device access under section 25 TDDDG and personal data processing under the GDPR separately.
6. Separate optional content: Avoid advance connections in the placeholder. Provide information and a choice directly at the content concerned.
7. Test subpages and states: Include direct entry routes, forms, mobile layouts, disabled JavaScript and return visits.
8. Reconcile the privacy information: Describe the processes actually used and provide the information required in each case.
9. Reassess changes: New plugins, campaigns and embeds can change a design that previously needed no general banner.

A clear table listing the component, purpose, data flow, storage operation, decision and responsible person is a useful starting record. Its connection to the running service must be verifiable. An old approval for an earlier plugin version is not evidence for a subsequently extended configuration. A test limited to the homepage may also overlook an embedded service on a rarely visited subpage.

Privacy information remains part of the website

Using fewer additional services often makes the explanation simpler, but does not replace it. Someone submitting a contact form should understand who processes their information and why. For server logs, the purpose, scope and retention period must fit the actual operation. The European Commission explains information obligations, including legal bases and data subject rights.

Coordination between the development team and the responsible business helps: which service providers are involved? What roles do they have? Are processor agreements required? Are there transfers to third countries? Serving a font file yourself does not resolve these questions. The GDPR's data protection principles continue to matter on a deliberately lean website.

For existing services, our article on website privacy, cookies, tracking and clear decisions complements this design approach by examining existing services and consent states. Here the focus is the earlier question: which additional operations do we need to create in the first place?

Frequently asked questions about websites without a cookie banner

Is removing all cookies enough?

No. Other storage technologies and access operations can fall within section 25 TDDDG. Personal data processing also needs separate assessment. A list showing zero cookies therefore describes only part of the situation.

Are session cookies always permitted without consent?

No. Their short duration does not decide the question on its own. What matters is their specific purpose and the requirements of a statutory exception. A session needed for a requested login is different from analytics started without being requested.

Is self-hosted analytics always possible without a banner?

No. Collection and configuration determine the assessment. Your own servers can also access device information or build personal profiles. One implementation can require a different assessment from another product configuration bearing the same name.

Does every externally hosted font require a cookie banner?

That cannot be stated as a general rule. The third-party connection, any device access and personal data processing need specific examination. Lawfully serving a font yourself can avoid the third-party connection and simplify the design.

Can a two-click approach replace a general banner?

A specific choice at optional content can be an appropriate design. It requires accurate information and, where necessary, valid consent before the relevant operations, among other conditions. Two clicks alone do not demonstrate that.

Can a website without a banner still have a form?

Yes. A form does not automatically require a general cookie banner. Its processing and protective mechanisms must still be appropriately assessed and explained. An external CAPTCHA can introduce additional questions.

A pleasant website without a general consent banner results from specific decisions about features and data flows. Choosing additional services deliberately, keeping necessary information accessible and reviewing changes regularly creates a traceable foundation. For a new website, that foundation can be built directly into planning and development. We can help you with that.