How reader sites are hosted

Every Doxbrix project is a documentation site that Doxbrix hosts for you. This page explains the addresses readers can reach your site at, how the site slug in those addresses is chosen, and how Doxbrix tells search engines what to index. Read it before you share a link, choose a slug, or connect a custom domain.

Three ways to reach one site

A single project can answer on up to three kinds of address. All of them serve the same published pages, with the same access rules.

Page addresses add the page slug to the site root, for example pocketbase.doxbrix.app/quickstart. Pages in a language other than the project's default language add a locale segment, such as /fr/quickstart, and non-default documentation versions add a version segment. See Publish docs in multiple languages and Version your product documentation.

How a request reaches your pages

When a reader opens any of these addresses, Doxbrix identifies the project from the host name or path and then serves it according to the project type.

• Resolve project. Doxbrix reads the first label of the host name (the slug in {slug}.doxbrix.app), the custom domain, or the workspace and project slugs in the path, and finds the matching project. An unknown slug returns Not found.
• Access check. A private project, or one that uses reader access, requires the reader to sign in before any page is served. Readers without access see a sign-in page or the message This documentation is private. See Make a site private.
• Native projects are sites you author in the Doxbrix editor. Doxbrix renders their published pages on request, so a page appears as soon as you publish it. Drafts never appear. See Publish and edit published pages.
• Connected projects are existing docs-as-code sites that Doxbrix builds from your repository. Doxbrix serves the files of the latest successful build. Until the first build finishes, readers see This documentation site has not been built yet. See Host an existing docs site.

Sign-in pages for readers, such as /reader-login, always render on the address the reader used, so the reader's session is kept on your own domain or subdomain.

Site slugs

The hosted slug is the label in front of the hosting domain. Doxbrix suggests one from your project name, and you can check whether a slug is free when you create a project.

A valid slug:

• is 2 to 40 characters long;
• uses only lowercase letters a–z, digits 0–9 and hyphens;
• starts and ends with a letter or digit, never a hyphen;
• is not already used by another project.

When Doxbrix suggests a slug from a name, it lowercases the name, replaces every run of other characters with a single hyphen, trims hyphens from the ends and shortens the result to 40 characters. For example, PocketBase Documentation! becomes pocketbase-documentation. A name with no usable characters falls back to docs.

Reserved slugs

These labels collide with Doxbrix infrastructure hosts and are never available as a site slug:

app, www, api, admin, console, assets, static, cdn, mail, status

Robots and sitemaps

Doxbrix generates search-engine discovery files for each native site from its current settings. You never upload them yourself.

• robots.txt at the site root contains Allow: / for an indexable site and Disallow: / for a site that must not be indexed. When the site is indexable and sitemap generation is on, it also points crawlers to the sitemap with a Sitemap: line.
• sitemap.xml at the site root lists the address and last-modified date of every published page. Drafts, pages in review and unpublished pages are never listed.

A site is treated as not indexable, with an empty sitemap and Disallow: /, when any of these is true:

• the project is not public, for example a private site;
• Robots rule is set to Noindex entire site;
• Indexing policy is set to Discourage indexing.

Turning off Sitemap generation leaves the site indexable but removes the Sitemap: line and empties the sitemap. Preview pages are always marked as not indexable.

Which address appears in the sitemap

Doxbrix lists one address per page, chosen in this order:

1. The Canonical URL from publishing controls, when set. For example, with https://docs.example.com a page appears as https://docs.example.com/quickstart.
2. Otherwise, the hosted subdomain, such as https://pocketbase.doxbrix.app/quickstart.
3. Otherwise, the workspace path on the Doxbrix app.

Set the canonical URL to your custom domain after you connect it, so search engines credit one address instead of splitting results across several. See Configure publishing controls and SEO indexing.

Tradeoffs to consider

• Hosted subdomain or custom domain. The hosted subdomain works immediately with no DNS changes. A custom domain keeps readers on your brand and survives slug changes, but needs DNS records and a plan that includes custom domains.
• Subdomain or subpath on your domain. A subdomain such as docs.example.com needs only DNS records. A subpath such as example.com/docs keeps docs under your main site but requires you to run a reverse proxy.
• Indexing during launch. Use Noindex entire site or Discourage indexing while you prepare content, then switch to Index everything when you are ready for search traffic.

Related pages