GDPR compliance is not a plugin you install once and forget. It is a property of how your site actually behaves: what data it collects, where that data travels, and whether you can produce or delete it on request. WordPress ships with more privacy tooling than people expect, but the personal data usually leaks out through places nobody thinks to check. Here is a practical tour of those places.
Where personal data actually lives in WordPress
Before worrying about cookie banners, take an inventory. Personal data in a typical WordPress install shows up in:
- Comments. Name, email address, and IP address are stored per comment by default.
- User accounts. Email is required; profile fields often add phone numbers, addresses, or social links.
- Form plugin submissions. Contact form entries are frequently stored in the database indefinitely unless you configure retention limits.
- Media library uploads. Photos taken on phones often carry EXIF metadata, including GPS coordinates, that WordPress preserves on upload.
- Order and checkout data, if you run WooCommerce or a similar plugin: billing addresses, purchase history, payment status.
None of this is unusual for a website. The GDPR question is whether you have a lawful basis to collect it, whether you disclose it in a privacy policy, and whether you can find and erase it when someone asks.
Embeds and third-party requests
This is the category most site owners miss entirely. Every time a page embeds a YouTube video, a tweet, a Vimeo clip, or a font loaded from a third-party CDN, the visitor’s browser makes a direct request to that third party, often before any consent decision has been made. That request typically includes the visitor’s IP address, which counts as personal data under GDPR.
Two common offenders worth checking specifically:
- Gravatar. If your theme or comment section displays avatar images, WordPress sends a hash of the commenter’s email address to Gravatar’s servers to fetch the image, on every page load, for every visitor viewing that comment.
- Externally hosted web fonts. Loading fonts from a third-party font service sends the visitor’s IP address to that service’s servers as part of the request.
The fix for both is straightforward: self-host fonts locally, and either disable Gravatar or serve a generic local placeholder instead of pulling from a third party.
Analytics and tracking scripts
Analytics tools, pixel-based ad trackers, and heatmap or session-recording scripts are the most visible privacy concern, and usually the easiest to reason about because they are intentional additions rather than accidental defaults. The key questions are the same for any of them: does the script set cookies or fingerprint visitors, does it fire before consent, and can you turn off IP logging or anonymize IPs at the source. If a tracking tool cannot anonymize IP addresses or delay firing until after consent, it needs to sit behind a consent gate, not just a disclosure notice.
Cookie consent and what it actually requires
A cookie banner that displays while every tracking script has already loaded and set cookies satisfies nobody, including regulators. Meaningful consent means:
- Non-essential scripts are blocked until the visitor actively opts in.
- Categories are granular (analytics, marketing, embeds) rather than an all-or-nothing toggle.
- Withdrawing consent is as easy as giving it.
- A record of what was consented to, and when, is kept.
This has a real technical wrinkle on cached sites. If Cloudflare or a full-page cache serves the same HTML to every visitor, the consent banner and the underlying scripts need to be handled client-side with JavaScript, since the server cannot know a given visitor’s consent state at the edge. Build consent as a script-blocking layer that runs in the browser, not as a server-side conditional, and it will work correctly regardless of caching.
Data export and erasure: the built-in tools
WordPress core actually handles a meaningful chunk of GDPR’s practical requirements out of the box, under Tools in the admin dashboard:
- Export Personal Data lets you create a request tied to an email address, have the person confirm it, then generates a zip export of the data WordPress and registered plugins know about for that user.
- Erase Personal Data runs the same request-and-confirm flow but deletes or anonymizes the matching data instead of exporting it.
- A privacy policy page generator assembles a draft policy from the data-handling notices that active plugins register, giving you a starting point rather than a finished document.
Well-built plugins hook into these tools to register their own exporters and erasers, so a form plugin or ecommerce plugin’s data gets included automatically. Poorly built ones do not, which means their data sits in the database untouched even after you “complete” an erasure request. It is worth manually checking a plugin’s settings or documentation for GDPR support before relying on the erase button to actually reach everything.
For auditing what is actually stored, wp-cli is useful for inspection work that the dashboard does not surface well:
wp user list --fields=ID,user_email,user_registered
wp user meta list <user_id>
wp comment list --fields=comment_ID,comment_author_email,comment_author_IP
After completing an erasure, clear caches so stale copies of erased data do not linger. A page that displayed a now-deleted comment or profile field may still be sitting in an object cache or full-page cache:
wp cache flush
If you run Redis or Memcached as a persistent object cache, this matters more than it might seem, since object caches can hold data far longer than a typical page cache TTL.
A practical checklist
- Audit comments, user profiles, form entries, and media uploads for personal data you are storing without a clear reason.
- Self-host fonts and disable or replace third-party avatar loading.
- Confirm analytics and tracking scripts respect consent state and support IP anonymization.
- Build consent banners as client-side script blockers so they work correctly behind a cache or CDN.
- Test the built-in Export and Erase Personal Data tools with a real account to confirm plugin data is actually included.
- Set a retention policy for form submissions and old comments instead of keeping everything indefinitely.
The takeaway
GDPR compliance on WordPress is less about buying a compliance plugin and more about knowing where data actually flows: through comments, embeds, avatars, fonts, analytics, and forms. Most of the fixes are configuration changes, not code. Managed hosts, ServerBorn included, keep the server layer current (PHP, caching, TLS) so that your attention goes to the parts only you control: what your site collects, discloses, and can delete on request.