Managing Project Content Structure and Navigation

Reviewing Your Project's Page Hierarchy

Before you reorganize anything in Atloria, open your project workspace and use the left navigation area to review the current page structure. Focus on how pages are grouped today, not just on the content inside each page. In the page tree, look for top-level pages that act as major sections, then check which pages appear nested underneath them. Indentation is your quickest clue: pages aligned to the far left are usually broader sections, while indented pages belong under a parent topic.

As you scan the list, compare page titles side by side. Similar names often reveal overlap, such as two setup pages that cover nearly the same task or a workflow page that was added under the wrong section. Open a few pages and check the title and slug together so you can spot naming mismatches early. If a page title says one thing but the slug suggests another, readers may have trouble understanding where that page belongs in the structure.

It also helps to identify pages that feel disconnected from the rest of the documentation. Draft pages, temporary pages, or pages sitting outside the expected topic branches are often the first signs that the hierarchy needs cleanup. If you recently worked through release status and page readiness in Managing Project Content from Drafts to Published Pages, use that same status awareness here while reviewing the tree.

As you review, ask one practical question for every branch: “Would a reader know where to click next?” If the answer is unclear, note the section for reorganization.

Organizing Pages into Clear Parent and Child Groups

Once you understand the current layout, start grouping pages into clear parent and child sections. In Atloria, a parent page should represent a broad topic that helps readers orient themselves quickly. Good parent pages are usually category-style entries such as setup, workflows, integrations, or reference. Child pages should then break that topic into focused tasks or subtopics that readers can scan without opening every page in the section.

1. In your project workspace, select the page that should become the main landing page for a topic area.
2. Review the related pages in the content tree and decide which ones belong under that topic.
3. Move those pages into the correct place using the page tree arrangement tools or the page location option in the page’s settings.
4. Open each moved page and confirm that the page title and slug still match its new position in the hierarchy.
5. Reorder sibling pages so readers see introductory or overview content first, followed by task-based guides and then deeper reference material.

Keep sibling pages consistent. For example, if one child page starts with “Setting Up…,” nearby pages should follow a similar pattern instead of mixing overview titles, question-style titles, and partial phrases. Consistent naming makes the sidebar easier to scan and reduces hesitation when readers are choosing between similar topics.

Also separate overview pages from action pages. A parent page can introduce a topic and explain when to use it, while child pages handle specific tasks. That structure keeps the navigation clean and prevents long, overloaded pages from trying to do everything at once.

Controlling How Pages Appear in Navigation

A strong hierarchy only helps if the navigation is easy to read. In Atloria, review how page titles appear in the sidebar and trim any titles that are too long, repetitive, or hard to distinguish from nearby items. If several pages begin with the same words, readers may need to read the full line every time. Shorter, clearer labels make the navigation faster to use.

1. Open the project’s page list or content tree and read the sidebar labels as a reader would.
2. Shorten titles that wrap awkwardly or look nearly identical to neighboring pages.
3. Check each page’s visibility and publish status before expecting it to appear in reader-facing navigation.
4. Decide whether the page belongs in the main navigation or should be reached only through links from another page.
5. Reorder pages within each section so the sequence matches a real reading path, from basic guidance to advanced detail.

Draft and unpublished pages are especially important here. A page can exist in your workspace without being ready for readers, so keep in-progress work out of the main navigation until the content is complete enough to support the rest of the section. This is useful when you are building a new branch of documentation gradually and do not want readers clicking into unfinished pages.

You should also be selective about what deserves a top-level position. Too many top-level pages make the sidebar feel crowded and flatten the structure. Reserve top-level placement for major sections, then place supporting material underneath them. If a page is useful but too narrow for the main menu, link to it from a parent page or a related guide instead of giving it equal prominence.

Keeping Related Content Discoverable

Even a clean sidebar cannot carry every navigation need on its own. In Atloria, readers often move between overview pages, task guides, and reference material while working through a topic. Add internal links wherever readers are likely to need the next step, a related explanation, or supporting detail. This keeps them moving through the documentation naturally instead of backing out to the project home every time.

