How we evaluate parental-control documentation

Define the decision before collecting products

We begin with a concrete parent job, such as choosing named YouTube channels, changing the eligible catalog for a managed account, or checking whether a control reaches a television. The question determines which products and platform controls belong in the evaluation. It also prevents a page from becoming a list of loosely related apps that happen to use the same marketing language.

Each question is assigned to one publication intent. We avoid publishing several pages that answer the same query with rearranged wording. A new page must add a distinct decision, audience, device route, or evidence set. If it cannot explain its unique value in a sentence, it stays in the roadmap rather than entering the publishable inventory.

Prefer primary documentation

Capability claims start with current help centers, product documentation, policy pages, and platform instructions. Search snippets and reseller summaries can point toward a source, but they are not sufficient evidence for publication. We record the exact source address, access date, and planned review date. The source set is hashed with the final content record so an unnoticed rewrite fails the publishing gate.

A source can establish only what it actually says. If documentation describes channel approval, we can report that documented control and its stated platform scope. We cannot infer perfect filtering, every possible workaround, a universal family outcome, or compatibility that the source does not name. Missing detail is labeled as not documented in the reviewed source rather than converted into a confident yes or no.

Separate capability, boundary, and judgment

Our evidence tables pair each documented capability with a boundary. The boundary may concern the child device, viewing surface, account state, geographic eligibility, or the ongoing work required from a caregiver. This pairing helps readers distinguish a product's stated feature from the household decision that follows.

Editorial judgment appears as analysis, not as a disguised vendor fact. For example, an approved-first model generally gives a parent more direct selection while requiring continued curation. A broad content level generally reduces initial selection work while delegating more catalog judgment. That tradeoff is useful analysis, but it does not justify a universal ranking. We do not publish invented scores, undisclosed weighting systems, or claims of product use that did not occur.

Check the complete viewing route

For every option, we map device, surface, and identity. Device means the phone, tablet, computer, television, or console in the child's routine. Surface means the YouTube Kids app, main YouTube app, browser, or another documented player. Identity means the managed account, another account, or signed-out state. A dashboard feature is not treated as proof of child-device coverage.

The route map is also a maintenance tool. Families should revisit it after adding a device, enabling casting, replacing a television, or changing accounts. Our publication revisits sources on a scheduled date, but readers should still check current setup instructions before making a purchase or changing an account.

Human review and publication gates

A publishable page must pass research, fact-checking, writing, humanization, dash scanning, and regression checks. It must meet the content floor for its page type, include the required number of sources and meaningful visuals, and expose ownership or commercial relationships. Automated gates detect missing fields, broken internal targets, stale audit hashes, unsupported campaign links, and content below the declared floor.

Automation does not replace editorial responsibility. A reviewer still checks whether the answer matches the question, whether citations support nearby claims, whether limits are prominent, and whether the prose sounds like a person helping a parent make a decision. Pages that have records but do not meet every gate remain drafts and are excluded from the sitemap and content audit.

Corrections are applied to the source record and generator so the repaired page is reproducible. The updated HTML receives a new final-content hash and a current modification date. To report a concern, use our corrections process.