GDPR-compliant website: review services, design consent, limit data flows

Open your own home page in a fresh browser window, without clicking any button in the cookie banner, and look in the network tab of the developer tools to see where requests go. In many cases you will see more counterparts than anyone in the company expects. Font files from a third-party server, a map tile service, a video player, a script for visitor statistics, a chat widget. That is the typical starting picture in this scenario.

Suppose a business with a grown website comes to us like this. The banner dates from the last relaunch and lists three categories, but two of the services embedded today were added later, via a plugin or a line of code that someone added for a campaign goal. The privacy policy was not updated in the process. The cause is neither ill will nor negligence, but simply a lack of responsibility.

A privacy-friendly website is therefore first of all a question of overview. Anyone who does not know what their site does can neither explain it correctly nor limit it sensibly. This article describes how we proceed with such an inventory, what can be changed technically, and where the limits of a purely technical view lie. Legal assessments in individual cases belong with your data protection officer or your lawyer, not in a specialist article.

The gap between banner and reality is so common for a simple reason: websites are built in stages, and nobody is responsible for the overall picture. Whoever works in a small business maintains the site on the side. Whoever looks after it at an agency often knows only their own share. The comparison falls between the areas of responsibility, and that is where an inventory starts.

With data protection questions on websites there are almost always three descriptions of the same reality. The first is the cookie banner, which names individual services and categories. The second is the privacy policy, which explains the same services in running text. The third is the actual behaviour of the site in the browser. Each of these lists was maintained at a different time by different people, and accordingly they rarely agree.

Services that are not recognisable as services are especially tricky. A theme loads fonts from a third-party server because the developer set it up that way during the build. An embed code for a video sets cookies before anyone clicks play. A form plugin includes a captcha that sends data to a third party. The operators decided none of this consciously, and yet they are responsible for it.

The time factor is added to this. Every plugin update, every new page with an embed, every additional marketing component can change the picture. A state that is correct today may be outdated in six months. The challenge is therefore not only a one-off review, but creating a state that can be kept up to date with manageable effort.

The most important distinction when sorting services is this: what is technically necessary to run the site, and what serves other purposes such as audience measurement, advertising or convenience? For the first group, consent is generally not requested; for the second, the opposite often applies. This rough line is widely known. Where exactly it runs in an individual case, however, is a legal assessment that we do not replace.

A thought experiment helps in practice: would the site still work for a visitor if this service were missing? A language switcher, a shopping cart, a session for a login belong to operating the site. Visitor statistics, an ad pixel, a video from a platform or a map from a third-party provider more likely do not. Beyond that, there is the question of whether a service transmits data to third parties and whether those third parties use the data for their own purposes.

Besides consent, legitimate interest exists as another legal basis. For audience measurement, it remains disputed when it holds up. We therefore stick to a pragmatic rule: the less a service processes personal data and the fewer third parties are involved, the more likely it can be operated without a prompt. Anyone who wants to be sure has the classification of the delicate services confirmed in writing by a qualified body.

The consequence of this classification is less legal than a matter of design. Every service that can be technically replaced or removed no longer has to be prompted, explained and documented. The simplest measure for a GDPR-compliant website is therefore often not a better banner, but dropping a component that nobody misses.

The order of measures that follows from this sorting is one we think of in three stages. First we check whether a service is needed at all. Then whether it can be run locally or in a data-minimizing way. Only for the services that remain and cannot easily be replaced do we design the consent. This order prevents an elaborate banner from managing things that are better left unloaded.

The alternative would be the more convenient route: installing a consent management tool that covers as much as possible and otherwise leaving the site as it is. That works technically but has drawbacks. The banner becomes complex, using it is tedious for visitors, and every additional script increases maintenance and risk. A tool documents decisions; it does not make them for you.

A third route would be to do without anything external: no statistics, no map, no video. For some businesses that is coherent, for example a trades business with a clear overview of its services and a contact form. For others it means lacking insight into their own site, and a location map has real practical value. Our recommendation is therefore not a doctrine but a trade-off per service.

An example of this trade-off: customers actually use a location map, whereas a social media feed in the footer is hardly used. The map then stays as a two-click solution, and the feed is replaced by a simple link. The result is a site that loads less, has less to explain and loses hardly any function for visitors. It is precisely this comparison of benefit and explanatory effort that provides the basis for the decision.

Where consent is required, the design decides whether it is meant seriously. The principle is widely known: consent should be freely given, informed and unambiguous, and declining should not be more laborious than agreeing. In practice that means equivalent buttons, i.e. “Accept all” and “Necessary only” of the same size, the same prominence and on the same level, not a glowing button next to a hidden text link.

The concept also includes understandable purposes instead of technical jargon. “We measure anonymously which pages are visited” is only honest if it is true; otherwise the description has to read differently. The choice per category should be reachable without detours, and a way to withdraw consent belongs in the footer menu as a permanent link, so that a decision, once made, can still be changed later.

How it is presented matters too. On a smartphone, the banner must not block the entire screen without the page behind it being usable, and it must be reachable by keyboard and with screen readers. This touches on the accessibility of the site and shows how closely these topics are intertwined. A banner that cannot be operated cannot obtain a valid decision.

Finally, the wording of the texts: short, concrete, without pressure phrases such as “Help us improve”. Such sentences obscure what is being consented to. We prefer to write what happens: which service, which data, which purpose. Anyone who words things this way can transfer the same information almost unchanged into the privacy policy, which noticeably simplifies maintenance.

