How we built a Roblox wiki that refuses to publish fake codes

100days — Tue, 18 Aug 2026 12:08:30 +0000

Most Roblox “wikis” are the same page with a different domain: a copied code list, a fake tier list, and recipe numbers nobody checked in-game.

That pattern ranks for a week. Then players waste time on dead codes, bounce, and teach Google that the site is another thin clone.

I wanted the opposite for 100 Days At Sea — a Roblox survival game with 250M+ visits where you build a raft, pick a class, and try to reach Day 100. The wiki should read like a guidebook, not a keyword farm.

The shipping rule was simple: if we cannot show the source, we do not publish the claim as fact.

The product problem is a content problem
People landing from search usually want one of five things:

Working codes
Which class to buy with Pearls
How not to die on Day 1
What a badge actually unlocks
A Discord / Trello invite that is not a scam
Those jobs collide. A codes page that invents values will get clicks. It will also train users to distrust every other page.

So the information architecture is built around source strength, not page count.

Claim type Publish as fact? What we show instead
Official Roblox page / group
Yes, high-level
Game framing, creator context
Public Roblox Badge API
Yes, as public data
Name, icon, description, award count
Player-reported class row
As reported
Cost / starter / role, marked unverified
Copied code list
No
Status table + why it was rejected
Exact recipes, coordinates, DPS
No
“Needs an in-game screenshot”
The last row is the hard one. Empty-feeling pages rank worse in the short term. Invented numbers get a click and then a bounce. We chose the bounce we can live with.

Codes: a registry, not a list
The codes page is the clearest example.

As of mid-August 2026, the working list is empty. Other sites still show CORRUPT, HERO, CHAOS, POTION, or invented strings like SEAADVENTURE. We keep those in a “not accepted yet” table with a reason:

past reported window
source conflict
no official publication
no recorded in-game reward
A code only moves into “working” after one of two things happens:

an official source publishes the exact value, or
an in-game redeem produces a recorded reward
That is slower than scraping five aggregator pages. It is also the only version of a codes page that stays true after the code expires.

If you maintain any community docs site, this is the reusable pattern: publish the rejected claims. Hiding them makes users think you missed the “real” list. Showing them with a status is the product.

working = official value OR recorded reward
not accepted yet = copied / expired / conflicting / unproven
historical lead = the official page once mentioned “codes”
but never published a usable string
POTION is a good example. A community post gave it a use-before date of August 7. That date passed, the official Roblox page never published the value, and we never recorded a successful reward. It stays in the past-claims table so a player does not mistake an old screenshot for a current code.

Badges as a public API, not a walkthrough
Roblox exposes public badge data. For this game that is currently 61 badges — names, icons, descriptions, award counts.

That data is useful, and dangerous if you over-read it.

Just Getting Started tells you Day 1 is a real checkpoint.
Cooking With Golems tells you the Volcano unlock involves tossing in three golems.
There Can Be Only One tells you three rival rigs can be beaten in one session.
Rescued! tells you Day 100 is a real end state.
None of those badges give coordinates, attack patterns, or drop tables. So we treat badges as milestone clues, then write the route as a lead until someone captures the UI.

The same rule applies to Ice Biome, UFO / Mothership, and the Corruption Dungeon. The badge proves the objective exists. It does not prove the YouTube comment that claims the exact path.

A docs site can do the same thing with any public platform API: use it as the spine, then hang unverified rows off that spine. Do not let the API write strategy it cannot support.

Classes without a fake S-tier
Players want a tier list. We track 23 reported class rows — Sailor, Survivor, Medic, Crewmate, and the rest — with Pearl costs and starter tools.

We still do not rank them.

A “best class” article is easy to write and almost always wrong after the next patch. What we publish instead:

reported cost
reported starter item
a role label (starter / support / combat / utility)
a one-line “what to check in the class menu”
Survivor is enough to show the difference. Players report 50 Pearls, Chowder as a starter, and a sustain kit (regen, oxygen, hunger). That is enough to tell a new player: check this if you keep dying to hunger. It is not enough to say “pick Survivor.”

If you maintain game docs, delay the ranking page until you have a repeatable test. Rankings are content. Tests are documentation.

The first-session route is the real homepage
Search traffic wants codes. New players need a raft that does not fall apart.

The useful first session is boring on purpose: gather floating resources, learn the harpoon loop, stabilize the raft, add defenses, then explore. Class shopping and code hunting come after the survival loop makes sense.

We also refuse exact material counts until the build UI is captured. “Stabilize the base before long trips” is useful tomorrow. “You need 17 planks” is a guess wearing a number.

This is the same discipline as writing API docs: describe the call you can see, not the payload you wish existed.

Safety is part of the docs, not a footer
Roblox code pages attract a second traffic type: people looking for executors, “free Robux,” and fake Discord invites.

Official links on the wiki only come from the Roblox experience page or the developer-owned group. Discord and Trello stay “not confirmed” until they appear on an official public surface.

The codes page is equally blunt:

no scripts
no browser extensions
no third-party login forms
YouTube comments are leads, not sources
If your docs site touches accounts, this is not optional legal text. It is the difference between a guide and a phishing funnel.

What I would reuse on any docs site
Separate source types in the data model. Official, API, player report, video lead, copied claim. Do not flatten them into “content.”
Publish negative results. “No working codes” is an answer. An empty heading is not.
Use public platform data as the spine. Badges, game stats, official descriptions. Hang unverified rows off that spine.
Delay rankings. Role notes beat S/A/B lists until you can re-run the test.
Keep the first-session path honest. Users forgive missing numbers. They do not forgive invented ones.
The live wiki is here: 100daysatsea.com. It is fan-made and not affiliated with Roblox or Stranded Devs. If a claim on the site is still a lead, that is intentional — we would rather show the gap than fill it with a number that looks finished.

DEV Community: 100days

How we built a Roblox wiki that refuses to publish fake codes