What Is a Wiki and How Do You Create and Run One?
Updated
A wiki is a website whose pages any permitted visitor can edit directly in the browser, with every change saved as a version you can review or revert. That single feature—open editing plus a full revision history—is what separates a wiki from a blog, a forum, or a static site. If you want to build one, the practical path is: pick a narrow topic, choose a MediaWiki-based host, create the main page and a category structure, then invite a few editors before you publicize it. Miraheze is one concrete option: it advertises free, ad-free wiki hosting powered by MediaWiki and run by a non-profit, with self-service configuration and a choice of over 300 extensions and skins.
What actually makes something a wiki
Four mechanics do the work. Remove any one and you have a different kind of site.
- Editable pages. Content lives in pages that authorized users change in place, not in a publishing queue.
- Version history. Every save creates a revision. You can compare versions, see who changed what, and roll back vandalism or mistakes.
- Links as structure. Internal links between pages form the real navigation. A wiki's shape emerges from how pages point at each other, not from a fixed menu.
- Talk/discussion pages. Each page can carry a companion discussion space for resolving disagreements about content without editing the article itself.
How a wiki differs from a blog, forum, or static site
| Wiki | Blog | Forum | Static site | |
|---|---|---|---|---|
| Who writes | Many editors, ongoing | One or few authors | Many posters, threaded | One owner, published |
| Structure | Emergent from links | Reverse-chronological | Threads and replies | Fixed pages |
| Editing | In-browser, versioned | Draft then publish | Post and reply | Code or CMS, then deploy |
| Best for | Reference that keeps changing | Commentary and updates | Q&A and community chat | Stable marketing or docs |
A wiki is the right tool when the goal is a shared, evolving reference. It is the wrong tool when you need a single authoritative voice or a simple brochure site.
How to create and run a wiki
1. Define the scope before anything else
Write one sentence: "This wiki documents X for Y." A topic that is too broad ("all games") collapses under its own weight; a topic that is too narrow runs out of pages in a week. Miraheze's own examples suggest the useful range—technology documentation and knowledge bases, game encyclopedias covering mods and hidden features, TV and entertainment references, science topics, and education material such as curricula and research.
2. Choose a platform or host
MediaWiki is the software behind Wikipedia and the engine Miraheze runs on. Your realistic choices are:
- Self-hosted MediaWiki — maximum control, but you own servers, upgrades, backups, and spam defense.
- A wiki farm / free host — someone else runs the infrastructure. Miraheze positions itself here: free, ad-free, non-profit, with a self-service admin interface and a large extension and skin library.
- A different wiki engine — lighter alternatives exist, but you give up MediaWiki's extension ecosystem and the familiarity many editors already have.
If your priority is getting content written rather than running servers, a farm is the lower-friction start. If you need deep customization or data control, self-hosting is the trade.
3. Set up the basic structure
Once your wiki exists, do these in order:
- Main page — a short orientation plus links to your top-level categories.
- Categories — group pages by type (e.g., Characters, Locations, Guides). Categories are how readers browse when they don't know a page name.
- Naming and style conventions — decide page-title format and a basic article layout now; retrofitting hundreds of pages later is painful.
- Core templates — infoboxes, stub notices, and citation templates save enormous time once reused.
4. Configure extensions and skins
Miraheze states administrators can configure almost every aspect of their wiki through a self-service interface and choose from over 300 extensions and skins. Practically, you'll want a handful early: an anti-spam tool, a visual editor if your contributors aren't comfortable with wikitext, and a skin that matches your subject. Add more only when a real need appears—every extension is something to maintain and learn.
5. Invite editors and set expectations
A wiki with one editor is a personal notebook. Recruit a few people who care about the topic, then agree on the boring but essential rules: what counts as a reliable source, how to handle disputes, and who can delete pages. Write these down on a policy page so you're not renegotiating them in every argument.
6. Plan for moderation and spam
Open editing attracts spam. The standard defenses are account requirements for editing, CAPTCHAs, moderation of new-page creation, and watchlists so admins see changes as they happen. Decide your posture before launch: fully open, or open-with-review. Most new wikis are better off starting stricter and loosening later.
Common problems new wiki owners hit
- Nobody edits. Usually a scope problem—the topic is too broad to feel "yours," or there's no seed content. Write 20–30 solid pages yourself first; empty wikis repel contributors.
- Spam floods. Tighten account and editing permissions, enable anti-spam extensions, and use recent-changes patrols.
- Structure chaos. Contributors invent conflicting page names and categories. Publish conventions early and fix drift while the wiki is small.
- Edit wars. Use talk pages to resolve content disputes rather than reverting back and forth, and give admins a clear escalation path.
- Abandonment. Wikis die when the founding editor stops. Recruit a second admin before you need one.
Choosing a host: what to weigh
Compare options on the same axes: cost model, ads, software, customization, and who handles maintenance. Miraheze's stated position is free, ad-free, MediaWiki-based, non-profit, self-service, with 300+ extensions and skins—a fit if you want MediaWiki without running servers and you accept a hosted platform's constraints. Self-hosting wins if you need full control over data, versions, or unusual configuration. The site's pricing page and sign-in terms aren't covered in the material here, so confirm current cost and account requirements directly before committing.