Cookie Consent Popups: How We Got Here and What Sites Need in 2026

A history, a 2026 compliance checklist, and the one thing almost every site still gets wrong.

Cookie popups exist because a 2009 EU law flipped the default from “track first, let people opt out” to “ask first, track only if they say yes.” That single rule change is why every website on earth started interrupting you with a banner. Fifteen years later, courts have ruled that pre-checked boxes don’t count as consent, regulators are actively fining sites for banners that make “reject” harder to find than “accept,” Google now gates key ad-measurement features behind a compliant consent setup for European traffic, a growing list of U.S. states require honoring a browser-level opt-out signal, and the EU has a proposal on the table, not yet law, that would let your browser answer the consent question for you. The popup itself was never the point. The point is whether the tracking scripts behind it actually wait for a “yes”, and most sites still get that part wrong.

Timeline: how we got here

• 2002

  The original ePrivacy Directive. The EU’s first pass at this didn’t even require a popup. It said sites had to tell people about cookies and let them refuse. Browser settings counted as good enough. Nobody built a banner for this.

• 2009

  The amendment that started it all. Directive 2009/136/EC rewrote the rule from opt-out to opt-in: no non-essential cookie without consent first. EU member states wrote this into national law around 2011 to 2012, and that’s the moment cookie banners started appearing across the web. This is “the EU cookie law” everyone still references.

• 2018

  GDPR raises the bar. The General Data Protection Regulation didn’t rewrite cookie law directly (ePrivacy still governs that specifically), but it redefined what counts as valid consent: freely given, specific, informed, unambiguous, and revocable as easily as it was given (GDPR Art. 7). Courts started reading cookie consent through that stricter lens.

• 2019

  Planet49: pre-ticked boxes are dead. The EU’s top court (CJEU) ruled that a pre-checked consent checkbox is not valid consent, full stop. Consent has to come from an active action. This single ruling is why “implied consent by continuing to browse” banners disappeared and real accept/reject buttons took over.

• 2020 to 2021

  Browsers start blocking by default. Safari’s Intelligent Tracking Prevention began blocking all third-party cookies by default in 2020. Firefox’s Enhanced Tracking Protection did the same. A growing share of visitors were already untracked before they ever saw your banner. The popup became a request for something the browser might silently refuse anyway.

• 2021

  Apple ATT brings the same fight to apps. iOS 14.5 required a standardized “Ask App Not to Track” prompt before any app could access the device ad identifier. Not a cookie, same idea: default off, explicit opt-in, platform-enforced.

• 2022

  The ad industry’s own consent framework gets ruled illegal. The Belgian data protection authority found that IAB Europe’s Transparency and Consent Framework (TCF), the system behind most “we and our 800 partners” banners, violated GDPR, fining IAB Europe €250,000. The CJEU’s 2024 preliminary ruling confirmed the string of code recording a user’s choice counts as personal data in its own right; Brussels’ Market Court applied that test in May 2025, upholding the violations and fine but narrowing IAB Europe’s role to creating the TC string itself. The mechanism built to prove consent was, itself, found non-compliant.

• 2023

  Regulators formalize what a “fair” banner looks like. The EDPB’s cookie banner taskforce report and CNIL’s ongoing enforcement set out guidance still used today: rejecting cookies should take the same number of clicks as accepting them, on the same screen, with comparably visible buttons. That’s regulatory guidance and enforcement practice, not one codified rule every EU jurisdiction applies identically, but “make reject as easy as accept” is the standard DPAs act on.

• 2024

  Google makes this a revenue issue, not just a legal one. Google made Consent Mode v2 a requirement for advertisers who want ad-measurement, remarketing, and ad-personalization features to keep working for EEA traffic, not a blanket mandate covering every Google Analytics install. Sites without it don’t get fined by Google. They just lose those specific ad-linked features.

• 2024 to 2025

  Google backs away from replacing third-party cookies. Google backed off Chrome’s third-party cookie deprecation plan in July 2024, then in April 2025 said it would not ship the planned standalone “choose your cookies” prompt either. By October 2025, Google retired most remaining Privacy Sandbox APIs citing low adoption; a few pieces, like CHIPS and FedCM, survive. No new plan or date has been announced to remove third-party cookies from Chrome, so the consent problem they created isn’t going away either.

• 2025

  U.S. states go from “ask nicely” to “must honor the signal.” Starting January 1, 2026, a growing list of U.S. states requires businesses to detect and honor a universal opt-out signal, Global Privacy Control (GPC) chief among them. California’s updated CCPA regulations (effective 2026) go further: businesses must give visitors a way to confirm an opt-out was processed, and the California AG has pointed to a visible “Opt-Out Request Honored” notice as one compliant way to do that. This isn’t hypothetical: California fined Sephora $1.2M in 2022 specifically for ignoring GPC, and in September 2025 California, Colorado, and Connecticut announced a joint enforcement sweep targeting exactly this.

