Consent for Minors: The Age Gate Your Banner Never Built
A twelve-year-old opens a site, the consent banner slides in, and the child clicks accept, because that is what the banner asks for and what the button says. The consent is not valid. The child cannot give it, the parent was never asked, and the site has been collecting a minor's data without a lawful basis since the first page load.
The banner assumes an adult, and the law does not
A consent banner asks the visitor for consent. It assumes the visitor can give it. Under GDPR Article 8, a child is someone under 16, although member states may lower the age to 13, and the UK set it at 13 while Germany kept it at 16. A child below that age cannot consent to the processing of their own data in relation to an information society service. The consent has to come from the holder of parental responsibility. A banner that asks the child and accepts the child's click has collected data without a lawful basis, and the consent it recorded is not consent.
Under COPPA, the rule is sharper. An operator that directs a service at children under 13, or knows it is collecting personal information from a child under 13, must obtain verifiable parental consent before collecting, using, or disclosing the information. A checkbox the child can tick is not verification. A birthday field the child can lie in is not verification. The consent has to come from the parent, through a method the parent actually controls, and the FTC's COPPA updates, effective June 23, 2025, with a compliance deadline of April 22, 2026, tightened the requirements around parental consent and the data collected from children.
The consent records post covers what a regulator asks for after a complaint. The point here is the banner, because the banner is the mechanism that fails: it asks the wrong person, records the wrong answer, and stores the result as if it were valid. The consent record is a lie the site tells itself, and it is a lie that survives until a regulator or a parent asks to see it.
The age gate the banner never built
The fix starts before the banner. A site aimed at children, or a site a child is likely to use, needs an age gate before the consent request, and a parental consent flow behind it. The gate asks for the birth date, and when the visitor is below the threshold, the consent request goes to the parent, not the child. The parent's consent is obtained through a method the parent controls, an email confirmation, a payment verification, a signed form, and the child's data is not collected until the parent has given it.
A general audience site needs the same gate for the services a child is likely to reach. A site that sells to everyone, with a children's section, a gaming feature, or a social element, is a site a child will use, and the banner that treats every visitor as an adult is a banner that will collect a child's data. The segmentation is the work: decide which services a child is likely to reach, gate those, and keep the general consent flow for the rest.
The Consent Mode post is the companion check: the signals the banner sends have to match the consent it actually obtained, and a banner that records a child's click as valid consent is sending a signal that is false. The audit that matters is not the banner's display. It is the consent record behind it, and the record has to show who consented, when, and how old they were, because that is what a regulator asks for first.
The check to run this week
Look at the consent records for the youngest visitors you can identify. If the banner has no age gate, the records do not show age, and the consent was obtained from whoever clicked, which means it was obtained from children as well as adults. That is the exposure, and it is the exposure that is easiest to fix and hardest to defend, because the fix is a gate and a parental flow, and the defense is nothing at all.
Build the gate, build the parental flow, and keep the records. A site that can show a regulator that it asked for the parent's consent, and got it, before collecting a child's data, is a site that has done the work. A site that can only show a banner click from an unknown visitor is a site that has a consent record with no lawful basis behind it, and no lawful basis is the finding that ends the conversation.
Frequently asked questions
What counts as a child under GDPR?
Under GDPR Article 8, a child is someone under 16, although member states may lower the age to 13. The UK set it at 13. Germany kept it at 16. A banner that treats every visitor as an adult gets this wrong in both directions.
What does COPPA require for a child under 13?
Verifiable parental consent. A checkbox the child can tick is not verification, and a birthday field the child can lie in is not verification. The consent has to come from the parent, through a method the parent actually controls.
Does a standard consent banner handle children?
No. A banner that asks for consent from the visitor assumes the visitor can consent. A child cannot consent to the processing of their own data under GDPR Article 8, and a parent has to give it. The banner has to know who it is talking to before it asks.
What should a site do if children might use it?
Segment the audience first. A site aimed at children, or a site a child is likely to use, needs an age gate before the consent request, and a parental consent flow behind it. A general audience site needs the same gate for the services a child is likely to reach.