A listing starts as data, not a thumbnail
Every game on Snacko Games exists first as a validated record: one data file per game, checked by a schema that fails the entire build if a required field is missing or inconsistent. Provider, embed URL, license evidence, domain approval, country rules, devices, orientation, age label — if any link in that chain is broken, the game cannot become a page.
The same invariant decides everything downstream: the Play button, the sitemap entry, the structured data and the recommendation rails all ask one shared question — does this record pass the publication checks right now? There is no path where a page renders but its embed is unapproved.
Licensing before anything else
Third-party games enter only through providers with an approved relationship to this domain, and their embed hosts are allow-listed in code — an unapproved host is rejected at import, not discovered in production. Self-hosted open-source games follow a stricter path still: the upstream license file itself is read and shipped unmodified, release files are audited for trackers and third-party loads, and the exact source commit is recorded in a public provenance file.
Automated health checks run continuously
Covers are mirrored locally and locked against their source with SHA-256 hashes, so what you see on a card is what the publisher shipped. The build re-verifies every page's links, images, titles, descriptions and metadata on each deploy. A daily import diff compares provider feeds against the catalog: feed outages keep the last approved snapshot, malformed data fails the build, and any change to a material field sends the record back to review.
What automated checks cannot tell you
A game that loads is not automatically a game worth your break, and we do not pretend otherwise. Difficulty and play-time labels are editorial estimates from catalog records, not stopwatch measurements. Hands-on gameplay review is an ongoing part of this catalog's workflow — games carry a scheduled retest date, and listings are corrected when a retest finds the notes wrong. If a game's controls card does not match what the game actually does, that is exactly the kind of report our contact page exists for.
What gets a game removed
A rights incident, an upstream removal, an expired license or repeated load failures all lead to the same place: the game is disabled with a recorded reason, and it disappears from cards, routes, the sitemap and structured data in the same build. Re-enabling requires the full evidence chain again — rights, provider status and review — not just a settings toggle.
Why all of this shows up on the page
The facts table on every game page — controls, devices, orientation, estimated session length, accessibility notes — is the same data the publication pipeline checks. You should not have to launch a game to learn it will not fit your phone, your keyboard or your five minutes. The four games featured in this guide each came through this pipeline; every listing on the site goes through the same gate.
The re-test: games drift, so we look again
A passing review is a snapshot, not a lifetime pass. Third-party games change without notice — providers update builds, swap ad slots, or let domains lapse — so listed games carry a re-test date and rotate back through the same checks. The gates that were true on launch day are re-verified on schedule: still licensed, still playable in this browser, still the game the page describes. A game that fails a re-test is hidden before it wastes anyone's five minutes, and it comes back only when it passes again.
This is also why the catalog shrinks as well as grows. Removing a game that stopped working is treated as maintenance, not loss — the alternative, a directory full of dead thumbnails, is the failure mode this whole process exists to prevent. Every removal and every return is recorded in the game's own review trail, so if you ever wonder why a page disappeared, the answer is written down.
The paper trail: what a review record contains
Every listing decision leaves a record, and the record is deliberately more detailed than the page. A review trail captures what was tested and when, which build of the game ran, what the licensing chain looked like on that day, and the reviewer's hands-on notes — including the notes that argued against listing. When a game later breaks or gets removed, the trail answers why with a date attached, which is what turns curation from an opinion into an audit.
It also protects the honesty statements players rely on. The claim that a page does not host a certain clone, or that a game plays on both desktop and mobile, is only as good as the check behind it — and the trail is where the check lives. When a guide on this site says a game was played before it was described, the paper trail is that sentence's receipt.
