Internal Wiki Examples: 6 Real Company Wikis (and What Goes in Yours)
Search for internal wiki examples and you mostly get screenshots. A cropped sidebar from a vendor's demo account, a fake org chart, three articles named "Article 1." That is an example of a product interface, not an example of an internal wiki.
The useful examples are the companies that publish theirs. A handful of organisations run their internal documentation in the open, which means you can read a real, maintained, in-use company wiki end to end without a signup or a sales call. Six of them are below, with what each one does well and the one habit worth copying.
After that: what actually goes inside a wiki, because reading a finished one and building your own are different problems.
If what you actually want is a product comparison rather than examples, the internal wiki tools round-up covers the software side.
Six internal wiki examples you can read in full
All six are public, maintained, and genuinely used by the companies that wrote them. None of them is a marketing artefact dressed up as documentation.
1. GitLab — the handbook-first company
GitLab's handbook is the reference example, and it is enormous. Top-level sections cover Company, People Group, Product, Engineering, Security, Marketing, Sales, Finance, and Legal & Corporate Affairs, each branching into the specifics of how that function operates.
What makes it worth studying is not the size but the rule behind it. GitLab describes taking a "handbook-first" approach: if a process is not written in the handbook, it is not the process. That single constraint is what stops a wiki from decaying into a graveyard of half-finished pages, because it forces the writing to happen before the work rather than after it.
Edits go through merge requests against a public repository. Every change has an author, a reviewer, and a diff.
Worth copying: change control. Most internal wikis fail on trust — nobody is sure whether a page is current, so everyone asks in chat instead. Making edits reviewable, with a visible history, is what earns the page the right to be believed.
2. PostHog — the handbook that lives next to the docs
PostHog puts its company handbook on its marketing site, in the same navigation as its product documentation. It splits into "Working here" — culture, tools, people ops, compensation, hiring — and "Resources", which covers engineering, growth, marketing, content, branding, and support.
The handbook opens by calling itself one of the most important things the company has made, and the placement backs that up. There is no internal-versus-external boundary for anything that is not confidential.
Worth copying: default to public. Deciding that everything is readable unless there is a specific reason it cannot be removes an enormous amount of permission-management work, and it forces the writing to be good enough for strangers.
3. 37signals (Basecamp) — the handbook as a policy contract
Sixteen chapters, and the table of contents is the interesting part: Getting Started, Benefits & Perks, How We Work, Making a Career, Our Rituals, Managing Work Devices, Our Internal Systems, Moonlighting Policy, Code of Conduct, State Leave Provisions, Severance Packages — then separate title guidelines for designers, ops, programmers, QA, and support.
Two things stand out. Severance terms are published before anyone needs them. And the role-specific ladders mean a programmer can read what the next level actually requires instead of asking their manager to interpret it.
The handbook states it may be updated at any time, and changes are tracked in a public GitHub repository, so "it changed and nobody told me" has an answer.
Worth copying: write the uncomfortable pages. The policies people most need in writing are the ones companies most often leave to a conversation.
4. Valve — the onboarding document as culture
Valve's handbook has been circulating since 2012 and is still the clearest example of a document written for the person who has just arrived. It explains how to work at a company with an unusually flat structure: how to pick what to work on, how projects form, what to do in your first week when nobody has assigned you anything.
It is also honest about the trade-offs of that structure, which is rarer than it should be in a document aimed at new hires.
Worth copying: write for week one. Most internal wikis are written by people who already know how the company works, for readers who do not. The Valve handbook inverts that.
5. Netflix — the memo people actually quote
Netflix's culture document is short by wiki standards and has been revised repeatedly over more than a decade. Its distinguishing feature is that people cite it. "Freedom and responsibility" is not a poster in a corridor; it is a line managers point to when explaining a decision about expenses or time off.
Worth copying: a page earns its place when someone quotes it to settle an argument. If no page in your wiki has ever been used that way, the wiki is a filing cabinet rather than a source of truth.
6. Wikimedia Meta-Wiki — the actual wiki
Meta-Wiki is where the Wikimedia community coordinates itself: policy proposals, project governance, working groups. It is the only entry on this list that is a wiki in the original sense — anyone can edit, every page carries a full revision history, and every page has a talk page attached to it.
That last detail is the one most company wikis miss. Discussion about a page lives with the page, not in a Slack thread that scrolls away.
Worth copying: keep the argument attached to the article. The reasoning behind a decision is usually more valuable six months later than the decision itself.
What goes in a company wiki
The examples above are finished products, built over years. Starting from a blank page is a different exercise, and it helps to know that almost everything in a working internal wiki falls into three groups.
Reference articles — the answers you give twice
The clearest signal that something belongs in the wiki is that you have explained it to two different people. The answer is currently buried in a Slack thread from four months ago, which means the third person will ask again.
What tends to live here:
- Frequently asked questions. Expenses, access requests, who owns which system, how to book time off. Short pages, one question each.
- How-to guides. The steps for a task someone performs occasionally enough to forget — running a release, setting up a local environment, filing a security review.
- Project documentation. Requirements, decisions, and the reasoning behind them, so a project can be picked up by someone who was not in the room.
Handbooks — policy and expectations
This is the section every example above invests in most heavily, and the one most internal wikis under-write. Policies feel well known to the people who set them and are invisible to everyone else.
- Standard operating procedures. The repeatable processes a team runs, written so a new person can follow them unaided.
- Company policies. Time off, equipment, remote work, expenses, conduct. Specific enough to answer the question without a follow-up.
- Values and how they are applied. Values on their own are wallpaper. Values with worked examples of decisions they shaped are useful.
Customer knowledge your team needs internally
Support and sales teams need a private counterpart to whatever the company publishes externally — the detail that would be wrong to put on a public page but that a team member needs before replying.
- Product knowledge. How features actually behave, including the edge cases the marketing page skips.
- Response guidance. Not word-for-word scripts, which read as robotic, but the shape of a good answer to a recurring situation.
- Pricing and discount rules. What can be offered, by whom, and up to what limit.
Making yours worth reading
Four habits separate the wikis people use from the ones they abandon:
- Start from the questions, not the structure. A week of noting every question answered twice produces a better table of contents than an afternoon of planning categories.
- One concept per page. A single page called "Everything about onboarding" is unsearchable. Ten short pages are not.
- Give every page an owner and a review date. Unowned pages rot, and one visibly stale page makes readers distrust the rest.
- Treat search as the interface. Almost nobody browses a wiki's navigation tree. They search. Page titles should read like the query someone would type.
For a longer walkthrough of building one from nothing, the internal knowledge base guide covers structure, ownership, and rollout in more depth.
Internal wiki or internal knowledge base?
The terms get used interchangeably and the distinction is real but narrow. A wiki is collaborative by default — many editors, loose structure, discussion attached to pages. A knowledge base is usually more curated, with defined owners and a publishing step before content goes live.
Most companies end up wanting both behaviours: open editing for internal process notes, tighter control for anything customer-facing. The full comparison is in knowledge base vs wiki.
Picking the software
The tooling matters less than the habits, but it matters. Confluence and Notion are the two most common starting points, and both have their trade-offs — we compare them directly on HelpCenter.io vs Confluence and HelpCenter.io vs Notion.
If your wiki needs to serve customers as well as staff, a help centre platform is often the better fit: HelpCenter.io is priced per help centre rather than per seat, starting at $29/month on Bootstrap and $179/month on Catalyst, which changes the arithmetic once a documentation habit spreads beyond a couple of people.
For the full software comparison, including the open-source options, see the internal wiki tools round-up.
Common questions
Are there public company wikis I can actually read?
Yes. GitLab, PostHog, and 37signals publish their full internal handbooks, Valve publishes its new-employee handbook, Netflix publishes its culture document, and Wikimedia's Meta-Wiki is open to read and edit. All six are linked above.
What should an internal wiki contain?
Reference articles for questions asked more than once, handbook content covering policy and expectations, and internal product or customer knowledge that supports client-facing teams. Anything that does not fall into one of those groups is usually better as a document than a wiki page.
What is the difference between an internal wiki and a knowledge base?
A wiki is collaboratively edited with loose structure and discussion attached to pages. A knowledge base is more curated, with clear ownership and a review step before publishing. Many companies run both.
How big should an internal wiki be to start?
Ten to twenty pages covering the questions your team actually repeats. Every example on this list began far smaller than it is now, and none of them was planned in advance at its current size.