How to build an RPG campaign wiki (the easy way)

Every group starts a campaign wiki. Most of them have three half-filled pages and a heroic page-one entry titled "The World of Eldara" that nobody has opened since session two. The problem isn't your discipline. It's that the wrong thing got built.

A wiki is a memory, not a museum

The instinct is to write an encyclopedia: kingdoms, pantheons, a thousand years of history before the party has done anything. It feels productive. It's also a beautiful way to never touch the wiki again, because none of it answers the question that actually stops play: "wait, who was that merchant, and what exactly did you promise the duke?"

A campaign wiki earns its keep by being the table's shared memory for the things that come back. If an entry never gets re-read, it was a diary, not a wiki. Build for recall, not for completeness.

There's a quieter rule hiding in here, too: the only canon is what happened at the table. The kingdom you sketched in your head, the villain's secret backstory the party never uncovered, the lore you wrote and never spoke aloud, none of it exists in the campaign yet. A wiki of the things you all witnessed together is worth more than an encyclopedia of a world nobody will ever play in. You can absolutely build the giant one with everything in it, but be honest about what that hour costs: it's an hour stolen from the description of the next room, the NPC voice, the map, the music, the twist that actually lands when everyone's at the table. Your time is finite. The wiki is a means to spend it well, never the place it disappears.

The best wiki page is the one someone reopens mid-session, swears under their breath, and says "right, that guy."

The five things worth tracking

You don't need every detail of your world. You need the handful of entity types that recur across sessions, each one a short, scannable entry rather than an essay.

• NPCs. Who the party met, plus one detail that makes each unforgettable (the blind ferryman, the guildmaster who never blinks). Names alone are useless a month later.
• Locations. Where things happened and how places connect, so the map in everyone's head stays the same map.
• Factions. The groups with agendas: who wants what, who they hate, where the party stands with them right now.
• Quests. Open threads, promises, and debts. This is the part that restarts the next session, so it's the part that must stay current.
• Items. The cursed sword, the sealed letter, the artifact nobody's identified. Track the ones that carry plot, ignore the +1 daggers.

Five categories. That's a wiki a table can keep alive. Twelve categories is a wiki that dies by session four.

