What breaks in a club website after six months.
A club website is delivered on a party night and dies in silence. Here is what we find six months later, in the order it happens, and what to plan for at launch so it does not.
Why six months
Six months is a season. The site was delivered before the September opening, with the autumn programme, the photos from the opening night and a “book a table” button that worked. In March, everything is still online. Nothing has been hacked, nothing shows a visible error. But a customer arriving from Google sees a site talking about another moment, and they leave. What follows is the list, in order of frequency, of what we find when a club or venue manager calls us to “redo the site”. Most of the time it does not need redoing; it needs the things that were never planned for to be fixed.
The programme stops in March
This is the first symptom and the most visible one. The “Nights” page still shows December’s dates, or worse, it is empty because someone deleted the past events without adding new ones. The Instagram account, meanwhile, is up to date: that is where the team posts, because that is where it is easy.
The cause is not laziness, it is the tool. Adding a night means opening a computer, remembering a password, resizing an image, filling in twelve fields. At 6 p.m. on a Friday, nobody does that. The site we deliver has a publishing interface designed for a phone: a poster, a date, a title, a booking link. Two minutes. And past nights disappear from the home page on their own without being deleted, so the archive page keeps existing and keeps being indexed.
The booking link goes nowhere
The “Book a table” button pointed to a form, a WhatsApp number or a ticketing platform. Six months later, the platform has changed address, the number belongs to a host who has left, or the form sends its messages to an inbox nobody opens any more. The customer clicks, nothing happens or nobody answers, and they book somewhere else.
Two rules at launch. First: every outbound link is listed in a document the manager owns, with the date it was last checked. Second: the booking must land somewhere the team looks at anyway — a floor tool, not a dedicated email inbox. That is one of the reasons we built NightBook: a booking from the site drops into the list the head waiter already has in front of them.
The opening hours contradict each other
The site says “open Thursday to Saturday, 11 p.m. to 6 a.m.”. The Google listing says “Friday and Saturday”. Instagram says something else in the bio. None of the three is completely wrong: the hours changed in January and only one of the three sources was updated.
For Google, that is an inconsistency signal that costs local ranking. For the customer, it is a wasted trip to a closed door. The technical fix is simple: the hours exist in one place only, in the site, and the Google listing is updated from that same data, through an API or a monthly routine. The human fix is less simple: someone has to own that data, and it is written into the handover training.
- Hours: one source, the site.
- Google listing, Instagram, directories: copied from that source, never entered separately.
- One named person, one monthly reminder.
The images weigh four megabytes
The site was fast at launch because we compressed every image. Since then, the team has added thirty posters exported straight from the designer’s software, 4,000 pixels wide and 4 MB each. On a phone, at the door, on a saturated 4G network at 1 a.m., the home page takes eight seconds to appear. Nobody waits eight seconds.
It is not the manager’s job to compress images. The site must do it on its own: every uploaded image is converted, resized for the screens that request it and served in a modern format. In Next.js, that is the image component’s job, provided it is used everywhere, including for images added after launch:
<Image
src={night.poster}
alt={`Poster for the ${night.title} night`}
width={1200}
height={1600}
sizes="(max-width: 768px) 100vw, 50vw"
/>
The alt text is written from the night’s title, not left empty: that is what Google reads, and what someone who does not load images reads.
The form writes to nobody
The contact or private-hire form sent to the address of the person who ran the project. They have left. Or the sending went through a third-party service whose free trial has expired. Or the messages arrive, but in the spam folder. In all three cases, the site says “message sent” and the message arrives nowhere. For a private-hire enquiry, that is expensive.
Two measures. The form writes to a role address (privatehire@…), not to a person. And every submission is also recorded in a database the manager can consult, so that nothing depends on an email inbox. Once a month, a test message is sent and checked. That is in the maintenance contract because nobody does it spontaneously.
The domain, the certificate, the dependency
The three silent failures. The domain name was registered by a previous provider and the renewal email goes to them. The certificate expires because the host does not renew it on its own. A library the site uses is no longer maintained and a browser update breaks the photo gallery. None of the three gives any warning.
A site without maintenance does not go down. It stops working one piece at a time, and nobody notices before the customer does.
The domain name is in the club’s name, on an account the manager has the password to, with automatic renewal switched on. The certificate is handled by the host (Vercel does it). Dependencies are updated as part of a monthly maintenance contract, and the site is a static site: fewer moving parts, fewer things that break.
What to plan for at launch
None of this is a design problem. These are operational problems, and they are settled on the day of launch, not six months later:
- A publishing interface usable from a phone, in two minutes.
- Bookings that land in the floor tool, not in an email inbox.
- Hours in one place only, one responsible person, one monthly reminder.
- Images compressed by the site, not by the team; alt text generated from the content.
- A form pointing to a role address, with submissions recorded and a monthly test.
- Domain in the club’s name, certificate handled by the host, contractual monthly maintenance.
That is what we deliver with every club website, and what we check on our own products every week. If your site is six months old and you recognise three points from that list, it probably does not need rebuilding. It needs running.