## Opening the right document view before you review output When you review a page in **Atloria**, start by opening the output view that matches the decision you need to make. If you are checking how the page reads inside your working session, use **Preview**. This is the best place to confirm rendered headings, paragraph flow, lists, tables, screenshots, and linked content without leaving your editing workspace. If you need to see what readers will get outside the editor, use **View as Published** or **Open Public Page** when those actions are available from the document screen. Choose the view carefully because each one answers a different question: - **Preview** helps you review the current page rendering while you are still working. - **View as Published** helps you check the page in its published presentation rather than the editing context. - **Open Public Page** helps you confirm what a public visitor will actually see. Before you trust what is on screen, confirm the page is in the right state for review. Look for signs that you are still viewing draft work, unpublished edits, or older page details. If you recently changed the title, page description, slug, audience settings, or navigation placement, make sure those updates are reflected in the view you opened. A preview may show current edits, while a public page may still show the last released version. It is also important to confirm you are checking the correct **version**, **locale**, or other page variant if your project uses them. A page can look correct in one release and still be wrong in another. Open the document from the intended project workspace, verify the selected version, and only then begin your page check. [SCREENSHOT: Document page with Preview, View as Published, and Open Public Page actions highlighted] ## Reviewing how the document page is presented Once the rendered page is open, review it as a reader would. Start at the top of the page and confirm the **page title** and the main visible heading match the document you intended to publish. If the page shows a short description or other visible page details, check that they are current and written for readers rather than for internal review. Then scan the body content for presentation issues. In Atloria, the previewed page should make the structure obvious at a glance. Look for: - **Heading hierarchy** that moves in a clear order - **Paragraph spacing** that makes sections easy to read - **Bullet lists** and **tables** that align properly - **Callouts** that stand out without breaking the page flow - **Code blocks** or technical examples that remain readable in the rendered view Do not rely only on the editor appearance. A section that looks fine while editing can still render awkwardly in preview, especially around long tables, nested lists, or wide content blocks. Next, check every embedded asset that appears on the page. Images should load fully, stay aligned with the surrounding text, and display any captions exactly where expected. If the page includes attachments or linked media, open them from the rendered page instead of assuming they work because they were inserted successfully. If your team also shares printable or exported output, compare that output with the in-app preview. A page can look correct in the browser and still break in print or PDF-style output because of page width, spacing, or image scaling. Focus on visible differences that affect readability, not minor cosmetic changes. [SCREENSHOT: Rendered document preview showing title, headings, image placement, and table formatting] ## Checking navigation context around the document A page is not ready just because its content looks good on its own. In Atloria, you also need to confirm the page appears in the right place within the surrounding documentation. Open the rendered page and check the navigation elements around it, starting with any **breadcrumb trail**, **section label**, or visible parent page reference. These cues tell readers where they are, and they quickly reveal whether the page has been placed in the wrong section. Pay close attention to the page’s position in the sidebar or section navigation. The current page should be highlighted in the expected area, and nearby pages should make sense in that sequence. If the page belongs under a parent topic, the preview should reflect that relationship clearly. If the breadcrumb or sidebar points to the wrong section, the issue is usually with page placement rather than page content. From the rendered page, test the navigation elements readers are likely to use: - **Table of contents** links - **Anchor links** within the page - **Previous** and **Next** links - **Sidebar** navigation states - Links to related pages or category pages Follow each one from the previewed or public-facing page, not from the editor. This helps you confirm that cross-references resolve to the intended destination and that the reader journey makes sense. If your preview exposes broader discovery surfaces, also check whether the page can be found from those entry points. That may include a section landing page, topic index, or search result snippet. You do not need to repeat the comparison workflow covered in [Managing Document Comparisons During Content Updates](doc:managing-document-comparisons-during-content-updates), but you should confirm that the final page sits correctly inside the documentation structure readers will browse. [SCREENSHOT: Public or preview page showing breadcrumb, sidebar highlight, and table of contents links] ## Validating what public visitors will actually see After checking the internal preview, open the page’s public-facing version and compare it with what you just reviewed. In Atloria, this is the most important readiness check before release because the public page may differ from the internal preview. Use **Open Public Page** or **View as Published** from the document screen when available, then inspect the page without relying on editor cues. Look for differences caused by publication state or visibility rules. A preview may include working details that should never appear to readers. On the public page, confirm that items such as these are not visible: - **Draft** markers - Internal notes or review-only text - Editing controls - Unpublished navigation items - Any workspace-only context that belongs to writers, not readers Next, review the public page details that affect release quality. Confirm the page is using the correct **slug** or public path, and check that the visible page description and title are the ones you intend to share. If Atloria shows any status label or environment banner, decide whether it is expected for your current review setting or whether it signals that you are not looking at the final public experience. It is also worth checking the page as a visitor rather than as an editor whenever possible. If you stay inside an authenticated session, Atloria may show navigation or access that a public reader would not have. Open the public page in a clean browser session or another window where editor context does not affect the result. The page should load correctly, display its assets, and allow normal reading without depending on workspace navigation. [SCREENSHOT: Public page view compared with internal preview, showing reader-facing content only] ## Comparing preview output with release expectations A reliable release check in Atloria compares the same page across all views you use before publication. Instead of reviewing each view in isolation, keep a simple comparison list and use it every time you verify a document revision. This helps writers and documentation managers agree on what must match before a page is considered ready. Your comparison should include the three most common outputs: - **Internal preview** - **Published-style view** - **Public page** For each of those views, confirm the same core elements: - **Title** - Main **headings** - **Body content** order and formatting - **Links** and cross-references - **Images** and other media - **Navigation placement** - Visible **page description** or related metadata When you compare views, treat some differences as acceptable and others as release blockers. For example, it is normal for the internal preview to include editor context that the public page does not show. A staging banner or temporary review label may also be acceptable during internal checks. What should not differ is the reader-facing content itself. If the public page shows an older title, missing image, wrong navigation placement, or broken internal link, the page is not ready. Define sign-off around visible outcomes, not assumptions. A writer can usually sign off on page presentation, while a documentation manager may also confirm navigation context and public readiness. Keep the sign-off focused on what readers will experience: - The page looks correct - The page appears in the right section - The public view matches release expectations - No internal-only content is exposed This kind of comparison makes final review faster and reduces last-minute publishing surprises. ## Fixing common issues found during preview and public page checks When preview and public output do not match, start with the most visible causes. In Atloria, the first thing to verify is the page’s **publication state**. You may be looking at current draft edits in **Preview** while the public page still shows the last released version. Also confirm that you opened the correct **version** and any intended locale or page variant. If the content still looks outdated, refresh the page and reopen the public view to rule out a stale browser view. If the page appears in the wrong section, focus on its placement in the documentation structure. Check the page’s **parent page**, section assignment, and sidebar placement from the document organization controls. A wrong breadcrumb, missing sidebar highlight, or incorrect previous/next sequence usually points to a structure issue rather than a formatting issue. Formatting problems are easiest to catch in rendered output. If a table breaks, a list nests incorrectly, or an image pushes the layout out of place, return to the page content and inspect the affected block closely. Common trouble spots include: - Very wide tables - Oversized images - Mixed formatting pasted from another source - Content blocks that render differently in preview and published views For public pages that are missing content or fail to load correctly, check whether the page is actually available to public readers. A page may still be hidden because of visibility settings, or it may link to assets and related pages that have not been made available yet. If images, attachments, or linked pages are incomplete on the public side, review each one from the public page itself rather than from the editor. When you fix an issue, repeat the same check in **Preview**, **View as Published**, and the **Public Page** so you know the correction is visible everywhere it needs to be. ## Overview This guide focuses on the final visual and navigational checks you should make before releasing a documentation page in **Atloria**. The goal is not to rewrite content or repeat editing tasks. Instead, you use the rendered page views to confirm that readers will see the right title, formatting, navigation context, and public-facing details. The review in this guide centers on four practical checks: - Opening the correct output view for the page you are reviewing - Confirming the page presentation in rendered form - Verifying the page sits in the correct navigation context - Checking the actual public-facing result before release These checks matter because a page can be correct in the editor and still be wrong in the published experience. For example, the content may render differently, the page may appear under the wrong section, or the public page may still show an older version. Atloria gives you separate views such as **Preview** and **Open Public Page** so you can catch those differences before readers do. This guide also helps you separate expected differences from real problems. Internal preview views may include editor context, while public pages should show only reader-facing content. Knowing which differences are normal makes it easier to decide whether a page is ready. If you need help reviewing changes between document revisions before doing these final checks, use [Managing Document Comparisons During Content Updates](doc:managing-document-comparisons-during-content-updates). That comparison work comes before the preview and public validation covered here. ## Prerequisites Before you start these checks in **Atloria**, make sure you already have a page that is far enough along to review in rendered form. This guide assumes you are no longer drafting basic content and are instead verifying how the page appears to readers. You should already have: - Access to the relevant **project workspace** - A document page that has been created and edited - Content saved in the page you want to review - Permission to open preview and published-style views for that page It also helps if the page already has its key publishing details in place, such as its title, location in the documentation structure, and any linked images or related pages. Without those pieces, the preview check will be incomplete because you will not be able to judge navigation placement or public readiness accurately. For the smoothest review, be ready to access more than one view of the same page: - The in-workspace **Preview** - A published-style view such as **View as Published** - The **Public Page**, if the page is already exposed for reader access If your team works with multiple versions or localized content, confirm in advance which version or locale you are supposed to review. Many preview issues are simply the result of checking the wrong output. You will get the most value from this guide if you have already completed the earlier authoring tasks in [Creating and Editing Documentation Pages](doc:creating-and-editing-documentation-pages) and [Organizing and Reviewing Document Content](doc:organizing-and-reviewing-document-content). After you finish the checks in this guide, continue with [Managing Document Previews Comparisons and Quality Checks](doc:managing-document-previews-comparisons-and-quality-checks).