1. Open an overview page and identify the task pages readers are most likely to need next.
2. Add links from that overview page to the most relevant child pages or related sections.
3. Review task pages and add links back to the overview page or onward to deeper reference content where appropriate.
4. Check page details such as title, summary, and slug so they use the same wording readers are likely to search for.
5. Find pages that are hard to reach and place them under a clear parent page or connect them through related links.

When you review discoverability, pay attention to terminology. If one page says “setup,” another says “configuration,” and a third says “getting started” for the same concept, search results and navigation labels become less predictable. Choose one naming pattern for each topic area and use it in titles, summaries, and linked text.

This is also the right time to reconnect orphaned content. If a page exists but is not clearly visible in the hierarchy, readers may never find it unless they already have a direct link. Place it under a logical parent or link to it from a nearby page that readers already use. Good structure and good linking work together; one without the other usually leaves gaps.

Auditing the Structure with Your Team

After you reorganize the hierarchy, review it with the people who write, review, and maintain the documentation. In Atloria, structural decisions affect more than navigation—they also affect ownership, review flow, and how quickly teams can find pages to update. A short walkthrough of the page tree can reveal issues that are easy to miss when one person reorganizes content alone.

1. Open the project’s page tree and walk through each major branch with your writers and subject matter experts.
2. Confirm that the order of sections matches how readers actually learn or complete tasks.
3. Review draft, published, and older pages together to decide what should stay visible, be merged, or be removed from navigation.
4. Identify duplicate topics that appear in more than one branch and choose a single page to keep as the main source.
5. Assign clear ownership for each branch so future changes do not pull the structure in different directions.

During this review, ask your team to think from the reader’s perspective rather than from internal team boundaries. A section that makes sense to one department may feel fragmented to readers if related tasks are split across several branches. If two teams contribute to the same topic area, agree on one parent section and one naming style before more pages are added.

Status indicators are useful here as well. A branch filled with draft pages may need to stay hidden until the section is coherent, while a published branch with outdated child pages may need consolidation. If your team already uses review steps and page status decisions from Managing Project Content from Drafts to Published Pages, apply those same habits to structure reviews so navigation changes stay coordinated.

Fixing Common Navigation Problems

Most navigation issues in Atloria come down to four things: placement, visibility, naming, or too much clutter. When a page is missing or hard to find, start by checking the simplest explanation before making larger structural changes.

1. If a page does not appear in navigation, open that page and check its publish status, visibility setting, and current parent page.
2. If readers cannot find a topic in search, review the page title, slug, and summary for inconsistent wording.
3. If the sidebar feels crowded, reduce the number of top-level pages and merge thin pages that do not need to stand alone.
4. If teams keep creating overlapping structures, agree on naming rules and assign one owner to each main branch.
5. After each change, test the navigation again by following the path a reader would take to reach the page.

Use the table below as a quick way to match a problem with the most likely fix:

When you troubleshoot, avoid solving every problem by adding another page. In many cases, the better fix is to rename, merge, reorder, or relink existing content. A smaller, clearer structure usually serves readers better than a larger one with too many choices.

Overview

• In Atloria, content structure starts with the page tree in your project workspace.
• Top-level pages should represent major topic areas, while child pages should handle narrower tasks or subtopics.
• Clear page titles, consistent slugs, and a logical reading order make the sidebar easier to scan.
• Visibility and publish status affect whether pages appear in reader-facing navigation.
• Internal links help readers move between overview pages, task guides, and supporting reference content.
• Team reviews are useful for spotting duplicate topics, misplaced pages, and unclear ownership.
• Common navigation issues are usually fixed by adjusting placement, naming, visibility, or page order rather than creating more pages.

If you need to revisit how page readiness affects what readers can see, refer back to Managing Project Content from Drafts to Published Pages. The next document in this workflow is Collaborating on Document Changes and Page Quality.

Prerequisites

• You should be able to open the correct project workspace in Atloria.
• Your project should already contain multiple documentation pages so you can review and reorganize the hierarchy.
• You should be familiar with creating and editing pages from Creating and Editing Documentation Pages.
• It helps to understand content review and page organization from Organizing and Reviewing Document Content.
• You should already know how draft and published states affect content availability from Managing Project Content from Drafts to Published Pages.
• If your team shares responsibility for documentation branches, confirm who can update page placement, titles, and navigation decisions before making large structural changes.