Choose the right published layout for your docs

Your published layout shapes how readers discover content, how quickly they orient themselves, and what kind of documentation experience your team is creating. In Doxbrix, the key choice is in Site Layout, where you set Published layout.

This guide helps you make that decision deliberately and configure the layout with the rest of the reader experience in mind.

Who this is for

• teams launching a new documentation site
• teams deciding whether their content should behave like structured docs or a support center
• teams reworking an existing site that feels hard to navigate

The two layout options

In Project settings → Site Layout, Published layout gives you two options:

• Documentation (sidebar)
• Help Center (categories)

Both can publish the same underlying content, but they create different reader expectations.

When to choose Documentation (sidebar)

Choose Documentation (sidebar) when readers need to move through a structured body of knowledge.

This layout is usually the right fit for:

• product documentation
• developer documentation
• onboarding guides with sequential steps
• technical reference organized into sections and subsections

It works best when:

• your navigation has clear hierarchy
• readers often move between related pages
• section order matters
• the site should feel like a product manual, not a ticket-deflection center

When to choose Help Center (categories)

Choose Help Center (categories) when readers are usually trying to solve a specific problem quickly.

This layout is usually the right fit for:

• customer support centers
• article libraries organized by topic buckets
• self-service troubleshooting sites
• account, billing, and setup help collections

It works best when:

• readers arrive from search, support links, or product help entry points
• category browsing is more important than deep page hierarchy
• the experience should feel lightweight and support-oriented
• many articles are short and standalone

A practical decision framework

Use these questions to choose the right layout:

How do readers usually arrive?

• If they arrive to browse a body of documentation, prefer Documentation (sidebar).
• If they arrive with a problem already in mind, prefer Help Center (categories).

Does page order matter?

• If readers should move from foundational pages into advanced pages, prefer Documentation (sidebar).
• If each page should stand on its own, Help Center (categories) is often a better fit.

What is the primary outcome?

• If the goal is understanding a product, use Documentation (sidebar).
• If the goal is resolving a question fast, use Help Center (categories).

What kind of navigation do you already have?

• If you have well-defined spaces, sections, and child pages, Documentation (sidebar) will usually present that structure better.
• If your content is flatter and grouped into broad topics, Help Center (categories) may be cleaner.

Step 1 — Review your current content structure

Before changing the layout, review the content itself.

Check:

• how many top-level sections you have
• whether pages are deeply nested or mostly flat
• whether readers need to move across a sequence
• whether articles can be understood without surrounding context

If the structure is unclear, fix the information architecture first. A layout cannot rescue poorly organized content on its own.

Step 2 — Set Published layout

Open Project settings, then go to Site Layout.

Step 3 — Adjust the surrounding reader experience

After setting Published layout, review Reader Experience so the site behavior supports the chosen model.

Pay attention to:

• Prev/next navigation
• Language switch placement
• Top-nav branding
• Support CTA label
• Support CTA URL

Recommended patterns:

• for Documentation (sidebar), keep Prev/next navigation on so readers can move through structured material
• for Help Center (categories), treat the support CTA as part of the support journey, not as an afterthought
• for multi-language sites, choose a Language switch placement that is easy to find without distracting from the article body

Step 4 — Test real reader tasks

Do not judge the layout only by how the home page looks. Test the tasks readers actually need to complete.

For a structured docs site, test whether a reader can:

• start at an overview page
• move into a subsection naturally
• tell where they are in the hierarchy
• move to the next useful page without using search every time

For a help center, test whether a reader can:

• scan categories quickly
• identify the right article group without technical context
• open an article and know what to do next
• escalate to support if the article does not solve the issue

Step 5 — Validate the choice with your content owners

Before you finalize the layout, review it with the people who understand the audience best.

Ask:

• does this layout reflect how customers ask questions?
• does it support the way internal teams link to documentation?
• will future content fit naturally into this structure?
• is the layout making the docs simpler, or just visually different?

Recommended defaults

For product and developer docs

• Published layout: Documentation (sidebar)
• Prev/next navigation: On
• Top-nav branding: Project branding

For customer support content

• Published layout: Help Center (categories)
• support CTA: configured and visible
• category names: written in customer language, not internal team language

Signs you chose the wrong layout

Revisit the decision if you notice these patterns:

• readers rely on search because navigation does not help
• categories feel forced and unclear
• the sidebar is overloaded with standalone support articles
• support articles are buried inside a hierarchy that no one naturally follows
• teams keep debating where new content belongs

Related pages