Protect a Public Game Demo From Scraping and Downloads

You cannot make a public game demo impossible to copy: anything a browser or player downloads can potentially be saved or captured. You can, however, reduce bulk scraping, slow automated downloads, limit exposure, and make abuse easier to detect without blocking ordinary players.

What You’ll Need

• Access to your game host, web server, or content delivery network (CDN) settings.
• A list of the files and routes the demo genuinely needs, including game assets, APIs, and update files.
• Access to request logs or analytics, plus a way to test from a separate browser or network.
• If the demo has accounts or a backend, a plan for rate limits and abuse reporting.

Step-by-Step

1. Decide what you are protecting. Separate public demo files from private development material. Remove source maps, debug builds, editor projects, credentials, test data, internal documentation, and unreleased content from the public deployment. Check both the visible site and the actual files exposed by the host; hiding a link does not make a file private. Keep a clean release directory and publish only the files required to run the demo.
2. Reduce unnecessary exposure. Avoid publishing development archives or directory listings. Configure the server to return an error for requests to folders that have no public index, rather than showing their contents. Do not rely on obscure filenames or robots.txt to protect sensitive files: robots.txt is public guidance for cooperative crawlers, not access control. If a file must be confidential, do not put it on a public origin.
3. Put the site behind request controls. Use controls available from your host or CDN, such as per-IP rate limits, connection limits, bot challenges for suspicious traffic, and rules that temporarily block abusive patterns. Apply stricter limits to expensive API routes and bulk file requests than to the page itself. Set limits based on normal player behavior; shared networks, schools, and mobile carriers can put many legitimate users behind one IP address.
4. Protect backend endpoints separately. Validate inputs, cap request sizes, and limit how often each account or client can call costly endpoints. Require authentication only for features that need an account, and authorize every protected action on the server. Never embed secret API keys in client files. For downloads that should be limited to eligible users, use server-authorized, short-lived links where appropriate; a permanent public asset URL remains shareable.
5. Make automated bulk retrieval less convenient. Keep large assets split and delivered only when needed, rather than offering an unnecessary all-in-one package. Set sensible cache headers for stable public files, and monitor unusually high request rates or repeated sequential downloads. Do not treat JavaScript obfuscation, disabling right-click, or hiding browser controls as security: they do not prevent saving network responses or capturing gameplay.
6. Set crawler guidance, but treat it as optional. Publish a robots.txt file if you want compliant search crawlers to avoid selected paths. Use page-level crawler directives only for search-indexing preferences. Neither approach stops a scraper that ignores them, and neither should contain secrets or reveal sensitive routes. For actual restrictions, enforce rules at the server, CDN, or application layer.
7. Log and alert on useful signals. Record request time, route, response status, and rate-limit actions while minimizing personal data. Look for bursts, repeated sequential asset requests, unusual error rates, and traffic that differs sharply from ordinary play. Set alerts for meaningful thresholds and keep logs only as long as needed for operations. A single unusual request or user-agent string is not proof of scraping.
8. Test the player experience and response plan. Load the demo as a normal player, including on a slower connection and from a shared network if possible. Confirm assets load, APIs still work, and legitimate users are not repeatedly challenged. Simulate a burst against a staging environment or with a low, controlled request rate—not a production stress test. Document how to tighten a rule, review a block, and restore access if a control causes false positives.

Common Mistakes

Assuming public files can be made uncopyable: If a player can receive an asset, a determined person can often retain it. Focus on reducing exposure and abuse rather than promising prevention.

Blocking by user-agent alone: Scrapers can change or omit this header, while legitimate tools may use unfamiliar values. Combine signals such as request rate, route, and behavior.

Setting aggressive IP limits: A low threshold can affect many real players behind one shared address. Start conservatively, measure impact, and provide a way to report access problems.

Blocking every automated client: Some accessibility tools, monitoring services, and search crawlers are automated. Decide which traffic you need, then apply targeted rules instead of broad, unexplained blocks.

Trusting client-side checks: Checks in game code can be inspected or altered. Enforce access, rate limits, and important gameplay rules on a server you control.

Tips

• Keep a known-good deployment so you can roll back a rule or release quickly.
• Use a separate staging hostname to test CDN rules and application changes before applying them to players.
• Serve only the resolution, language, or platform assets the player needs when practical.
• Show a clear, brief message when a challenge or rate limit blocks access, with a support route if available.
• Review controls after each demo update; new APIs and file paths can create new exposure.

Troubleshooting

Players report that the demo is blocked: Check the CDN or server logs for the matched rule and response status. Temporarily relax the specific rule, not all protections, and test from a shared network. Add a narrow exception only after confirming the traffic is legitimate.

Assets fail to load after adding restrictions: Use the browser’s network panel to identify the failing request. Check whether a rate limit, hotlink rule, or access policy also blocks required asset and API routes. Allow the necessary origins and methods, then retest a full play session.

Scraping continues: Confirm the requests are reaching the protected host and that the rule applies to the right hostname and paths. Add controls to the actual origin as well as the CDN where possible; otherwise, someone may bypass the CDN and request the origin directly. Restrict origin access to the CDN when your hosting setup supports it.

Traffic spikes but the cause is unclear: Compare request paths, timing, response codes, and volume with normal traffic. Check for a release, a popular link, or a misconfigured client before blocking. If the pattern is clearly abusive, use a temporary targeted limit and keep reviewing its effect.

Frequently Asked Questions

Can I stop people from downloading a browser game?
No. A browser must receive the code and assets it runs, and users may save or capture them. You can remove unnecessary files and make bulk access harder.

Does robots.txt stop AI crawlers?
No. It requests that compliant crawlers avoid listed paths, but any client can ignore it. Enforce real access restrictions on the server or CDN.

Should I require a login for every demo?
Not necessarily. A login can add friction and does not prevent an authorized user from copying public assets. Use accounts when they support a real feature or access requirement.

Will a CAPTCHA protect every download?
No. Challenges can inconvenience players and may be bypassed or outsourced. Apply them selectively to suspicious behavior, alongside rate limits and server-side controls.

Can I block all traffic from data centers?
That may reduce some automated traffic, but it can also block legitimate players using VPNs, cloud gaming, or other services. Prefer targeted, observable rules and provide a way to report false blocks.

What should I do if a scraper gets through?
Preserve relevant logs, remove any exposed private material, and rotate credentials if secrets were accidentally published. Tighten the specific route or rate rule, check for direct-origin access, and verify that legitimate play still works.

Related

• Multi-Model Database: How It Works and When to Use One
• Validate AI-Generated Hardware Designs Before Prototyping
• Website SEO Through Hosting: A Practical Guide