A fan wiki for a live game is not one article with three URLs. It is three products that share a domain: a status table, an onboarding spine, and a gated progression doc. Mixing them is how pages go stale, spoil new players, and burn editor time on the wrong refresh cycle.
I have been looking at how small teams keep 100 Days at Sea style sites honest without a newsroom. The workable pattern is to give each page type a job, a refresh SLA, and a hard rule about what it must not contain.
Product 1: the codes page is a status API in HTML
Promo codes rot on a weekly (sometimes daily) clock. The page's job is not inspiration. It is Active / Contested / Expired with a checked date. Redeem steps change rarely; status cells change often. Ops rule: rewrite cells, not essays.
That is why a maintained codes list should look boring on purpose. Flashy "NEW CODES!!!" banners train readers to distrust you when last week's string is still glowing. Keep Expired rows visible so dead codes stop getting reposted as fresh. If you need the method behind the labels, the verification note on how we verify codes is the editorial contract — not a second redeem tutorial.
Refresh SLA: short. Touch this page whenever a dump hits Discord or a major tracker updates. Do not wait for a "content calendar."
Product 2: the beginner guide is a Day-1 spine
Beginner pages fail when they try to be walkthroughs. New players need a resource triage and unlock order, not boss mechanics from week three. The job is: stabilize the raft, name the first stations, set a night-1 exit plan, then stop.
A focused beginner guide should refuse midgame spoilers the way a codes page refuses vibes. If a paragraph only helps after the first boss gate, it belongs elsewhere. Ops rule: update when the early economy or tutorial flow changes — not when a new late island ships.
Refresh SLA: medium. Patch notes that touch Day 1–3 matter; cosmetic seasons usually do not.
Product 3: the walkthrough is gated chapters
Walkthroughs exist for gates: prep checklists, failure modes, "you are blocked until X." They should be chaptered so a returning player can open one stretch without swallowing the whole plot. Spoiler boundaries are a product feature, not a courtesy.
Structure a walkthrough as spine mode documentation: when to follow, when to explore, what prep the next gate demands. Ops rule: update per gate when the encounter or recipe changes; do not reshuffle the whole TOC every week for SEO theater.
Refresh SLA: long per chapter, event-driven per patch.
Shared editorial rules that keep the three from collapsing
- One primary job per URL. Codes do not teach Day-1 builds. Beginner does not list contested promo strings. Walkthrough does not bury a redeem form in chapter 1.
- Timestamps match the job. Codes need a "checked" stamp. Beginner needs a "early-game verified as of" line. Walkthrough needs per-chapter patch notes.
- Cross-link as handoffs, not keyword stuffing. Beginner → walkthrough when the raft is stable. Codes → beginner when someone is redeeming instead of eating. Walkthrough → codes only if a chapter is gated behind a seasonal reward.
- Source methodology is public. A short source methodology page turns "trust us" into a checklist outsiders can audit.
Why this split helps SEO and humans
Search queries cluster by job: "codes," "beginner," "walkthrough / how to beat." One mega-page ranking for all three usually ranks cleanly for none after the first month, because refresh noise and spoiler complaints fight each other. Three products, three SLAs, one domain — that is content ops for a small game wiki, not a content calendar cosplay.
Top comments (0)