## Confirming you can review the correct public audience pages
Before you start checking pages, make sure you are looking at the same public documentation experience your readers will see. In Atloria, that usually means opening the public documentation site in its preview or published view rather than staying inside the editing workspace. If you are still deciding which pages belong to each audience, review your plan first in [Planning Audience Specific Documentation Experiences](doc:planning-audience-specific-documentation-experiences) and compare it with the public page structure you already reviewed in [Reviewing Audience Specific Pages in Public Documentation](doc:reviewing-audience-specific-pages-in-public-documentation).

Look for the visible cues that tell you which audience view you are reviewing. Depending on how your documentation is organized, this may be an audience selector, a dedicated audience landing page, or a navigation section that groups pages for a specific reader type. Stay in one audience view at a time so you do not mix pages from different reader journeys.

You should also confirm the release context before checking anything else. Use the version switcher, release label, or any version name shown in the page header to make sure you are reviewing the intended release. If the page URL includes a version segment, compare that with the release you expect to launch.

Next, prepare a simple page checklist from what is already visible in the public navigation:

- Top navigation items
- Sidebar sections
- Audience landing pages
- Child pages under each section
- Any related pages linked from the main audience entry point

This gives you a clear list of what should be publicly available. As you review, compare each visible page in the menu or sidebar against that expected list so you can quickly spot missing pages, extra pages, or pages showing up under the wrong audience.

[SCREENSHOT: public documentation page showing audience selector, sidebar, and visible version label]

## Checking navigation paths for each audience
Once you have the correct audience and version selected, walk through the public navigation exactly as a reader would. Start from the audience landing page or the main public home page, then open the navigation menu and sidebar. Your goal is to confirm that each audience page appears in the right place and leads to the correct destination.

1. Open the audience’s main section in the public navigation. Check that the expected pages appear under the correct heading and in the right order. If a page belongs under a parent section, make sure it is nested there instead of appearing as a top-level item.
2. Select each page link one by one. On every page, compare the page title with the navigation label you clicked. If Atloria shows a breadcrumb trail, confirm it matches the path you expected through the site structure.
3. Watch the page URL as each page opens. The URL should match the intended audience page and stay within the correct public documentation area. If the URL changes to an unexpected section, you may be opening the wrong page or the wrong version.
4. Check movement between related pages. Use previous and next links, related content blocks, and links inside the page body to make sure readers can continue through the audience journey without getting stuck.
5. Repeat the same review for every audience section included in the release.

Pay close attention to nested content. A child page may technically open, but still be misplaced in the sidebar or grouped under the wrong parent. That creates confusion for readers even when the page itself is published correctly.

Helpful signs to verify on each page:

- Navigation label
- Page title
- Breadcrumb path
- URL
- Previous/next navigation
- Related content links

[SCREENSHOT: public page with sidebar navigation, breadcrumb trail, and page title highlighted]

## Verifying page availability and public access
After navigation looks correct, test whether each page is truly available to public readers. A page can appear in the menu but still fail when opened directly, especially if it was not fully published or if linked files are not available outside internal workspaces.

1. Open each target page from the public navigation and confirm it loads normally without a sign-in screen, restricted-access message, or internal-only prompt.
2. Copy the page URL and open it directly in a fresh browser tab. This helps you confirm the page works as a public destination, not only as a page you reached while already browsing.
3. Check that the page shows the published content rather than a missing-page message, unpublished notice, or empty placeholder.
4. Test pages that should stay private by trying their direct links if you have them. They should not appear in public navigation, and they should not open as public pages in the release you are reviewing.
5. Open linked assets on the page, including screenshots, downloadable files, and embedded media. Make sure they load for a public reader and are not broken or blocked.

If you want a cleaner access check, open the public page in a browser window where you are not signed in to Atloria. That helps you catch cases where your own account access hides a publishing problem.

Look for these warning signs during the check:

- A sign-in page appears
- The page shows a 404 or missing-page message
- A draft or unpublished notice is visible
- Images do not load
- Download links fail
- Embedded media areas appear blank

When you find a problem, note the exact page title and URL so the publishing or content team can correct the right page quickly.

[SCREENSHOT: public page opened directly by URL with visible published content and working image]

## Reviewing version context and release accuracy
A public page can look correct and still belong to the wrong release. Before launch, verify that every audience page is shown in the intended version context and that readers will not be pushed into older or future documentation by mistake.

1. On each page, look for the version switcher, release badge, or version label in the header. Confirm it matches the release you are preparing to launch.
2. Open the same page in another available version, if Atloria shows one. Compare the content to make sure audience-specific changes appear only in the release where they were meant to go live.
3. Check the page URL for version-related wording or structure that helps identify the release. The URL should match the version you selected in the page header.
4. Follow links from the page to nearby content. Make sure those links stay inside the same release instead of sending readers to an older version or a future branch.
5. If a page is likely to be shared externally, open it from its direct URL again and confirm it lands in the correct release view without forcing readers to switch versions manually.

This review is especially important when a page exists in more than one release. A reader may arrive from search, a shared link, or a bookmarked page. If the visible version label and the page content do not match, they may read outdated instructions without realizing it.

Check for consistency between these visible elements:

| What to check | What should match |
|---|---|
| Version switcher | The release you are reviewing |
| Release label or badge | The same release name shown elsewhere on the page |
| URL | The expected version context |
| Cross-page links | Other pages in the same release |
| Shared direct link | Opens the intended public version |

If you spot unreleased content in an older version, or outdated content in the launch version, stop and correct that before sharing the public site.

