There's a problem with age verification that nobody mentions until you're a few months past launch, looking at your organic traffic chart, and wondering why the line went flat. Most age gate implementations break Google indexing. The fix usually recommended is to choose a bad age gate — one that satisfies Google but doesn't satisfy the law you installed the gate to comply with in the first place.
The team at 2Much.net wrote a solid overview of the problem recently. If you want the lay of the land — which jurisdictions require what, why the regulators are paying attention — read that first. This post picks up where their solutions section gets vague, because they're consultants selling a service and we're not, and I'm going to show you exactly how to thread the needle on a WordPress site.
The Trade-off Most Plugins Force on You
Here's the basic problem. To do age verification robustly — which is the word UK regulators in particular keep using — you have to stop the page from rendering until verification succeeds. That means a server-side check that intercepts every request and redirects unverified visitors to a verification page before any content gets sent to the browser.
Now consider how Googlebot works. Googlebot is a robot. It can't pass a face liveness check. It can't upload a driver's license. So when Googlebot requests a page on your age-gated site, your server-side gate does exactly what it's supposed to do: it redirects Googlebot to the verification page.
What happens next is bad. Google indexes the verification page. It does not index the content the verification page protects. Over a few weeks, your real pages drop out of the index. From Google's point of view, your entire site is a single age-gate page. Search traffic collapses.
The shortcut most plugins (and most advice articles) recommend is to skip the server-side gate entirely and use a JavaScript overlay instead. The content loads in the DOM; a JS modal sits on top of it; humans see the modal, Googlebot reads the underlying HTML, everybody wins.
Everybody except the regulator. A JS overlay isn't a real gate. Anyone who disables JavaScript, opens dev tools, or views source can see the content. It's the modern version of the "click to confirm you're 18" checkbox, and Ofcom in the UK has been increasingly explicit that gates bypassable by basic user actions don't meet the "highly effective age assurance" threshold the Online Safety Act requires. US state regulators have been moving in the same direction. You've solved your SEO problem and gained a compliance problem.
Why This Damage Often Goes Unnoticed
There's a complication operators run into the first time they launch an age gate. The gate itself causes an immediate, visible traffic drop — sometimes as much as 50%, depending on the geographic profile of your audience. That's just visitor abandonment: people hit the gate, decide they don't want to do a biometric check or hand over an ID, and leave. It's expected. It's the cost of compliance.
The SEO damage is a second drop, layered underneath. It doesn't show up immediately because Google's index doesn't update overnight — it takes a few weeks for pages to roll out, and rankings damage compounds over months. By the time your search-derived traffic falls off, the original gate-driven drop has long since become your baseline. You don't see a new event in the chart; you see your already-lower numbers slowly trending lower, which is easy to write off as "the gate is still costing us conversions" or "the market is soft this quarter."
The way to tell them apart is the indexed-page count in Search Console. Visitor abandonment doesn't change how many of your pages Google has indexed. The SEO damage does — and once it starts, it accelerates.
How XYZ Age Verification Avoids the Trade-off
XYZ does server-side gating. The MU plugin runs early in the WordPress request, before the page is rendered, and redirects unverified visitors to the verification page. That's the genuinely compliant approach. It's also the approach that creates the SEO problem.
The SEO problem gets solved one layer up the stack, at Cloudflare. Cloudflare maintains a global reputation system for verified bots — Googlebot, Bingbot, and a handful of other legitimate crawlers. Crucially, Cloudflare doesn't trust the User-Agent header (which any visitor can spoof in two seconds). It verifies through reverse DNS lookup and known IP ranges that the request actually came from Google's or Bing's infrastructure. This signal is available on every Cloudflare plan, including the free one.
If Cloudflare can vouch for the bot, your site can let it through the gate. The mechanism is straightforward: a Cloudflare Transform Rule that, when Cloudflare's cf.client.bot field evaluates to true, injects a header into the request before it reaches your WordPress origin. The MU plugin checks for that header on every request and skips the gate for any request that has it.
The flow looks like this:
Googlebot → Cloudflare
→ Cloudflare verifies it's really Google (reverse DNS + IP range)
→ Transform Rule injects bot-bypass header with your site's key
→ WordPress / XYZ plugin sees the header, skips the gate
→ Real page content returned, indexed by GoogleHumans get the gate. Verified search engines get the content. Spoofed User-Agents get the gate, because Cloudflare didn't verify them and the header was never injected.
Setting It Up
The plugin requires Cloudflare for its other features anyway — the regional geo headers (CF-IPCountry and CF-Region-Code) are how it knows whether a visitor is in a regulated jurisdiction in the first place. So this isn't extra infrastructure. You already have Cloudflare in front of your site.
There are two settings on the main plugin page that control this:
- Allow Verified Bots — a toggle that controls whether the plugin honors the bot-bypass header at all. On by default. Turn it off if you want even verified crawlers to be redirected to the age gate.
- Verified-Bot Token — the secret value the plugin expects in the bot-bypass header. Leave it on the default for the basic setup; generate a per-site 128-bit value for the stronger setup.
Basic configuration
The simplest setup, which works on every site:
- Make sure Allow Verified Bots is enabled in the plugin settings (it is by default).
- In Cloudflare's dashboard, go to Rules → Transform Rules → Modify Request Header → Create rule.
- Match condition:
cf.client.bot(Cloudflare's verified-bot field). - Action: set a request header named
verified-botto the valuetrue. - Save and deploy.
The plugin's Cloudflare setup guide (linked from the settings page) shows the exact expression. Test by viewing your homepage as a normal visitor (age gate redirect), then use Google Search Console's URL Inspection tool to render the same page as Googlebot (real content).
Strong configuration (recommended for compliance-sensitive sites)
If you're operating in a jurisdiction with active enforcement — UK Online Safety Act, the various US state laws — you want the strong setup. It changes the answer to one question an auditor or regulator might ask: "Is there any documented bypass path on your site?"
With the basic configuration, the answer is technically yes — anyone reading the GPL-licensed plugin source can see that a request with verified-bot: true skips the gate. Exploiting that requires bypassing Cloudflare to talk directly to your origin, which is hard, but "hard" isn't the same as "impossible by design." With the strong configuration, the answer becomes no — the bypass requires a 128-bit secret unique to your installation, with no shared default across sites running the plugin.
To enable it:
- In the plugin settings, generate a new value for the Verified-Bot Token. The plugin produces a random 128-bit string and saves it.
- Update your Cloudflare Transform Rule to set the
verified-botheader to your generated token instead of the literal stringtrue. - Save and deploy.
The header comparison in the MU plugin runs in constant time, so even if someone reached your origin and started guessing tokens, they couldn't use response-time differences to leak which characters are right.
Existing configurations continue working without changes — the default token is the literal true that the basic Cloudflare rule produces, so the upgrade path from 2.5.x to 2.6.x is opt-in. You change configurations on your own schedule.
Strongest defense: lock your origin to Cloudflare
The bot-bypass conversation only matters if someone can reach your origin server without going through Cloudflare. That's a separate problem you can solve at the network layer: restrict your origin's HTTP and HTTPS ports to accept connections only from Cloudflare's published IP ranges. At that point, no request can reach your origin without first passing through Cloudflare's bot verification, the geo-detection logic, and any other rules you've configured.
This closes both the bot-bypass and the geo-detection bypass at the same time. The plugin's setup guide walks through this for common hosting environments.
If you can do this, do it. It's the genuinely defense-in-depth approach, and it makes the other two tiers above largely academic — though the strong configuration is still worth turning on for the audit-question reason.
What If You Don't Want Search Engines to Index Your Content?
Some operators don't. Adult tube sites that get their traffic from affiliate networks and direct bookmarks may not want Google indexing — and depending on your jurisdiction or business model, you may have legitimate reasons to prefer that your site only be discoverable to people who already know it exists.
In that case, just don't enable the Allow Verified Bots toggle. The default is off. Without the Transform Rule, every visitor — bot or human — gets the gate. Googlebot can't pass it. Your site is effectively unindexed.
This is a legitimate choice. The plugin doesn't make it for you.
Complementary: The RTA Content Label
While you're configuring all this, add the RTA (Restricted to Adults) meta tag to your site's HTML head:
<meta name="RATING" content="RTA-5042-1996-1400-1577-RTA">This tells parental controls, ISPs, and Google's SafeSearch that your site contains adult content. It doesn't replace age verification — it's a signal, not a gate — but it's the industry-standard signal and it takes five minutes to add. If you're running an age-gated site without it, add it today.
Summary
The SEO-versus-compliance trade-off most age verification plugins force on you isn't a real trade-off. It's a consequence of skipping the harder architecture. Cloudflare's verified-bot detection plus a server-side gate is the foundation. Add a per-site token for the audit-defensible version. Add origin IP restriction for the genuinely-locked-down version. None of these are exotic — they're standard infrastructure choices made deliberately.
If you have an age-gated WordPress site and you haven't configured the verified-bot bypass yet, that's the highest-leverage thing you can do this week. If you're evaluating age verification plugins and the plugin you're looking at doesn't have a server-side gate at all, you have a different and bigger problem.
The plugin is free on WordPress.org: XYZ Age Verification. The free plan includes 100 verification credits per month and a built-in admin for managing regions, thresholds, and verification history. More details on the WordPress plugin page.