May 31, 2026

GDPR-Compliant Website – The Ultimate Checklist for Business Owners

Cookie banners, tracking, privacy policy & hosting: Everything your website needs for GDPR compliance – as a practical checklist.

Data protection is the topic where first conversations carry the most half-knowledge – usually a mix of some wave of legal notices someone heard about and the hope that nobody checks a small company anyway. The General Data Protection Regulation has applied since May 2018 to every website that processes personal data of EU citizens, and the penalty ceiling is up to 20 million euros or 4% of annual turnover – whichever is higher (Art. 83(5) GDPR). The practical part is manageable all the same. The following twelve points are what I work through on every project before a site goes live.

What this article is – and isn't: Technical orientation from practice, not legal advice. Whether a website is compliant in a specific case depends on the services actually in use, the data processed and the legal basis relied on. This checklist does not replace a review by a qualified lawyer or data protection officer.

1. SSL Encryption (HTTPS)

Your website should be accessible via HTTPS without exception. Without a certificate, form data is transmitted unencrypted. Art. 32 GDPR requires protection measures reflecting the state of the art – and transport encryption has been exactly that for years. Where personal data is transmitted without it, that is a substantial risk and practically impossible to justify.

2. Privacy Policy

Every website needs a complete privacy policy describing what data you collect, why, how long you store it, which third parties have access, and users' rights.

Cookies must not be set without prior consent (except technically necessary ones). Your banner must offer a genuine choice with "Reject" as easily accessible as "Accept."

4. Host Google Fonts Locally

Loading Google Fonts via Google CDN transmits visitor IP addresses to US servers. Solution: Host fonts locally on your server.

5. Secure Contact Forms

Inform users about data processing directly at the form, link to your privacy policy, and store only necessary data.

6. Use Analytics in a Privacy-Compliant Way

Privacy-friendly alternatives to Google Analytics include Umami (self-hosted), Plausible (EU), and Matomo (self-hosted). Whether a tool needs consent is not decided by the provider's reputation but by two questions: does it store or read information on the user's device (then § 25 TDDDG applies in Germany and consent is required), and what is the legal basis for the processing that follows? For cookieless, aggregated measurement a legitimate interest is debated – but that only holds up after reviewing the concrete setup. When in doubt, ask for consent.

7. Legal Notice (Impressum)

Required by German law (§ 5 DDG – the Digital Services Act implementation replaced the TMG in May 2024; older checklists still cite § 5 TMG) for every commercial website. Must be reachable within two clicks from any page.

8. Data Processing Agreements (DPA)

You need a DPA under Art. 28 GDPR for providers that process personal data on your behalf and on your instructions – typically hosting, email marketing, analytics, cloud storage and CRM systems. Not every third party qualifies: anyone deciding on the purposes and means of processing themselves is a separate or joint controller, which calls for a different agreement, not a DPA.

9. Check External Resources

Every external resource transfers the visitor's IP address. Load Google Maps only on click, use YouTube's enhanced privacy mode, and use static social media links.

10. Hosting Location

Ideal: Servers in Germany or the EU. If data is transferred to the US, you need additional safeguards and must disclose this in your privacy policy.

11. Deletion Concept

You must be able to delete data when requested. Have a process for contact form data cleanup, easy newsletter unsubscription, and regular backup purging.

12. Record of Processing Activities

Document all data processing activities, especially if you regularly process personal data.

Where It Goes Wrong in Practice

Nearly every problem I encounter on existing sites traces back to a handful of causes. The classic remains the externally loaded font. It sits preconfigured in countless themes, nobody notices because you cannot see it, and in 2022 it was the trigger for a wave of legal notices that caught many off guard. Then there are the consent banners that are not consent banners. A dialogue offering only one visible way forward does not document agreement – it documents that someone wanted to move on. Declining has to be as easy to reach as accepting. The third case is the privacy policy written once and never looked at again. It describes services that stopped running long ago and says nothing about the ones that arrived since. A generator gives you a starting point, not a permanent state. And finally, measurement tools that start before consent. That is the mistake that surfaces least often, because everything works – just too early.

The Three Services That Cause Most of the Trouble

Fonts from external servers. Loading fonts directly from a provider's server transmits the visitor's IP address there on every page view – before any consent. The Regional Court of Munich I ruled on this in 2022 (case 3 O 17493/20) and awarded damages to a claimant. A wave of warning letters followed, some of them dubious in themselves. Regardless of the legal question, the fix is simple: serve fonts yourself. It is faster as well. Embedded maps. An embedded map opens a connection to the provider as the page loads, even if nobody interacts with it. If you want to show a map, you have three routes: load it only after consent, use an image linking to the map service, or pick a provider that works without personal data. For most websites the second option is enough – all anyone needs is the route. Videos. Embedded videos usually set identifiers before anyone taps play. The privacy-friendlier embed mode offered by the large providers reduces this but does not remove it. The clean approach is the same: show a preview image, load on click. The common thread: the question is not whether you analyse data, but whether data leaves on the mere loading of the page. That distinction explains most of the disputes.

How to Tell Whether It Actually Works

Ticking the checklist is one thing; checking is another. Three tests you can run yourself: The network panel in your browser. Open developer tools, go to "Network", reload the page without touching the banner. Every connection to a third-party domain that appears there has to be explainable. Third-party domains before consent are the most common genuine finding. Cookies before consent. In the same tools, under "Storage", look at which cookies are already set. Without consent only technically necessary ones are permitted – including the entry that remembers your refusal. The reject button. Click it and reload. If the same connections are made afterwards as before, the banner is decoration.

What This Checklist Is Not

I am a web developer, not a lawyer, and this text is not legal advice. It describes what I encounter regularly in practice and how it can be solved technically. That distinction matters more than it sounds. Whether a particular service is permissible in your specific case depends on details a checklist cannot know: who processes what, on what basis, under which contract, shared with whom. For processing with recognisable risk – applicant data, health data, extensive tracking – that question belongs with someone qualified to answer it. What I can tell you: the technical points on this list remove most of what is actually disputed. What remains afterwards is usually a question of documentation, not of programming.

What Can Be Avoided From the Start

Some of these points never arise if the site is built without foreign components: fonts are local anyway, there are no third-party extensions whose data flows you would have to trace, and the server stands where you put it. That is not a free pass. Such a site still needs an accurate privacy policy, an imprint, contracts with the service providers that do exist, and a way to delete data again. The difference is only that fewer places exist where something can leak unnoticed. Data protection remains something you do not finish once. It shifts with every tool that gets added. A checklist like this covers the technical groundwork and rules out the most common mistakes – it is explicitly not a final verdict on any particular website. If you would like an existing site checked against exactly these twelve points, send me the address. You will get a list of what stands out to me – including the places where I will point you to legal advice rather than technology. Have your website checked