Every game wiki faces the same failure: the build guide said a weapon was "best," the patch changed it, and now a reader must choose between last week's truth and this week's rumor. The failure is rarely missing content. It is the absence of a way to tell the reader how sure the site is and when it last checked.
Iron Soul Dungeon Wiki is a fan-made reference for Iron Soul: Dungeon, a Roblox action RPG. Its guides cover forging, weapons, races, dungeons, codes, and builds. What makes it a useful example for developers is not the game lore. It is how the site handles a problem most documentation systems ignore: evidence that changes over time.
The core documents that everything else is built on
Most wikis present a fact as a statement of truth. This site instead treats every page as a dated observation. The guides index is a JSON-LD ItemList of 21 guides, each labeled "source-checked," and the intro line is explicit: "Claims that could not be verified are marked Pending confirmation." That single sentence is the design contract for the whole site.
The evidence model shows up consistently. The codes page is published as a snapshot, not a permanent promise: it names the date checked, lists the codes, and tells readers to "confirm them in the official Discord before publishing long-term." Codes expire, so the site refuses to present them as durable fact.
The same logic appears across categories. The cave ticket page documents a hard-coded dungeon ("Abandoned Courtyard, which has four documented difficulties") but marks the VIP and Double Ticket effects as community-sourced and to be "checked in the live store." Worse areas get the louder label: the Scythe materials page says plainly that no fixed list "can be verified" and tells the reader to "use the live forge preview" instead.
Labeling uncertainty beats pretending certainty
The strongest pattern is the confidence label. The site reserves "Pending confirmation" for outcomes it could not verify. The Fate Potion page is a textbook example: it confirms the potion is one of eight names in a community reference, then explicitly lists effect, values, duration, price, and stacking as "Pending confirmation in the live game." It does not guess.
This is a lesson for any documentation pipeline. When a fact is unverified, the correct action is often to say that it is unverified rather than to omit the page or fabricate the answer. A "we don't know yet" is useful to a reader; a confident falsehood is not.
The tier-list pages show a different subtlety: conflict reconciliation. The wiki collects multiple community rankings and reports where they disagree, instead of picking one winner. The weapon tier list states "Sky Flare is the only clear S-tier agreement," then explains that Gamezebo and MrGuider use different, newer orderings and tells readers to "compare category, forge roll, and source date before changing weapons." In other words, the site publishes the disagreement and the date, not a single authoritative answer.
Data structure is the implementation detail
The site is built on Next.js, and the metadata is clean enough to inspect. The guides index emits structured data for every article: a BreadcrumbList, a WebSite entity, and an ItemList with positions, names, and URLs for all 21 guides. The homepage emits a VideoGame schema with platform and developer fields. That means the information architecture is not just visual; it is machine-readable.
Localization is handled the same way. The head declares en, es, pt-BR, and ja with hreflang alternates on both the homepage and the guides index. Each locale is a separate route, and the site sets the locale via a query parameter (/set-locale?locale=...) before redirecting.
The practical takeaway: if a game's codes, builds, and drops churn every season, treat the whole knowledge base as versioned content, not as static articles. Give every claim a data source and a timestamp, add a "pending confirmation" state to your content model, and let structured data mirror the same hierarchy the reader sees.
What to copy and what to skip
The site is honest about its own limits, and that is the strongest thing about it. It never claims to be the official wiki, it disclaims affiliation with the developer and Roblox, and it labels its sources. For a developer building a similar reference, that transparency is worth replicating.
One thing it does not do is expose a public API or interactive data. There are no docs for consuming the guide data programmatically despite the structured markup. So the lessons here apply to information design, not to a backend you can integrate with.
The trade-off of the confidence model is that the site often under-answers. Readers who want a hard "use X" might leave frustrated, because the wiki sometimes says "we don't know." But for a game where facts shift constantly, that restraint is more useful than an overconfident list that becomes wrong a week later.
The lesson for your next docs project
Build the evidence model first, before you write the content. Decide how a fact gets a date, a source, and a confidence state. Let "Pending confirmation" be a first-class status in your content schema, not a free-text note. When sources conflict, publish the conflict and the dates rather than a single winner. And when the domain is volatile, version your facts and make the machine-readable metadata match the hierarchy the reader sees.
That is the difference between a wiki that answers and a wiki that merely fills a page.
This article was prepared with AI assistance.
Top comments (0)