Reviewing Audience Specific Pages in Public Documentation

Opening the public page review tools for a specific audience

1. Open the published documentation site for the project in Atloria and go to the public page you want to review. You can reach it by browsing through the public navigation, using a search result, or opening the page directly from its public URL. For this task, stay in the public documentation experience rather than opening the page from a project editing screen.

2. Make sure you are looking at the live public reading view. You should see the page as a reader would see it, including the page title, navigation, breadcrumb trail, and any public audience controls. If you are in a workspace that shows editing tools, version management options, or other internal project actions, return to the published public page before continuing.

3. Find the audience selection control on the public documentation page. This is the control you use to switch the reader view from one audience to another. It may appear near the top of the page or within the public reading layout. Use that control before you begin checking page visibility, links, or redirects.

4. Confirm that the audience setting applies to the page you are currently viewing. After you select an audience, watch for changes in the page content, navigation links, or page route. If nothing changes right away, refresh the page and check again.

5. Before you start your review, verify that the page you opened is the exact public page you intend to inspect. Check the page title, the breadcrumb path, and the surrounding navigation so you know you are validating the correct destination for that audience.

Switching the page to the audience you want to review

1. On the public documentation page, open the audience picker and choose the audience you want to test. Use the exact audience name that matches your review plan, such as a role-based reader group or another public audience segment already set up for the project. If you planned the audience structure earlier, use that naming consistently with Planning Audience Specific Documentation Experiences.

2. After you select the audience, wait for the page to update. In Atloria, changing the audience can affect what appears in the left navigation, which links are shown on the page, and whether the current page remains available. If the page does not visibly update, refresh the browser and confirm the selected audience is still shown.

3. Review the page again with the new audience applied. Look for visible changes such as:

   • A different set of navigation links
   • Hidden or newly visible content sections
   • Different related links or calls to action
   • A redirect to another page if the current page is not available to that audience

4. Record the exact audience name shown in the selector before taking notes or screenshots. This helps avoid confusion later, especially when comparing two similar audience groups on the same page.

5. If you are reviewing with teammates, ask everyone to switch to the same audience before discussing results. Small differences in the selected audience can make the same page look different, even when the URL stays the same.

Checking whether the selected page is available to that audience

1. Start by confirming that the page loads normally for the selected audience. A successful review page should display its expected title and content. If Atloria sends you to a different page, shows a missing-page message, or blocks access, note that result immediately because it means the page is not available in the way you expected for that audience.

2. Check the page title and breadcrumb trail. These two elements help confirm that the page you are seeing is the intended public page, not a fallback page or a nearby section with a similar name. Also review the navigation state so you can see whether the correct section is highlighted.

3. Test the page through direct access. Copy or open the public page URL while keeping the same audience selected. This confirms whether the page is truly available for that audience or only reachable when you click through navigation. A page that opens through menus but fails on direct access needs further review.

4. Compare discoverability across the public reading experience. Look for the page in:

   • The main navigation
   • Breadcrumb paths from parent pages
   • Search results, if public search is available
   • Related links or next-step links on nearby pages

5. If the page is meant to be public for that audience, it should be both reachable and discoverable through normal reading paths. If it only appears in one place, or disappears from menus while still loading by direct URL, capture that mismatch in your review notes.

Confirming readers are seeing the intended content path

1. Begin from a realistic public starting point instead of jumping straight to the page every time. Open a landing page, category page, search result, or related link that a reader from the selected audience would normally use. Then follow the path to the page under review.

2. Watch for redirects as you move through the public site. If Atloria sends the selected audience to another page, confirm that the destination makes sense for that audience. A correct redirect should guide the reader to the matching public content path, not to a general fallback page or a page intended for another audience.

3. Review the page’s surrounding navigation once you arrive. Check the breadcrumb sequence, nearby menu items, and any related links shown on the page. These should all support the same audience journey and keep the reader moving through the right set of documentation pages.

4. Pay close attention to audience-specific guidance on the page itself. If the page includes banners, prompts, or calls to action, make sure they point to the next page that audience should read. A page can be available and still be wrong if its follow-up links send readers into another audience’s route.

