How to build a team wiki that people actually use
Build a team wiki in seven steps: four top-level sections, one owner and a review date per page, and search that answers questions. Four tools compared.
On this page
To build a team wiki that gets used, start with four top-level sections (handbook, how we work, runbooks, decisions), give every page one named owner and a review date, write the first twenty pages yourself before inviting anyone, and pick a tool whose search answers a question rather than listing files. A wiki fails when nobody owns it, not when it is small.
This is the structure we run at Atrix for a team of about a dozen people across three countries, and the rules we arrived at after letting two earlier wikis rot. It is written for teams of two to fifteen.
Why most team wikis die within a year
A wiki dies in a predictable order. Someone sets it up with enthusiasm and a deep folder tree. The tree has empty branches from day one, so people stop trusting it. New pages get created at the top level because nobody can find the right place. Within three months there are two pages on the same topic, one of them wrong. Someone searches, gets the wrong one, and from then on asks in chat instead.
Each stage has a cause you can design against:
- Empty structure. Folders created before content. Fix: create a section only when it has three pages to go in it.
- No owner. A page nobody is responsible for drifts until it is wrong. Fix: one name per page, visible on the page.
- Duplicate pages. Caused by weak search and no naming rule. Fix: a naming convention and a weekly five-minute merge.
- Stale content. The page was right in January. Fix: a review date on every page and a quarterly sweep.
- Search that lists instead of answers. The person asking "what is our refund policy" does not want nine documents containing the word refund. Fix: a tool with good search, and page titles written as the question people ask.
A wiki structure for a small team
Four top-level sections cover almost everything a team of fifteen or fewer needs. Resist adding a fifth until one of these is overflowing.
| Section | What goes in it | Who reads it | Changes |
|---|---|---|---|
| Handbook | Who we are, how we pay, leave, expenses, equipment, working hours, values written as behaviours | Everyone, especially new hires in week one | Rarely; a few times a year |
| How we work | Rituals (standups, planning, reviews), how we ship, how we write, how we name things, tool list | Everyone, weekly | Monthly |
| Runbooks | Step-by-step procedures: deploy, rotate a key, onboard a customer, close the month, handle an outage | The person doing the task, under time pressure | Each time the procedure changes |
| Decisions | One page per decision: context, options, choice, date, who decided | Anyone asking "why do we do it this way" | Append-only; never edited after the fact |
The handbook is the slowest-moving and the first thing a new hire reads. "How we work" is the operating manual. Runbooks are the pages that save you at 2 a.m. Decisions are the memory of the company, and the section most teams skip. We keep a decision log template that fits the fourth section.
Inside each section, nest no deeper than three levels: section, topic, page. "Runbooks / Infrastructure / Rotate the database password" is fine. Anything deeper means people will create a duplicate at the top rather than find the right branch.
Naming pages as questions or verbs
Title runbooks with a verb: "Deploy the API", "Refund a customer", "Rotate an API key". Title handbook and how-we-work pages with the question people ask: "How do I book leave?", "What do we pay for?", "When do we do standups?". The title is the first thing search matches, and people search in the words they would use to ask a colleague.
Ownership rules that keep the wiki alive
The structure is the easy part. These three rules are what keep a wiki accurate after the first month.
- One owner per page, named on the page. Not a team, not a role, a person. When they leave, their pages are handed over in the offboarding checklist. A page without an owner is archived, not left to drift.
- A review date on every page. Handbook pages get twelve months, how-we-work pages six, runbooks three. The owner either confirms the page is still right or fixes it. A page past its review date shows a visible warning, and a monthly report lists overdue pages by owner.
- The person who found the mistake fixes it. If you follow a runbook and step four is wrong, you fix step four before you finish. This is the single rule that most changes a wiki's trajectory, and the one that needs saying out loud at onboarding, because new people assume they are not allowed.
How to build the wiki in seven steps
- Choose the tool, then stop evaluating. The tool matters less than the ownership rules. Pick one that nests pages, has search that works on page content, shows who edited what and when, and exports to Markdown so you can leave. The table below compares four.
- Write the first twenty pages yourself before inviting anyone. An empty wiki looks like a thing to ignore. The first twenty are usually: ten handbook pages, five how-we-work pages, three runbooks for the scariest procedures, and two decisions you made this quarter.
- Move, do not rewrite. Most of these pages already exist in chat threads, Google Docs and someone's head. Paste them in with a date and an owner. Polish later.
- Set owners and review dates on every page in one sitting.
- Announce the rules, not the wiki. The announcement is three lines: where the wiki is, the "fix what you find" rule, and that chat answers to recurring questions will be replaced by a link to the page.
- Answer chat questions with links for one month. When someone asks "how do I expense a flight?", answer with the link, and if there is no page, write it in five minutes and send the link. After a month, people search first.
- Hold a quarterly sweep. Thirty minutes, whole team: archive what is dead, merge duplicates, confirm overdue reviews. Keep the page count small. A good small-team wiki is 80 to 200 pages, not 2,000.
The search problem, and why Confluence users complain about it
The complaint about wiki search is almost always the same: searching a phrase returns a long list of pages that contain the words, ranked in a way nobody understands, with the right page on the second screen. Confluence is the tool most often named in this complaint, partly because it is the most widely deployed, and partly because large Confluence sites accumulate years of attachments, personal spaces and archived pages that all rank alongside the current answer.
To be fair to Atlassian, its support documentation does not state a search limit on any Confluence Cloud plan. What it does say, as of October 2026, is that the Free plan covers up to 10 users with 2 GB of file storage, and that AI features, including Rovo, are listed on Standard and above with higher usage quotas on Premium. So on a Free Confluence site, search is the traditional keyword search; the AI-answer layer is a paid feature.
Three things reduce the problem regardless of tool:
- Fewer pages. Search works better over 150 current pages than over 3,000 pages of which 2,850 are stale. The quarterly sweep is a search improvement.
- Titles in the words people search. A page called "PTO policy v3 final" will not be found by someone typing "how do I book holiday".
- Ask-style search. The newer approach is to answer the question from the pages, with a citation, instead of listing the pages. Slite, Nuclino and Atrix all do a version of this; Confluence does it through Rovo on paid plans.
Tools for a small-team wiki, as of October 2026
| Tool | Entry paid price | Free plan | Search | Good fit when |
|---|---|---|---|---|
| Confluence | Per user per month; see Atlassian's page | Up to 10 users, 2 GB storage | Keyword search; Rovo AI search on Standard and above | You already run Jira and want the same admin |
| Slite | $10 per member per month, billed yearly (Basic); Pro $20 | None; 14-day trial, no card | AI answers, 30 questions per seat per month on Basic | You want a wiki and only a wiki, with a quiet editor |
| Nuclino | Per user per month; see Nuclino's page | Up to 50 items, 3 canvases, 2 GB total | Keyword search; Sidekick AI on Business | A very small team that values speed over features |
| Atrix | $39 per month for 5 seats (Builder); $149 for 15 (Studio) | None; 7-day trial, card required | Keyword search plus ask-the-workspace AI answers | The wiki should sit next to tasks, chat and CRM |
Notes on the figures. Slite's page shows Basic at $10 and Pro at $20 per member per month billed yearly, no free plan, and a 14-day trial without a card. Nuclino lists Free, Starter and Business with yearly billing up to 25% off, but we could not verify its per-user prices on the page, so we are not printing them; Starter includes unlimited items and 30-day version history, Business adds Sidekick AI and unlimited history. Confluence Cloud prices vary by billing term and region and were not readable from Atlassian's page when we checked, so confirm them directly.
Where Atrix fits
Atrix is one option, and the honest case for it is that the wiki is one tab in a workspace that also holds work, chat, calendar, customers and hiring, so a runbook can link to the issue it came from and a decision page can link to the deal that prompted it. Pages nest as a tree, a page can be a database (useful for the decisions section: one row per decision, with status and date columns), several people can edit a page live with visible cursors, every page keeps version history and comments, and the whole workspace exports as a ZIP of Markdown. The search box answers a question across pages, tasks and messages and cites where the answer came from; the same ask-the-workspace capability is exposed to Claude, ChatGPT and Cursor through the MCP server, so you can ask your wiki from the tool you are already in.
The limits: there is no free plan, Builder is sized for five seats, there is no importer for a Notion or Confluence export beyond Markdown, Word and Excel files, and if you only want a wiki, Slite or Nuclino will be simpler. The docs and whiteboards page lists what pages can and cannot do. If you are weighing it against Notion, the Notion comparison and the Notion alternatives list cover the differences in detail.
FAQ
What should a company wiki contain?
Four things: a handbook (pay, leave, expenses, equipment, values), an operating manual for how the team works and ships, runbooks for every procedure someone might have to follow under pressure, and a decision log. Product documentation and customer-facing help belong elsewhere.
How do you structure an internal wiki for a small team?
Four top-level sections, each with topics, each topic with pages: three levels, no deeper. Create a section only when it has three or more pages ready to go in it. Keep the total under 200 pages by archiving aggressively.
Who should own the team wiki?
Every page has one named owner; the wiki as a whole has one person who runs the quarterly sweep and the monthly overdue-review report. In a team under fifteen that is usually a founder or the operations lead. Ownership of a page passes to someone else in the offboarding checklist.
How often should wiki pages be reviewed?
Handbook pages yearly, how-we-work pages every six months, runbooks every three months or whenever the procedure changes. Decisions are never edited after the fact; a reversed decision gets a new page that links to the old one.
Is Confluence good for a small team wiki?
It works, and the Free plan covers up to 10 users with 2 GB of storage as of October 2026. The common complaint is search quality on large sites, and the AI search layer (Rovo) is on paid plans. For a team under fifteen that does not already run Jira, a lighter tool is usually faster to set up.
Next step
Start with the structure above and the first twenty pages. If you want the wiki next to the rest of the team's work, the docs and whiteboards feature page shows nested pages, databases and live editing, and the Notion comparison covers what moving a wiki involves.
Sources
Checked in October 2026: Slite pricing, Nuclino pricing, Atlassian: Confluence Cloud plans.