Not legal advice: This article explains general legal concepts as they apply to web analytics in 2026. It is not a substitute for professional legal advice. If you operate a site in a regulated industry or have specific compliance requirements, consult a qualified privacy lawyer.

Most WordPress site owners believe they need a cookie consent banner because “GDPR requires it for analytics.” That framing is an oversimplification — and it has driven a proliferation of consent popups across the web, many of them legally unnecessary. Running GDPR analytics without a consent banner is not a loophole or a gamble: for a correctly architected setup, it is the straightforward reading of the law. Understanding why requires separating two distinct instruments of European privacy law that operate in parallel but govern entirely different things.

  • GDPR (General Data Protection Regulation, EU 2016/679) governs the processing of personal data across the EU and EEA. It establishes six legal bases for processing: consent, legitimate interest, contractual necessity, legal obligation, vital interests, and public task. Consent is one option, not the only one.
  • ePrivacy Directive (Directive 2002/58/EC, as amended) specifically governs electronic communications privacy, including what happens on users’ devices. Article 5(3) — the so-called “Cookie Law” — is the provision that requires prior informed consent before storing or accessing information on a user’s terminal equipment.

The consent requirement that drives most analytics banners flows from the ePrivacy Directive, not GDPR directly. Critically, the ePrivacy Directive targets a specific act: accessing or storing data in the browser. It is not a blanket requirement on every form of analytics data collection. Understanding this distinction is the key to building a legally defensible no-banner analytics setup on WordPress in 2026.

What Article 5(3) actually covers — and what it does not

Article 5(3) of the ePrivacy Directive requires prior informed consent before “the storing of information, or the gaining of access to information already stored, in the terminal equipment of a subscriber or user.” In practice, this provision covers:

  • HTTP cookies — both setting and reading them
  • localStorage and sessionStorage access used for persistent tracking
  • Browser fingerprinting techniques that reconstruct identifiers from browser attributes
  • IndexedDB, Flash Local Shared Objects, and equivalent persistent browser-side storage mechanisms
  • Any JavaScript-based technique that reads previously stored information to re-identify a visitor across sessions

Article 5(3) does not cover:

  • Server-side logging of HTTP request metadata — IP address, User-Agent, referrer, timestamp — transmitted to your server as part of how the HTTP protocol works
  • Analytics derived purely from server-received data without reading or writing anything to browser storage
  • Aggregate statistical analysis of access patterns that does not involve individual identification

When a user loads a page, their browser transmits certain information to your server as part of the TCP/IP and HTTP handshake — before any JavaScript runs, before any cookie is set. Processing that server-received data is fundamentally different from injecting a script to probe the browser’s local storage. That distinction defines the boundary between consent-required and consent-optional analytics — and it is precisely the boundary that makes analytics without a consent banner possible under GDPR.

Key principle: A server-side analytics approach that collects only request-level data and never sets, reads, or stores anything in the visitor’s browser sits entirely outside Article 5(3)’s consent trigger. The ePrivacy Directive simply does not apply to it.

Even where GDPR’s personal data rules are engaged, consent is not the only lawful basis available. Article 6(1)(f) of GDPR permits processing based on legitimate interest when three cumulative conditions are satisfied. The European Data Protection Board addressed the relationship between these two frameworks directly in EDPB Opinion 05/2019 on the interplay between the ePrivacy Directive and the GDPR. That Opinion clarifies that when ePrivacy consent is required for a browser-access layer, a separate GDPR legal basis is still needed for any subsequent personal data processing — and that legitimate interest can validly serve as that basis where the three-step test is satisfied. Critically, the Opinion also confirms that when the ePrivacy layer does not apply at all (because no browser storage is accessed), the GDPR legitimate interest analysis stands alone and is not constrained by ePrivacy’s stricter consent standard.

The three-step legitimate interest test requires:

  • Purpose test: You have a genuine, articulated legitimate interest in the processing — for example, understanding how your website is used in order to improve its content and performance. The interest must be specific and real, not merely asserted in boilerplate privacy policy language.
  • Necessity test: The processing is necessary to achieve that interest and you cannot reasonably achieve the same outcome through less privacy-invasive means. Using server-side, cookieless analytics with IP hashing rather than full-resolution IP logging satisfies this test more cleanly than any client-side alternative.
  • Balancing test: Your legitimate interest is not overridden by the data subject’s rights and reasonable expectations, taking into account the nature of the data collected, the likely impact on individuals, and the safeguards in place.

