Get Started

Why club websites actually fail

A club website usually runs quietly for years, right through several changes of secretary or treasurer, until the person who actually built it or maintained it stands down. Nothing about the site itself has changed. What has gone is the one person who knew the login, or who was recorded as owning the domain, or who was simply the only one who remembered how the fixture list got updated each week.

Why it looks like a technical fault

When a committee can't log in to change a date or add a name, it looks like the site has broken. It hasn't. The pages that worked last season still work. What's missing is access, and most clubs only discover the gap when they need to change something and find they can't.

Where responsibility for the site actually sits

A club website isn't automatically owned by the club just because the club paid for it or uses it every week. The domain, the hosting account, even the login details, can all sit under one volunteer's name and email address, with nothing written down about what should happen when that volunteer leaves. Committees change on a regular cycle by design. Most websites aren't built with that cycle in mind, which is where the trouble starts.

What the governing document usually says, or should say, about who holds this on the club's behalf is covered separately: what your constitution or governing document probably says about digital assets. What to ask for from whoever is on their way out is set out in what to get from whoever is leaving, before they stop answering emails.

How it plays out

What breaks, and in what order

A club website does not lose its administrator and its domain on the same day. The problem moves through stages, and each one is harder and more expensive to put right than the last.

  1. The knowledge leaves with the person

    The moment someone stops being involved, whatever they knew but never wrote down goes with them: which registrar the domain sits with, which email address the hosting account is registered to, how the fixture list actually gets updated. The site itself looks exactly the same the next morning. That is what makes this stage easy to miss.

  2. Content stops moving

    Fixtures, minutes and newsletters stop being updated because nobody left on the committee has the login, or knows what to do with it if they did. A visitor arriving at the site sees nothing wrong, which is why members usually notice before the committee does.

    Someone finds a way back in

    A committee member guesses a password or tracks down an old email, and updates resume, unevenly and without anyone quite trusting the process.

    Nobody does

    Updates stop for good, and the site settles into whatever state it was left in by whoever last touched it.

  3. The renewal notice goes to the wrong inbox

    Domain renewals arrive by email, sent to whatever address was used when the domain was registered. If that address belongs to someone who has left, the notice sits unread. This is the point where the problem stops being an inconvenience and starts being a risk, because a missed renewal can mean the domain is no longer the club's to keep.

    The card on file still works

    The renewal goes through automatically, and the domain survives by accident.

    The card has expired

    The renewal fails quietly, and the domain moves towards expiry with nobody aware it is happening.

  4. The domain lapses

    Once a domain expires it typically has a short window in which it can still be renewed, and after that it becomes available for anyone to register. Getting it back at that point can mean negotiating with whoever picks it up next, with no guarantee of success. This is the stage that is genuinely hard to reverse, and the one everything before it exists to avoid.

Everything up to the domain lapsing is recoverable with some patience. Once it lapses, the options narrow considerably.

Why this keeps happening at every committee change, and what makes it stop

A club website usually gets built by one person, at one moment, out of goodwill. Someone on the committee is comfortable with computers, so they put a site together, register the domain, set up the accounts and keep it running for as long as they hold that role or that enthusiasm. Nothing is written down about what they did or how, because at the time there is no reason to write it down. The site works, so nobody asks.

The gap opens at the handover

Committees change on a cycle. Chairs step down, secretaries move on, treasurers hand over the books at the AGM. Most governing documents say a good deal about how officers are appointed and what they do while in post, but very little about what happens to the things an officer was quietly holding on the club's behalf: a domain registration, a hosting account, an admin login. The governing document (the constitution, rules or articles that set out how an organisation is run) is a natural place to look for this, and what it usually does and doesn't cover is worth checking on its own terms.

So the handover happens for the treasurer's role and the secretary's role, because those are named jobs with a known list of duties. It does not happen for the website, because nobody thought of it as a job at all. It was just something one person did.

Why it repeats

The next committee inherits a site that still works, so there is still no reason to ask who controls it. That question only becomes urgent once something breaks: a renewal fails, a login stops working, the person who knows the password stops answering emails. By then the person who could have answered easily is often long gone from the club, and sometimes hard to reach for anything.

This is not a technology problem. The software does not care who is on the committee. It is a succession problem (the committee-change cycle that is the underlying cause of most club website problems): the site's continuity depends on one person's memory and goodwill, and that person eventually leaves, with or without notice.

What actually stops it

Two things break the cycle. The first is a record, kept somewhere the whole committee can find it, of who the registrant is, where the domain is registered, and who holds the login to the hosting account and the email address it's tied to. A checklist for building that record is set out at what to get from whoever is leaving, before they stop answering emails. The second is making that record part of the handover itself, alongside the treasurer's accounts and the secretary's files.

Neither of these requires anyone on the committee to become technical. They just require someone to write down, once, the small set of facts that only exist in one person's head at the moment. After that, the website stops depending on which volunteer happens to be good with computers this year.