Most GDPR violations are not caused by rogue data brokers or negligent executives. They are caused by developers who loaded a Google Analytics script before consent was granted, stored full IP addresses in server logs indefinitely, or wired up a cookie banner that looked compliant but technically was not. The legal framework is complex, but the developer's responsibility within it is specific and manageable - if you know exactly what to implement.
This guide focuses on what the regulation actually requires at the code and infrastructure level, not the legal theory. By the end, you will know which cookies need consent, what valid consent looks like technically, how to implement it correctly in WordPress, and what server-side changes are non-negotiable.
What GDPR Actually Requires from a Website
The General Data Protection Regulation (GDPR), enforced since May 2018 across the EU and EEA, applies to any website that processes personal data of EU residents - regardless of where the site is hosted or where the developer is based. "Personal data" is broader than most developers assume: IP addresses, cookie identifiers, device fingerprints, and behavioral tracking data all qualify.
From a practical standpoint, GDPR imposes four concrete obligations on websites:
Lawful basis for processing: Every act of data collection must have a legal basis. For most tracking and analytics on commercial websites, that basis is consent. Alternatives like legitimate interest exist but are increasingly scrutinized by Data Protection Authorities (DPAs) and cannot be used to justify advertising trackers.
Transparency: Users must be told what data is collected, for what purpose, for how long it is retained, and with whom it is shared - before collection begins.
Data subject rights: Users have the right to access, correct, delete, and export their data. Your database and your application logic must be able to honor these requests.
Data minimization and retention limits: You should collect only what you need, and you must not keep it longer than necessary for the stated purpose.
The regulation is enforced by national DPAs - the CNIL in France, the DPC in Ireland, the BfDI in Germany - each with the authority to issue fines up to 4% of global annual turnover or €20 million, whichever is higher. Enforcement has shifted heavily toward website-level cookie violations since 2021.
Cookie Categories and What Requires Consent
Not all cookies are equal under GDPR. The standard taxonomy used across consent management platforms maps directly to what regulators examine.
Strictly Necessary Cookies
These cookies are required for the website to function - session management, authentication tokens, shopping cart state, CSRF protection tokens, load balancer stickiness. They do not require consent because they are not used for tracking or profiling. However, "strictly necessary" is a narrow category. A cookie that remembers a user's language preference for convenience is functional, not strictly necessary.
Functional (Preference) Cookies
Cookies that remember user preferences - language, region, accessibility settings, dismissed notices - fall here. These enhance usability but are not required for core functionality. Under GDPR, they technically require consent, though in practice enforcement focuses far more on analytics and marketing cookies. You should include them in your consent banner but can reasonably pre-select them if your privacy notice is clear.
Analytics Cookies
Google Analytics, Matomo, Plausible, Fathom, and similar tools set cookies or collect behavioral data to measure traffic and user behavior. These require explicit consent. The French CNIL and other authorities have specifically ruled that Google Analytics (in certain configurations) violates GDPR because data is transferred to US servers without adequate safeguards. This is not a gray area - analytics cookies must be blocked until consent is given.
Marketing and Advertising Cookies
Pixels from Meta, Google Ads, LinkedIn, TikTok, and any remarketing or behavioral advertising technology require explicit, prior consent. These are the highest-risk category and the most common source of DPA enforcement actions. No pre-ticking, no implied consent, no "by continuing to browse" language.
What Valid Consent Looks Like Technically
GDPR Article 7 and Recital 32 define consent with precision. For developers, this translates into four non-negotiable technical properties.
Explicit and Unambiguous
Consent must be given through a clear affirmative action - a checkbox ticked, a button clicked. Pre-ticked boxes are invalid. Continuing to scroll or browse does not constitute consent. Your banner must present a genuine accept/reject choice with equal visual prominence. The "Accept All" and "Reject All" buttons must be the same size, color weight, and placement. Regulators have fined companies specifically for using dark patterns where the reject option was visually de-emphasized.
Informed
At the point of consent, the user must know what they are consenting to. This means your banner must name the categories of cookies, identify the third parties involved (or at minimum describe them), and link to a full privacy policy. Vague language like "we use cookies to improve your experience" does not meet the informed standard when marketing cookies are involved.
Revocable
Users must be able to withdraw consent as easily as they gave it. Technically, this means your site must provide a persistent, accessible way to reopen the consent management interface - typically a small icon or link in the footer - and honor preference changes immediately. When consent is withdrawn, cookies in that category must be deleted from the browser and the associated processing must stop.
Logged and Auditable
You must be able to demonstrate that consent was obtained. This requires storing a consent record: a timestamp, the user identifier (typically a consent cookie ID), the version of the privacy policy shown, and the specific categories accepted or rejected. This log must be retained and producible in the event of a DPA inquiry. Most mature consent management platforms handle this automatically - but you need to verify that the plugin or service you use actually logs consent records, not just sets a browser cookie.
Implementation in WordPress
Choosing a Consent Management Plugin
WordPress has several capable consent management plugins. Cookiebot (now Usercentrics) and CookieYes are among the most widely deployed, offering automatic cookie scanning, IAB TCF 2.2 compliance for advertising networks, and consent logging. Complianz and WPML-compatible alternatives are popular with agencies managing multilingual European sites. When evaluating options, check for: consent record storage, automatic prior-consent script blocking, granular category controls, and a documented audit trail export.
Avoid lightweight "cookie notice" plugins that only display a banner without actually blocking scripts. A banner that informs users about cookies while those cookies are already running is not compliant - it is a cosmetic layer over a live violation.
Conditional Script Loading
The most critical technical implementation detail is blocking non-essential scripts until consent is granted. In WordPress, this typically means one of two approaches.
The first approach uses the consent plugin's native script blocking, which rewrites <script> tags to use a non-executable type attribute (such as type="text/plain") and adds a data attribute indicating the consent category required. When the user accepts a category, the plugin re-executes those scripts. This approach works well with plugins that load their own JavaScript inline or via wp_enqueue_script.
The second approach is manual conditional loading using the consent cookie value. After verifying that the user has accepted analytics, for example, you enqueue the analytics script:
add_action( 'wp_enqueue_scripts', function() {
// Only enqueue analytics if consent cookie indicates acceptance
if ( isset( $_COOKIE['consent_analytics'] ) && $_COOKIE['consent_analytics'] === 'true' ) {
wp_enqueue_script( 'google-analytics', 'https://www.googletagmanager.com/gtag/js?id=G-XXXXXXXX', [], null, true );
}
} );This server-side check prevents the script from even appearing in the HTML for users who have not consented - which is cleaner than client-side blocking. The trade-off is that it requires a page reload after consent is given to activate the scripts, unless you supplement it with client-side activation logic.
Banner Requirements Checklist
No pre-selected non-essential categories: Analytics and marketing must default to off.
Equal prominence for accept and reject: Both options must be visually equivalent.
Granular controls accessible without extra clicks: Users should be able to accept strictly necessary only, without needing to navigate into a settings layer.
No scripts firing before interaction: The page should load with only strictly necessary scripts active until the user makes a choice.
Persistent re-access to preferences: A footer link or floating icon that reopens the consent panel at any time.
Server-Side Implications
Log Anonymization
Web server access logs (Apache, Nginx) record full IP addresses by default. A full IPv4 or IPv6 address is personal data under GDPR. At minimum, the last octet of IPv4 addresses should be masked before logging. For Nginx, this can be done at the log format level using a map directive to truncate the IP. For Apache, the mod_anonymize_ip module or a custom log format with substring functions achieves the same result. If you use a CDN or WAF, check whether it passes real IPs via headers and ensure those are also handled.
Data Retention Policies
GDPR requires that personal data not be retained longer than necessary. For server logs, a 30 to 90 day retention window is typical and defensible. For analytics data, most DPAs consider 14 months acceptable for aggregate behavioral data. For user account data, you need a documented retention schedule tied to the purpose of collection. Automated log rotation with deletion - not archiving - is the correct implementation.
Right to Erasure in the Database
When a user submits a deletion request, your application must be able to identify and remove all personal data associated with that individual. In WordPress, this includes: user account rows in wp_users and wp_usermeta, comment author data in wp_comments, form submission entries if you use a plugin like Gravity Forms or WPForms, WooCommerce order data (subject to retention requirements for financial records), and any custom post types or meta fields that store user-identifying information.
WordPress 4.9.6 introduced built-in personal data export and erasure tools under Tools > Export Personal Data and Tools > Erase Personal Data. These work for core data but do not automatically cover third-party plugin data. Audit every plugin that handles user data and verify it either integrates with the WordPress privacy tools or provides its own erasure mechanism.
Common Developer Mistakes That Create GDPR Liability
Several patterns appear repeatedly in GDPR audits of WordPress sites, and each represents a real compliance failure - not just a technicality.
Loading Google Tag Manager unconditionally: GTM itself may seem neutral, but the tags it fires are not. If GTM loads before consent and fires an analytics or advertising tag, consent has been bypassed regardless of what the banner says. GTM must either be blocked until consent is granted, or configured with consent mode so that tags respect the user's choices before firing.
Using consent cookies with no expiry or excessively long expiry: GDPR requires that consent be re-obtained periodically if the purpose or parties change. Consent cookies with a 10-year expiry are not defensible. A 12-month expiry is a common and reasonable standard.
Treating logged-in users as having consented: Creating an account on a site does not constitute consent to analytics or marketing tracking. Consent must be obtained separately and specifically for each purpose.
Embedding third-party content without consent: YouTube embeds, Google Maps iframes, social media share buttons, and font loading from Google Fonts all send data to third-party servers when the page loads. Each of these must be blocked until the relevant consent category is accepted, or replaced with privacy-preserving alternatives (self-hosted fonts, facade patterns for video embeds).
Ignoring the "Do Not Track" signal and GPC: While DNT has no legal standing under GDPR, the Global Privacy Control (GPC) signal is increasingly recognized by regulators in some jurisdictions as a valid opt-out signal. Implementing GPC header detection is a forward-looking measure worth considering.
The ePrivacy Directive and the Regulation on the Horizon
Cookie consent requirements in the EU are primarily governed not by GDPR directly, but by the ePrivacy Directive (2002/58/EC, amended 2009) - often called the "Cookie Law." The directive requires prior informed consent for the storage of or access to information on a user's device, which is the legal basis for cookie consent banners. GDPR sits alongside it, governing what happens to the personal data that those cookies collect.
The ePrivacy Regulation has been in draft since 2017 and was expected to replace the directive with a directly applicable EU regulation - removing the inconsistency between member state implementations. As of 2025, it remains stalled in the legislative process, with significant disagreement over browser-level consent signals, legitimate interest for analytics, and the scope of machine-to-machine communications. When it does pass, it will likely shift consent management toward browser and OS-level signals rather than per-site banners - but developers should not wait for it. The current ePrivacy Directive, as interpreted by national DPAs, is the enforceable standard today.
One practical implication of the current patchwork: Germany and France have historically taken stricter positions on analytics cookies than some other member states. If your WordPress site serves audiences in those countries specifically, aligning with CNIL and DSK guidance is prudent even where it exceeds the minimum interpretation elsewhere.
Compliance Is an Architecture Decision
GDPR compliance on a WordPress site is not a plugin you install and forget. It is a set of architectural decisions - about which scripts load when, how logs are retained, how the database handles deletion requests, and how consent is recorded and audited. The developer who treats it as a checkbox exercise creates liability for themselves and their clients. The developer who understands the technical requirements can build sites that are genuinely compliant, not just cosmetically so.
If your site also relies on structured data and technical SEO, it is worth auditing how your SEO plugins interact with user data and third-party services - the Signocore SEO Analyzer surfaces technical signals across your site that can inform a broader privacy and performance audit. Clean, minimal implementations that avoid unnecessary third-party dependencies are easier to make compliant and tend to perform better on every dimension that matters.
