# Docs site vs knowledge base vs wiki: which one you need Three words used for three different things, and picking the wrong one is how teams end up with a wiki nobody trusts or a docs site nobody updates. Sorted by who reads it and who writes it, because that decides everything else. _Source: https://docszero.com/resources/docs-site-vs-knowledge-base-vs-wiki_ _guide · 6 min read_ _Published 10 September 2026_ > **In short:** A docs site is published to people outside the company and needs a publish step. A knowledge base answers repeat questions and needs search above all. A wiki is a shared workspace and needs to be easy to edit. Pick by audience, not by feature list. ## The actual difference 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. | | Docs site | Knowledge base | Wiki | | --- | --- | --- | --- | | Read by | Customers, users, the public | Support agents, or customers with a problem | The team | | Written by | A few people, deliberately | Support and product, continuously | Anyone | | Organised as | A curated tree, read in order | Articles found by search | Whatever grew | | Optimised for | Being correct and current | Answering one question fast | Being easy to add to | | Publish step | Essential | Useful | Usually none | | Fails by | Going stale | Duplicating articles | Nobody trusting 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. ## A documentation site 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. ## A knowledge base 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. ## A wiki 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. ## What going wrong looks like ### 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](https://docszero.com/compare/notion) 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. ## Most teams need two of the three 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. ## Questions ### What is the difference between a knowledge base and a wiki? A knowledge base is written to answer specific repeat questions and is found by search, usually maintained by support and product with an owner per article. A wiki is a shared workspace anyone on the team can add to, organised by links rather than a tree, and optimised for how cheap it is to write. A knowledge base fails by duplicating articles; a wiki fails when people stop trusting it. ### Can I use Notion as a documentation site? For an internal wiki it is a good fit. For a public docs site the mismatch is structural: editing is publishing so there is no draft, there is no build to roll back to, a custom domain is a paid add-on, and the price follows workspace members rather than the number of sites you run. ### Do I need both a docs site and a wiki? Most teams past about ten people do, because the two have opposite requirements. A public docs site needs a gate between writing and publishing; a wiki needs no gate at all, or people stop writing things down. One tool doing both does one of them badly. ### When should I add a knowledge base? When the same support question has been answered by hand three times. Before that, the answers belong in your docs site as guides. A knowledge base is worth its maintenance cost once volume makes finding a canonical answer faster than writing one again. ### Which one does Docszero build? A documentation site: a curated tree of Markdown pages with full-text search, a publish step, versioned builds you can roll back to, and your own domain on Pro and above. Password protection makes it workable for internal handbooks and runbooks too, but it is not a wiki — there are no databases, comments or real-time co-editing. --- Published by Docszero (https://docszero.com) — docs, minus the setup. Upload Markdown, a Word document or a PDF and get a searchable documentation site. Free for one site; export the source on every plan.