A few months back I explained why ADT had to add age verification — the legal landscape made it unavoidable, and I wasn’t willing to hand visitor data to a third-party verification service that treats personal information as a commodity. So I built XY Zinc instead.
That solved the legal problem. It didn’t solve a problem I’d been quietly working around for years — a problem most WordPress operators don’t even know they have, and most of the ones who do know about it can’t afford to fix the way ADT had been fixing it.
This post is about that problem, why my own workaround for it didn’t scale beyond ADT, and why every page on the interviews site now runs through a second piece of software called XYZ Protect.
The Question That Started It
The story actually started with a conversation. The owner of Cerulean Software — a development firm that builds and maintains a wide variety of sites and services for content creators in the adult industry — was looking at the XYZ Age Verification plugin and asked a simple question:
“The plugin gates the page. But what about the images on the page?”
The point was sharp, and it wasn’t really about ADT. ADT had been protected for years by custom Cloudflare rules at the edge — checking for the right cookies on every media request and blocking anything that didn’t have them. But those rules require a Cloudflare Business plan, which runs about $200 per month. That puts edge-level media protection out of reach for almost every independent WordPress operator I know.
I wrote up the full story over on the XY Zinc blog if you want the long version, but the short version is this: a WordPress age gate stops a visitor from loading the page. It does not stop anyone from loading the images, videos, or PDFs that the page links to. The page-level gate doesn’t extend to the file URLs in /wp-content/uploads/.
Try it on almost any age-gated or membership-gated WordPress site. Right-click an image, copy the URL, and open it in an incognito window. The file loads. No login. No age check. Nothing.
This isn’t a problem unique to age verification. The same gap exists on any WordPress site with login-protected or membership-gated content. MemberPress, Paid Memberships Pro, WordPress login — none of them protect the media files in /wp-content/uploads/. They protect the pages that display the media, but the file URLs themselves are wide open to anyone with a direct link.
ADT has been running edge-level protection for this for years, but only because we’d been paying for the Cloudflare tier that allows it. Asking every independent WordPress operator to upgrade to a $2,400/year plan to protect their members’ content isn’t a real answer. So I built the XYZ Protect WordPress plugin instead.
What I built
I’m not going to turn this into a technical post — XYZ Protect has its own product page for that. But here’s what it does in plain English.
When you load an interview page on this site, the image URLs in that page no longer point at interviews.adultdvdtalk.com. They point at media-interviews.adultdvdtalk.com — a separate hostname that runs through a protection layer before reaching the server that hosts this site. Every request to that hostname gets checked against an authorization rule before the image is served. If you’ve passed age verification (or you’re a logged-in ADT member, or you’re not in a region that requires age verification), you get the image. If you don’t match one of those conditions, you get a placeholder image.
That’s it. The page renders normally for legitimate visitors. The URLs in the page source are useless to anyone else. (including most bots and scrapers)
For ADT specifically, this replaces the custom Cloudflare rules I’d been maintaining. Same protection, but now it’s a few clicks in WordPress instead of edge rules I have to update by hand every time something changes. For everyone else, it means edge-level protection on the free Cloudflare tier — the kind of protection that used to be gated behind a $200/month plan.
The dashboard tracks how many unauthorized requests get blocked, and that number climbs surprisingly fast. Bots, scrapers, and people poking at URLs they shouldn’t have access to.
What This Looks Like Behind the Scenes
The plugin runs from inside the regular WordPress admin. There’s nothing exotic about the install process — three DNS records, a couple of settings pages, save. About five to ten minutes start to finish.
The first tab handles the API connection and shows the overall status. Connected, content protection active, age verification enabled, license active. The protection stats live on this same page.
The second tab is where the actual content protection lives. ADT runs in Guard Cookie mode — protected URLs are obfuscated, and a signed cookie proves the visitor is authorized. There’s a stronger mode (Encrypted URLs, AES-GCM, per-user, time-limited) for sites where every URL needs to be unique to one viewer, but Guard Cookie is the right fit here because it’s compatible with caching plugins and lighter on infrastructure.
The Age Verification Side
The third tab is where the age gate itself is configured — and this is the same XY Zinc service I wrote about back in February, just managed from a different admin panel.
The settings are exactly what you’d expect: enable the gate, set the scope to the entire site, choose how long a verification cookie lasts (365 days for casual visitors), and decide what to do if the verification service is unreachable for some reason. ADT runs Fail Open — if the service is down, visitors get through. I’m comfortable with that tradeoff because the alternative (locking everyone out during an outage) is worse for legitimate users than the small risk window during downtime.
There’s also a Bypass Cookies field, which is useful for a site like this. ADT users who are already age-verified through the main site don’t get re-verified on the interviews subdomain — the plugin recognizes their existing session and skips the gate. Verify once, get into everything.
Region Rules: Where Verification Actually Triggers
The age gate doesn’t fire for everyone. It fires for visitors from jurisdictions that legally require it — the UK, Australia, and the growing list of US states that have passed verification mandates. Everyone else loads the site like nothing changed.
The region rules table is where each jurisdiction’s behavior is defined: which tier of verification applies (Tier 1 is a face scan; Tier 2 adds a government ID check, used in states whose laws explicitly require it), what the minimum age is, and whether the rule is enabled.
If you look at that table closely, you’ll spot something: Tennessee is set to Block, not Verify. I want to explain that one, because it’s not an oversight.
Tennessee’s age verification law requires sites to re-verify every visitor every 30 minutes. Not once per session. Not once per day. Every half hour, the user has to do another face scan. There is no reasonable way to comply with that — it’s hostile to users and operationally absurd. So rather than subject Tennessee visitors to a verification screen every thirty minutes for the rest of their lives, I block the state outright. If you’re in Tennessee and you want to read pornstar interviews, write to your state legislators about that 30-minute clock.
What This Doesn’t Do
A quick note on what XYZ Protect is and isn’t, because I want to set expectations honestly.
It does not stop a verified visitor from saving an image to their computer. Once you’re authorized and the page renders in your browser, the file is in your browser — that’s true of any image on any website, with or without protection. What it does stop is unauthorized access: people who never verified, search engine crawlers, scrapers, and anyone who copied a URL hoping to share or scrape it.
It also doesn’t track you, fingerprint you, or build a profile. The protection layer checks “does this request have a valid authorization cookie” and serves the file or a placeholder accordingly. That’s the whole interaction. Same privacy posture as the age verification itself: collect as little as possible, store nothing identifiable.
Why I’m Telling You This
Two reasons.
First, transparency. ADT has been running for over 25 years, and the only reason it’s still here is because I’ve been straight with the community about what changes I make and why. The site already had media protection — what changed is how it’s implemented. Most of you will never notice the difference, but it’s still a change to how the site works, and you deserve to know.
Second, if you run a WordPress site with login-protected or membership-gated content, you almost certainly have the same gap ADT used to fix with paid-tier Cloudflare rules. Whether you’re using MemberPress, Paid Memberships Pro, or just WordPress’s built-in login, your media files in /wp-content/uploads/ are still publicly accessible regardless of which pages they’re embedded in. You probably don’t have a $200/month Cloudflare plan with custom edge rules handling that. The plugin does it for you, on whatever Cloudflare tier you’re on — including the free one. The product page is here if you want to look. The free trial covers 10,000 protected requests, no credit card required.
If you have questions about how any of this works on the user side — verification, cookies, what happens if you log in from a new device — drop a comment or reach out. I’m always around.
— Drew
