A community garden's website was built by a volunteer who knew what he was doing and kept everything in his own head. He was generous with his time, picked a decent content system, and made it look tidy. He hosted it on his personal hosting account, under a domain registered in his name, because that was the quickest route and nobody on the committee had expressed a view.
For three years that was perfectly fine. Then he moved abroad and became hard to reach. A plugin update broke the events page, and nobody on the committee had a login. The domain was approaching renewal, and the registration email went to him.
They eventually recovered access, and then did what should have happened at the start: moved the domain and hosting to the organisation, and wrote a one-page document saying where everything is. This composite story is about a risk that has nothing to do with hackers or faulty servers. The risk is a single person who is the only one who knows how things work.
How it started
Most community websites begin the same way. Somebody says "we should have a website", and somebody else says "I can do that". The volunteer was happy to, and did a good job. He registered the domain with his own email address, since it needed one. He set up the hosting on an account he already had for a personal project, because adding a site to it cost nothing. He installed WordPress, created an administrator account for himself, and chose a theme. The committee saw the finished result and applauded.
No part of this was careless. It was efficient. The trouble is that every decision tied the garden's online presence a little more tightly to one person: the domain registration, the hosting contract, the administrator login, the email address that received password resets and renewal notices, and the knowledge of how the pieces fit together.
Organisations of every size do this, and small ones do it with the best intentions. The committee did not ask who owned the domain because nobody thought of it as an asset. It was just "the website".
What the committee found when he left
The events page was the first thing to fail. A plugin that drew the calendar was updated automatically on the server, and the new version no longer worked with the theme. The page showed an error message instead of the list of planting days. The secretary, who had never edited the site, tried to log in at example.org/wp-login.php using a password she half remembered from a meeting. It was refused.
She used the "lost your password" link. The reset email, of course, went to the volunteer's own address, which he checked every few days from another time zone. He eventually replied, but the reset link had expired by then, and a second request produced a second delay.
The deeper discovery was about ownership. When someone looked up the domain, the registrant was the volunteer, personally. The registrar's renewal notice was due in five weeks. If it had been missed, the domain would have lapsed, and a lapsed domain can be picked up by anyone after a redemption period, along with the web traffic and the links pointing to it.
Getting back in
Recovery took about three weeks, mostly spent waiting. The committee worked through it in an order that is worth copying, because the order matters.
- Reach the volunteer by every route available, and ask for three things: a transfer of the domain to the organisation, a full copy of the site, and the administrator credentials. He was cooperative, just busy, and agreed to a video call at a time that suited his new time zone.
- During the call, create a second administrator account in the content system tied to a role address the committee controls, such as
[email protected], and confirm that it can log in and edit. - Log in to his hosting account together, export the files and database, and download them straight away. Having a copy before changing anything is the safest position.
- Start the domain transfer, which needs an authorisation code from the old registrar and approval from the current registrant. The registrant details were then changed to the organisation's name and shared address.
- Set up a new hosting plan in the organisation's name, restore the copy, and test it on a temporary address.
- Switch DNS to the new host at a quiet time, with a short TTL in place beforehand, as the TTL planner suggests.
The broken events page was the smallest part. Once they had a way in, they rolled the plugin back to the previous version from the plugin's page, and later replaced it with one that was still maintained. They also switched off automatic plugin updates for the time being and started applying them by hand, after taking a backup, with a note in the shared calendar.
It was also a lesson about the content system itself. The committee decided to keep the site deliberately plain: fewer plugins, a standard theme, and a monthly check of what had been updated. Every extra plugin is one more thing that can break while the only person who understands it is on another continent, and a plain site is cheaper to hand on to the next volunteer.
The one-page document
The most useful output of the whole episode was a single sheet. It did not try to be a manual. It answered the questions a stranger would ask on a bad day:
- Which company holds the domain registration, which email address is on it, and when does it renew?
- Which company hosts the site, on which plan, and who pays?
- Where is the administrator login, and which two people hold an account on it?
- Where do backups go, and how often, and who has checked that a restore works?
- Who receives mail for the role addresses, and what are the recovery steps if that person leaves?
- Which outside services are connected (a newsletter tool, a donation page, a map embed), and who owns each account?
Passwords themselves went into a shared password manager, not onto the page. The page said where to find them. It sits in the committee's shared drive and is printed once a year and stapled into the minute book.
How to check your own organisation
Take half an hour and look at what you have. Search the domain at a registrar's lookup page or run:
whois example.org | grep -iE "registrant|registrar|expir"Many registrars hide personal details behind a privacy service, in which case the lookup shows less, but the registrar's account owner is still the person who can renew or transfer the domain. Ask who that is. Do the same for the hosting account and the content system, and look at the user list for administrator accounts.
Then find out where renewal and security emails are going. If the answer is a personal address, change it to a role mailbox that several people can read. You can estimate how soon things lapse with the SSL expiry checker, which shows the certificate dates, though the domain and hosting renewal dates must be read from the accounts themselves.
The takeaway
Ownership of the domain, the hosting and the logins belongs to the organisation, not to whoever happened to set them up. Keep two administrators, a shared mailbox for renewals, and a one-page note of where everything is.