Personalized content | NookDocs

Personalization means the same docs page renders differently depending on who's viewing it. NookDocs ships one real split today — browser readers vs LLM agents — plus a roadmap for authenticated user-group personalization once the auth layer lands.

Shipping status today. <Visibility for="humans | agents"> works right now (audience split between browser readers and LLM crawlers). Authenticated user-group personalization (public: false, authGroups: [...]) is roadmap — schema support is scaffolded but runtime enforcement isn't wired.

Audience split — `<Visibility>`

The real feature shipping today. Wrap any block with <Visibility for="humans"> or <Visibility for="agents"> and the content appears only for that audience.

<Visibility for="humans">
  <Note>
    Click the **Copy page** button in the top-right to copy this doc as Markdown.
  </Note>
</Visibility>

<Visibility for="agents">
  <Note>
    If you're an LLM reading this page, the full MDX source is
    available at `/content/personalization.md`. Use that for context.
  </Note>
</Visibility>

Browsers render for="humans" blocks normally, hide for="agents" blocks entirely.
Markdown exports (.md URLs, llms-full.txt, copy-for-llms) do the inverse — agent blocks included, human blocks stripped.

When to use audience split

Human-only UX cues

Instructions that reference UI state — "click the button", "look at the sidebar", "watch the cursor". Agents read raw text, so these instructions confuse them.

Agent-only context

Meta-instructions for LLMs — "this page's schema reference lives at ...", "when generating code, use the <Steps> component not plain ordered lists". Hide from browsers; surface to agents.

Legal boilerplate

Some compliance text only matters for humans (cookie banners, accessibility disclosures). Ship it to browsers, strip from LLM context.

Debugging directives

"If your answer doesn't compile, retry with the component spec at /llm-first/component-spec.md" — guidance agents should see, but clutter for human readers.

See the Visibility component for the API reference.

User-group personalization (roadmap)

The schema already accepts two personalization fields. They're not enforced at runtime yet — setting them today has no effect.

`public: boolean` (page-level)

Whether a page is publicly accessible. Default true. When false, the page becomes visible only to authenticated users with an allowed role. Ships when the auth layer lands.

`authGroups: string[]` (group + page level)

List of group slugs a viewer must belong to. Ships with the auth layer.

{
  "navigation": [
    {
      "group": "Admin",
      "public": false,
      "authGroups": ["admin", "devrel"],
      "pages": ["docs/admin/rotate-keys"]
    }
  ]
}

When the auth layer ships, only viewers whose JWT / session carries a matching group slug see this nav group.

What the roadmap covers

Viewer identification

Tenants configure an upstream auth provider (Clerk / Auth0 / custom JWT). The docs shell reads the session cookie and extracts the viewer's group memberships.

Nav-level gating

Groups / tabs / pages with public: false disappear from the sidebar for viewers lacking the right authGroups entry. Direct navigation returns 404.

Page-level gating

Individual pages with frontmatter public: false + authGroups: [...] check viewer context at render. Same 404-on-miss behaviour.

Per-block gating (long-term)

<Visibility for="group:enterprise"> inside an MDX page to show/hide sections by tier. Long-term — the nav/page-level gating lands first.

Track progress at github.com/Codivion/NookDocs/issues.

Related patterns that already ship

`hidden: true` — remove from sidebar + search + SEO

Hide a page from discovery (sidebar, search, sitemap, llms.txt) while keeping the URL accessible. Public to anyone who has the URL; invisible to anyone who doesn't.

---
title: Internal API
hidden: true
---

Useful for gated flows ("only people who get this URL from our CS team see this page") or deprecated-but-still-reachable pages. Not personalization — no viewer check — but covers some of the same use cases.

See hidden pages when that lands, or the hidden field in the schema reference.

`seo.indexing: "noindex"` — hide entire site from search

Site-wide version of the same idea. noindex emits robots: noindex, nofollow on every page. Staging sites, private docs, early-access beta docs.

See SEO.

`Visibility` for audience, not viewer

The name suggests "show/hide" which is what personalization does too, but <Visibility> splits by AUDIENCE (browser vs LLM) not VIEWER (user group). Don't confuse the two.

Limitations

No viewer-aware gating today. public / authGroups fields are accepted by the schema but not enforced. Adding them to config has no effect until the auth layer lands.
No cookie / geo / AB conditionals. Content doesn't branch by IP, user-agent, or session state.
<Visibility> is boolean, not multi-audience. for="humans" or for="agents" — no for="enterprise+pro" tiers yet.

Visibility component — audience-split API reference
Markdown export — how agent blocks flow to LLMs
Schema reference — authGroups and public field listings
Reusable snippets — a different kind of content reuse (dedupe vs gate)

Audience split — <Visibility>