GDPR-Ready Framer Sites for European Teams

GDPR compliance on a marketing site is mostly about three things: not loading tracking before consent, telling people plainly what you collect, and not collecting more than you need. Framer can do all three, but none of them happen by default — and the default is the part that catches people out.

This is practical guidance from building sites for EU clients, not legal advice. For your specific obligations, talk to a lawyer.

TL;DR

• Analytics and marketing scripts must not fire before the visitor consents. Loading them and asking afterwards is the common failure.

• Consent must be as easy to refuse as to accept. A prominent Accept and a buried Reject is not valid consent.

• Google Consent Mode v2 needs its default call to run before the tag manager loads.

• Forms should collect only what you actually use, and say what happens to it at the point of collection.

• Embeds — fonts, maps, video, chat — are third-party data transfers and belong behind consent.

The mistake almost everyone makes

A cookie banner appears, the visitor clicks Accept, and everyone assumes the site is compliant. Meanwhile the analytics script loaded with the page, before the banner even rendered, and has already sent a pageview. The banner is decorative.

The requirement is sequencing, not signage. Non-essential scripts must not execute until consent exists. In practice this means your tracking loads conditionally — either gated behind a consent check, or using a consent framework that holds tags until a signal arrives.

Doing it properly with Google Consent Mode v2

If you use Google Analytics or Google Tag Manager, Consent Mode v2 is the mechanism. The critical detail is ordering: the consent default call must run before the tag manager script loads. If it runs after, the tags have already fired with default permissions and the call does nothing.

On Framer that means the default call goes in the head start slot, ahead of the GTM snippet. Then your banner updates the consent state when the visitor chooses, and Google's tags react to the update. Get the order wrong and you have the appearance of compliance with none of the substance.

Second detail worth knowing: your consent default should read whatever the visitor already chose on a previous visit, not hardcode denied. Hardcoding denied means returning visitors who accepted last week are silently untracked.

What a valid banner looks like

• Reject is as prominent and as few clicks as Accept. Equal visual weight, same level.

• No pre-ticked boxes for non-essential categories.

• Categories the visitor can choose between, not one all-or-nothing switch — at minimum necessary, analytics, and marketing.

• A way to change the decision later, reachable from every page. A footer link is fine.

• No dark patterns: no cookie wall, no 'Accept to continue', no Reject hidden behind two more clicks.

Embeds are data transfers

This is the part people miss because it does not look like tracking. A Google Font loaded from Google's servers transmits the visitor's IP address to Google. So does an embedded map, a YouTube player, a chat widget, and most marketing pixels. German courts in particular have taken a firm view on remotely loaded fonts.

Practical fixes: self-host fonts rather than loading them remotely — Framer does this for its own font handling, but check any custom font code you added. Load maps, video, and chat behind a click-to-load placeholder, or behind consent. Each of these is a small change and each removes a category of risk.

Forms and data minimisation

Collect what you will actually use. A contact form asking for company size, budget range, and phone number when you only ever reply by email is collecting data you cannot justify. At the point of collection, say plainly what happens to it — one sentence beside the submit button does more than a link to a policy nobody opens.

Also worth checking: where form submissions go. If your form provider stores data outside the EU, that is a transfer with its own requirements, and it is worth knowing before a client asks.

Where Framer's own analytics changes the checklist

One piece of this gets easier if you are using Framer Analytics instead of Google Analytics: it sets no cookies and generates no persistent identifier, so it does not need to sit behind your consent banner at all. IP addresses and user agents are hashed against a secret that rotates and is deleted every 24 hours — the same visitor looks like a different hash the next day, which is also why day-over-day unique counts cannot be de-duplicated across dates. If that is your only analytics tool, your consent banner exists purely for third-party embeds, not for your own traffic numbers. Swap in Google Analytics, Meta Pixel, or a heatmap tool and you are back to needing the full consent-gating described above for that specific script.

What belongs in your privacy policy

Written for a person, not for a lawyer: what you collect, why, who else sees it (name the actual processors — analytics, form provider, hosting), how long you keep it, and how someone exercises their rights. If you cannot list your processors, that is the first thing to fix, because you cannot disclose what you have not inventoried.

A short audit you can run today

• Open the site in a private window with devtools open. Before touching the banner, check the network tab — is anything loading from analytics or marketing domains?

• Click Reject. Check again. Anything still firing is a problem.

• Count the clicks to reject versus accept. They should be equal.

• List every third-party domain the page contacts. Each one needs a justification.

• Check your privacy policy names those same processors.

What to do next

Run the private-window test — it takes two minutes and tells you immediately whether your banner is doing anything. If scripts fire before consent, fix the ordering first, because that is the substantive issue and everything else is presentation. For EU-facing sites I build, this is set up as part of the build rather than added afterwards.