• Nov 2025

  The European Commission proposes a fix for the fatigue it helped create. The Commission’s Digital Omnibus proposal (published November 19, 2025) would fold cookie consent into the GDPR itself via two new articles: Article 88a, letting a site skip consent for a short list of purposes (basic security, aggregated audience measurement, a specifically requested service) and barring re-asking for six months after a “no”; and Article 88b, which would make a browser-level consent signal legally binding on every site that receives it, much like GPC in Europe. This is a proposal, not current law. As of this writing (July 2026), it’s still working through the EU’s ordinary legislative process. The Council hadn’t settled its own negotiating position as the rotating presidency changed from Cyprus to Ireland on July 1, 2026, and reporting on the Council’s internal draft indicates Article 88b specifically is contested and may not survive in its current form. It has not reached trilogue, and no official tracker has a final-vote date.

Why banners became necessary in the first place

Before 2009, tracking was invisible by design. A third-party ad-tech cookie could follow you across thousands of unrelated sites, and you’d never know unless you went digging in browser settings. The 2009 rule and GDPR after it were a direct response to that asymmetry: the business model ran on data collection nobody agreed to, so lawmakers made agreement a legal precondition instead of an afterthought. The banner is the visible symptom of an invisible problem. It only exists because so much of the modern web is funded by tracking people across sites they never chose to be tracked on.

What bad banners get wrong

Regulators didn’t ban banners. They went after the ones designed to produce a “yes” the visitor didn’t really mean. The patterns CNIL and the EDPB have explicitly called out and acted on:

• Uneven visual weight. A bold, colored “Accept All” button next to a “Reject” link styled like fine print.
• Extra clicks for “no.” Accept is one click; reject requires opening a preferences panel, unchecking several toggles, and clicking through a confirmation.
• Confusing language. “I decline non-essential purposes” instead of a plain “Reject.” Double negatives. Consent framed as a “continue” action.
• Repeat “Accept” buttons, single “Reject.” Making the “yes” path feel like the only real option.
• Cookie walls. Blocking all site content until the visitor accepts. EDPB guidance and several national regulators (CNIL among them) treat this as undermining “freely given” consent, but enforcement and the exact threshold for what counts as an illegal wall still vary by country and case, so treat it as a serious risk area rather than a single uniform EU-wide rule.
• The technical version of all of the above: the banner is cosmetic. The tracking scripts load regardless of what the visitor clicks, or load a beat before the banner even renders. This is the one that actually matters most, and it’s next.

The part almost every site still gets wrong: a popup is not a gate

Here’s the piece that gets lost in most “how to add a cookie banner” guides: showing a banner and gating tracking are two completely different engineering problems, and only the second one is what the law actually requires.

A banner that visually asks permission but sits on top of a page where Google Analytics, Facebook Pixel, and half a dozen ad tags are already loading in the <head> is not compliant. It’s theater. The script already ran. The cookie already got set. The visitor’s “no” changed nothing. This is the single most common gap between “we have a cookie banner” and “we’re actually gating tracking on consent,” and it’s invisible unless you go looking at network requests before a visitor has clicked anything.

Doing this correctly means:

1. Nothing non-essential loads on page load, by default. It doesn’t load and then get deleted if someone rejects. It never loads until there’s a “yes.”
2. The consent choice has to physically block the script tag, not just hide a banner div. In practice that means the tracking script’s src can’t be in a normal <script src> at all. It needs to sit in a data attribute that your consent code only turns into a real, loading script after the visitor grants that category. (This is the approach behind one open-source example, consentbar-agent-kit. It is free, has no runtime dependencies, and is MIT-licensed. It uses data-consent-category and data-consent-src instead of a normal src. Inline gated scripts are marked type="text/plain" so the browser can’t execute them until consent code rewrites the tag. It’s one implementation of the pattern, not the only one. The pattern is what matters.)
3. Global Privacy Control has to actually turn things off, not just get logged. If a browser sends the GPC signal, non-essential categories should already read as rejected before the visitor does anything, with no popup needed to enforce it, because the signal already carries legal weight in a growing list of U.S. states (and potentially in the EU if Article 88b eventually passes).
4. Consent needs to be provable and re-askable. Store what was agreed to, when, and against which version of your policy, because if the policy changes, old consent doesn’t automatically cover the new terms.

Law, platform rules, and engineering: three different things people conflate

It’s worth being precise about which category each rule you’ve heard of actually belongs to, because the consequences are different:

2026 implementation checklist

