When separate search profiles help
Use separate policy when a child needs Google SafeSearch filtering but parents need normal research access. It also helps distinguish tablets, phones, school laptops, shared screens, guest devices, and adult work computers.
The goal is to stop one child setting from becoming a blunt home-wide restriction. Use a few understandable profiles:
- a protective household baseline for malware and phishing;
- a child profile with Google SafeSearch set to Filter;
- a parent profile without the child search restriction;
- a shared-device profile based on how that device is used.
When device profiles cannot separate users
Do not expect DNS to recognize the signed-in user on a shared device. It can apply policy to a resolver, endpoint, or profile, but cannot see who is typing. Use separate operating-system or browser accounts, or choose a clear shared default.
Per-device DNS is incomplete on mobile data, a VPN, a browser-selected resolver, or a school-managed device. Use account and device controls for those paths.
Google says SafeSearch works only on Google Search1, not other engines or websites. DNS cannot read search words, thumbnails, page content, messages, or browser history; it can enforce a supported response or block a domain.
Separate child and parent search profiles
1. Inventory devices by context, not only by owner
List every search-capable device, its usual user, and whether it is personal, shared, school-managed, or a guest device. “Living-room TV” is a better policy identity than “Dad.”
Ask:
- Who usually uses this device?
- Does it leave home or switch to mobile data?
- Can its DNS or VPN settings change?
- Is it shared or managed by a school or employer?
The answers show where device-scoped DNS fits and where account or device control is needed.
2. Define the common baseline and the child-only rule
Keep general security separate from content choices. Malware and phishing blocking can be the baseline; SafeSearch can be child-only. Parent devices keep the baseline without the child restriction.
Choose Filter, not Blur, to exclude explicit results. Google says Blur primarily blurs explicit images and may leave relevant explicit text and links visible. Blur working as designed can look like Filter failing.
Write down the expected result for each profile before configuring anything. For example:
| Device context | Baseline | Search rule |
|---|---|---|
| Child tablet | Malware and phishing protection | SafeSearch Filter enforced |
| School laptop | Compatible household baseline | Account control first; do not override school policy |
| Shared TV | Protective shared profile | Conservative platform settings |
| Parent laptop | Malware and phishing protection | Parent-controlled SafeSearch choice |
3. Give the DNS service stable endpoint context
Different rules require distinguishable context before DNS answers. It may come from device-specific resolver configuration, endpoint registration, or a network segment assigned to a profile. What matters is that child and parent requests arrive under their respective contexts.
If all devices share one undifferentiated router identity, upstream policy can apply only one answer. Verify each profile binding from its device.
4. Put account controls beside DNS controls
For an eligible Family Link account, SafeSearch filtering is on and locked by default. Google’s guidance2 notes that the child must be signed in and alternative search apps may not enforce the preference.
Account supervision follows the signed-in Google experience. DNS covers the child endpoint while it uses the intended resolver. Use both for their respective paths.
5. Apply the least broad search action
Prefer documented enforcement to blocking a whole engine. Google’s network instructions3 use forcesafesearch.google.com and require coverage for the country or region domains people use.
Apply it only to the child profile. Unrelated Google, image, login, or delivery-domain blocks can break normal services without improving SafeSearch accuracy.
6. Test both sides of the boundary
Testing only the child device proves half the outcome. Use a simple matrix:
- On the child device, confirm Google reports SafeSearch as locked to Filter.
- Search from the child’s normal browser and Google app, if used.
- Repeat while signed out only if signed-out use is allowed.
- On a parent device, confirm the parent’s chosen SafeSearch setting remains available.
- Move the child phone from Wi-Fi to mobile data and note whether account or device controls still apply.
- Enable any normal VPN or secure DNS configuration and check which resolver path is active.
Run benign, preselected test queries rather than searching for increasingly explicit material. The useful result is the setting and scope, not a collection of sensitive examples.
7. Review with the least visibility necessary
Start with the visible outcome and aggregate counts. If it fails, inspect a short domain-level window for device/profile, Google domain, matched rule, and action. DNS cannot provide search terms. Reduce detail after testing.
Review after adding a browser, VPN, phone, router, or school device.
Child-parent profile mistakes to avoid
- Putting the child rule on the router default. Everyone receives the same answer, and adults eventually demand an unsafe broad exception.
- Assuming a profile name proves endpoint identity. Verify the child and parent devices independently.
- Using Blur when the requirement is Filter. Blur may leave explicit text and links visible.
- Forgetting regional Google domains. A rule for one Google hostname may not cover the country domain the device uses.
- Treating a shared device as a person. DNS cannot see who picked up the tablet.
- Ignoring alternate resolvers and networks. Secure DNS, VPNs, mobile data, and managed devices can change the path.
- Logging the household by default. Troubleshoot with a purpose, short retention, and domain-level context only.
Child and parent search questions
Can two devices on the same Wi-Fi receive different DNS policies?
Yes, if the filtering service receives stable, distinguishable endpoint context for each device. Not if all requests arrive under one undifferentiated identity.
Does SafeSearch Filter block explicit content everywhere?
No. It applies to Google Search. Other search engines, websites, and in-app content need their own controls.
What should happen on a shared family computer?
Use separate device or browser accounts where possible. Keep the DNS profile suitable for the least-supervised normal user, because DNS cannot identify the active person.
Should parents inspect detailed DNS logs?
Only when a named problem requires it. First use a direct test or aggregate metric; then review the smallest domain-level window needed to diagnose scope.
Configure separate Veilty search profiles
Veilty’s public guidance recommends profiles that fit a child tablet, shared TV, guest device, and parent laptop. Review Veilty’s family DNS setup guide4, create child and parent profiles, connect one endpoint to each, and run the six-part boundary test before adding devices. If another caregiver helps, invite them to the Veilty account, then assign a family Space role that grants only the policy and retained-history access they need. Keep each exception on the profile that needs it, with a reason and review date.