BC-0118 · CORE GUIDE
Editorial review 2026-09-26
Roblox Build and Roblox Kids
Current Roblox Support says Build games cannot be made available to Roblox Kids, ages 5–8. Do not treat a gentler theme, a different description or a Select application as a way to remove that Build-specific restriction.
Objective
Apply the Build-specific Kids restriction to audience planning without inventing an exception or bypass.
Before you start
- Know the audience the project intends to serve.
- Read the specific Build rule rather than only general Kids documentation.
- Keep age and account verification in Roblox's legitimate workflow.
Steps
- Compare the intended audience with the current product restriction.
- Correct promotional descriptions that imply excluded access.
- Choose whether to revise the intended audience or research another workflow.
- Check that workflow's requirements independently before moving the project.
- Record unresolved eligibility without requesting private verification material.
Verification
- A child-friendly theme is not used as evidence of audience eligibility.
- The specific Build restriction remains attached to general Kids references.
- Select or Studio is not presented as an automatic exception.
- The planning note names a real next decision rather than an age workaround.
Limitations
- This page does not evaluate an individual child or account.
- A different creation workflow still has its own publication and audience requirements.
- No future change to the Build-specific restriction is assumed.
Working notes
Separate design suitability from distribution eligibility. A game can use simple controls and avoid frightening content without becoming available to an audience that the product rules exclude. Describe the actual audience state when discussing the game with families or collaborators.
General Kids documentation covers a broader set of Roblox experiences. Read it alongside the specific Build rule instead of selecting the more permissive passage and silently dropping the product qualification. A rule for another workflow is not an exception for this one.
If the project was conceived for that restricted audience, make a deliberate planning decision. You can revise the intended audience or investigate another appropriate creation and review workflow. Do not assume a Studio handoff alone removes every audience condition; its version-status consequences and the destination's publication requirements need separate review.
Keep troubleshooting age restrictions away from private identity data. The useful record contains the intended audience, public destination and visible restriction. It does not need another person's verification images or credentials, and it should never recommend falsifying an age or bypassing account controls.
Examples
- Planning correction: a simple color-matching prototype was described as available to all children. Replace that unsupported audience claim with the actual permitted distribution scope before presenting the project as ready for that group.
- Source comparison: read the general audience guidance alongside the specific product paragraph. Keep both scopes recorded before interpreting eligibility, rather than merging the pages into a broader permission.
- Alternative-workflow note: intended audience / current product restriction / candidate creation workflow / requirements still to research / version changes involved. This is a research decision, not a promised route around the restriction.