5. Confirm that the URL path, breadcrumb order, and linked next steps all match the intended reading journey you planned for that audience. If the path breaks at any point, note exactly where it happens: the starting page, the redirect, the breadcrumb jump, or the related link.

Comparing what different audiences see on the same public page

1. Open the same public page and switch between at least two audience selections using the audience picker. Keep the page URL the same while you compare results. This makes it easier to spot whether Atloria changes the page content, hides the page, or redirects one audience elsewhere.

2. For each audience, review the same set of page elements:

   • Page title
   • Main heading
   • Body sections
   • Navigation links
   • Related content modules
   • Calls to action
   • Redirect behavior, if the page is unavailable

3. Note which parts stay the same and which parts change. Some pages should remain shared across audiences, with only small differences in supporting links. Other pages may be fully audience-specific and should disappear or redirect when the wrong audience is selected. Your review should confirm that the page behaves according to its intended public use.

4. Pay special attention to cases where the same URL shows the wrong variation. For example, one audience may see content that should only belong to another audience, or a shared page may hide content that should remain visible to everyone. These are important review findings because they affect the public reading experience directly.

5. When documenting differences, use the audience names exactly as shown in Atloria and describe the visible change on the page rather than using general notes like “looks different.” Clear comparisons make it easier to correct audience targeting later.

Fixing common issues when audience-specific pages do not match expectations

When a page does not behave the way you expect, start with the simplest checks on the public page itself. First, confirm the audience picker is set to the correct audience and that the selected audience name is still visible after the page loads. If the page does not change after switching audiences, refresh the page and compare the navigation, title, and visible sections again. In many cases, the issue is that the audience change was not fully applied before the review started.

If a page seems missing for one audience, test the public page URL directly while keeping that audience selected. Then compare what appears in the navigation and breadcrumb trail. A page may be hidden from menus, redirected to another page, or unavailable entirely. These are different results, so record which one you see instead of writing only that the page is “not there.”

If readers land on the wrong page, trace the route step by step. Start from the public landing page or category page, click the same links a reader would use, and note the exact point where the path changes unexpectedly. Check:

• The redirect destination
• The breadcrumb sequence
• Related links on the page
• Calls to action that move the reader forward

If different reviewers report different results, make sure everyone is using the same public URL, the same selected audience, and the same published page state. Differences in any of those three items can make review findings look inconsistent even when Atloria is working as configured.

Overview

Use this review when you need to confirm that a published documentation page in Atloria behaves correctly for a specific audience. The goal is not to edit content or change audience settings. Instead, you are checking the public reading experience: whether the page is available, whether readers can find it through normal navigation, and whether the surrounding links keep them on the right documentation path.

This task is most useful after audience planning is complete and the public documentation is already published. If you still need to define which pages belong to which audience, return to Planning Audience Specific Documentation Experiences before starting this review.

During the review, focus on what a public reader actually sees:

• The selected audience in the audience picker
• The page title and main heading
• Breadcrumbs and navigation menus
• Related links and calls to action
• Redirects or missing-page behavior
• Differences between audience views on the same page

A strong review answers three practical questions:

• Can this audience open the page?
• Can this audience discover the page through normal public navigation?
• Does this page lead the audience to the correct next page?

Because Atloria supports audience-specific public experiences, the same page URL may not behave the same way for every audience. That is why it is important to test both direct access and normal click paths, and to compare results across more than one audience when needed.

Prerequisites

Before you start reviewing audience-specific public pages in Atloria, make sure the following are already in place:

• You can access the project’s published public documentation site.
• The project already has audience options available in the public reader view.
• The page you want to review has been published to the public site.
• You know which audience name you are testing.
• You have a specific page, section, or reader journey to validate.
• You are working in the public documentation view, not in an internal editing or project workspace.

It also helps to have these details ready before you begin:

• The public page URL you want to test directly
• The expected starting point for the reader, such as a landing page or category page
• The expected next step after the page, such as a related page or follow-up section
• Any review notes from earlier audience planning work

If you need help getting into Atloria or reaching the correct workspace first, use Accessing and Registering Your Atloria Account or Understanding Account Entry Points and Session Navigation. If you need to confirm how public readers browse published content before testing audience behavior, see Viewing Public Documentation by Audience.

The next step in this audience workflow is Planning Audience Specific Release Views.