## Inspecting the reader-facing presentation before release
Once access and versioning are confirmed, review the page as a reader would. This is where you catch issues that make a page feel unfinished even though it technically works. Focus on what is visible on the page: header details, content formatting, labels, and how the page behaves on different screen sizes.

1. Start at the top of the page. Check the title, summary text, and any audience label or callout shown near the header. These should clearly tell readers what the page is for and who it is meant to help.
2. Scan the body content from top to bottom. Look at headings, lists, tables, callout boxes, and screenshots. Make sure spacing is consistent and the page is easy to read without awkward breaks or crowded sections.
3. Watch for internal-only content that should never appear publicly. Remove or flag anything that looks like an editorial note, draft wording, review comment, placeholder text, or unfinished instruction.
4. Open the page on a smaller screen or narrow browser window. Confirm the navigation menu still works, the content width remains readable, and images or embedded media do not overflow the page.
5. Test any visible buttons or links inside callouts and content blocks to make sure they still fit the public reading flow.

Common presentation issues include mismatched headings, missing summaries, oversized tables, screenshots that do not scale well, and notes that were meant only for internal review. These are easy to miss when you focus only on publishing status.

Use this quick visual review list:

- Page title is clear
- Summary text matches the page topic
- Audience label is correct if shown
- Headings are in logical order
- Tables and lists are readable
- Callouts look complete
- No draft badges or internal comments are visible
- Desktop and mobile layouts both work

[SCREENSHOT: published documentation page on desktop with title, summary, callout, and formatted content blocks]

## Fixing common issues found during launch review
Most launch-review problems fall into a few repeat patterns. When you find one, use the visible page structure in Atloria to narrow down the cause before you publish again. Focus on the page’s audience placement, version selection, and public visibility rather than rechecking everything at once.

1. If a navigation item is missing or appears in the wrong section, return to the page’s audience setup and navigation placement. Confirm the page is assigned to the correct audience, grouped under the right parent section, and ordered correctly in the public sidebar or menu.
2. If a page opens in the wrong release, check the selected version in the version switcher first. Then review whether the page is actually included in the release you are launching. A page may exist publicly but still be tied to another version.
3. If public pages show draft wording or internal notes, open the published page and compare it with the latest approved content. Remove editorial comments, unfinished callouts, and placeholder text, then confirm the public view reflects the approved version.
4. If links or assets fail, test them again without relying on your signed-in session. Broken screenshots, files, or media usually become obvious when you open the page as a public reader.

A simple issue log can help you move faster during final review:

| Issue found | What to check in Atloria |
|---|---|
| Page missing from navigation | Audience assignment, parent section, page order |
| Page in wrong section | Navigation grouping and audience placement |
| Wrong release shown | Version switcher and release selection |
| Draft content visible | Published content and final approved page |
| Broken image or file | Public asset availability and direct link behavior |

If several issues appear across the same audience path, recheck the full audience journey from the landing page instead of fixing pages one at a time. That usually reveals a shared setup problem more quickly.

## Overview
This review is the final public-facing check for audience pages before launch. In Atloria, you are not editing content here—you are validating what readers will actually experience on the public documentation site. That means checking the audience path, confirming the correct release is visible, opening pages directly by URL, and making sure the published presentation looks complete.

This guide focuses on launch review for public audience pages only. It assumes you have already planned the audience experience and already know how to read audience-tailored content in the public site. If you need to revisit that earlier reading flow, see [Reading Audience Tailored Documentation](doc:reading-audience-tailored-documentation).

During this review, you should confirm four things:

- The right audience pages are included in the release
- Readers can reach them through public navigation
- Each page opens publicly in the correct version
- The published page looks clean and ready for external readers

This is not the same as a full content rewrite or a project setup task. You are checking the live or preview reading experience from the outside. The most useful mindset is to behave like a first-time reader: use the menu, follow links, switch versions, and open pages directly.

A strong launch review in Atloria helps you catch issues such as:

- Missing audience pages
- Incorrect page grouping
- Wrong-version links
- Unpublished assets
- Draft notes left on public pages
- Mobile layout problems

If you work through each section in order, you will have a reliable final check before making audience-specific documentation broadly available.

## Prerequisites
Before you begin this launch review in Atloria, make sure you have enough context to recognize what should be public and what should stay hidden. You do not need deep administrative knowledge, but you do need access to the public documentation experience you are reviewing and a clear idea of the release scope.

Have these items ready:

- Access to the public documentation site in preview or published form
- The audience or audiences included in the upcoming release
- The expected page list for each audience, based on the public navigation or launch plan
- The release or version name you are supposed to validate
- At least one way to test pages as a public reader, such as opening links directly in a separate browser tab or unsigned session

It also helps if you are already familiar with:

- Public navigation in Atloria
- Audience-specific page groupings
- The visible version switcher or release label
- How published pages differ from internal editing views

If you have not yet reviewed how audience content is structured in public documentation, read [Viewing Public Documentation by Audience](doc:viewing-public-documentation-by-audience) and [Reviewing Audience Specific Pages in Public Documentation](doc:reviewing-audience-specific-pages-in-public-documentation) before continuing.

You may also want a simple review list while you work, such as:

- Audience name
- Page title
- Expected navigation location
- Direct URL result
- Version shown
- Issues found

After you finish this launch review, continue with [Reading Audience Specific Documentation Views](doc:reading-audience-specific-documentation-views) to examine how readers move through audience-focused documentation after publication.