A game is not complete because its loading screen appears.
Our release checks cover the full playable loop, the surrounding game page, search-readable content, and failure recovery. Test notes distinguish automated browser emulation from physical-device checks.
For every maintained Original we check entry or start, the first meaningful input, core mechanics, visible feedback, success or failure, settlement, and retry. We also check pause or focus loss and the bounded loading recovery path.
Desktop and mobile layout
The automated viewport set is 1440×900, 1024×768, 430×932, 390×844, 375×812, and 360×800. Checks cover horizontal overflow, playable-stage fit, minimum control size, focus visibility, and intentional portrait or landscape guidance. Current recorded mobile results are Chromium emulation unless a game record explicitly names a physical device.
Search and content checks
We verify one canonical URL and H1, unique title and description, visible HTML instructions, working internal links, structured data that matches visible copy, sitemap eligibility, screenshot paths, and an explicit rights record.
Startup and old-cache resilience
Canonical game pages contain a direct runtime URL in their HTML. Shared site assets carry a release identity. Loading must become playable, show a clear retry state, or fail visibly within a bounded period; registry and account enhancements are not allowed to block the game.
Known verification boundary
Automation cannot prove visual polish or real touch ergonomics. Before an AdSense resubmission, the site owner still needs to play every affected game on a desktop browser and at least one physical phone, record the result, and resolve any mismatch with the published controls.