If you search "age verification for WordPress" right now, the same handful of plugins come up that have been showing up since 2016. Most of them ask the visitor to click a button confirming they're old enough, set a cookie, and let them through. A few have a date-of-birth dropdown. A couple have prettier popups.
None of them meet the standards that became enforceable law across the UK, EU, Australia, and most of the United States in 2025.
This isn't a marketing claim. It's a regulatory finding. The UK's media regulator, Ofcom, published guidance in January 2025 that explicitly named the click-a-button method — what they call "self-declaration" — as not capable of being highly effective. The same standard now applies, in different words, in France, Italy, Germany, Australia, and 25+ U.S. states.
If you build, run, or admin WordPress sites that show age-restricted content — adult sites, alcohol shops, vape stores, cannabis retailers, gambling platforms, certain gaming sites — the plugin recommendations on the first page of Google are probably steering you toward non-compliance. This post is an attempt to fix that.
A note before we start
This isn't legal advice. I'm not a lawyer. What I can do is explain what the regulators have published, what the most popular plugins actually do, and how to tell the difference between "verification" and "popup with a button." For your specific situation, talk to a compliance lawyer in the jurisdictions you operate in. Their advice beats anything you read on a blog, including this one.
What this post will give you is the framework to have an informed conversation with that lawyer — and the technical knowledge to evaluate plugins against whatever requirements they identify.
What "highly effective" actually means
The phrase "highly effective age assurance" comes from the UK's Online Safety Act, but the concept is the same across all the regulators that matter. Ofcom defined it with four criteria. I'll translate each one into plain language:
Technically accurate. The system has to actually check the visitor's age, not just ask. Lab testing should show it works. A popup with a "yes, I'm 18" button isn't checking anything — it's accepting a self-report.
Robust. It has to keep working in the real world, not just in lab conditions. A check that can be bypassed by editing browser cookies, copying a URL, or using a friend's login isn't robust. The regulator specifically calls this out: the method must "address risks of circumvention."
Reliable. The result has to be reproducible and based on trustworthy evidence. If the visitor's age is being established by checking their face against a database, the database needs to actually exist and the face check needs to actually run.
Fair. It has to work for everyone, regardless of skin tone, gender, age, or device. A system that works great for some demographics and fails for others isn't fair.
To these four, every regulator adds an unspoken fifth: the verification has to handle the visitor's personal data lawfully. In the UK, the EU, and a growing list of US states, that means data-protection law applies. You can't keep biometric data forever. You can't share it without permission. You can't use it for things the visitor didn't consent to.
What Ofcom will accept as capable of meeting these criteria — their published list — includes:
- Showing a government ID and matching it to a selfie
- A face scan that estimates whether you're an adult, with liveness detection to prove a real person is in front of the camera
- Open banking checks (your bank confirms you're over 18 without sharing other info)
- Mobile network operator checks (your phone company confirms you're over 18)
- Credit card checks
- Digital identity wallet apps
What Ofcom will not accept:
- Clicking "I am over 18"
- Entering a date of birth in a form
- Agreeing to terms and conditions that mention age
- Any payment method that doesn't require the user to be 18 (gift cards, prepaid cards, etc.)
That's the line. Every WordPress age verification plugin on the first page of search results falls on the wrong side of it.
A quick note on terminology
If you've been researching this in WordPress blogs and forums, you've probably noticed something confusing. WordPress writers tend to use "age verification" to mean a popup that asks the visitor to confirm their age, and "authorization" or "ID verification" to mean the rigorous kind that actually checks who the visitor is. AI search summaries pick up this distinction and repeat it back as if it's settled.
Regulators use the words exactly the other way around.
When Ofcom, the EU, ARCOM in France, AGCOM in Italy, or US state legislatures talk about "age verification," they mean the rigorous kind — biometric checks, ID document verification, the methods listed earlier. What WordPress writers call "age verification" — the popup that asks the visitor to confirm — regulators call "self-declaration," and they've explicitly ruled it out as not capable of being highly effective.
"Authorization" isn't a regulatory term at all in this context. Authorization, in technical usage, means deciding whether an already-identified person is allowed to do something. The bouncer at a club checking your ID is doing age verification — confirming a fact about you. The bouncer checking the guest list is doing authorization — confirming you're allowed in. Checking someone's age isn't authorization; it's verification. The WordPress ecosystem grabbed the word as a way to distinguish "the serious kind of check" from "the popup," but the rest of the world doesn't use it that way.
For the rest of this post, I'm using the regulators' definitions. "Age verification" means a check that actually verifies. Popups are popups, not verification. If you've been reading WordPress blogs that use the words differently, this is the translation key.
What the popular WordPress plugins actually do
Here's an honest assessment of the plugins that show up first when you search. I'm not naming these to attack them — most of them do what they were built to do, and many are perfectly fine for situations where regulatory compliance isn't the goal. The problem is that the search results don't make it clear when each kind of plugin is appropriate and when it isn't.
The popup plugins. Age Gate, AgeVerify, Dispensary Age Verification, WP Terms Popup, Fastest Age Verification, Age Gator, and a dozen others. They all do roughly the same thing: a popup asks the visitor to confirm their age, the visitor clicks yes, and a cookie is set so they don't have to do it again.
These plugins are popups. They are not verification. They satisfy regulatory standards in zero countries. If your site needs to comply with UK, EU, Australian, or US state age verification laws, none of these plugins meets the bar — they all fail at the first criterion (technically accurate). The visitor self-declared. Nothing was checked.
This isn't a flaw in the plugins. They were built for a different era, when self-declaration was the standard. They still work fine for situations that don't need real verification — for example, an alcohol-themed blog with no commerce, or a craft brewery's email signup form. They just shouldn't be marketed as compliance solutions for sites where compliance is required, and the search engines that recommend them shouldn't present them as the answer to "effective age verification."
The checkout-time plugins. AgeChecker.Net is the main one. It runs at WooCommerce checkout, takes the customer's name and address, runs them against commercial identity databases, and asks for a photo ID upload if the database lookup fails. About 90% of US customers verify automatically; the rest upload an ID that gets reviewed by a human team.
This is real verification, and it works for US-based e-commerce in regulated industries (vape, tobacco, alcohol, firearms). It doesn't work as well outside the US because the underlying databases are US-focused. It also stores customer data — by their own privacy policy, "for the purpose of expediting verification during subsequent transactions." That may or may not matter for your situation. Pricing is around $25/month plus $0.50 per verified customer.
If you run a US e-commerce site selling regulated products and your only concern is checkout-time verification, AgeChecker is a reasonable option. If you need to gate content (not just checkout), or operate internationally, or care about not retaining customer data, look further.
Membership plugin date-of-birth fields. MemberPress, Paid Memberships Pro, Restrict Content Pro, and similar can collect a date of birth at signup. This isn't verification either — the user types in whatever date they want — but some operators treat it as a form of compliance. It isn't.
That said, these plugins are genuinely useful for what they do (membership management). They're just not age verification, and the regulatory standards apply to age checks, not membership systems. If you use one of them for memberships, you'll likely also need a real age verification layer alongside it.
The third-party verification services
Beyond the WordPress plugins, there's a separate market of identity verification services that operate at a different level. These are the providers that can meet regulatory standards, but they generally aren't WordPress plugins — they're enterprise services with API integrations.
The names you'll encounter:
Yoti is the most rigorously tested provider in this space. They were the first company in the world to pass the highest level of independent fake-detection testing (in February 2026), and they're approved by regulators in the UK, Germany, and Italy. If you're running a major platform with a real compliance budget, they're a solid choice. They cost about five times what the alternatives do, they don't have a WordPress plugin (you'd integrate via custom development), and they keep the visitor's selfie image after verification for re-authentication purposes. That's fine for a lot of use cases. It's not what every operator wants.
Veratad offers a multi-method verification platform — database lookup, ID documents, biometrics, and more, configurable per use case. They explicitly retain biometric data; their privacy policy says they "store your biometric data for the purpose of verification services, fraud prevention, and/or long-term proof of inspection." This is a deliberate design choice for clients who want re-verifiable records of past checks. It's also a privacy posture some operators won't accept.
Didit is a newer entrant offering biometric verification at lower price points. They've completed a lower level of independent testing than Yoti has (Level 1 vs Level 3) and aim primarily at developer integrations rather than WordPress sites. Useful to know about; not the right fit for most WordPress operators.
There are several other identity-verification providers in the broader market — Incode, Persona, Sumsub, Onfido, iProov — but they're all enterprise-tier and don't have WordPress integrations. If you're at the scale where one of them makes sense, you're probably not reading this post.
Where XYZ Age Verification fits
Full disclosure: I built XYZ Age Verification. I built it because I was running an adult site for 25 years, got hit with a UK regulatory action in late 2025, and couldn't find an option that met the requirements without either costing more than my site earned or storing my visitors' data in ways I wasn't comfortable with.
The short version of what XYZ does:
- It runs a real face scan to determine whether the visitor is an adult. The scan uses an industry-standard biometric service that's been independently tested against fake-detection attacks (printed photos, video replays, latex masks, deepfakes).
- For jurisdictions that require government ID verification — about 20 US states — it adds an ID document check with face matching against a selfie.
- It routes visitors automatically based on where they're coming from. UK visitors get one method, Texas visitors get another, French visitors get a third.
- It doesn't keep the visitor's selfie, ID image, biometric data, or age. The check runs, the system returns a pass/fail, and the data is discarded immediately. The only thing that persists is whether the visitor passed (yes or no) and a timestamp.
- It's a free WordPress plugin on WordPress.org, with 100 free verifications per month, and it integrates with WordPress login, MemberPress, and Paid Memberships Pro.
The plugin isn't the most-tested option in the broader market — Yoti has spent a decade on certification rigor that takes a decade to build. What XYZ is, is a WordPress-native plugin built around the principle that the visitor's data shouldn't be stored, that meets the technical bar regulators have set, and that costs roughly a fifth of what enterprise verification providers charge.
Two privacy architectures
When evaluating age verification vendors, there's a distinction worth understanding that vendor marketing doesn't always make clear.
Some vendors offer privacy-by-policy: they collect biometric data, store it for some retention period, then delete it. Their privacy posture depends on you trusting that they actually delete the data, that their retention policy doesn't change, that no court orders or breaches happen during the retention window, and that no future merger or acquisition brings the data under different controls. Vendors in this category include most of the major identity verification providers, including Yoti, which retains liveness images for re-authentication purposes.
Other vendors offer privacy-by-architecture: they never store the data in the first place. Verification happens, the result is returned, the inputs are gone. There's nothing to delete because there was never anything to retain. There's nothing to subpoena, breach, or hand over to a future acquirer, because the records don't exist.
Both architectures can produce verification systems that look similar from the outside. The difference becomes visible when something goes wrong — a subpoena lands, a database is breached, a vendor changes ownership. Privacy-by-architecture vendors have nothing to produce in any of these cases, regardless of legal or commercial pressure. Privacy-by-policy vendors have whatever's currently in their database, regardless of what their marketing says.
A related distinction shows up in cross-site verification features, sometimes marketed as "verify once, use everywhere." A vendor offering this capability is, by necessity, maintaining a persistent record linking visitors' verification events across sites. That record is a privacy-relevant artifact regardless of how it's marketed. Operators whose threat model includes subpoena exposure or breach risk should weigh the convenience of cross-site verification against the persistent identity record that makes it possible.
For operators in industries with long histories of subpoena exposure — adult content, cannabis, firearms, certain financial services — privacy-by-architecture vendors are usually the safer structural choice. The privacy-by-policy approach can produce identical day-to-day operation, but the underlying data structures are different, and that difference matters when legal or commercial pressure arrives.
The legal landscape has actually intensified this consideration recently. Several recent US state age verification laws — including Texas HB1181, Utah SB287, and others modeled on them — include private rights of action, allowing private citizens or parents to bring civil suits against non-compliant platforms directly. Utah took this further on May 6, 2026, when SB 73 went into effect: the law holds website operators liable for users who bypass age verification with a VPN or proxy, treating anyone physically located in Utah as a Utah user regardless of IP. The Electronic Frontier Foundation and NordVPN have both publicly characterized SB 73 as creating an "unresolvable compliance paradox" because VPN tools are specifically designed to be undetectable by IP, and the Free Speech Coalition has sued every previous state age verification law and is expected to challenge SB 73 as well.
The practical effect for operators is that exposure now comes from multiple directions: government regulators with subpoena power, plaintiff's attorneys filing civil suits with discovery rights, and now — under Utah SB 73 — private actions tied to circumvention scenarios where verification vendor records become directly relevant evidence. Vendors who don't hold records have nothing to produce in any of these scenarios; vendors who do hold records have whatever's in their database, regardless of what their marketing pages say about privacy.
XYZ is built around privacy-by-architecture deliberately. The system is designed so that biometric data, document images, and selfies cannot be retained, regardless of legal or commercial pressure. The only persistent records are pass/fail outcomes and timestamps, which are insufficient to identify a visitor or reconstruct what they verified. This is a deliberate architectural choice rather than a marketing claim.
How to figure out what your site actually needs
Here's a rough decision framework. Talk to a lawyer to confirm any of this for your specific situation, but this should help you frame the conversation:
You run a small site that mentions age-restricted topics but doesn't sell or display them. A blog about wine, a brewery's marketing site, a hobbyist cannabis information page. A popup plugin is probably fine for due diligence. None of the regulatory frameworks require verification on content that isn't itself age-restricted.
You run a US-only e-commerce site selling regulated products. Vape, tobacco, alcohol, firearms. Look at AgeChecker.Net or a comparable database-lookup service. The underlying US identity databases are good, the integration is well-tested, and the privacy tradeoff (some customer data stored) is generally accepted in this category.
You run an adult content site, a platform that allows adult content, or anything else covered by the UK Online Safety Act. Self-declaration is no longer legal. You need biometric verification, ID document verification, or one of the other methods Ofcom listed. Yoti is the gold-standard option if budget allows. XYZ Age Verification is the WordPress-native option if it doesn't.
You operate internationally and have visitors from multiple regions. You need verification that can route by region, because the requirements differ. A French visitor faces different rules than a Texan visitor than a German visitor. A single-method system means either over-verifying everyone (poor user experience, higher costs) or under-verifying some visitors (compliance risk).
You run a membership site that happens to have age-restricted content. Your membership plugin handles membership; it doesn't handle age verification. You need both layers. XYZ Protect was designed for this case specifically — it combines the age verification with file-level content protection, so the gated content can't leak around the gate.
You run a site for a regulated industry but you're outside the major regulatory jurisdictions (e.g., parts of Africa, Asia, Latin America). Your local laws may not require formal verification, but your payment processor, hosting provider, or advertising network probably has its own rules. Worth checking what they require before you build anything.
The honest summary
The WordPress plugin directory was built before any of these laws existed. The recommendations on the first page of Google were established when "click to confirm you're 18" was the industry standard. Most of those plugins still work fine for what they were originally built for — they just don't meet the legal standard that became enforceable in 2025.
If you're building or running a site that needs real age verification, the choice isn't between popup plugins. It's between enterprise-tier verification services like Yoti, US-focused checkout services like AgeChecker, and WordPress-native solutions like XYZ that try to bring the same technical standards to WordPress operators at a price they can afford.
Pick based on your actual situation — your jurisdiction, your budget, your stance on visitor data — not based on which plugin shows up first when you search.
If your situation is "I have a WordPress site that needs to comply with UK, EU, or US state age verification laws and I don't want to retain my visitors' personal data," XYZ Age Verification is the plugin I built for that case. There's a free tier with 100 verifications per month, and the documentation walks through region-specific rule configuration.
For deeper background on the regulatory landscape itself — which regulators are enforcing what, what penalties have been issued, and how the laws differ across jurisdictions — see the companion post on why click-to-confirm no longer counts.
For the technical reader
If you want to verify the claims above with primary sources, here are the details that the body of the post translated into plain language.
Ofcom's "highly effective age assurance" criteria are published in their guidance documents from January and April 2025, available at ofcom.org.uk. The four criteria are technical accuracy, robustness, reliability, and fairness. The non-exhaustive list of methods capable of being highly effective includes photo-ID matching, facial age estimation with liveness detection, open banking, mobile network operator checks, credit card checks, digital identity services, and email-based age estimation. Self-declaration is explicitly excluded, as are payment methods that don't require the user to be 18.
Independent testing for biometric liveness systems is conducted under ISO/IEC 30107-3 by NIST-accredited labs, primarily iBeta Quality Assurance. There are three levels of testing. Level 1 tests against attacks costing under $30 (printed photos, basic video replays, paper masks). Level 2 tests against attacks costing up to $300 (3D-printed masks, latex masks, resin masks, deepfakes). Level 3 was introduced by iBeta in summer 2025 and tests against expert attackers with no budget limits, using high-end masks and sophisticated injection attacks.
As of May 2026:
- Yoti's MyFace passive liveness system: iBeta Level 3 (achieved February 2026 — first company in the world). Also ACCS Level 2 certified.
- AWS Rekognition Face Liveness: iBeta Level 2 (achieved October 2023, confirmation letter). This is the underlying biometric engine XYZ Age Verification uses for Tier 1 verification.
- Didit: iBeta Level 1.
XYZ Age Verification's Tier 1 verification is performed using AWS Rekognition Face Liveness, which holds iBeta Level 2 PAD certification. XYZ-as-a-system has not been independently submitted to iBeta for testing.
On data retention. AWS Rekognition Face Liveness sessions expire automatically three minutes after creation, after which all session data (session ID, reference image, audit images) becomes unavailable. By default, AWS may use submitted Face Liveness data to improve the service. Customers can opt out via the AWS AI Services opt-out policy. XYZ has opted out, so AWS does not retain XYZ-submitted data for service improvement.
XYZ's own architecture processes biometric data, document images, and selfies in memory only. None of these are written to persistent storage. The only data persisted across the verification event is the binary outcome (pass/fail), a timestamp, and the visitor's IP address for fraud prevention.
On anti-circumvention. After successful verification, XYZ sets a cryptographically signed cookie using HMAC-SHA256. The signature can be verified at the edge without a database lookup, but cannot be forged with browser developer tools. This addresses the circumvention requirement that Ofcom and the UK ICO specifically called out in their March 2026 joint statement on age assurance.
On geo-routing. XYZ uses Cloudflare's geo-detection headers (CF-IPCountry, CF-Region) to identify the visitor's country and US state at the edge, before any verification logic runs. Region-specific rules are evaluated to determine which verification tier applies — Tier 1 (biometric only) for jurisdictions accepting facial age estimation, Tier 2 (biometric plus government ID) for jurisdictions requiring document-based verification.
These details aren't required reading for choosing a plugin, but they're the factual basis for the claims above. If anything in the body of the post seemed handwavy, this section is where the receipts live.