Applying Audiences to Public Documentation Experiences

Understanding How Audiences Shape the Public Reading Experience

In Atloria, audiences control what a reader sees after your documentation is published. They affect three parts of the public experience: which pages appear in navigation, which published pages can be opened, and which documentation versions are available in the version selector. This means two readers can visit the same documentation site and see different menus, different page lists, and different version choices based on the audience rules you applied.

Public access and audience-targeted access are not the same thing. A page can still be published and available in your project, but filtered out of the public experience for readers who do not match the selected audience. For example, a page meant for partners may remain published while staying hidden from general public readers. In the same way, a version can stay live for one audience while not appearing at all for another.

You apply these settings in the places where readers actually experience the content:

• On the page itself, using the page visibility or audience setting
• In navigation setup, where menu items, section links, and sidebar entries are shown or hidden
• In version publishing settings, where access to specific documentation releases is controlled

If your public documentation supports audience-aware reading for signed-in users, Atloria can show different content depending on who the reader is. Anonymous visitors usually see the default public set. Signed-in readers may see additional pages, sections, or versions if their audience membership allows it. This is why audience planning matters beyond page editing alone. If you only tag pages but do not align navigation and version settings, readers may miss content or see links that lead nowhere.

If you need help deciding which audience groups to use before you start assigning them, review Planning Audience Targeting for Project Content.

Assigning Audiences to Pages and Navigation

When you want a page to appear only for certain readers, start in the page editor. Open the documentation page you want to control, then find the visibility or audience setting for that page. In Atloria, this is the setting that determines whether the page is available to everyone or only to selected audience groups. If no audience is assigned, the page typically remains part of the general published experience. Once you select one or more audiences, the page becomes targeted to those readers.

1. Open your project and go to the documentation page you want to update.
2. In the page editor, locate the audience or visibility control.
3. Choose the audience values that should be able to read the page.
4. Save or publish the page changes.
5. Open the public documentation preview and confirm the page appears only for the intended audience.

After updating the page, check the navigation that points to it. A common mistake is setting the page audience correctly but leaving the menu item visible to everyone. That creates a public menu link that leads readers to a page they cannot open. To avoid this, update the matching navigation item, section entry, or sidebar node so it uses the same audience rule as the page.

Review these areas together:

• The page audience setting
• The sidebar or menu item for that page
• The parent section that contains the page

If a navigation item is visible but the page is hidden, edit the navigation entry and assign the same audience as the destination page. If the page is public but the menu item is restricted, readers may still reach it from a direct link but not discover it through browsing. The cleanest setup is to keep page visibility and navigation visibility aligned so the public site feels consistent.

For broader audience setup inside a project, see Managing Project Audiences for Targeted Documentation.

Controlling What Readers See Across Documentation Versions

Audience targeting becomes more important when your project has multiple published versions. In Atloria, version access is not only about whether a version is published. It also affects whether that version appears in the version selector for a specific reader. If a version is intended only for a certain audience, readers outside that audience should not see it listed as an available choice.

A page can also behave differently across versions even when the page title or URL path stays the same. For example, a page in one version may be public, while the same page in a newer version may be limited to customers or internal readers. In that case, Atloria treats access according to the rules of the version the reader is viewing, not just the page name. This is useful when a release introduces content that should only be shared with a narrower group.

When you review versioned audience behavior, pay attention to:

• Which versions appear in the version selector
• Whether the same page is visible in every version
• What happens when a reader opens a direct link to a restricted version
• Whether in-page links point to pages or versions the reader can actually access

If a reader tries to open a version they are not allowed to view, that version may be absent from the version selector and unavailable through normal browsing. If links inside a visible page point to hidden version content, the reading experience becomes confusing. Check those links during preview so readers are not sent from an allowed version into a restricted one.

This setup lets teams create distinct reading tracks without rebuilding the entire documentation structure. You can keep one project and use audience rules to present beginner-friendly content, customer documentation, partner materials, or internal release notes through different version choices and page visibility rules. For release planning and version control, pair this work with Publishing Documentation for Specific Audiences and Managing Version Visibility and Reader Access.

Designing Audience Rules for Clear Public Navigation

Good audience targeting should make public navigation feel simpler, not more fragmented. In Atloria, readers should be able to move through top-level navigation, section landing pages, and child pages without running into empty categories or menu branches that contain nothing they can open. The best way to avoid that is to map audience rules across the full navigation path, not page by page in isolation.

Start with your top-level sections. If an entire section is meant for one audience, apply the same audience to the section landing page and all of its child pages. This keeps the sidebar and section menus clean. Readers outside that audience will not see the section at all, which is usually better than showing a heading that opens to no visible content.

