What is GDPR compliant website development?
GDPR compliant website development is the practice of designing and coding a website so that its technical behaviour supports the General Data Protection Regulation, known in the Netherlands as the AVG, and the Dutch cookie rules. It covers what the site stores in the browser, which third parties receive data, how forms collect and keep information, where the site is hosted and how it is secured.
The phrase can mislead, so it helps to be precise. A website on its own cannot be “GDPR compliant” in the way a product can pass a test. Compliance belongs to your organisation as controller: your purposes, legal bases, privacy statement, processing register and how your staff handle data. What developers can do is build a site that makes compliance possible and does not undermine it through careless defaults.
Article 25 of the GDPR, on data protection by design and by default, describes the idea: by default, only personal data necessary for each purpose should be processed, covering how much is collected, how far it is processed, how long it is stored and who can access it. Translated to a website, that means analytics off until consent, short forms, retention you can enforce and admin access limited to people who need it.
BtechWaleTech builds those controls and documents them so your privacy officer or lawyer can check and sign off. We never label our work as certified, and we never give legal advice.
What does the AVG require from a Dutch business website?
Most obligations are organisational, but several show up directly on or behind the website. The Dutch government's business portal lists the essentials for businesses handling personal data, and a website touches nearly all of them.
- A privacy statement. Business.gov.nl says it is mandatory to include one on your website. You write it; we place it where every form and banner can link to it.
- A processing register. Your record of what data you process and why. We give you a list of the site's data flows and providers to feed into it.
- Breach notification. The same portal states you must notify the Dutch DPA within 72 hours of a data breach. Logging and alerts on the site help you notice one in time.
- A DPIA where required. Some processing needs a data protection impact assessment. We supply technical descriptions if your adviser decides one is needed.
- Safe transfers. Personal data may only go to countries outside the EU with adequate protection or appropriate safeguards, which matters for hosting, tools and your developers.
In other words, GDPR compliant website development is half code and half paperwork, and the paperwork is easier when the developer hands over clear documentation. That is part of every handover we do.
What are the Dutch cookie rules for websites?
Non-essential cookies need active, informed consent, and refusing must not lock visitors out. The Dutch government guidance on business.gov.nl lists when consent is not valid: when visitors do not actively give it, when continuing to browse after a banner is treated as agreement, when boxes are pre-checked, and when a cookie wall prevents people from entering or using the site normally if they refuse.
The same guidance says withdrawing consent must be as easy as giving it, that you must inform visitors about the cookies you use, and that the Autoriteit Persoonsgegevens monitors whether cookie notifications comply. Functional cookies, and analytical cookies with no or little impact on visitors' privacy, do not need consent.
For a developer, those rules turn into specific requirements:
- No optional cookie or tracking request before a choice, on any page, including the first one a visitor lands on.
- Accept and refuse offered at the same level, with similar visual weight.
- Categories switched off by default, never pre-ticked.
- A link in the footer that reopens the choices at any time.
- A cookie list that matches what the site actually sets, checked again after every new tool is added.
We test all five in a clean browser profile before launch and give you the results. Whether a specific analytics set-up qualifies as low-impact is a judgement for your adviser; we make sure the technical configuration matches what they decide.
How do you build a cookie banner without a cookie wall?
In GDPR compliant website development, the site works fully behind the banner and refusing takes one click, just like accepting. A cookie wall blocks content until the visitor accepts; a compliant banner asks the question and respects either answer.
Layout that does not steer
“Accept all” and “Refuse all” share a row, size and style. A third button opens category settings. We avoid a bright accept button next to a grey text link for refusal.
Plain wording
Two or three sentences naming the purposes, such as statistics, marketing and embedded media, with a link to the cookie list and privacy statement. You approve the text in Dutch and English.
Real enforcement
The banner is not decoration. Every optional tag is wired to a consent category through the tag manager or code, so nothing fires without the matching choice.
Remembered, but not forever
The choice is stored so returning visitors are not asked on every page, and the banner returns after the period your policy sets or when purposes change.
Proof of consent
Where your adviser wants a consent log, we record the choice, time and banner version without storing more personal data than needed.
Off-the-shelf consent platforms can do most of this if configured properly; custom banners suit lean sites. We will use whichever you prefer. For the same approach on a WordPress site, see WordPress development for Dutch businesses.
What is Google Consent Mode v2, and does a Dutch website need it?
Consent Mode v2 is Google's way of telling its tags what the visitor agreed to. If you use Google Analytics, Google Ads or other Google tags on a site with visitors from the EEA, you need it configured so those tags respect the banner.
Google's documentation names four consent types: ad_storage, analytics_storage, ad_user_data and ad_personalization, each set to granted or denied. Google describes two implementations. In basic mode, Google tags are blocked until the visitor interacts with the banner and no data is sent beforehand, not even the default consent status. In advanced mode, tags load with defaults set to denied and, while consent stays denied, send the consent state and measurements without cookies, which Google uses for modelling.
Which mode fits is a decision for you and your adviser, because advanced mode still sends some requests to Google before consent. Many privacy-cautious Dutch businesses choose basic mode; advertisers who depend on conversion modelling often choose advanced. We build either, document which one you chose and why, and check the result in Google's Tag Assistant.
Common mistakes we fix on existing sites: defaults set after the tags fire, ad_user_data and ad_personalization missing entirely, a banner that updates consent only after a page reload, and tags hard-coded in the theme so they ignore consent altogether.
Which analytics set-up suits a GDPR compliant website?
GDPR compliant website development starts analytics from what you actually need to know, not from habit. Many small Dutch businesses need page views, sources and conversions, which privacy-friendly configurations can deliver without profiling visitors.
There are three broad routes, and the analytics table further down compares them:
- Low-impact analytics: a cookieless or first-party tool configured to minimise data, with short retention and no sharing for advertising. Whether it falls under the Dutch exemption for analytics with little privacy impact is for your adviser to confirm.
- Self-hosted analytics such as Matomo on your own EU server, which keeps raw data under your control and can run with or without cookies depending on settings.
- Google Analytics 4 behind consent, with Consent Mode v2, IP-related settings reviewed, data retention shortened and Google signals switched off unless you have a reason.
Whatever you choose, we set up one source of truth for reporting and remove leftover tags from previous agencies, which are a frequent source of unexpected cookies. If search reporting matters more to you than visitor analytics, Google Search Console works without any tag on the site at all, and our technical SEO services for Dutch sites rely heavily on it.
GDPR compliant website development with a developer in India: DPA and SCCs
It is possible, and the lawful route depends on whether the developers access personal data at all. India does not appear on the European Commission's list of countries with an adequacy decision, so any transfer of personal data to a team there needs an appropriate safeguard.
Our first step is to avoid the transfer where we can. We build on staging with dummy data, never copy your production database to our machines, and design forms so submissions go straight to your EU hosting or your own systems. For many website projects, that means we never process your customers' personal data.
Where support work does need access, for example to debug a form or maintain a live database, two documents come into play:
- A verwerkersovereenkomst (data processing agreement). Article 28 of the GDPR requires processing by a processor to be governed by a contract setting out the subject matter, duration, nature and purpose, types of data, categories of data subjects and the controller's rights. We sign one with you before access.
- A transfer safeguard. The Standard Contractual Clauses adopted by the European Commission on 4 June 2021 (Implementing Decision 2021/914) are the usual choice for transfers to countries without adequacy. Your adviser selects the module and any transfer assessment.
We do not act as a certified processor and we do not give transfer advice. We follow the instructions in the agreement, keep access limited and logged, and delete any data we held when the work ends. The same approach appears on our custom software development page for Dutch SMEs.
In GDPR compliant website development, every field should have a purpose you can name, and anything without one should go. Forms are where websites collect the most personal data, and where old habits, such as asking for date of birth or a full address on a simple enquiry, quietly create risk.
Our form review runs field by field with three questions: what is this used for, is it needed at this stage, and how long do you keep it. The answers usually shrink the form and improve completion rates at the same time.
Notice at the point of collection
A short line beside the submit button says what happens to the data and links to the privacy statement. No hidden consent in the terms.
Separate, optional opt-ins
Newsletter sign-up or marketing follow-up is a separate unticked box, never bundled with the enquiry. GDPR Article 7(3) requires withdrawal to be as easy as giving consent, so every email has an unsubscribe link that works.
Retention enforced in code
Submissions are deleted or anonymised automatically after the period you choose, including copies in email notifications where we can control them.
Spam protection without tracking
Honeypot fields and server-side checks first; a third-party challenge only if spam demands it, and then disclosed in the cookie list.
Uploads handled carefully
Files stored outside the public web root, scanned, access-controlled and deleted on schedule.
Where should a GDPR compliant website be hosted?
For GDPR compliant website development, host the site, its database and its backups in an EU region, on an account registered to your business, with a provider that offers a processor agreement. That keeps most data inside the EU and gives you a clear contract for your register.
Options that work well for Dutch businesses include EU regions of the large cloud platforms, European hosting providers, and managed WordPress hosts with EU data centres. The right choice depends on your traffic, your team's familiarity and whether you need things like staging environments and automatic scaling.
Hosting is only the start. A website usually relies on other services that also process data:
- Transactional email for form notifications and password resets.
- A CDN that caches pages near visitors and sees their IP addresses.
- Backups, sometimes stored by a different provider.
- Fonts, maps, video and chat, each loaded from its own servers.
- Error monitoring and uptime tools.
We list every one of these with its location and a link to its processor terms, so you can decide what stays and what goes. See our cloud hosting setup page for how we configure servers.
Fonts, maps, videos and chat widgets: the hidden privacy leaks
Embeds are where GDPR compliant website development most often fails: third-party embeds send visitor data to other companies the moment a page loads, often before any banner appears. On many sites we review, they are the main reason tracking requests leave the browser even when every optional cookie has been refused.
Our default handling for each common embed:
- Web fonts are self-hosted on your server instead of being loaded from a font service on every page view.
- Maps show a static image with an address and a “load interactive map” button that states the provider.
- Videos use a thumbnail placeholder and load the player only on click, using the provider's privacy-enhanced mode where available.
- Chat and booking widgets load after consent or on click, never silently in the background.
- Social feeds and share buttons are replaced by plain links, which cost nothing in privacy.
This also helps speed, because fewer third-party scripts mean faster pages and better Core Web Vitals. If a WhatsApp chat button is important to your sales, our WhatsApp chatbot page for Dutch businesses explains how to add it without loading Meta scripts on every page.
Which security measures support GDPR compliance on a website?
Security is part of GDPR compliant website development: the GDPR expects security appropriate to the risk, and for most business websites that means a short list done consistently. Breaches on small sites usually come from outdated plugins, reused passwords and forgotten admin accounts, not from sophisticated attacks.
What we set up as standard:
- HTTPS on every page with modern TLS settings and HSTS.
- Two-factor authentication for all admin accounts, and named accounts rather than a shared login.
- Automatic security updates where safe, and a monthly update routine for the rest.
- Daily backups stored in the EU, with a tested restore.
- Access logs and alerts for failed logins and unexpected admin changes.
- Security headers and a content security policy that limits which scripts can run.
- Removal of unused plugins, themes and test accounts before launch.
These controls matter for the AVG's breach rules too: if something goes wrong, logs show what happened and when, which you need in order to notify the Autoriteit Persoonsgegevens within 72 hours where required. Our website security page describes the checks in more detail.
How does a website support access and deletion requests?
By storing personal data in known places and giving you simple tools to find, export and delete it. When a customer asks what you hold about them or wants to be erased, the website should not be the place where their data is impossible to track down.
In GDPR compliant website development, we keep a short map of every place the site stores personal data: form submissions, user accounts, order records, newsletter lists, logs and backups. For each, we note how to search it and how to remove a person's data.
On sites with user accounts, customers can download their data and delete their account themselves where your policy allows. For simpler sites, we add an admin screen that searches submissions by email address and exports or deletes matching records in one step.
Backups are the tricky part: they are kept for a defined period and then overwritten, and your privacy statement should say so. We document the rotation so you can answer the question honestly.
Responding to requests remains your process. The website's job is to make each request a five-minute task instead of an afternoon of searching mailboxes and plugins.
What to ask for in a GDPR compliant website development quote
Ask for specific, testable commitments rather than a line saying “GDPR proof”. A developer who has built privacy-first sites can answer these questions in a sentence each:
- Which scripts and cookies load before a visitor makes a choice?
- Is refusing as easy as accepting, and where can visitors change their choice later?
- Will you configure Consent Mode v2, and in basic or advanced mode?
- Which analytics set-up do you recommend for our needs, and why?
- Where are the site, database, backups and email delivery hosted?
- Which third parties receive visitor data, and will you give us a list?
- Will your team access our personal data, and if so, will you sign a verwerkersovereenkomst?
- How are form submissions stored, who can see them and when are they deleted?
- Who owns the domain, hosting and code?
Our answers are on this page, and each one appears as a line in the itemised quote. If you are comparing costs across providers, our guide to website development cost in the Netherlands puts privacy work in context.
How much does GDPR compliant website development cost?
Privacy-first work is part of every build we quote, so a new GDPR compliant website starts from US$150 and large content sites from US$300. The extra effort comes from the tools you want to run, not from the privacy controls themselves.
Number of tracking and marketing tools
Each analytics, advertising or heatmap tool must be mapped to a consent category and tested. A site with one analytics tool is quick; a site with six marketing pixels takes longer.
Webshop checkout
Payment, shipping and review integrations add data flows to document and test. Webshops start from US$750.
User accounts and portals
Logins, profiles and self-service data export turn a site into a web application from US$900.
Languages
Banner, notices and cookie list in each language you publish, with text you supply or approve.
Fixing an existing site
Quoted after a scan, because a theme with hard-coded tags takes longer to clean than one that uses a tag manager.
Other developers' quotes vary widely, often depending on whether they include a consent platform subscription, legal templates or ongoing monitoring. Ask what each line covers before comparing totals.
Working with a privacy-focused web team in India from the Netherlands
It runs on a written scope, a shared tracker, weekly video demos and a staging site you can open at any time. India is 3.5 hours ahead of the Netherlands in summer and 4.5 in winter, so calls fit your late morning and early afternoon.
The first two weeks look like this: an itemised quote within about two working days, a kick-off call with whoever owns privacy in your business, a scan of the current site's cookies and tags if you have one, agreement on analytics and Consent Mode choices, and the first templates on staging with the banner already working. Nothing is billed before you approve the quote in writing.
Contracts are simple to keep clean. The quote describes scope and milestones; a verwerkersovereenkomst is added only if we will access personal data; any NDA terms are agreed in writing before work starts. Domain, hosting and code stay registered to you throughout, and we work through access you grant.
Payments are in USD by Wise, bank wire or PayPal against milestones, and invoices come from India. Your accountant advises on the VAT side of a non-EU invoice.
Limits worth stating: we do not write your privacy statement, give legal advice or visit your office. Our guide to hiring Indian developers covers the general model.
Example: GDPR compliant website development for a Utrecht language school
A hypothetical case to make the steps concrete, not a past project. Say a language school in Utrecht runs a WordPress site with course pages, a trial-lesson form, a newsletter, Google Analytics, an advertising pixel, embedded videos and a map. Its old site loads the pixel and analytics on arrival and hides refusal behind a settings screen.
The rebuild plan: a lean theme with self-hosted fonts, videos and map as click-to-load placeholders, and a banner with accept and refuse side by side. After talking to its adviser, the school keeps GA4 behind consent in basic Consent Mode, drops the advertising pixel from course pages about children's lessons, and moves the pixel to consent-only on adult course pages.
The trial-lesson form shrinks from nine fields to five: name, email, phone, course and preferred day. Newsletter sign-up becomes a separate unticked box. Submissions go to the site's database on EU hosting and are deleted after the period the school sets. Nobody on our side ever sees a real submission, because testing uses dummy data.
On price, a site this size would start from the US$150 plan, with the tag clean-up and consent configuration included in the build. Timeline around two weeks, plus the time the school's adviser needs to approve the banner text and privacy statement.
GDPR compliant website development checklist before launch
Test these on the staging site in a fresh browser profile, with the developer tools network tab open:
- With no choice made, no analytics, advertising or social requests leave the browser.
- “Refuse all” is as visible and as quick as “Accept all”.
- The site works normally after refusing every optional category.
- A footer link reopens the consent choices, and changes apply without a reload.
- Consent Mode v2 defaults are set before any Google tag fires, with all four signals present.
- Every form field has a stated purpose, and optional opt-ins are unticked.
- Submissions are deleted automatically after the agreed period.
- Fonts are self-hosted; maps and videos load only on click.
- Hosting, backups and email delivery are in the EU, with providers listed for your register.
- Your privacy adviser has reviewed the banner, notices and privacy statement.
Send us your site address and we will run the first three checks and tell you what we find before you commit to anything.