GDPR Compliant Website Architecture for South African Businesses

Most GDPR advice stops at cookie banners and ignores the website architecture underneath, which is why so many implementations break the moment a new tracking tag gets added. This post explains the specific build decision, JavaScript loaded by default versus loaded only after consent, that determines whether compliance holds up over time.

By Arnaud Brunel — Founder, Brunel Studios31 July 2026 Last updated: 31 July 2026

A GDPR compliant website architecture means the site is built so no tracking or non-essential script runs before a visitor consents, not just that a cookie banner sits on top of an unchanged site. For South African businesses with EU customers or EU data flows, this is a build decision made before a single line of tracking code is written.

What a GDPR Website Compliance Checklist Actually Needs to Cover

Most GDPR website compliance checklists list legal obligations without saying what to build to satisfy them, which is why so many South African sites end up with a cookie banner sitting on top of a site already running Google Analytics and a Facebook Pixel on page load. The banner is legally required. It does nothing if the tracking scripts fired before the visitor made a choice.

Here is the pairing most checklists skip: what GDPR requires, and the architectural answer that delivers it.

Requirement Architectural answer
No tracking before consent Scripts load conditionally, after a consent event, not on page load
Consent as easy to refuse as to accept Consent layer sits in front of the render tree, not bolted on after
Data minimisation Analytics and marketing tags absent from the default JavaScript bundle
Right to erasure and access Backend model separates identifiable visitor data from site content

A checklist tells you these four things are required. It rarely tells you that "no tracking before consent" is unreliable to bolt on after launch, because most sites ship one JavaScript bundle containing every script the site will ever use.

The Trade-Off Most Website Compliance Guides Get Wrong

The honest trade-off is this: retrofitting consent onto a JavaScript-heavy site is fragile, while building consent into the architecture from the start is cheap, the same logic behind compliance-by-design software architecture that survives South Africa's regulatory cycle, and almost nobody chooses the second option because it is a decision made at project kickoff, not at launch. Guides on Google Tag Manager and Consent Mode configuration assume the hard part is already solved: a site that does not run anything until it is told to.

Most modern frameworks ship JavaScript by default and hydrate the whole page whether a component needs interactivity or not, so every script, including tracking scripts, is bundled and ready to execute the instant the page loads. A consent banner layered on top has to actively block each script, a brittle pattern that breaks the moment a developer adds a new tag six months later and forgets to gate it. The stakes for getting this wrong are not theoretical: South Africa's Information Regulator can levy a fine of up to R10 million under Section 109 of POPIA, according to popia.co.za, and it already issued a real R5 million penalty in 2024, its first, reported by Bowmans.

We ran into this directly on an 11.5-week engagement rebuilding the digital presence of a group of six sister companies operating across the EU, under a data-privacy regime stricter than POPIA with real enforcement behind it. We built the frontend on Astro's islands architecture, a framework that ships close to zero JavaScript by default and only hydrates the specific components that need interactivity, rather than the whole page, the same underlying approach that let us isolate 3D and animation hydration from a storefront's page speed budget on a separate build. We chose it because nothing runs until a component is explicitly hydrated, so wiring the consent layer (Axeptio's Consent Mode v2) to gate hydration itself, not individual scripts after the fact, made "no tracking before consent" true by construction across all six brands, not something six teams had to remember by hand.

A checklist tells you what the law requires. It cannot tell you which frontend decision makes the requirement true by default instead of a permanent maintenance risk that resurfaces every time a new tag gets added.

How to Think About This for Your Own Site

If your site collects EU visitor data, handles payments, or runs any marketing pixel, ask the architecture question before the tooling question. Ask your developer whether the site's JavaScript loads conditionally or all at once, a question central to how we scope web app development work for any business handling regulated data, because that answer decides whether every later compliance fix is a five-minute config change or a rebuild. A small local business with no EU customers and no payment processing beyond South African gateways still has to satisfy POPIA, but the stakes are lower, and a well-configured consent banner on the existing stack, paired with the basic cybersecurity controls every Cape Town SME needs under POPIA, is usually enough. Scale the investment to the data you actually handle.

South African connectivity is uneven enough that shipping less JavaScript by default is a load-time decision that matters on its own, since the same architecture loads faster on a patchy mobile connection whether or not anyone is asked for consent. Businesses handling EU data, payment details, or health and financial records should build the consent architecture in from day one. A local services business with a simple contact form can retrofit a compliant banner onto what it already has instead.

Get the architecture decision right and the compliance conversation becomes a formality instead of a recurring fire drill. Get it wrong and every new tracking pixel or subsidiary site becomes a fresh risk someone has to remember to gate by hand. If your business genuinely handles EU or sensitive data, this is worth doing properly once. If it does not, do not let a checklist talk you into rebuilding a site that was never the actual risk.

Questions About GDPR Compliant Websites

Is my website GDPR compliant?

Check whether any script, especially Google Analytics, Meta Pixel or a chat widget, loads before a visitor accepts cookies. If it does, the site is not compliant regardless of whether a cookie banner is present. Open your browser's network tab on first load with no consent given and see what fires.

How do I make my website GDPR compliant?

Start by auditing what loads before consent, then gate every non-essential script behind a consent event rather than adding a banner on top. A consent management platform like Axeptio's Consent Mode v2 handles the legal logic, but the site still has to be built to respect it before anything runs.

Is Google Analytics GDPR compliant?

No, not by default. Google Analytics sets tracking cookies and processes visitor data as soon as its script executes, so it must be blocked until consent is given and configured to anonymise IP addresses and limit data retention to remain within GDPR's data minimisation requirement.

Does GDPR apply to a South African website?

Yes, if the site targets EU visitors, sells to EU customers, or processes EU residents' personal data in any form, regardless of where the business is registered. A South African ecommerce site shipping to Germany is subject to GDPR on those transactions even though the company itself sits outside the EU.

Is POPIA the same as GDPR?

No. POPIA is South Africa's own data protection law and shares GDPR's core principles, but its enforcement regime, fine structure and specific obligations differ, and a site can satisfy one without fully satisfying the other. A business serving both South African and EU customers needs to meet the stricter of the two on every point where they diverge.

What is the maximum POPIA fine in South Africa?

The Information Regulator can levy an administrative fine of up to R10 million under Section 109 of POPIA, according to popia.co.za. This is separate from any civil claim a data subject brings, and the Regulator has already shown it will use this power.

What does a GDPR-compliant website example look like?

A genuine example ships no analytics or marketing script until a visitor actively consents, and keeps that rule true no matter how many tags get added later. On one EU-facing rebuild, we achieved this by tying script hydration itself to the consent event across six subsidiary sites, rather than gating each script by hand.

Arnaud Brunel

Founder, Brunel Studios

Arnaud Brunel is the founder of Brunel Studios, a software product studio based in Cape Town. He has spent the last 8 years building digital products for founders and SMEs across South Africa and Africa, working across mobile, web and AI-native platforms.

LinkedIn ↗