Use more detailed audience splits only when the section itself should stay visible to everyone but some child pages should be limited. For example, a general “Getting Started” section may stay public while a few deeper pages are reserved for customers or partners. In that case, make sure the parent section still contains enough visible pages for each audience so it does not feel incomplete.

A simple naming pattern helps teams assign the right audience quickly. Use labels that are easy to recognize at a glance, such as:

• Public
• Customer
• Partner
• Internal

Avoid audience names that are too similar or too broad, especially when Documentation Managers and Technical Writers are updating pages across multiple versions.

Before publishing, use a review workflow that checks:

• The audience on each page
• The audience on the matching navigation item
• The audience on the parent section
• The audience on the published version

If your team already planned audience structure at the content level, connect that work here by reviewing Applying Audiences to Documentation Structure and Content Decisions.

Previewing the Site as Different Audiences

Before you publish audience changes widely, preview the public site as each audience type you support. In Atloria, this is the fastest way to confirm that readers see the right navigation, the right pages, and the right versions. A page can look correct in the editor while still disappearing from the public site because of a parent section rule or a version-level filter, so previewing is essential.

1. Open the public documentation preview for your project.
2. Use the available audience preview or simulation control to switch between audience types.
3. Check the top navigation, sidebar, and section landing pages for each audience.
4. Open pages directly from the menu and confirm they load as expected.
5. Test direct page links for restricted pages to see whether they open, redirect, or stay hidden.
6. Open the version selector and confirm only the intended versions appear for that audience.

Do not stop at menu browsing. Copy a direct page link for a restricted page and test it while previewing another audience. This helps you catch situations where a page is hidden from navigation but still opens from a saved link. Also test the same page across multiple versions if the audience assignment changes between releases.

If your documentation supports signed-in readers with audience-based personalization, compare that experience with the anonymous public view. Anonymous visitors usually see only the broad public set. Signed-in readers may see additional sections or versions after Atloria recognizes their audience membership. That makes it important to test both states:

• Anonymous visitor view
• Signed-in reader view
• Signed-in reader with a different audience assignment

This side-by-side check helps you confirm that audience membership changes the public experience in the way you intended, especially for customer-only or partner-only documentation. For related reading on public browsing behavior, see Viewing Public Documentation by Audience and Using Public Navigation with Audience Specific Content.

Fixing Common Audience Visibility Problems

Most audience visibility issues in Atloria come from one of three places: the page setting, the navigation setting, or the version setting. When something looks wrong in the public site, check those in that order.

If a page is published but does not appear in public navigation, review:

• The page audience or visibility setting
• The navigation item linked to that page
• The parent section or category that contains it

A hidden parent section can remove a page from browsing even when the page itself is published correctly. If the page should be visible, make sure the parent section allows the same audience.

If readers can open a page from a direct link but cannot find it in the menu, the page and the navigation item are probably using different audience rules. Edit the menu entry, sidebar node, or section link so it matches the page audience. This is one of the most common causes of “missing” pages.

If a version is missing from the version selector, check the version’s audience rules first. Then confirm that the selected audience can access at least one published page in that version. A version with no visible pages for that audience may not appear as a useful option in the public reading experience.

If signed-in readers see the wrong content set after logging in, compare their audience membership with what you expected to test. Then repeat the check in preview mode or audience simulation, if available, to confirm whether the issue is with the audience assignment or with the reader account being used.

When troubleshooting, it helps to test one page and one version at a time. Change a single audience rule, refresh the public preview, and confirm the result before adjusting anything else. That makes it easier to find the exact mismatch. For broader public-reading checks, use Reviewing Audience Specific Pages in Public Documentation.

Overview

• In Atloria, audiences shape the public reading experience by controlling page visibility, navigation visibility, and version availability.
• A page can remain published while still being hidden from readers who do not match the assigned audience.
• Audience rules need to stay aligned across the page, its navigation link, its parent section, and the published version.
• Public readers and signed-in readers may see different content sets when your documentation uses audience-aware personalization.
• Previewing the site as multiple audiences helps you catch hidden pages, empty navigation sections, and missing versions before readers do.

This document focuses on applying audience decisions to the public documentation experience. If you still need to define the audience groups themselves, start with Defining Audiences for Targeted Documentation. If your next step is validating the published reader journey, continue with Viewing Public Documentation by Audience.

Prerequisites

• You have access to an Atloria project with published or publish-ready documentation.
• Your project already includes audience groups that were created and organized for documentation use.
• You can open documentation pages in the editor and update their visibility or audience settings.
• You can review or edit public navigation for the project.
• You have access to version publishing settings if your project uses multiple documentation versions.
• You can open the public documentation preview to test what readers see.
• If you are checking signed-in reader behavior, you have a reader account that belongs to the audience you want to test.

If you have not completed the planning work yet, review Planning Audience Targeting for Project Content before applying these rules to the public site.