Using Public Navigation with Audience Specific Content

Understanding What Public Readers See When Audience Targeting Is Applied

When audience targeting is active in Atloria, public readers do not see the full internal page tree. They only see the published pages and sections that are available to their audience. This changes the reading experience in a very specific way: the left navigation stays clean and only lists pages the current reader can actually open.

If you already read Using Public Navigation to Browse Documentation, think of this as the same published navigation experience with one important difference: visibility rules can remove pages from view entirely. Atloria does not show restricted pages as grayed out items or blocked links. If a page is not available to that audience, it is simply missing from the side navigation.

This means the page hierarchy still matters, but readers may see a shortened version of it. A parent page can still appear in the left navigation while only some of its child pages are shown underneath. If several sibling pages exist internally, a public reader may only see the ones that match their audience access. The result is a filtered page tree that still follows the original structure as closely as possible.

For example, a reader may open a published guide and see a parent page with only two visible child pages, even though your team sees more pages in the authoring workspace. That is expected when some pages are audience-restricted. The reading path is still shaped by parent and child relationships, but hidden pages do not interrupt the public experience because they are removed rather than displayed as unavailable.

Moving Through the Side Navigation and Page Tree

In Atloria’s published documentation, the left navigation panel is the main way readers move through related pages. When audience targeting is applied, readers still move through the same page hierarchy, but only through the branches available to them.

1. Open a published documentation page.
2. Look at the left navigation panel to find the current page in the page tree.
3. Use the visible parent pages and child pages to move to related content.
4. If a section has nested pages, expand or collapse it using the arrow or disclosure control beside the page title.
5. Select another page title to open it.

As you move through the page tree, hierarchy cues help you understand where you are. Parent pages appear higher in the tree, child pages are indented underneath them, and the current page is usually highlighted so you can tell which page is open. Expanded sections show available child pages. Collapsed sections hide them until you open that branch.

Audience targeting affects what appears inside each branch. A visible parent page may show only a few child pages, even if more exist in the workspace. That is normal. Atloria only shows child pages that are both published and available to the current audience.

If a page in the middle of a hierarchy is not available to the current audience, the visible tree adjusts around that restriction. Readers do not see a broken placeholder for the missing page. Instead, they see the remaining published path that is available to them. This is why a branch can look shorter or simpler in the public view than it does for authors managing the full documentation structure.

Using the Table of Contents on a Page with Audience-Specific Sections

The table of contents on a published page helps readers jump to sections within the page they are currently viewing. In Atloria, this table of contents is built from the headings that are visible on that page. When audience-specific sections are used, the table of contents changes to match what the public reader is allowed to see.

If a page contains headings for both public content and audience-restricted content, only the visible headings appear in the table of contents for that reader. A heading inside a hidden section is not listed. This keeps the page navigation accurate and prevents readers from clicking links to sections they cannot access.

To use the table of contents, readers open a published page and select a heading from the on-page list. Atloria then moves them directly to that section on the same page. This is especially useful on long pages with multiple heading levels, because readers can skip straight to the part they need without scrolling through the full page.

Audience filtering can explain why a heading expected by an internal author does not appear publicly. If your team knows a page includes a section such as advanced setup, internal process notes, or audience-specific instructions, that heading may be visible in the workspace but absent from the public table of contents. In the public view, Atloria only includes headings from sections that remain visible after audience rules are applied.

This also means the public table of contents may be shorter than the authoring version of the same page. That is not a formatting problem by itself. It usually means the page contains hidden sections that are intentionally excluded for the current audience.

Checking the Reader Experience as a Documentation Manager

If you manage documentation in Atloria, it is important to review the public reading experience instead of relying only on the internal page tree. Audience targeting can change both the left navigation and the table of contents, so a quick check in the published view helps you catch confusing gaps before you share links.

Start by reviewing the page hierarchy in your documentation structure. Confirm which pages are published for general public visibility and which pages are limited to specific audiences. Pay close attention to parent and child relationships. A parent page may still be public even when some of its children are restricted, and that can be perfectly fine if the remaining child pages still make sense on their own.

Next, open the published site and move through the same branch as a reader would. Check the left navigation panel and make sure the visible page list feels complete. If a parent page appears with only one or two visible children, verify that those page titles still provide enough context without the hidden siblings around them.

