GDPR-Compliant WordPress: A Practical Setup Guide for EU Businesses
A GDPR compliant WordPress site is one where no personal data leaves the visitor’s browser before they consent, every form and plugin that stores personal data has a lawful basis and a retention rule, and the business can prove both. In practice that comes down to seven controls: a consent-gated tag layer, self-hosted assets instead of third-party embeds, privacy-respecting analytics, minimal form data with documented retention, a working export/erase workflow, a hosting and backup setup inside the EU (or with valid transfer safeguards), and a privacy policy that reflects what the site actually does.
Most sites that claim to be a GDPR compliant WordPress setup fail on the first two. A default install with Google Fonts, a YouTube embed, Google Analytics and a chat widget sends the visitor’s IP address to four different companies before the cookie banner has even rendered. The banner is cosmetic; the data has already gone.
This guide is written for marketing directors and founders at EU companies (and US companies with EU customers) who need a WordPress site that is defensibly compliant without turning it into a legal exercise. It covers what actually leaks data, how to fix each leak at the technical level, which plugins help, and the documentation you need to keep.
What GDPR actually requires from a website
The General Data Protection Regulation applies whenever you process personal data of people in the EU/EEA. On a website, “personal data” includes IP addresses, cookie identifiers, form submissions, email addresses and behavioural data tied to a device. The obligations that touch a WordPress site directly are:
- Lawful basis (Art. 6) for every processing activity — consent for marketing cookies and tracking, legitimate interest or contract for things like fraud prevention and order fulfilment.
- Consent that is freely given, specific, informed and unambiguous (Art. 7 and the ePrivacy Directive for cookies). Pre-ticked boxes and “by continuing you agree” banners do not qualify.
- Data minimisation and storage limitation (Art. 5): collect only what you need and delete it when you no longer need it.
- Data subject rights (Arts. 15–22): access, rectification, erasure, portability — and you must be able to fulfil them within one month.
- Records of processing and processor agreements (Arts. 28 and 30): a written Data Processing Agreement with every vendor that handles personal data for you, including your host, email provider and analytics vendor.
- International transfers (Chapter V): data leaving the EEA needs a valid mechanism, such as the EU–US Data Privacy Framework for certified US companies or Standard Contractual Clauses.
The full regulation text is at gdpr.eu. The practical takeaway: compliance is about what your site does, not what your banner says.
Step 1: audit what your WordPress site actually sends, and to whom
Before touching plugins, open the site in a private window with Chrome DevTools’ Network tab, filter by third-party domains, and reload the homepage without interacting with the banner. Everything that appears in that list is a data transfer that happened before consent. On a typical mid-market WordPress site we audit, the list looks like this:
| Request | What it leaks pre-consent | Fix |
|---|---|---|
| fonts.googleapis.com / fonts.gstatic.com | IP address to Google on every page view (a German court fined a site for exactly this in 2022) | Self-host fonts as WOFF2 in the theme |
| youtube.com / player.vimeo.com iframes | IP, cookies, device fingerprint on load | Use youtube-nocookie.com behind a click-to-load facade, or lite-youtube |
| google-analytics.com / googletagmanager.com | IP, client ID, page path | Fire only after consent via a consent-mode-aware tag manager, or switch to a cookieless analytics tool |
| Chat widgets, heatmaps, session recording | Full behavioural data, sometimes form keystrokes | Consent-gate, or load on user interaction only |
| Gravatar (secure.gravatar.com) | Hashed email of commenters; IP of visitors | Disable avatars in Settings → Discussion |
| Google reCAPTCHA | IP, device signals, cookies from google.com | Replace with a privacy-respecting alternative (hCaptcha in privacy mode, Turnstile, or honeypot + rate limiting) |
| Google Maps embeds | IP and cookies on load | Static map image with a click-to-open link |
| CDN-hosted plugin scripts (jsDelivr, cdnjs) | IP to a third party | Self-host all JS/CSS |
Do the same on a product page, a blog post and the contact page. Page builders and “premium” themes are the usual culprits for loading icon fonts, sliders and map scripts from CDNs on every page.
Step 2: the consent layer every GDPR compliant WordPress site needs
A cookie banner is only compliant if scripts and cookies that need consent do not run until consent is given. That requires two things: a consent management platform (CMP) that records the choice, and a tag-loading mechanism that respects it.
Choosing a CMP for WordPress
Look for these capabilities rather than a brand name:
- Granular categories (necessary, functional, analytics, marketing) with equal-prominence “Reject all” and “Accept all” buttons on the first layer. Several EU regulators have stated that hiding “reject” behind a second click is non-compliant.
- Consent logging with timestamp, version of the policy and the categories chosen — you need this as proof.
- Google Consent Mode v2 support if you use any Google tags, so that Ads and Analytics receive the consent signals they now require in the EEA.
- Automatic script blocking that rewrites
<script>tags totype="text/plain"until consent, plus a hook (or a JavaScript event) you can use in a custom theme to defer your own embeds. - Re-consent when the policy changes and an always-accessible “Cookie settings” link in the footer.
Gate tags through a tag manager, not the theme
Put every non-essential tag in Google Tag Manager (or a server-side alternative) with consent-based triggers, and keep the theme free of hard-coded pixels. In a well-built block theme this is a policy your marketing team can enforce without a developer: new tags go into GTM with a consent trigger, or they do not go in. It is also a performance win, which we cover in our Core Web Vitals guide for marketing teams.
Step 3: choose analytics you can defend
Two workable approaches exist for a GDPR compliant WordPress site.
- Cookieless, EU-hosted analytics (Plausible, Fathom, Matomo self-hosted or EU cloud, Umami). These tools do not set identifying cookies and can be configured to anonymise IPs, so most regulators treat them as usable under legitimate interest without consent — provided you document the assessment. You lose cross-session user tracking but keep everything a marketing team needs for content and campaign reporting.
- Google Analytics 4 with consent. GA4 only runs after analytics consent, with Consent Mode v2 sending cookieless pings before consent. You will see 30–60% fewer users than reality, because that is roughly how many EU visitors decline. Google’s US transfer is currently covered by the Data Privacy Framework, but the decision has already been challenged once, and several EU DPAs ruled against earlier GA versions.
Our default recommendation for EU clients is option 1 as the primary tool, with GA4 added only when paid media genuinely needs it. It removes the biggest single point of legal risk and improves page speed at the same time.
Not sure what your site is leaking before consent? Drop your URL and a senior strategist will record a free 15-minute teardown of its speed, structure and conversion leaks — within 48 hours.
Step 4: forms, comments and the data WordPress stores by default
WordPress itself is fairly conservative, but plugins are not. Go through every place the site collects personal data and answer three questions: why do we collect it, where is it stored, and when is it deleted.
Contact and lead forms
- Collect only what the next step needs. A “Request a quote” form does not need a phone number and a company size and a date of birth.
- Add a short purpose statement under the form (“We use this to reply to your enquiry. See our privacy policy.”) rather than a consent checkbox — consent is the wrong basis for responding to an enquiry; legitimate interest or pre-contractual steps is. Use a checkbox only for the separate newsletter opt-in, unticked by default.
- Decide whether the form plugin should store submissions in the database at all. If it does, set a retention period (many form plugins have a built-in auto-delete after N days) and make sure the entries are included in your export/erase workflow.
- Check where notifications go. If the form emails a CRM or a Slack channel, those are processors and need DPAs.
Comments, users and WooCommerce
- Disable comments on pages that do not need them; where they are on, enable the “Show comments cookies opt-in checkbox” in Settings → Discussion and turn off avatars.
- WooCommerce has a built-in personal data retention setting (WooCommerce → Settings → Accounts & Privacy) for inactive accounts, pending, failed and cancelled orders. Set it. Orders themselves are usually kept for the statutory accounting period, which is a legitimate legal-obligation basis.
- Keep the admin user list clean. Former staff and agency accounts are both a security and a GDPR problem.
Use the tools WordPress core already gives you
Since 4.9.6, WordPress core includes Tools → Export Personal Data and Tools → Erase Personal Data. They generate an export ZIP or anonymise data for a given email address, across core tables and any plugin that registers itself with the wp_privacy_personal_data_exporters and wp_privacy_personal_data_erasers filters. Well-built plugins (WooCommerce, the major form plugins) hook into these. Test the workflow once with a real address so that a request from a customer is a five-minute task, not a panic. There is also a Privacy Policy page generator under Settings → Privacy that collects suggested text from installed plugins — useful as a checklist of what is collecting data, not as a finished policy. The developer documentation is at developer.wordpress.org.
Step 5: hosting, backups and email — the processors people forget
Your host is a processor. So is your backup destination, your transactional email service and your CDN. Each one needs a Data Processing Agreement, and each one is a potential international transfer.
- Hosting location. An EU data centre is the simplest defensible choice for an EU business. If the provider is US-owned but the data centre is in the EU, check the DPA for where support staff can access data from and which transfer mechanism covers it.
- Backups. Off-site backups often default to US object storage. Choose an EU region and encrypt at rest. Backups also hold personal data you may have “erased” from the live site, so define a backup retention window (30–90 days is typical) and note in your records that erased data persists in backups for that period.
- CDN and WAF. A global CDN terminates TLS at edge nodes worldwide, which means an EU visitor’s request may be processed in the US. Most large CDN providers are DPF-certified and offer EU-only data-processing settings; enable them.
- Transactional email. Order confirmations and form notifications routed via a US email API are transfers too. Pick an EU region or an EU-based provider.
Hosting choice also drives security, which GDPR treats as a compliance obligation in its own right (Art. 32). A breach caused by an unpatched plugin is a reportable incident. That is one reason we bundle patching, malware scanning and off-site EU backups into every WordPress maintenance and care plan, and why a full WPScan pass with zero critical findings is part of our launch checklist.
Step 6: the privacy policy and the paperwork
Once the technical layer is honest, the documents are straightforward. You need:
- A privacy policy that lists each processing purpose, its lawful basis, the data categories, the recipients (named processors), retention periods, international transfers and how to exercise rights. Write it from the audit in Step 1, not from a template — the template will list things your site does not do and miss things it does.
- A cookie policy (can be a section of the privacy policy) with the actual cookie table your CMP generates.
- Records of processing activities (Art. 30) — a spreadsheet is fine for most companies under 250 staff, but it must exist.
- DPAs with host, CDN, email, analytics, CRM, form and chat vendors, filed together.
- A legitimate-interest assessment for anything you run without consent, such as cookieless analytics or fraud prevention.
- A breach response procedure: who is notified, how you assess risk, and how you would report to the supervisory authority within 72 hours.
Legal review is worth paying for on the policy and DPAs; the rest is operational discipline.
A GDPR compliant WordPress checklist you can hand to your team
| Area | Control | Done? |
|---|---|---|
| Assets | Fonts, icons, JS and CSS self-hosted; no CDN calls pre-consent | ☐ |
| Embeds | Video, maps and social embeds behind click-to-load facades | ☐ |
| Consent | CMP with equal Accept/Reject, consent logs, Consent Mode v2, script blocking | ☐ |
| Tags | All non-essential tags in GTM with consent triggers; none hard-coded in theme | ☐ |
| Analytics | Cookieless EU-hosted tool, or GA4 strictly after consent | ☐ |
| Forms | Minimal fields, purpose text, unticked newsletter opt-in, retention set | ☐ |
| Core settings | Avatars off, comment cookie opt-in on, WooCommerce retention set | ☐ |
| Rights | Export/Erase tested; request handled within 30 days | ☐ |
| Processors | EU hosting/backups/email; DPAs filed; transfer mechanisms noted | ☐ |
| Security | Patching cadence, malware scanning, 2FA on admin, zero critical WPScan findings | ☐ |
| Documents | Privacy policy, cookie policy, Art. 30 records, LIA, breach procedure | ☐ |
Why architecture matters more than plugins
Every compliance failure above is easier to prevent than to patch. A theme that self-hosts its fonts and only loads each block’s assets where the block is used has nothing to un-leak. A site where marketing adds tags through a consent-gated tag manager cannot accidentally ship a pre-consent pixel. That is the same modular thinking behind the block-based architecture we build every site on, and it is why we treat GDPR as a design constraint from the first wireframe rather than a plugin installed the week before launch. If you want to see how that plays out in a real engagement, our process page walks through the discovery and launch checklists step by step.
Key takeaways
- Compliance is about what the site does before consent, not what the banner says — audit third-party requests first.
- Self-host fonts and scripts, and put video, maps and chat behind click-to-load facades.
- Use a CMP with equal Accept/Reject buttons, consent logging and Consent Mode v2, and route all tags through a consent-gated tag manager.
- Prefer cookieless EU-hosted analytics; run GA4 only after consent if paid media needs it.
- Set retention on forms, comments and WooCommerce data, and test WordPress core’s export/erase tools.
- Treat host, CDN, backups and email as processors: EU regions, DPAs, transfer mechanisms.
If your current site fails half of this checklist, a rebuild on a clean, modular foundation is often cheaper than patching. Our 7-Day Homepage Sprint ($4,900, fixed) delivers a privacy-clean, Lighthouse-green homepage in a week and is credited toward a full build within 60 days — a low-risk way to see how we work.
Frequently asked questions
WordPress core is reasonably privacy-friendly and includes personal data export and erasure tools, but a real site becomes non-compliant through themes, plugins and embeds that send data to third parties before consent. Compliance depends on how the site is built and configured, not on the CMS itself.
If the site sets any non-essential cookies or runs tracking scripts for visitors in the EU/EEA, yes. The banner must offer an equally prominent reject option and must actually block those scripts until consent is given. A site with no tracking and self-hosted assets may not need one at all.
GA4 can be used if it loads only after analytics consent and Consent Mode v2 is configured, and the transfer to the US relies on the EU-US Data Privacy Framework. Many EU businesses choose a cookieless, EU-hosted analytics tool instead to reduce legal risk and avoid losing 30 to 60 percent of their data to consent declines.
Yes, when loaded from Google's servers, because the visitor's IP address is sent to Google before consent. A German court fined a website for this in 2022. The fix is to self-host the font files inside the theme, which also improves page speed.
There is no single plugin that makes a site compliant. You need a consent management plugin with script blocking and consent logs, combined with self-hosted assets, consent-gated tags, minimal forms with retention rules, and EU-based processors. The plugin handles consent; the architecture handles everything else.