Auditing a game-server hosting website

Two classifications run side by side. The gaming classification looks for gaming vocabulary, multiplayer wording, player-community wording, named games such as Minecraft, FiveM, Terraria, Valheim or Counter-Strike, and the gaming category from the category engine. `gaming.classification` reports it and says in so many words that it does not mean the site operates game servers.

The hosting classification requires offer vocabulary: "game server hosting" or "serveur de jeu", player-slot pricing, a management panel such as Pterodactyl or Multicraft, dedicated or VPS offers, game instances or ports, and an order path such as `/order` or `/game-servers`. It only runs when the hosting, slots or panel signal is present, and needs two signals and a score of 30.

A community server's website that talks about its Minecraft world is gaming context. A company selling Minecraft server slots with a control panel is a host. Only the second gets the checks below.

`gaming.hosting_classification` documents the detection and its signals. `gaming.panel` reports a Pterodactyl or Wings panel only from public evidence — a mention, a login page fingerprint — and, when there is none, says that no panel is identifiable publicly rather than that none exists.

`gaming.infrastructure_recommendations` gives the infrastructure checklist of a hosting activity: capacity sized per game, network-level DDoS protection, a customer panel, monitoring, world and database backups, and a CDN for the website and downloads.

`gaming.server_monitoring` gives the monitoring checklist — uptime, CPU and memory, player count, centralised logs, alerting, per-instance health — and `gaming.backups` the backup checklist — worlds, databases, configuration, an off-site copy, retention and restore testing.

`gaming.database` reports database technologies only when the host's public documentation mentions them. No database is ever contacted.

DNS checks query `_minecraft._tcp` among the SRV records they look for, which is how a Minecraft server is commonly announced on a domain; `dns.srv` reports the targets and whether they resolve.

`infrastructure.ddos_protection` reports whether a provider publicly offering mitigation sits in front of the site. It performs no traffic test, and what a provider really enables for a customer is a private setting it cannot see.

For a site detected in the gaming category, the score gives DevOps, database and backup checks 1.2 times their base weight and monitoring, infrastructure and availability checks 1.25 times. The gaming category adds no rule module of its own; the hosting checks above are what make a host's audit different.

The scan never connects to a game server, never opens a game port, never logs into a panel and never measures latency or player capacity. It audits the website that sells and documents the service.

Every internal topic — backups, monitoring, databases, the capacity behind a slot — is either shown from public evidence or given as a checklist, never scored as a failure. Absence of public proof is not evidence that something is missing.

A host that wants a measurement of its game servers needs a tool that connects to them, from the regions its players are in; the website audit is the complement, not the substitute.

Each signal carries a weight. For gaming context: gaming vocabulary 8, multiplayer or PvP wording 10, player-community wording 6, each named game 10, and the gaming category from the category engine 12. The gaming classification needs two distinct signals and a score of 20.

For hosting: a game-hosting offer 22, dedicated or VPS offers 14, player-slot pricing 12, a panel mention 16, instances or ports 10, an order path 10, and 20 more when a panel is actually fingerprinted. Confidence is reported as low below 45, medium from 45 and high from 70.

The checklists of the host-only checks appear in the report as fix steps, and those checks are marked for manual re-verification: nothing a later automated scan can observe would prove that backups or monitoring now exist.