If children might reach your product, regulators increasingly expect you to know it before they do. An age gate (a screen asking the visitor's age or date of birth) and broader "age assurance" measures recur across app-store review, US COPPA enforcement, the UK Children's Code, and the EU Digital Services Act's minor-protection rules — and for an indie developer shipping fast, a missing age screen is easy to forget.
LaunchTrust does not decide whether your product legally needs an age gate or whether yours is good enough. It scans your public page and reports one thing: whether an age-assurance signal appears present — a starting point for your judgment, not a verdict.
What LaunchTrust checks
The age_gate detector applies only to web surfaces (your site, web app, or landing page). It fetches the page's HTML and looks for text patterns that commonly indicate an age gate or age-assurance prompt — phrases like "age gate", "age verification", "age assurance", "are you over / at least NN", "must be at least NN", "date of birth", "enter your age", "confirm your age", "18+", "13+", "parental consent", and "under 18 / under 13".
The detector's polarity is positive — the signal is something you generally want present when children could be in your audience. It returns one of three results:
- Detected — a matching phrase was found, recorded as an informational signal with the matched snippet shown (for example,
date of birth). It means the words are present; it does not assess whether the gate blocks anyone, is enforced server-side, or is the right mechanism for your audience. - Not detected — no age-assurance phrase was found, flagged at low severity because it only matters if children may use your service. A note points you to COPPA, the UK Children's Code, and the DSA's minor-protection rules.
- Unable to determine — the page could not be retrieved or parsed. This is a limitation of the scan, not a finding about your app.
Because the check is text-based, a gate injected by JavaScript after load, or one behind a separate flow, may read "not detected" even though it exists. Treat the result as a prompt to look, not proof.
Why it matters
- US COPPA. The Children's Online Privacy Protection Act governs services directed to children under 13, or that knowingly collect personal information from under-13 users. A neutral age screen is one common way to avoid unknowingly collecting children's data. Whether COPPA applies is fact-specific.
- UK Children's Code (Age Appropriate Design Code). It expects services likely to be accessed by children to establish age with a proportionate level of certainty and apply child-appropriate protections by default. "Age assurance" is its umbrella term for that range of measures.
- EU Digital Services Act. The DSA includes obligations aimed at protecting minors online, and platforms are increasingly expected to consider age-related risks. See our European Union overview for context.
- App stores. Both major stores ask about age and audience at submission and apply age ratings; a mismatch between your declared audience and actual gating is a recurring source of review questions.
A concrete example
A minimal age gate the detector would match might look like this:
<div class="age-gate">
<h2>Confirm your age</h2>
<p>You must be at least 18 to continue.</p>
<label>Date of birth <input type="date" name="dob"></label>
</div>Here "confirm your age", "must be at least 18", and "date of birth" each independently trip the detector, so it reports detected. A decorative footer line like "© 2026 — all ages welcome" would not match, and the page would read not detected.
How to address it
- Decide whether children are in scope. Assess whether under-13 (COPPA) or under-18 (Children's Code, DSA) users are likely or intended; if not, document why.
- Add a clear, neutral age prompt. Prefer a date-of-birth field over a single "I am over 18" button, which provides weaker assurance.
- Enforce it server-side. A front-end modal alone is easy to bypass; gate the content or account creation on the server, not just the UI.
- Apply child-appropriate defaults. Minimize data collection and review your third-party tracking.
- Describe it accurately. Reflect your age handling in your privacy policy and align your store declarations — Google Play Data safety and the App Store privacy labels.
- Re-scan and review the snippet. Confirm the gate text appears in the served HTML, and verify it actually blocks the flow.
Check this in 30 seconds
Run your URL through LaunchTrust's free scanner. It tells you whether an age-assurance phrase is present and shows the exact snippet it matched, so you can see at a glance whether a reviewer would find one too — a fast way to catch a missing gate before submission, without any claim about your legal obligations.
FAQ
Does detecting an age gate mean my app meets the rules? No. LaunchTrust surfaces signals — it reports that age-assurance text appears present or absent. It is not legal advice, a certification, or a verdict on whether your age handling satisfies COPPA, the Children's Code, the DSA, or any store policy. Use it to inform your own review.
My gate loads as a JavaScript popup — why "not detected"? The detector reads the HTML it can see. If the gate text is injected client-side after the scan, or lives in a separate flow, it may not appear in the scanned markup. Keep the gate text in the served HTML where it can be observed.
Is an "I am over 18" checkbox enough? That is a judgment call. A single self-declared click provides weaker assurance than a date-of-birth prompt with server-side enforcement, and codes like the UK Children's Code expect a proportionate level of certainty. The detector matches both, but presence of text is not the same as adequacy.
Compliance aid, not legal advice. LaunchTrust reports signals, not a verdict or certification.