Journal
Get in touch

[ Journal ]

What a band website
actually needs.

Most band websites are built for the launch and then quietly fail on the day they matter most. Here is what earns its place, and what to leave until version two.

The Rolling Stones archive on desktop

Start with the two jobs

An artist site does two things. It sells — tickets, records, merch — and it holds the canon: the record of who this act is, which nobody else can be trusted to keep. Every feature request should be pushed against those two jobs. A tour archive is canon. A press kit is canon. A parallax splash screen is neither.

The order matters too. On any given day the majority of your traffic is looking for one of three things: when are you playing near me, where do I buy the thing, and what is the new release. If those three are not answered in the first screen, the rest of the site is decoration.

The tour list is the most-visited page you will build

It is also the one most likely to be an image. Dates set as flat artwork cannot be read by a screen reader, cannot be indexed, cannot be filtered by country and have to be redone by a designer every time a show moves. Keep dates as structured data, render them as HTML, and mark them up so search engines can show them as events.

Two details that pay for themselves: sort by the visitor's own location rather than chronologically, and never remove a past show. Old dates are the archive, and they are what people search for years later when they are trying to remember whether they were at that gig.

Mobile components from the Rolling Stones archive
Dates, releases and store first — the rest is decoration until those work.

Plan for the announcement, not the average Tuesday

Traffic to an artist site is not a smooth line. It is flat, and then a tour goes on sale and it is fifty times flat, for about ninety minutes. Everything that breaks, breaks then.

The usual culprits are unsurprising once you have watched it happen a few times: uncached pages that hit a database on every request, a hero video nobody compressed, a mailing-list signup that writes synchronously to a third-party API, and images served at full resolution to phones. Serve the pages as static wherever you can, put the dynamic parts behind a cache, and load-test the announcement path before the announcement.

Own the mailing list

Platforms change their terms, their reach and occasionally their entire existence. An email address is the only channel an artist genuinely owns. Put the signup somewhere honest rather than in a modal that appears over the thing the visitor came for, tell people what they are actually going to get, and store the list somewhere you can export from.

The same logic applies to the site itself. If the whole of an act's history lives inside a platform that formats it for you, you are one pricing change away from losing it.

What can wait

Fan accounts, forums, loyalty schemes and anything with the word "portal" in it. Not because they are bad ideas — some of the best work we have done is exactly this — but because they need an audience already arriving and someone whose job it is to run them. Build them when there is a reason, not because the deck had a slide for it.

Custom audio players usually fall here too. Fans have somewhere they already listen. Link out to it and spend the money on something that is only yours.

Accessibility is not a nice-to-have

Dark type on a photograph, dates as images, autoplaying video with no control and hover-only navigation will lock out a slice of the audience and, in most territories, put the act on the wrong side of the law. It is also cheap to get right at the start and expensive to retrofit, which is the whole argument.

The short version

Ship dates, releases, store and list first, in HTML, fast, on a stack that will not fall over at 9am on announcement day. Then build the interesting thing. We have never regretted that order.

[ Next ]

Working on
something like this?

Tell us where you are up to — info@modernenglish.co.uk.