For privacy-preserving first-party, cookieless analytics, this framework is genuinely defensible. Understanding visitor behavior is a recognized legitimate business interest. Using hashed and truncated IP addresses is a proportionate means of pursuing it — you are not building advertising profiles, not tracking users across sites, and not sharing data with third-party infrastructure. The balancing test tilts firmly in the controller’s favor when the privacy impact is demonstrably low.

Legitimate interest is not a free pass, however. You must conduct and document a Legitimate Interest Assessment (LIA) — a written record showing you worked through all three steps. For well-designed, privacy-first WordPress analytics, the LIA outcome is substantially more favorable than it would be for behavioral advertising or cross-site tracking. The LIA should document: the specific purpose pursued, the technical safeguards applied, and your reasoned conclusion on the balancing test. File this alongside your Records of Processing Activities (ROPA) and review it annually.

Regulatory comparison: EU, UK (PECR), and Japan (APPI)

European Union — ePrivacy Directive and member-state implementations

The EU ePrivacy Directive is transposed differently across member states, creating a patchwork of national implementations. France’s CNIL has published an analytics exemption permitting cookieless or limited-cookie audience measurement without consent when: (1) data is used solely by the first party; (2) it is not combined with other datasets; (3) it serves only statistical measurement of the site’s own audience; and (4) it is not transmitted to third parties. The Spanish AEPD and Belgian APD have taken compatible positions. Germany’s TTDSG — which implements ePrivacy rules into German law — provides that consent is not required for technologies strictly necessary for a service explicitly requested by the user. The overarching pattern across the EU in 2026: the closer your analytics is to pure server-side, first-party, non-identifying measurement, the more defensible a no-consent posture becomes across all member states.

United Kingdom — PECR

Post-Brexit, the UK operates under the Privacy and Electronic Communications Regulations 2003 (PECR) alongside UK GDPR. PECR Regulation 6 mirrors Article 5(3) of the EU ePrivacy Directive in requiring consent for setting cookies or accessing terminal equipment. The ICO has explicitly acknowledged that analytics with a low privacy impact may be treated more permissively — and has confirmed that server-side analytics without any browser storage access falls outside PECR’s consent trigger entirely. For UK-focused WordPress sites, a pure server-side approach that never writes to or reads from the browser avoids PECR’s consent requirement, while UK GDPR’s legitimate interest basis covers the residual server-side data processing.

Japan — APPI 2022 Amendments

Japan’s Act on the Protection of Personal Information (APPI), substantially amended in 2022, refined the framework for pseudonymous processed information (仮名加工情報) and anonymously processed information (匿名加工情報). An IP address irreversibly hashed using a one-way function — so that re-identification is computationally infeasible — is treated as anonymously processed information, subject to significantly lighter obligations. Japan has no direct equivalent of Article 5(3): there is no Japanese “cookie law” requiring consent for client-side storage per se. For Japanese operators running WordPress, first-party analytics using server-side IP hashing and no cross-linking with personal data presents minimal APPI risk, provided appropriate privacy policy disclosure is made.

What enforcement has actually targeted

Reviewing enforcement actions from the major European data protection authorities since 2018 reveals a consistent pattern. Cases resulting in fines and formal notices have targeted:

  • Google Analytics (Universal Analytics and GA4) transferring EU visitor data to US servers under transfer mechanisms deemed insufficient after Schrems II
  • Advertising cookies — Meta Pixel, Google Ads conversion tags, LinkedIn Insight Tag — deployed without valid prior consent
  • Consent banners that made rejection harder than acceptance, or that ignored “reject all” selections entirely
  • Cross-site behavioral tracking and advertising audience profiling without a valid lawful basis
  • Data brokers processing personal data at scale without meeting any of the Article 6 conditions

There are no published enforcement actions targeting first-party, cookieless, server-side analytics that process only pseudonymized identifiers and do not transmit data to third-party infrastructure. This is not an oversight — the regulatory purpose of ePrivacy and GDPR enforcement has been to protect users from hidden third-party data collection, not to prevent site owners from understanding how their own website performs. Replacing Google Analytics with a self-hosted alternative removes the most significant vector of enforcement risk in a single step.

