# WEB-109 — The age gate must come before the restricted content, not after it

> The age gate must be presented before any age-restricted content is accessible, including on a page reached by a direct link.

- **Rule ID:** WEB-109
- **Layer:** Website (`WEBSITE`)
- **Checks:** `page flow ordering`
- **Severity:** BLOCKING — Breaking this rule gets the submission rejected outright.
- **When it bites:** Gates approval — get this wrong and registration is refused
- **How it is detected:** AI judgement over the crawled website or policy page
- **Fix type:** Fix the website — no form edit clears it
- **Required by:** Twilio, Aerialink
- **Applies:** Applies to every 10DLC registration.
- **Canonical URL:** https://ekas.io/rules/10dlc/website/web-109/

## Why this rule exists

A gate that appears after the visitor has already seen the product has protected nobody — the harm the rule addresses happened on page load. The usual cause is a gate wired into the home page template only, so every deep link from a message, a search result or a QR code lands past it.

## How to fix it

Enforce the gate on every restricted URL rather than on the home page, and check the answer server-side before the page renders. Done when pasting a product URL into a fresh browser shows the gate first.

## Common mistakes

- For a QR opt-in the date of birth must be captured before consent is collected, not on the confirmation step — a gate after the number has been submitted is too late for both requirements.

## Provider rejection codes

| Provider | Code | Resubmission allowed |
| --- | --- | --- |
| Twilio (gen2) | `30956` | yes |

## Notes

Conditional on age-restricted content being present, the same condition as WEB-107, and carried in the criteria for the same reason: tagging on the declared ageGated attribute would exempt exactly the brands that under-declare.