## Understanding How Audience-Specific Public Views Are Chosen In Atloria, a public documentation page is not always a single page shown the same way to every reader. The public reading experience depends on two choices working together: the **audience** being viewed and the **documentation version** being opened. When you validate a public page, check those two controls first before judging whether the content is correct. A reader can arrive in a tailored public view in several ways. They might open an audience-specific link, switch to a different release with the **version selector**, or land directly on a public page from a shared URL. In each case, Atloria opens the public reading view for that audience and version combination if that matching page is available. This is the view external readers use, and it opens without requiring sign-in. If Atloria cannot find a tailored page for the selected audience or version, the result may change. In some cases, the general public page appears instead of the audience-specific variant. In other cases, the page may not appear in navigation for that audience at all. That is why it is important to test both the page itself and the surrounding navigation, not just the URL. A page that exists for one release may fall back to a general version in another release, and a page that is visible to one audience may be hidden for another. Keep the public reading view separate from the editing workspace in your review process. The page record and editing screens help you manage content, audience assignment, and publication choices, but they do not show the exact experience an outside reader gets. When you need to confirm what customers, partners, or internal readers actually see, open the **public preview** or the published public page instead. If you already worked through [Validating Audience Targeted Release Views](doc:validating-audience-targeted-release-views), use that process as your release check and use this guide to focus on the actual reading experience once the page is open. ## Opening the Public Reading Experience for a Specific Audience and Version 1. Start from the documentation page you want to review in Atloria. Open the page record you use to manage the content, then choose the option that opens the **public preview** or the published public page. This is the safest way to move from authoring into the reader-facing view without guessing the correct public link. [SCREENSHOT: Documentation page with the public preview or published page option highlighted] 2. Once the public view opens, set the **audience** you want to test. If Atloria shows an **audience selector** or audience-specific page controls, switch to the intended audience before reviewing the page. Do this before checking the text, because the same page title or navigation label may lead to different content for different audiences. 3. Next, choose the correct release in the **version selector**. If your team uses version-specific public links, open the page through the version you want to inspect. Confirm that the selected version matches the release you are validating, especially when you are comparing a current release against an older one. 4. Review the visible page elements as a reader would: - **Page title** - **Body content** - **Navigation links** - **Breadcrumbs** - Any audience-limited sections or release-specific notes 5. Compare what you see against the intended audience/version combination. For example, a customer-facing page in one version may include simplified instructions, while another audience or release may show different wording or a different set of linked pages. If the page looks wrong, do not stop at the body text. Check whether the audience or version control changed while loading the page. Also confirm that the navigation menu matches the same audience and version. A correct page body with the wrong navigation still creates a broken reading experience for public visitors. ## Following the Reader Journey to Tailored Content Readers do not always begin on the exact page you are validating. In Atloria, they may enter tailored documentation through a homepage, a navigation menu, a search result, a shared page link, or a version-specific landing page. To review the full reading experience, trace the same routes a public reader would actually use. A common path starts on the public documentation homepage. From there, the reader uses the visible navigation, page cards, or landing sections to open content meant for their audience. When Atloria is set up correctly, those menus and page lists should expose only the pages intended for that audience. If a page should be hidden from one audience, it should not appear as a tempting navigation option in the first place. Shared links are another important entry point. A reader may open a direct public URL to a page without first browsing the site structure. When that happens, check whether the page opens as the correct audience-specific variant, falls back to a general page, or leads to a page that is not available in that version. This matters most when teams reuse the same page name across multiple releases. Version changes are especially important to test. A reader might land on a page in one release and then switch versions using the **version selector**. When they do, Atloria may keep them on the same page path if a matching public page exists in the selected release. If it does not, the reader may see a general public page instead, or the page may no longer be available in navigation. Review both outcomes so you know whether the experience is expected. Look for visible cues that help confirm the reader is in the right place: - **Version labels** - **Audience labels** - **Breadcrumbs** - Matching page titles - Navigation placement within the correct section These cues are often the fastest way to spot a mismatch before you read every paragraph on the page. ## Checking Which Pages Appear for Each Audience To confirm that Atloria is showing the right public structure, review one audience at a time. Open the public site, choose the target audience, and inspect the visible navigation tree, landing sections, and linked page lists. This is often more useful than checking isolated pages because audience mistakes usually show up first in menus and section lists. Start with one section of the public site and compare it across two audiences. For example, open the same documentation area for Audience A and then Audience B. Look for three possible outcomes: - A page appears for both audiences because it is shared - A page is hidden for one audience - A page is replaced by a different audience-specific variant When a page appears unexpectedly, go back to the page’s setup in Atloria and review its audience assignment and publication state. A page may be visible because it is published as a general public page rather than limited to a specific audience. When a page is missing, check whether it was excluded from public navigation, left unpublished for that version, or never assigned to the audience you are testing. Do not stop with the menu. Open the page and inspect its in-page links as well. Cross-links inside the content should lead to pages available to the same audience. If a customer-facing page links to a page that only another audience can access, the public reading experience becomes confusing even if the original page looked correct. A simple comparison table can help during review: | What to check | Audience A | Audience B | What to confirm | |---|---|---|---| | Navigation item | Visible or hidden | Visible or hidden | Matches intended audience access | | Page content | Shared or tailored | Shared or tailored | Correct variant opens | | In-page links | Working links only | Working links only | No links to unavailable pages | [SCREENSHOT: Public documentation navigation compared across two audience selections] ## Comparing Versioned Content Across Audiences Audience review becomes more important when you add versions. In Atloria, a page may be available to the same audience in one release but not in another, or it may keep the same page path while showing different content. Use the **version selector** to review the same page across multiple releases and confirm that each supported version shows the correct audience-specific result. Begin with a page that is known to be tailored by audience. Open it in the current release, then switch to an older release and compare: - **Page title** - **Body content** - **Navigation position** - **Linked pages** - Any release notes or warnings shown on the page Pay special attention to changes in page names or navigation placement between versions. A reader may use a bookmark or a shared link from a previous release, and the page may open differently depending on whether that release still contains an audience-specific variant. If the same page path now points to a general public page in an older version, note that as expected fallback behavior rather than treating it as a publishing error. You should also identify gaps. One audience may have a tailored page in the latest version, while another release only includes the general version or no public page at all. Record those combinations clearly so reviewers and support teams know what readers should expect. Check release-specific messaging carefully. Version warnings, deprecated content notices, and release-only instructions should appear only where they belong. If an older version shows guidance meant for the newest release, or if a customer audience sees internal release notes, the issue is usually easiest to catch by comparing versions side by side. If you need a broader release validation process, pair this review with [Managing Documentation Versions Across the Release Cycle](doc:managing-documentation-versions-across-the-release-cycle) and [Comparing Documentation Versions for Release Decisions](doc:comparing-documentation-versions-for-release-decisions). ## Verifying the Correct Public Pages Before Sharing Them 1. Build a small test matrix before you share public links. List the combinations you need to verify, such as one page across multiple audiences and versions. Then open each public URL or preview link one by one and confirm that the expected page resolves every time. This is the fastest way to catch a page that works for one release but not another. [SCREENSHOT: Reviewer checking the same public page across several audience and version combinations] 2. If the wrong page appears, recheck the basics in Atloria: - The selected **audience** - The selected **version** - The page’s **publication state** - Whether a general public page is appearing instead of a tailored variant 3. If a page is missing, inspect the surrounding structure as well as the page record. Confirm that: - The page is included in public navigation if it should be discoverable - The page is visible for that audience - A published page exists for that audience/version combination 4. Open the same public page in an **incognito** or signed-out browser window. This removes editor-only controls and helps you see the true public reading experience. It also helps you catch cases where your signed-in session makes a page seem available when a public reader would not see it. 5. Repeat the check from more than one entry point. Test the direct link, then reach the same page through navigation or another in-page link. A page that loads correctly from a saved URL may still be hard to find if the public menu is wrong. Before sending links to customers, partners, or internal teams, make sure the page body, version label, and surrounding navigation all agree. In audience-specific publishing, the page itself is only part of the experience. ## Overview This guide focuses on how to review the **public reading experience** in Atloria when documentation changes by **audience** and **version**. The goal is not to edit content, but to confirm that public readers reach the correct page, see the correct navigation, and stay within the right documentation path after they arrive. You will use this review when: - A page has audience-specific variants - A release includes different public content by version - You need to confirm what an external reader sees before sharing a link - A page appears correct in editing screens but may behave differently in public view The most important idea is that public pages should be checked as a reader would experience them. That means opening the **public preview** or published page, selecting the intended **audience**, switching the **version** when needed, and reviewing the visible result. A page can look correct in the documentation workspace while still leading readers to the wrong navigation path, the wrong version, or a fallback page. This guide also helps you spot problems that are easy to miss in page-by-page editing: - Hidden pages that still appear in public navigation - Shared links that open a general page instead of a tailored variant - Version switches that change the page unexpectedly - Cross-links that send readers to pages unavailable to their audience If you need help with setup decisions before this validation step, refer to [Planning Audience Specific Documentation Experiences](doc:planning-audience-specific-documentation-experiences). If you need to confirm release targeting before checking the reading flow, use [Validating Audience Targeted Release Views](doc:validating-audience-targeted-release-views). ## Prerequisites Before you review audience-specific reading experiences in Atloria, make sure the basic publishing pieces are already in place. This guide assumes you are checking an existing public documentation setup rather than creating one from scratch. You should have: - Access to the relevant project in Atloria - At least one documentation page that is already available in **public preview** or published view - More than one **audience** defined if you plan to compare tailored experiences - At least one **documentation version** available if you plan to test release-specific behavior - Permission to review project content and public-facing pages It also helps if you already know: - Which pages are meant to be shared across all audiences - Which pages should be hidden or replaced for specific audiences - Which versions are currently supported for public readers - Whether your team expects a general public page to appear when a tailored variant is unavailable For the smoothest review, prepare a short list of pages and combinations to test before you begin. Include: - A shared page - An audience-specific page - A page that changed between versions - A page reached through navigation - A page reached through a direct shared link If you have not yet reviewed how audiences are defined or how public audience pages are organized, read [Defining Audiences for Targeted Documentation](doc:defining-audiences-for-targeted-documentation) and [Reviewing Audience Specific Pages in Public Documentation](doc:reviewing-audience-specific-pages-in-public-documentation) first. Those guides cover the setup decisions that this reading-experience review depends on.