This guide takes a documentation project from a working draft to a polished, production-ready site. It is intended for teams that already have content in place a...
This guide takes a documentation project from a working draft to a polished, production-ready site. It is intended for teams that already have content in place a...
This guide takes a documentation project from a working draft to a polished, production-ready site. It is intended for teams that already have content in place and now need the site to look intentional, work cleanly for readers, and be ready for launch.
Who this is for
- teams preparing a first public documentation launch
- teams moving from a raw internal docs build to a polished customer-facing site
- teams rebranding an existing docs property
What this guide covers
You will configure:
- Branding
- Published layout
- Footer builder
- Reader Experience
- SEO & Social
- Custom Domains
- Publishing Controls
Step 1 — Set the project identity
Open Project settings and start with General and Branding.
In General, review:
- Project name
- Project slug
- Description
- Project icon
- Favicon
In Branding, review the visual identity choices that will shape the published shell.
Step 2 — Choose the published layout
In Site Layout, set Published layout to the experience that matches your documentation model:
- Documentation (sidebar) for structured docs with a classic navigation system
- Help Center (categories) for a support-oriented article experience
Use Documentation (sidebar) when readers should move through top-level sections and nested pages. Use Help Center (categories) when the site is primarily a support destination with category-led discovery.
Step 3 — Configure the reader chrome
In Reader Experience, review the controls that shape how the published shell behaves:
- Prev/next navigation
- Language switch placement
- Top-nav branding
- Support CTA label
- Support CTA URL
Recommended defaults for a first launch:
- turn on Prev/next navigation
- use Header or Both for Language switch placement if more than one locale is enabled
- use Project branding for Top-nav branding unless your workspace brand should anchor every project
- set a clear support action only if the destination is already ready for readers
Step 4 — Build the footer
Open Footer builder and create a footer that feels like part of the product rather than a generic docs afterthought.
Use the footer to reinforce:
- company identity
- navigation to support or legal pages
- trust signals
- cross-links to key destinations
As you configure the footer, use the preview behavior in the builder to check:
- spacing and readability
- whether link groups are logically named
- whether the footer duplicates too much of the top navigation
- whether the content looks complete on mobile as well as desktop
Step 5 — Set the canonical and indexing posture
Open Publishing Controls and SEO & Social next. These sections define how your site behaves for search engines and shared links.
In Publishing Controls, review:
- Canonical URL
- Robots rule
- Sitemap generation
- Indexing policy
- Unpublished page handling
In SEO & Social, review:
- Meta title template
- Fallback meta description
- OG image
- Locale alternates
- Search engine hints
Recommended launch posture for a public site:
- set the correct Canonical URL
- keep Sitemap generation on
- use an indexing posture that matches production, not staging
- verify that Fallback meta description is reader-facing and accurate
- set a valid OG image before you share launch links
Step 6 — Connect the domain
Open Custom Domains and connect the production hostname for the site.
Enter the desired documentation domain in Custom Domains.
Doxbrix provides the records you need to create in your DNS provider.
After the DNS change propagates, return to Doxbrix and verify the domain.
Make sure the site is served securely before public launch.
If the site is already accessible on a temporary domain, test both domains before the final switch so you understand how canonical behavior and share previews will resolve.
Step 7 — Validate the reader experience as a reader
Before launch, inspect the site as if you were a first-time visitor.
Check:
- the home page and first visible navigation
- top navigation clarity
- sidebar readability
- footer usefulness
- preview cards and shared-link appearance
- language switching, if enabled
- support CTA behavior
- private or public access behavior
Run this check in a clean browser session so cached admin state does not hide real reader issues.
Step 8 — Publish intentionally
Once branding, layout, domain, and publishing controls are ready:
- review the pages or sections that are about to go live
- verify that critical drafts are no longer incomplete
- publish the required pages or sections
- open the live site and verify it on the final domain
Launch checklist
- project identity is complete
- branding is intentional and consistent
- published layout matches the reader journey
- footer is useful and polished
- SEO and social defaults are configured
- domain is connected and verified
- publishing controls match production intent
- reader access is correct
- launch content has been reviewed