It starts with the inventory, using tools anyone can follow: the browser’s network tab with an emptied cache and without consent, the cookie view in the storage area of the developer tools, and a look at the source code for embedded scripts, iframes and stylesheets. The result is a table with service, purpose, where it was found and provider. It becomes the source for everything that follows.

Fonts are the easiest win. Instead of loading them from a third-party server on every visit, the files sit in your own project and are delivered with the page. That saves a connection, can improve load time and removes a transmission to third parties. What matters here is checking whether the font’s license permits self-hosting, and cleanly removing the old embed, which would otherwise keep running unnoticed.

We usually solve maps and videos as a two-click solution. Instead of the embed code, a placeholder appears first with a note on what happens on loading. Only the visitor’s click loads the external content. For videos, privacy-friendly embedding variants come into question, and directions can often be shown just as well with an address, a link and your own static image, without any data flowing at all.

For statistics there are two ways: a service with consent, or a privacy-friendly, self-hosted solution that manages without personal identifiers. Whether the latter is permissible without a prompt in an individual case is something you clarify with a qualified body. Technically, in both cases: scripts are loaded only after consent, not loaded and then merely “disabled”. The banner controls delivery; it is not decoration on top of a page that has already sent its requests.

If you use Google services with consent, Consent Mode comes into play. It passes the consent status as signals, for example for storage for advertising and analytics purposes, to the Google scripts, which adjust their behavior accordingly. The correct order matters: default values of “denied” are set before the scripts load, and only the visitor’s choice changes them. Anyone who sets up this sequence wrongly creates a banner that only looks as if it controls something.

Besides the obvious components, there are special cases that, in our experience, get forgotten. A contact form processes names and messages, and the path of this data does not end at the submit button: does it land in a mailbox, in a CRM, in a ticketing system? Every stop is a recipient, and the privacy policy should describe the actual path, not the imagined one.

Chat widgets and AI assistants deserve special attention because visitors enter free text there and reveal more than in a form field. The questions here are where the data is processed, how long it is stored and whether the provider uses it for its own purposes. A notice about the processing before the first input is a sensible design measure but does not replace contractual clarification.

By this contractual side we mean data processing on behalf of a controller: if a service provider processes personal data on your behalf, a written contract is generally required. This concerns hosting providers, newsletter providers, chat services and some analytics tools. Part of the upkeep is to collect these contracts and assign them to the providers in the list of services, so that nothing has to be searched for when a request comes in.

Another edge case is services based or hosted outside the EU. The question of transfers to third countries is legally fluid and changes over time. We do not assess it; we flag such services in the list and recommend having them reviewed separately there. Here too: if a European or local alternative serves the same purpose, it is often the simpler path.

A privacy overhaul delivers no certification and no free pass. Whether a website stands up in a dispute is decided by authorities and courts based on the individual case, and the legal situation and its interpretation remain in flux. An honest goal is therefore this: the site’s actual behavior is known, limited, documented and matches what visitors read in the banner and in the policy.

This state can be verified. In the network tab you can see that no non-essential requests go to third parties before consent. The number of third-party servers contacted on the first visit is smaller than before. The list of services, the privacy policy and the banner name the same services. In addition, a spot check with a fresh browser profile can be repeated after every major change.

Site performance can also benefit when third-party resources are dropped. Fewer external connections tend to mean shorter load times, measurable with Lighthouse or PageSpeed Insights. That is a side effect, not a promise, since the impact depends on what exactly was removed. On the other side there is a limitation: if you run statistics only with consent, you see only part of the visits and should read the numbers accordingly with caution.

You should not expect all risks to be eliminated. Even a carefully cleaned-up site can be criticized, for example because of a provider whose classification changes. The only reliable thing is the ability to react to such changes: whoever has the overview replaces a service in an afternoon instead of starting a weeks-long search.

The most important lesson is unspectacular: most problems arise from adding things without approval. A fixed rule that every new embed is entered in the list of services first prevents more than any after-the-fact audit. The rule needs no software, but a responsible person and a habit that applies to every plugin and every marketing component.

Second, it is worth maintaining the banner and the privacy policy from the same source. If the two are created separately, they drift apart. If they come from one list with service, purpose, provider and retention period, the reconciliation takes minutes. This also applies to the legal notice and other mandatory information, which tend to be forgotten when moving or changing legal form.

Third, it turns out that fairness in the banner is no conflict with business. Declining on equal terms costs, in our experience, a little reach in the statistics, but creates a picture of the website in which visitors do not feel patronized. For a business that lives on trust, that can weigh more than a marginally more complete analysis.

A GDPR-compliant website does not come from a single banner but from a sequence: know your services, remove the superfluous ones, host resources locally, ask fairly for the rest and reflect everything consistently in the banner and the policy. Each of these steps is manageable on its own. Together they produce a site whose behavior you can explain without looking anything up.

The next step is small. Open your homepage in a private window, open the network tab and count the domains contacted before any consent. Compare them with your banner and your privacy policy. If the numbers do not match, an inventory makes sense, and we are happy to carry it out with you.

Part of putting this in context is the limit of our contribution: we design and build the technical side and prepare the information. The binding legal assessment of your individual case, the classification of delicate services and the wording of the final texts belong in the hands of data protection law specialists. With a clean inventory, their work becomes faster and cheaper.

One more note on expectations: data protection is not a project with an end date. New browser rules, changed services and shifts in interpretation mean that even a well-positioned site needs a look at regular intervals. Plan a fixed, small appointment for this once a year. The effort is low when the list of services is maintained, and it grows when you postpone it.