An owner-edited wiki: when a knowledge base website is enough
Most people who search for a wiki want a knowledge base: articles on one subject, linked together, that a small group keeps up to date. If only you or your team edit it, a site built from CMS collections does the job. If strangers need to edit pages, track changes and discuss them, you need wiki software such as MediaWiki instead.
Two very different things called a wiki
The word covers both Wikipedia, where anyone can edit and every change has a history and a talk page, and the help centre for a small product, where three people write everything. The first is a piece of collaborative software. The second is a website with good structure. Decide which you're building before choosing a wiki website builder or any other tool.
| You need | Choose |
|---|---|
| Visitors who edit pages, with page histories and discussion | Wiki software (MediaWiki, DokuWiki, or a hosted wiki) |
| Private internal notes behind a login | A team tool such as Notion or Confluence |
| A public reference that you or a small team write and keep current | A knowledge base website built from structured entries |
| A personal wiki site for your own notes that others may read | A knowledge base website, or a notes app with publishing |
Structure that makes a knowledge base usable
Wikis feel easy to navigate because of a few habits, not because of the software. Copy the habits.
- One topic per article, with a title that matches what people search for, such as "Resetting the hub" rather than "Hub issues 2".
- A short summary first. Two sentences that answer the common question, then detail.
- Categories as index pages. A page per category listing every article in it, so nothing is orphaned.
- Links between articles where one mentions another's subject. These links are most of what makes a wiki feel like a wiki.
- A last-updated date on every article, and an owner who checks it.
- A glossary if your subject has its own terms.
Building it from CMS collections
In Anticode, a knowledge base website is a set of CMS collections. Each collection has typed fields you define, such as title, summary, body, category and last reviewed, and you edit entries in the dashboard. Collection pages are served at /<collection>/ for the list and /<collection>/<slug> for each article, so an articles collection gives you /articles/ and /articles/resetting-the-hub.
For a bigger reference, split it: a guides collection, a troubleshooting collection and a glossary collection, each with fields suited to it. A troubleshooting entry might have symptom, cause and fix fields, which forces every entry into the same useful shape. Describe this when you start, for example "a knowledge base for our open-source sensor kit with guides, troubleshooting and glossary collections, and a page per category".
Write the internal links yourself as you edit. Keep slugs short and stable, because other articles and outside sites will link to them; changing a slug later breaks those links.
A team wiki website with several editors
On a Team plan the project sits in a shared workspace with an owner, admins and members, so several people can work on the same site. Members can't delete projects or take the site down, which suits a team wiki where most contributors only write. Saves are kept in version history, so you can preview and restore an earlier version of the project if an edit goes wrong. That history is for the whole project, not a per-article change log with authors, which is the main thing proper wiki software adds.
Limits to know first
- Visitors can't edit or comment. There are no visitor accounts on published sites. Offer a contact form for corrections and suggestions.
- No per-article history or talk pages. Version history covers the project as a whole.
- No private sections. Published pages can't be locked behind a login.
- No search box that filters as you type. Published pages run no scripts, so plan good category pages and a clear glossary instead.
- No import from another wiki. Moving from MediaWiki or Notion means copying content into collections.
If your project grows into needing open editing, the documentation website page covers the adjacent case of product docs, and the directory website page covers structured listings.
Questions people ask
Can I make a personal wiki site just for my notes?
Yes, if you're happy for it to be public. Use one collection for notes with a topic field, and category pages to browse. For private notes, use a notes app.
Can someone else on my team edit articles?
Yes, on a Team workspace. Members can edit the project; only the owner and admins can delete it or take it down.
Can I restore an article someone broke?
You can restore an earlier version of the project from version history. It restores the project, so note any other changes made since.
Is a knowledge base website good for search engines?
One article per topic, with clear titles and summaries, suits search well. Each published site also serves its own sitemap so the articles can be found.