There is a sixth thing, and it sits a little apart from the rest: the session record itself. Every other entry answers who or what; the session log answers when. It's the spine the whole wiki hangs off, a one-paragraph recap per session ("the party crossed the river, lied to the toll-guard, and woke something in the cellar"), each one quietly name-dropping the NPCs, places, and quests it touched. Keep recaps short. Their job is to be a timeline you can scroll, not a transcript you have to re-read. The Alexandrian makes the same case for a campaign status document: a single living page you update through play, not a static bible written once and abandoned. If you already write a few lines after each game, you are most of the way to a wiki and probably don't know it. (A good capture habit is its own skill, and there's a whole guide to session notes if yours need rescuing.)

What goes in each entry

The discipline that keeps a wiki usable isn't what you track. It's how much. Every entry wants the same shape: a name, one line that tells you who or what this is, and then only the details that have actually mattered at the table. For an NPC that might be "owes the party a favour, secretly working for the Ashen Hand." For a location, "burned down in session 7, the party doesn't know it was them." Resist the urge to backfill a biography. The entry can grow later, the session it becomes relevant, and a wiki is allowed to be mostly stubs. Stubs that exist beat essays that don't.

Cross-link, or it's just a list

A flat list of NPCs is a phone book. The value appears when entries point at each other: the smug guildmaster belongs to the merchant faction, who controls the river port, where the party still owes a debt from the quest that went sideways. Open any one card and the threads to everything connected are right there.

You don't need a graph database for this. A simple rule does most of the work: whenever you name something that has its own entry, link to it. One mention, one link. After a few sessions the web builds itself, and "remind me how these two are connected" becomes a click instead of an argument.

Here's why this matters more than it looks. A connected wiki surfaces the consequences you forgot you set up. You open the river-port location to check a name and notice the faction that controls it has a grudge against the NPC the party just befriended. That collision is a plot hook you didn't have to invent. It was already sitting in the links. A flat list never does this for you; it just stores facts in separate drawers. The web is where running the campaign gets a lot easier, because the prep starts doing some of the thinking. Aim for a small number of strong connections rather than linking everything to everything: a card with three meaningful threads is more useful than one wired to forty. This is the spirit of the Alexandrian's node-based design: a handful of well-connected nodes the party can move between beats a sprawling web nobody can hold in their head at the table.

Three ways to actually build one

Once you know what goes in, the only real question is where. There are broadly three approaches, and the best one is whichever you'll still be using in three months.

1. A plain notes app

A plain notes app (Google Docs, a Word file): a folder of documents, one per NPC or location, or a single growing page with headings. Zero setup, works offline, nothing to learn. The catch is cross-linking: most notes apps don't connect entries, so you end up Ctrl-F-ing for "that merchant" and scrolling. Perfectly fine for a short campaign or a one-shot. It starts to groan around the point you stop remembering everyone's name, which is roughly when a wiki was supposed to start helping.

2. A dedicated wiki app

A tool built for linked pages: proper backlinks, a sidebar, a search that understands your entries. Notion, Obsidian and World Anvil all do this well, and honestly it's what I use for prep itself, because for jotting ideas, sketching NPCs and building the world it's hard to beat. The catch shows up only for the record of what happened, where you are still the engine. Every entry, every link, every update is something you type, by hand, after the session, which lands you straight back at the problem nobody likes to say out loud.

3. Let an AI build it from your sessions

The newest option flips the work around. Instead of you writing the wiki and the tool storing it, the tool listens to (or reads a transcript of) the actual session and drafts the entries for you: a recap, plus cards for the people, places, factions and quests that came up, already cross-linked. You stop being the typist and become the editor, which is a much easier job to keep doing. It only works if you can capture the session in the first place, but if you play on voice that's nearly free. See Discord session recording and what the AI session summaries actually produce.

None of these is "cheating." A wiki is a tool for remembering, and the method that remembers the most while asking the least of you is the right one for your table.

Keep one split clear, though: prep and recap are two different jobs. Your ideas, the NPCs you're cooking up, the world you're building, that's prep, and it can live wherever you like to think (Notion is genuinely great for it). The record of what actually happened at the table is the other half, and it's the half you can hand off. Kompanion's job is that reliable memory, so the tool you brainstorm in stays free for brainstorming.

The real reason wikis die

It isn't laziness. It's timing. Updating the wiki is a separate task, done at the worst possible moment, after a four-hour session, when everyone's brain is fried and the snacks are gone. So it gets skipped "just this once," and once is all it takes.

The fix isn't more willpower. It's making the wiki fall out of something you already do. If you keep good session notes, the wiki should be the byproduct, not a second chore. Capture the session once; turn that capture into cards. The blank page is the enemy, so don't start from one.

One more failure mode worth naming: the perfect wiki, the one where every entry has to be polished before it counts. That standard guarantees a backlog, and a backlog guarantees abandonment. Let entries be ugly. A line of "TODO: this guy betrays them later?" is doing more work than a beautifully formatted page that doesn't exist yet. Current and scruffy beats pristine and three months behind.

A starter structure you can steal

If you want to begin tonight, here's a layout small enough to actually maintain. Six top-level sections, nothing nested more than one level deep:

• Sessions. A dated list, newest on top, one paragraph each. This is your timeline and your most-used page.
• People. Every named NPC, one line of who-they-are plus one line of where-they-stand-with-the-party.
• Places. Locations the party has visited or heard of, grouped loosely by region.
• Factions. The handful of groups with agendas, and the party's current standing with each.
• Threads. Open quests, unpaid debts, unanswered questions. The page you read before a session, not after.
• Loot & oddities. The items, letters, and unidentified things that might matter later.

That's it. No "Cosmology," no "Calendar of the Seven Moons," no nine-page history of a kingdom the party will never visit. Add those only if and when they earn a spot by coming up at the table. Start with the six, link entries as you write them, and let the structure grow from play instead of trying to predict it. A wiki that fits on one screen and stays current will beat a sprawling one that's a graveyard, and it'll do it by session three.

Build it once, keep it current, and let the next session do the updating for you.