Every game wiki has the same failure mode, and it isn't hosting or search — it's rot. A roguelite ships a balance patch, the "best build" everyone recommends gets quietly nerfed, and the wiki keeps presenting last month's meta as truth. Players burn a run on stale advice, blame the site, and never come back.
Sephiria is a new action roguelite that patches every few weeks, which makes it a worst case for wiki rot. So when I built sephiriabuilds.xyz, I spent more time on the correctness pipeline than on the visual design. This post is the parts worth stealing.
Start from a template, then strip it honest
I started from AnvilWiki — an open-source Astro 5 game-wiki template (MIT). It gives you content collections, tag pages, breadcrumbs, sitemap, and a clean card layout out of the box, which saves a week of plumbing.
The first real job was deletion, not addition. The template ships with demo content for its original game — placeholder boss pages, a fake "video guides" section with a YouTube ID that doesn't exist, promo blocks for games the template never covered. All of it gone. A wiki that shows one piece of fabricated content teaches the reader that none of it can be trusted.
What survived the strip is what a wiki actually is: content collections for builds / weapons / guides, tags as a free secondary navigation layer, and per-page frontmatter I could extend.
Mechanism 1: every page carries the patch it was written against
Each piece of content declares the game version it targets:
---
title: "Biryuu Katana — Crit Build"
gameVersion: "1.0.25"
evidence: "video-verified"
lastModified: "2026-08-26"
---
gameVersion renders as a version badge next to the title; lastModified renders in a trust bar under it. A reader landing from search can immediately see "written for 1.0.25, updated three days ago" versus "written for 1.0.18, untouched for a month" — which, for a game that patches monthly, is the difference between advice and archaeology.
This also disciplines me as the author. When a patch lands, I don't "refresh the site"; I open the pages whose mechanics the patch notes touched, bump their version stamp, and leave everything else alone. The Sephiria builds hub and the weapon tier list are the most patch-sensitive pages, so they get reviewed every time; a beginner guide explaining core mechanics rots much slower and is reviewed far less often.
Mechanism 2: grade the evidence, don't just cite it
Build guides have an evidence problem: half of what circulates on Reddit and YouTube is one player's opinion from two patches ago. So every recommendation on the site carries an explicit evidence grade:
- video-verified — someone demonstrated it on camera in the current patch
- community-reported — multiple independent players claim it works, no video yet
- tested-this-patch — I reproduced it myself
- carried-over — verified in an older patch, not yet re-tested after balance changes
This has a nice property: the grade is a to-do list. Anything sitting at carried-over after a balance patch is exactly the page that needs attention next.
Mechanism 3: make re-crawl instant
When a patch drops and I update pages, I want search engines back the same day, not in three weeks. Three boring pieces of plumbing do that:
- Static generation. The whole site is SSG — a patch update is one rebuild, deploy takes seconds, and there's no server state to worry about.
-
Sitemap
lastmodwired tolastModified. Not a static build date — the actual content date, so crawlers see which URLs genuinely changed. - IndexNow. After each deploy, a tiny script pings the updated URLs to IndexNow (Bing, Yandex, and friends), which accepts them within seconds. No quota anxiety, no waiting for organic re-crawl.
What I'd tell past me
- Launch thin, launch honest. The site went live with four hand-written pages — a best-builds comparison, a tier list, a beginner guide, and one deep weapon build page — each with version stamps and evidence grades, rather than forty half-finished stubs. For search, four real pages beat forty hollow ones.
- The template saves you a week of plumbing, not a week of judgment. The demo content, the fake sections, the "works for any game" defaults — deleting all of it was the product decision.
- Design for the patch, not the launch. Every mechanism above exists because the game changes monthly. If your content has a shelf life, build the expiry date into the page itself.
The site is live and growing a few pages a week. Too early for traffic numbers — but the pipeline means that when a patch lands at 10am, the wiki is correct again by lunch.