Why GA4 was ruled non-compliant in multiple EU countries

Between 2022 and 2023, the Austrian DSB, French CNIL, Italian Garante, Danish Datatilsynet, and Finnish DPA all issued findings that Google Analytics — including GA4 — was incompatible with GDPR. The core problem was a data transfer problem, not a consent problem: GA4 sends European visitor data to Google’s US infrastructure, and the Standard Contractual Clauses used to authorize that transfer were found insufficient under the post-Schrems II Supplementary Measures framework.

The EU–US Data Privacy Framework adopted in 2023 partially eased the transfer question for certified US companies, but it did not resolve the underlying architecture problem: GA4 still requires a consent banner under Article 5(3) because it sets cookies and accesses browser storage, still shares your visitor data with an advertising company’s infrastructure, and remains exposed to the legal instability of transatlantic transfer frameworks — the DPF faces ongoing legal challenges just as Privacy Shield and Safe Harbor did before it. A consent banner does not fix GA4’s structural issues; it only documents that visitors were asked. And with consent-banner rejection rates commonly reported between 30% and 60%, a banner-gated GA4 install means your analytics is blind to a large fraction of your audience anyway. A cookieless first-party setup measures 100% of traffic with no banner at all.

The practical implementation of GDPR analytics without a consent banner on WordPress comes down to choosing a tool whose architecture keeps you outside Article 5(3) by design. The free FPAI – First-Party AI Analytics plugin on WordPress.org was built for exactly this posture:

  • No cookies, no browser storage: the plugin never sets or reads cookies, localStorage, or any other terminal-equipment storage — so the ePrivacy Directive’s consent trigger is never engaged
  • First-party by architecture: all data is collected and stored on your own WordPress hosting, inside your own database — no third-party endpoints, no cross-border transfer problem, no data processing agreement with an ad-tech vendor
  • Pseudonymization by default: visitor IP addresses are hashed with a one-way function and truncated before storage, satisfying the necessity and balancing prongs of the legitimate interest test
  • No cross-site tracking: measurement is scoped to your own site’s audience, matching the CNIL exemption criteria for consent-free audience measurement

Installation is the standard WordPress flow: in your dashboard, go to Plugins → Add New, search for “FPAI First-Party AI Analytics,” then install and activate. Or install via WP-CLI:

wp plugin install fpai-first-party-ai-analytics –activate

There is no measurement ID to configure, no external account to create, and no tag manager to wire up. Once activated, the plugin begins recording pageviews server-side immediately — including from the visitors a consent banner would have lost you.

Your no-banner compliance checklist

Removing the banner does not remove your GDPR obligations — it changes their shape. Before going live with a consent-banner-free configuration, work through this checklist:

  • Audit your other scripts. The no-banner analysis applies to your analytics layer only. If your site also loads Meta Pixel, Google Ads tags, embedded YouTube players, or any other cookie-setting third-party script, those still require consent under Article 5(3). Remove them or gate them behind consent — the analytics exemption does not launder the rest of your stack.
  • Update your privacy policy. GDPR’s transparency obligations (Articles 13–14) apply regardless of legal basis. Disclose that you collect server-side usage statistics, name legitimate interest as your Article 6(1)(f) basis, describe the pseudonymization applied, and state the retention period.
  • Document your LIA. Write down the purpose, necessity, and balancing analysis described above. This is your primary evidence if a supervisory authority ever asks why no consent was collected.
  • Honor the right to object. Legitimate interest processing carries an Article 21 right to object. Provide a contact route in your privacy policy and a process for handling objections.
  • Keep data first-party. Do not export raw analytics data into third-party platforms or combine it with other datasets — doing so undermines both the CNIL exemption criteria and your balancing test.
  • Review annually. Regulatory guidance evolves; revisit your LIA and configuration once a year or whenever you add new tracking functionality.
Bottom line: the consent banner was never the compliance goal — it was a remedy for a specific technical act (browser storage access) that a well-architected analytics stack simply never performs. Fix the architecture and the banner becomes unnecessary; keep the documentation and the setup becomes defensible.

Ready to drop the banner? Download the free FPAI – First-Party AI Analytics plugin from WordPress.org — cookieless, first-party, server-side analytics that keeps your WordPress site measurable and your visitors’ browsers untouched.