Age Gates on WordPress Sites Collect the Data They Claim to Protect Against
The age gate went up for the right reasons, and within a month it had quietly built the most sensitive small database on the site: dates of birth in a form table, self declaration logs with IP addresses, and, on one memorable configuration, uploaded document images sitting in the media library next to the blog photos.
Age assurance and data minimisation pull in opposite directions unless someone designs for both at once. Most WordPress age gates are installed as plugins chosen for conversion and appearance, and their data behaviour, what is stored, where, for how long, is whatever the default happened to be.
Verify the threshold, store the result
The legal and safety question is almost always a threshold: is this visitor over a stated age. That question has a yes or no answer, and the answer, the method used, and the timestamp are usually all a site needs to retain to show it checked. A full date of birth is more data than the threshold requires, and a document image is vastly more.
Where a third party verification service is used, configure and confirm what it returns and what it retains on your behalf. A service that returns only an over threshold flag is a fundamentally different risk position from one that returns and stores identity details in your WordPress database, and procurement should treat that difference as a headline feature, not a footnote.
Self declaration is weak, and sometimes that is proportionate
A click through I am over 18 is easy to bypass and everyone knows it. Whether that matters depends on what sits behind the gate, the applicable law, and the regulator's expectations for that content or product category. Some contexts require stronger assurance. Others accept declaration, and adding document checks there collects sensitive data out of proportion to any requirement.
The design error is choosing the method by anxiety rather than by obligation. Map the actual requirement first: what the law or the platform rule says for your category and jurisdiction, then choose the lightest method that meets it, and record that reasoning. Proportionality is a defensible position. Maximum collection by default is not.
The gate itself is a consent and privacy surface
Visitors meet the age gate before the privacy policy, often before any consent banner, which means the gate's own storage, cookies to remember the answer, analytics on the gate page, third party scripts inside the verification flow, all operate in the most sensitive moment of the visit. A gate that sets advertising cookies while checking age has its priorities visibly backwards.
Remembering the result in a cookie is usually necessary for usability, and that cookie should be classified and disclosed like any other, with a duration matched to the need. A visitor should not have to re verify on every page, and the site should not remember the verification for a year because a plugin default said so.
Retention and access for what little you keep
Verification logs, even minimal ones, link an age result to a time and often an IP address or account, which makes them personal data with a sensitivity beyond their size. Give them a short, stated retention, restrict who can view them, and include them in subject access and deletion processes. Data collected to protect users deserves at least the care of ordinary marketing data, and in audits it regularly receives less.
Review the gate after plugin updates, because defaults reset and new features, fraud scoring, document options, marketing integrations, arrive switched on. The gate you audited in January is not automatically the gate running in June, and its data behaviour is the part most likely to have drifted.
Related reading
These earlier guides go deeper on connected questions: Headless WordPress Consent: The Banner Works, the API Ignores It Headless builds separate the banner from the backend. Consent choices made in the frontend may never reach the APIs feeding apps and partners., When Consent Mode Eats Your Traffic: Reading the Gap Between Clicks and Modeled Data Consent mode gaps get blamed on users. Often the signals are late, wrong, or never sent. How to tell refusal from breakage., and Global Privacy Control on a Small Site: Honouring the Signal Without a Legal Department.
Frequently asked questions
What data should an age gate store?
As little as the threshold decision requires: usually the result, the method used, and a timestamp. A full date of birth, and especially document images, exceed what most sites need to demonstrate they checked, and create a sensitive data store with its own retention and security obligations.
Is a self declaration age check enough?
It depends on the legal requirement for the content or product and jurisdiction involved. Some contexts accept declaration, others require stronger age assurance. Choose the lightest method that meets the actual obligation, and record the reasoning, rather than defaulting to the heaviest collection available.
Does an age verification cookie need disclosure?
Yes. A cookie that remembers the verification result is storage on the visitor's device and should be classified, disclosed and given a proportionate duration like other cookies. It is usually defensible as necessary for the service's operation, but that status should be a decision, not an assumption.
How long should age verification records be kept?
Only as long as needed to demonstrate compliance for the access they governed, under a stated schedule, with restricted access. Verification logs are personal data and belong in access and deletion processes. Indefinite retention of age records, especially dates of birth or documents, is difficult to justify.