An event website is not one website. It is three, running in sequence on one domain, and it changes job twice inside a few days. Most are built for the first job, half-built for the second and abandoned before the third, which is why so many get rebuilt from nothing every year. The wider picture sits on our marathon and event marketing page; this is the build.
Phase one: the site that sells
For most of its life the site does one job: turning interest into payment.
Above the fold, five facts and nothing in front of them: the date, the city, the distances, the price and the deadline. Run The Street, Equathon and Kiddathon draw three different audiences, and all three visitors look for those five facts first.
Under that, a page per category. A distance category is a landing page in its own right: start time, cut-off, age eligibility, what the entry includes, its own registration link. A children's category, as at Kiddathon, is read by a parent, so it carries safety detail an adult category does not need.
Then the registration flow. Short, mobile-first, money before paperwork. A group entry needs its own path, because an HR desk entering forty colleagues needs an invoice, not a form built for one. Those funnel decisions belong to event registration marketing; the site is where they work or fail.
Phase one also carries the sponsor-facing section, which most events bury. A prospective sponsor should reach the inventory, the deck and a named contact without asking, because that is how the sponsor conversation starts long before a meeting.
Phase two: the site that instructs
In race week the site stops persuading. Everybody reading it has already paid, and every one of them has an operational question.
What belongs on the page, in plain blocks: the route map, start times by category, kit collection windows and address, parking, baggage, hydration and medical points, cut-off times, the bib list with a lookup, and after the gun, timing and results.
The traffic pattern is what surprises people. It arrives in one burst on race morning, from mobile phones held by people standing in a queue on a patchy network with a start gun minutes away. That is a performance requirement, not a refinement: the race-day view must be light and readable on a bad connection, and the bib lookup cannot be a query that hits the database once per impatient tap. A site that is slow on race morning is slow at the only moment it was built for.
Make the change a scheduled switch rather than a rebuild: on a set date persuasion moves down the homepage and instruction moves up.
Phase three: the site that remembers
After the finish line the site takes a third job, and this is the one nearly always thrown away.
Results stay live and findable, by name and by bib. The gallery goes up and stays up. The edition is archived at its own stable URL, results and route and categories intact, while the main pages move on.
Nearly every organiser does the opposite. Next year's site is published over last year's, the old pages vanish, and the event starts again from nothing.
Why overwriting last year's site is expensive
Three separate losses, usually unnoticed.
The proof a sponsor checks. A brand deciding whether to fund your fourth edition looks for the first three; if they are gone you are a proposal rather than a recurring property.
The memory a returning runner searches for. People look for their own time and their own photograph. Those searches carry the event's name and come from people already inclined to enter again.
The accumulated search relevance of the name itself. Every edition page, results page and gallery has spent a year gathering links and recognition. Deleting them resets that annually, invisibly, because nobody misses traffic they never saw arriving.
The fix is structural and cheap if decided at build time. Archive each edition under a dated URL of its own, keep the current edition at the canonical address, and never overwrite an old edition in place. That is ordinary website development discipline, and expensive to retrofit after two editions have gone.
The operational realities nobody scopes for
An event site is built under conditions no commercial project would accept.
One immovable launch date. Registration cannot open a week late to accommodate a build, because the calendar behind it is fixed and the sponsor commitments referenced it.
No webmaster. The committee is small, often volunteers, and there is nobody whose job this is. So content has to be editable by a person who is not technical, at eleven at night, from a phone, in the week when something changes daily. If correcting a start time needs an agency ticket, the start time stays wrong. Route maps, timings, collection windows and the bib list all need editing in place by a volunteer.
A third-party registration platform, most of the time. The site is the front door, the platform is the checkout, the handover should not look like a different company, and the participant data has to come back somewhere you can reach it.
A closed field changes the shape again. Hindustan Club runs events for its own membership, so there is no public sell to build and the effort moves to a members' calendar, an access check in front of registration, and pages that answer practical questions.
Digi Kydo, 17R Dover Terrace, Ballygunge, Kolkata, West Bengal 700029. Call +91 98305 45687 or write to [email protected].