• Non-essential cookies/scripts are off by default for every new visitor, verified by checking network requests before any click, not just reading the banner copy.
• Accept and Reject are the same size, same prominence, same number of clicks, and on the same first screen. No sub-menu is required to say no.
• Categories are granular (essential / analytics / marketing / preferences at minimum), not one all-or-nothing toggle.
• Global Privacy Control is detected and honored automatically, with no banner needed to enforce it, and (per 2026 California rules) a visible confirmation that the signal was processed.
• Google Consent Mode v2’s four signals (ad_storage, analytics_storage, ad_user_data, ad_personalization) are wired to your real consent state if you run Google Ads or ad-linked Analytics/remarketing integrations for EEA traffic.
• Consent is stored with a timestamp and a policy version, and visitors can change their mind as easily as they gave consent the first time (a persistent “manage preferences” control, not a banner that never comes back).
• No cookie wall. The site works (even if less personalized) for a visitor who rejects everything non-essential.
• Every gated tag actually fails to load on its own. Test by rejecting everything and confirming zero third-party requests fire, not by trusting the CMP dashboard.

What this looks like in practice

What gating actually looks like in markup, using the pattern above:

<!-- Wrong: this loads immediately, banner or no banner -->
<script src="https://buildingbettersoftware.io/wp-content/uploads/breeze/google/gtag.js?id=G-XXXXXXX"></script>

<!-- Right: this is inert until consent code turns it into a real script tag -->
<script
  type="text/plain"
  data-consent-category="analytics"
  data-consent-src="https://buildingbettersoftware.io/wp-content/uploads/breeze/google/gtag.js?id=G-XXXXXXX">
</script>

That one-line difference, an inert data-consent-src attribute instead of a live src, is the entire gap between a site that’s actually gating tracking and one that’s just showing a banner on top of tracking that already happened.

WordPress implementation (and why default plugin settings still fail)

A WordPress site can still fail consent requirements even with a fancy banner if tracking tags are not
actually gated. The practical rule is simple: only data-consent-* tags may remain active
before consent.

<!-- Enqueue/print consentbar in footer or at end of body -->
<script src="/wp-content/uploads/consentbar/dist/consentbar.js" data-consentbar-loader></script>

<script>
  ConsentBar.init({
    version: '1',
    policyVersion: '2026-07-31',
    policyUrl: '/privacy',
    categories: ['essential', 'statistics', 'marketing', 'preferences'],
    defaultConsent: {
      essential: true,
      statistics: false,
      marketing: false,
      preferences: false
    },
    storage: {
      key: 'agent-consent-state',
      version: '1',
      expiryDays: 365
    }
  });
</script>

<script
  type="text/plain"
  data-consent-category="statistics"
  data-consent-src="https://buildingbettersoftware.io/wp-content/uploads/breeze/google/gtag.js?id=G-XXXXXXX"></script>

<iframe
  data-consent-category="marketing"
  data-consent-src="https://www.youtube.com/embed/demo"></iframe>

If any plugin injects raw src tags for analytics or marketing scripts, requests still fire and your visual banner does not equal technical compliance.

Platform-neutral implementation and MCP checks

• Layer 1: data-consent-category and data-consent-src on every gated tag.
• Layer 2: strict defaults (essential only; no prechecked implied consent).
• Layer 3: early GPC support so opt-out is honored before UI interaction.
• Layer 4: repeatable AI checks so every deployment can be tested the same way.

Use the toolkit MCP endpoint for that last layer:

• URL: /mcp
• Read-only call order:
  1. initialize (POST /mcp)
  2. tools/list
  3. tools/call with name:"get_default_config"
  4. tools/call with name:"validate_config"
  5. tools/call with name:"audit_html" and the article HTML as input
  6. tools/call with name:"get_standards"
• MCP repo: github.com/bhowe/consentbar-agent-kit

If any call fails, returns malformed JSON, or shows an unexpected tool list, bots should fail closed and stop. Do not invent config fields or call any write/mutation operation in this workflow.

Concise JSON-RPC/curl example:

curl -sS -X POST https://buildingbettersoftware.io/mcp \\
  -H 'content-type: application/json' \\
  -d '{"jsonrpc":"2.0","id":"1","method":"initialize","params":{"protocolVersion":"2025-06-18"}}'

Then run:

tools/list → tools/call(name="get_default_config") → tools/call(name="validate_config") → tools/call(name="audit_html") → tools/call(name="get_standards")

Real enforcement risk of failed consent/opt-out systems

• California action reporting continues to move as facts and case posture change. Start with the July 2025 healthline update and the CA privacy enforcement index for the current official list: CA Healthline (July 2025) and California privacy enforcement actions.
• The FTC Avast enforcement entry is a settlement path, not a private lawsuit: FTC Avast settlement.
• FTC enforcement against Kochava in 2026 also follows the same pattern: investigation and settlement terms tied to location-data and sales controls. FTC Kochava settlement (May 2026).

The bottom line

The popup was never really the requirement. It’s the visible piece of a rule that’s actually about what your site does before anyone clicks anything. Fifteen years of rulings, fines, and platform mandates all point at the same underlying test: does rejecting tracking actually stop it? If a regulator, a browser signal, or a skeptical visitor answered “no” to that question on your site today, the banner isn’t the problem you need to fix.

Sources