Then inspect individual pages that contain mixed content. On pages with both public and audience-specific sections, compare what appears in the page body with what appears in the table of contents. The visible headings in the table of contents should match the sections a public reader can actually scroll to and read.

This kind of review is especially useful before sharing a published documentation link with customers, partners, or external readers. It helps you confirm that Atloria is presenting the right navigation path and that hidden content is removed cleanly rather than leaving the page feeling incomplete.

Designing Page Hierarchies That Still Read Clearly for Different Audiences

A clear page hierarchy matters even more when different audiences see different parts of your published documentation. In Atloria, the best public navigation experience usually starts with keeping the most important orientation pages visible to everyone who needs them. That way, readers still understand where they are, even when some child pages are hidden.

Keep broad, high-level pages public whenever possible. Introductory pages, section landing pages, and general workflow pages give readers context before they move into more specific content. If those pages remain visible, the left navigation still feels complete when audience-restricted child pages are removed.

Be careful about relying on a restricted page in the middle of a branch to explain the pages underneath it. If that middle page is hidden from a public audience, the remaining visible pages may appear without enough context in the side navigation. Readers may still be able to open those pages, but the branch can feel abrupt or incomplete.

Use headings consistently inside each page as well. A strong heading structure makes the table of contents useful even after audience-specific sections are filtered out. If your public sections use clear heading levels and descriptive titles, readers can still scan the page and jump to the right section without seeing the hidden material.

Before sharing published links, test the hierarchy from each audience view you intend to support. Open the published documentation as that audience and move through the left navigation branch by branch. Then open longer pages and confirm that the table of contents still reflects the visible content in a way that feels natural to a first-time reader.

For planning related audience structure, see Defining Audiences for Targeted Documentation and Applying Audiences to Documentation Structure and Content Decisions.

Fixing Missing Pages, Empty Navigation Branches, and Incomplete Tables of Contents

When something looks wrong in published navigation, the cause is often a visibility setting or a page structure issue rather than a publishing error. In Atloria, you can usually narrow the problem down by checking whether the missing item is restricted, unpublished, or placed in a branch that no longer makes sense after filtering.

A page does not appear in the side navigation:

• Check whether that page is restricted to an audience that does not include the current public reader.
• Confirm the page is published.
• Review its parent page. If the parent is not available in the published structure, the page may be harder to discover through navigation.

A navigation branch looks incomplete:

• Compare the public view with your internal documentation structure.
• Confirm that missing sibling pages or child pages are intentionally restricted.
• Make sure the remaining visible pages still read clearly without the hidden pages around them.

The table of contents is missing expected entries:

• Open the published page and look for whether the related section is visible at all.
• If the section is hidden for that audience, its heading will not appear in the table of contents.
• Also check whether the content uses proper page headings rather than plain bold text or styling that does not create a table of contents entry.

A direct link opens a page, but readers cannot find it from navigation:

• Review where that page sits in the page tree.
• Check whether the parent path is visible to the same audience.
• If the page is reachable only by direct link, consider whether its placement in the hierarchy still works for public readers.

If you need to validate how a specific audience sees published pages, Viewing Public Documentation by Audience is a helpful companion.

Overview

• Atloria’s published navigation changes based on audience visibility.
• Public readers only see pages and page sections available to their audience.
• The left navigation does not show restricted pages as disabled items; those pages are omitted entirely.
• Parent and child relationships still shape the reading path, even when some pages are hidden.
• The table of contents only includes headings from sections visible on the current published page.
• Documentation managers should review the public view to confirm that navigation branches, page titles, and in-page headings still make sense after filtering.
• Clear public landing pages and consistent heading structure make audience-specific documentation easier to browse.

This guide focused on how audience targeting changes what readers see in the published navigation. The next step is Browsing Published Documentation and Finding the Right Page.

Prerequisites

• You should already be familiar with the basic public reading experience described in Using Public Navigation to Browse Documentation.
• You need access to a published documentation site in Atloria.
• To verify audience behavior as a documentation manager, you should also have access to the project’s published documentation structure and audience visibility settings.
• It helps to review pages that include:
  • Parent and child pages in the left navigation
  • Nested page branches
  • Long-form content with multiple headings
  • Pages or sections that are visible only to selected audiences