Every site keeps a backstage page

Every multi-page site I build has a page the public never sees. It’s called the backstage, and it lists every page and every data feed on the site, with a tag that says where each one stands.

The problem it solves

A site in progress has pages in every state at once. The home page is live. A new services page is built but not deployed. There’s an experiment for a new hero that may never ship. There’s a data file feeding a map or a price list.

If the only way to reach a page is the public menu, the unfinished ones are hard to find. So people do the tempting thing and add a link to the menu “for now.” That’s how a half-built page ends up in front of a customer.

The backstage is the other place those pages can live.

What’s on it

It’s one file, _backstage.html, sitting at the root of the site next to the home page. It links every page and every data feed, grouped, and each row carries one of four tags:

• live means it’s deployed and public.
• local means it’s built and waiting for a deploy.
• sandbox means it’s a preview or an experiment, and it never deploys.
• data means it’s a feed the site reads, like a JSON file.

Every link opens in a new tab, so the backstage stays put while I click through. When a redesign is halfway done, each row also notes which skin the page is wearing, old or new. One look tells me what’s been brought up to standard and what hasn’t.

Why the underscore matters

The file name starts with an underscore on purpose. The deploy step skips any file that starts with _ or ., so the backstage and every _preview- sandbox page stay on my machine and never reach production.

That’s a rule the build enforces, not one I have to remember on a busy day. I can’t forget to remove the backstage before launch, because it was never going to ship.

The rules around it

It never goes in the public nav. Neither does any unfinished page. The backstage is the only place an orphan or in-progress page gets linked, until I decide to promote it.

Every row has to answer. Before I rely on the backstage, each link gets checked for a 200 response. A row that points at nothing is worse than no row.

It stays current. When a page gets added, it gets a row. On bigger sites a small build step can read the page titles and write the rows itself, so the list can’t drift from the folder. On a small site I keep it by hand.

A page earns its way into the menu. Before anything moves off the backstage and into the public nav, it gets a responsive check: phone, tablet and desktop widths, with the mobile menu opened and closed.

It records the port. When I preview a site locally, the port I used goes on the backstage row. The next session reuses that server instead of starting a second one.

What it means for a client

Mostly, you’ll never see it. That’s the point. What you’ll notice is what’s missing:

• No “coming soon” page sitting in your menu.
• No experiment going live because someone forgot it was there.

When I’m working on your site, I can open every page in every state from one place, and none of the unfinished ones can reach your visitors. When I send you a preview, it’s a page I’ve already found, checked and tagged.

It’s a small file. It stops a whole category of launch-day mistakes by giving unfinished work somewhere to live that isn’t your menu.