Docs site vs knowledge base vs wiki: which one you need

The words are used interchangeably in marketing, which is why teams end up with the wrong shape. The distinction that predicts everything is not what the content looks like — it is who reads it and who is allowed to change it.

Notice that the failure modes are different. That is the most useful column, because it tells you what the tool has to protect you from.

Written for people outside your company: getting started, guides, reference, how to do the thing your product does. It is part of the product surface, and often the first thing a prospective customer reads properly.

What it needs

• A publish step. A half-written paragraph must not be public because someone saved.
• Its own domain, because it is your product speaking, not a workspace URL.
• Full-text search, because readers arrive from a search engine at a random page.
• Versioning and a way back, because it is public and wrong is expensive.
• To load fast on a bad connection for someone who is already frustrated.

What kills it

Going stale. A docs site that describes last year’s product is worse than none, because it costs a reader the time to follow instructions that cannot work. Almost every dead docs site died of friction in the publishing path rather than of a decision to stop.

Written to answer a question someone already has. Either a support agent looking for the canonical answer while a customer waits, or a customer trying to solve it themselves before opening a ticket.

What it needs

• Search that works on the words a frustrated person would type, not the words you would.
• Short, single-question articles. A knowledge base article that requires reading is failing.
• A clear owner per article, and a review date, so accuracy has a name attached.
• A path from a support ticket into a new article, or it stops growing.

What kills it

Duplication. Three articles half-answer the same question, each slightly wrong in a different way, and nobody knows which is canonical — so agents stop searching and ask in Slack instead, and the knowledge base becomes an archive.

Written by the team for the team. Meeting notes, decisions, runbooks, onboarding, the architecture rationale someone typed up at 11pm. Its value is that adding to it is nearly free.

What it needs

• The lowest possible cost to write. Any ceremony and it does not get written at all.
• Permissions, because some of it is genuinely internal.
• Links between pages, since a wiki’s structure is its link graph rather than a tree.
• A tolerance for mess. Tidying is not the goal; capture is.

What kills it

Nobody trusting it. Once a reader has been burned twice by an outdated page they check with a person instead, and from then on the wiki is a place things go rather than a place people look.

A wiki is the one where "anyone can edit, instantly, no publish step" is a feature rather than a flaw. That is exactly why using a wiki tool for a public docs site goes wrong: the property that makes it good internally is the property you do not want facing customers.

A wiki used as a public docs site

The common one, because the team already has the wiki and publishing a page is one toggle. It works until it does not: editing is publishing, so there is no draft; there is no build to roll back to; search is built for members rather than for strangers; the address belongs to the tool; and the bill grows with headcount rather than with how many docs you run.

If this is where you are, the Notion comparison works through the specifics — it is the tool most often pressed into this job.

A docs site used as a wiki

Less common and less harmful, but real. Meeting notes and half-formed decisions go through a curated publishing flow, everyone finds it heavy, and people stop writing things down. Capture wants to be cheap.

A knowledge base used as documentation

A pile of short articles with no reading order. Each answers a question, none teaches the product, and a new user has nowhere to start. Search finds the article; nothing tells them what they needed to know before it.

The realistic answer for a company past about ten people is a public docs site and an internal wiki, with the knowledge base arriving later if support volume justifies it.

• Public docs site — the product, for customers, with a publish step and its own domain.
• Internal wiki — the team, for everything else, optimised for writing quickly.
• Knowledge base — added when the same support question has been answered by hand for the third time.

That split is not a failure to consolidate. The two have opposite requirements: one needs a gate between writing and publishing, and the other needs no gate at all. One tool that does both does one of them badly.