GDPR-Friendly Websites

Build websites on PageWeave that meet European privacy law (GDPR/DSGVO, ePrivacy Directive, German TDDDG) by construction — not by bolting on a cookie banner. The platform baseline is already compliant; your job is to keep it that way and add the required legal pages.

The platform baseline (already compliant)

PageWeave's architecture satisfies the strictest EU position (Germany §25 TDDDG) by default:

Area	Platform fact
Hosting	Hetzner Online GmbH, Germany (Nuremberg/Falkenstein/Helsinki data centers, all EU)
Analytics	Server-side only. No cookies, no JavaScript trackers, no fingerprinting. Visitor hash = SHA256(IP + UA + date). Raw data 90 days, aggregated daily stats kept longer
Cookies	None on public sites. No session, analytics, or tracking cookies on *.pageweave.site
Fonts	Google Fonts automatically proxied through PageWeave — never loaded from Google
Assets	Hetzner Object Storage (S3-compatible, EU)
TLS	HTTPS everywhere, on-demand TLS for hostnames
Forms	Submissions stored as JSONB in PostgreSQL (EU); email notifications via SMTP

Legal consequence: ePrivacy Art 5(3) / §25 TDDDG only triggers when information is stored on or read from the visitor's device. PageWeave stores nothing and reads nothing — so no consent banner is required. German DPAs (DSK) confirm: no device storage = no consent requirement. Never break this baseline.

Never add

These reintroduce consent obligations (banner + CMP + consent logging) and can get the site owner fined:

• Analytics or tracking JavaScript — Google Analytics, GTM, Meta Pixel, Hotjar, or any client-side analytics script. Platform analytics is already server-side; adding JS analytics is both redundant and unlawful without consent.
• External CDN resources — scripts, CSS, or fonts from cdnjs, jsdelivr, unpkg, or any other third-party host. Google Fonts are automatically proxied by the platform (no action needed); every other third-party CDN or API is a direct request to that provider.
• Embeds that load on page load — YouTube/Vimeo iframes, Google Maps, social media widgets. See the facade pattern below.
• Cookie-dropping widgets — chat widgets, newsletter popups, share buttons that set cookies.
• A cookie banner itself. There is nothing to consent to; a banner would be a lie and a maintenance burden.

If the site owner insists on a third-party tool that needs cookies or device storage: explain that it reintroduces banner + consent + CMP obligations, and prefer the platform-native alternative first.

Required legal pages

Privacy policy (always)

Every site that processes personal data needs one — and every PageWeave site does (server logs, analytics, forms). Requirements:

• Written in the site's language (use the page language field).
• Real controller identity from the user — name, address, contact. Never invent or guess this data.
• Covers every processing activity actually present: hosting, analytics, forms, and any embeds.
• Linked from the footer on every page (footer component).

Use the template in references/privacy-policy-template.md — it pre-fills the PageWeave platform facts.

Impressum / legal notice (DE and AT commercial sites)

Germany (§5 DDG) and Austria (§5 ECG, §25 MedienG) require provider identification on commercial sites. Ask the user for the real data — never invent it. Details and field lists: references/imprint-guide.md.

Cookie policy (only if cookies exist)

On a default PageWeave site there are no cookies, so no cookie policy is needed. Only add one if the owner insisted on a cookie-setting third-party tool.

Forms

• Always ask for notification_email before creating a form — it triggers a verification email, and notifications only start after the owner clicks the link.
• Collect only what the purpose needs (Art 5 data minimization). A contact form rarely needs phone number or company.
• Near the submit button: state the purpose and link the privacy policy.
• Marketing consent (newsletter) must be a separate, unchecked checkbox — never pre-checked, never required to submit an inquiry.
• The privacy policy must list each form: purpose, legal basis (Art 6(1)(a) consent or (b)/(f)), retention (owner deletes submissions), and the fact that the site owner is controller and PageWeave is processor.

Embeds — click-to-load facade (consent by design)

Default: no third-party embeds. If the owner wants a video or map:

1. Simplest and safest: self-hosted thumbnail + plain link to the provider. Zero processing, zero consent needed.
2. Facade pattern (click-to-load): the visitor sees a self-hosted thumbnail with a labeled activation button; the real iframe loads only after the click. The labeled click IS the consent (Art 4(11) GDPR, §25 TDDDG affirmative act) — so no cookie banner is needed, as long as this is the only third-party processing on the site.

Facade rules:

• Thumbnail must be self-hosted: upload_asset with the provider's thumbnail URL (e.g. i.ytimg.com). The platform fetches it server-side once; the visitor's browser never contacts the provider before the click. Hotlinking the thumbnail defeats the whole pattern.
• No iframe src, no player scripts, no preconnect/dns-prefetch to provider domains in the page HTML. Store the iframe URL in data-src; swap to src only on click.
• Button label names the recipient and the data transfer, in the site language: "Load video from YouTube — your IP address and browser data are transferred to Google. [Privacy policy]". A bare play button is not informed consent.
• Use youtube-nocookie.com in the post-click iframe as defense-in-depth. It is NOT sufficient alone — it writes localStorage on load and transmits the IP.
• No autoplay before consent. Keyboard accessible: role="button", tabindex="0", Enter/Space activates. noscript fallback: plain link.
• Privacy policy must disclose the embed: provider (Google Ireland Ltd / Google LLC), data types, purpose, legal basis (consent), US transfer under the EU-US Data Privacy Framework, joint controllership (CJEU Fashion ID C-40/17), and how to withdraw.

Same pattern applies to Vimeo, Google Maps, Spotify, and social embeds.

Language

Legal pages in the audience's language. German sites: Datenschutzerklärung + Impressum. Multilingual sites: one policy page per language.

Launch audit

Before handoff, run the checklist in references/launch-audit.md: grep every page's HTML for third-party hosts, check the head for preconnects, confirm fonts are proxied, forms have notices, policy and imprint exist and are footer-linked.

Gotchas

• Never invent legal entity data — names, addresses, register numbers. Wrong Impressum data is worse than none. Ask the user.
• Never write a privacy policy listing services that aren't present. List only what the site actually does.
• The platform's analytics is automatic and server-side. Do not add JS analytics "to see traffic" — it breaks compliance and duplicates what already exists.
• Dev environments are noindex and not GDPR-relevant; legal pages must be published on the live site.
• This is technical guidance, not legal advice. Retention periods, DPO obligations, and DPA paperwork are the owner's responsibility — flag commercial sites for lawyer review.