Why our website showed a 404 inside a video game

There's a browser game called Destroy Any Website. You type an address, and the site becomes a level you run, jump and blast your way through. We typed hexerize.com, and instead of our home page the game loaded our "page not found" page. Plenty of other sites loaded fine. Here's why ours didn't, and what we changed.

How the game shows a site

The game doesn't open the site at its own address. It fetches the page and shows it from the game's address, with the original tucked into the path, something like /p/https/hexerize.com/. That's not unusual: web archives and some translation tools do the same kind of thing.

Why our site said "not found"

Until this week, hexerize.com worked like many modern sites. The server sent a mostly empty page and the code for the whole site. Each page's file had its title and description, and blog posts carried their text, but the page you saw was drawn by that code in your browser.

To decide which page to draw, the code read the address bar. Inside the game, the address bar said /p/https/hexerize.com/. That isn't one of our pages, so the code did what it was told and drew "page not found".

Sites that build their pages before they're sent didn't have this problem. Their page arrives finished, so it doesn't matter what the address bar says.

What we changed

Every page is now built in full ahead of time. Each time we publish, every page on the site is built into a finished page: the menu, the text, the pictures and the links. A blog post arrives as the whole post, and the blog page arrives with its list of posts.

The browser picks up where the page left off. When the site's code starts, it doesn't draw the page again. It takes over the page that's already there and wires up the buttons and menus. Then it checks for anything newer, like a post published since the last build, and fills it in.

Each page knows which page it is. Every page now carries a note of its own address. If the address bar ends with that address but has something extra in front of it, like the game's /p/https/hexerize.com, the site treats the extra part as a prefix and keeps showing the right page. On hexerize.com itself, nothing changes.

Now the game shows our home page, and you can blow it up properly.

The part that took care

The page built ahead of time and the page the browser would draw have to match exactly. If they differ, the browser throws the built page away and draws its own, and you see a flash. A few things we had to get right:

• Dates. A post's date is always written in the same time zone, so the build and every reader's browser write the same day, wherever they are.
• The year in the footer. It's written when the site is built, and updated in your browser if the year has changed since.
• Your settings. The home page's moving background holds still if your phone asks for less motion. That's decided once the page has loaded, since the build can't know your settings.

Why it matters beyond a game

• Pages show up sooner, especially on slow phones, because there's something to see before any code runs.
• Anything that reads only the page sees all of it: search engines, link previews on WhatsApp, translation tools, web archives and, yes, games.
• The site holds up when it's shown somewhere unexpected. A site that only works at its own address is more fragile than it looks.

If you build websites, try opening yours through a web archive. If it says "not found", you'll know why.