Multi-Space Docs: One Workspace, Many Published Sites
Knowledge is genuinely multi-tenant — one workspace can run many spaces, each its own docs site with its own navigation, appearance, and optionally its own domain.
A lot of what makes Knowledge's custom-domain support and its /llms.txt behavior work the way they do traces back to one structural decision: Knowledge treats "one docs site" as a unit — a space — rather than assuming your entire workspace publishes exactly one site.
What a space actually is
A knowledge_spaces record is one published docs site: its own URL slug, its own navigation structure, its own appearance settings, and optionally its own custom domain (see the dedicated guide on custom domains for how that claiming process works). Multiple spaces live under one workspace, each independently configured and independently published.
Why the routing is built this way
The public doc route is structured as /docs/[spaceSlug]/... specifically, and that's a deliberate design choice, not an accidental URL shape — the routing logic explicitly resolves either a plain space slug or an @host-prefixed segment when a request comes in through a custom domain instead of the default path. The comment behind this in the codebase is direct about why: Knowledge is genuinely multi-tenant, and the routing has to account for the same space being reachable both through the platform's own domain structure and through a client's or product's own custom domain.
Who this is actually for
If your business publishes exactly one docs site, multi-space support is mostly invisible to you — you'll have one space and never think about the boundary. It becomes directly relevant the moment you're managing documentation for more than one product line, or delivering documentation as part of a service to multiple clients. That's specifically the use case Docsie's 2026 comparison research flags as underserved by GitBook and Notion — consultancies and implementation partners managing docs for multiple clients don't get a first-class multi-tenant primitive from either competitor. Knowledge's space model is that primitive.
Setting up more than one space
Each space is independently configured, so there's no shared navigation or shared appearance to fight with across spaces — a space for Product A's docs and a space for Product B's docs can look and behave completely differently, right down to having entirely separate custom domains. The tradeoff is that content doesn't automatically cross spaces: a snippet or article written in one space isn't visible in another by default, so decide your space boundaries around how you actually want to separate (or share) content before you start writing, rather than consolidating into one space and splitting later.