Insight ·
Should my game's website be on the same domain as the game?
For indie developers with a browser game: why the website should sit at the root of the domain, with the game on its own path, and what to check before moving.
The short answer: yes, in most cases. Put the website on the root of your game’s domain and the game itself on its own path, such as /play/, or a subdomain. That way the name’s domain is a proper front door that explains the game, and the game is one click behind it.
This is mainly for browser games, where the game runs on a web page of its own. If your game is on a store, the same thinking applies to where you point people.
The problem with the game at the root
A browser game is usually one page that runs a canvas. It has almost no text for a visitor or a search engine to read, and it loads a large download before anyone sees anything. If that is the page at your main address:
- search engines have nothing to index except a title;
- a link in a message or on social media previews badly;
- press and creators have nowhere to find a press kit or screenshots;
- a first-time visitor is dropped into a loading bar with no idea what they are getting.
The options
| Layout | What it means | My view |
|---|---|---|
Website at the root, game at /play/ |
One domain; the game is a path | The one I use. Everything stays together, and the website carries the name. |
Game on a subdomain (play.name.com) |
The game has its own address; the website is at the root | Fine, and a little more separate for search engines than a path. |
| Two different domains | The website and the game live apart | Splits your links and your name between two places. I would avoid it. |
| Game at the root, website as a few extra pages | The canvas is the front page | The weakest for search and for first-time visitors. |
Why the path works well
- The website is the indexable front door. The game page is marked so search engines follow it but do not index it, and the website pages carry the title, the description and the structured data.
- One domain gathers the links. Every link to the game’s address helps the same place.
- The deploys are separate. Many game build scripts replace their whole folder every time. If the website lives in its own folder, a game deploy cannot overwrite it.
- The game barely changes. Browser games usually load their files relative to their own page, so they work unchanged under a path.
What to check before you move a live game
This is the part to be careful with, because a game that is already live may have things depending on the address:
- Links in the wild, including ones that carry a place or a player in the web address. These need to redirect to the new path with their details intact.
- Any server routes the game talks to, such as a leaderboard, a WebSocket connection or an account service. They usually need to stay exactly where they are.
- Other systems that call your domain, for example a hub that fetches a file per player.
- Saved progress. If it is stored in the browser, check it is tied to the domain and not the path.
- Your deploy script, if it verifies the live address after uploading.
I list these first, probe each one before and after the change, and keep the game itself untouched.
An example
When I put a website at the root of The Unfinish’d’s domain and moved the game to /play/, the list was long: a game WebSocket, a per-player file fetched by another system, links that opened the game at a place, a wiki and a set of land pages. All of them kept working. You can read about it in the case study, and the service is described on the indie game websites page.
What to do next
If your game is live and you are wondering whether to move it, send me a short message with what it is and where it is hosted, and I will say what I would check first.