Taking back your website after the volunteer who built it leaves

“Hey!! So sorry, I don’t remember the password, I think it was on my old laptop? Try the info@ email maybe. Miss you all!”

That’s the reply, sent from an airport, to the question nobody thought to ask while Marcos still came to Thursday meetings. Marcos is made up. The situation is common enough that you may have just felt a small chill.

Volunteers build a lot of good websites. They do it for free, on weekends, because they believe in the work. The problem starts later, when the site has to change and the only person who knows how is gone.

The conversation that never happens

Here is how it usually goes. A board member’s nephew, or a parent with a design job, or a retired engineer who likes a project, offers to build the site. Everyone is grateful. The site goes up, it looks better than the old one, and for two or three years it quietly works.

Nobody writes anything down, because there’s no reason to. Marcos is right there. If something breaks, someone texts him and he fixes it on Sunday night. The arrangement runs on goodwill and a phone number.

Then Marcos gets a new job in another state, or has a baby, or simply gets tired. He leaves on good terms. There’s cake. Six months later the executive director needs to post a job opening. That’s when she discovers that the only person who can log in to the website was the guest of honor at the cake. Nobody can find the job posting page, let alone edit it.

Write down where everything lives, today

A website is really three things: the domain (your address), the hosting (where the files live) and the site builder or code itself. Each one has a login. Find all three, put them in your organization’s name and keep them somewhere two staff members can reach. We wrote about the domain part in who owns your website.

Then keep going, because a website has relatives. Make a short list of every account that touches it, with the login email for each:

• The domain registrar, where the address is renewed every year or two.
• The hosting or site builder account.
• Google Search Console, which shows how your site appears in Google.
• Your Google Business Profile, the listing people see on Maps.
• Analytics, if anyone set it up.
• The inbox that receives your contact and donation forms.

Some of these accounts have rules about who’s in charge. Google Search Console says a property must have at least one verified owner, or nobody can get in. A Google Business Profile can have several owners but only one primary owner. If the only owner on either one is a volunteer’s personal Gmail, you know where your next problem is coming from.

Your organization’s name, two people, one safe place

The fix is boring, which is a good sign. Each account should be registered to an email address the organization controls, ideally a shared one like web@ that doesn’t belong to any single person. At least two staff members should be able to get into each account. Their own logins are better than one shared password passed around.

Keep the credentials in a password manager the organization pays for, so access survives people coming and going. A spreadsheet called “passwords FINAL v2” on someone’s desktop doesn’t count, however carefully it was made.

Once a year, when you renew the domain or approve the budget, open the list and check it. Does every login still work? Is anyone on it who left? It takes about an hour, and the person who checks it should be on staff.

Find out who can change an event date

Try this: ask whoever is around this week to update the date of your next event on the site. If the answer involves waiting for someone, the site is only half yours. Dates, staff names, a new program or a new photo should be things your own team changes in a few minutes, without fear of breaking the homepage.

Watch what happens when they try. A small community kitchen we can all imagine has a volunteer coordinator who knows exactly what needs to change and is perfectly comfortable with email and spreadsheets. She opens the site editor, sees a wall of boxes labeled “div block 47” and closes the tab. The site technically lets her edit. In practice it doesn’t.

If that sounds familiar, the issue is the setup, and it can be fixed. A good site gives non-technical staff clear, labeled fields for the things that change often: events, team members, programs, news. The layout stays protected, so nobody can break the homepage by accident.

Custom isn’t always kinder

Some volunteer sites are built with a lot of heart and a lot of custom code. That’s wonderful until something needs fixing and nobody else can read it. When you rebuild, ask for a site your staff can edit in plain language, with short training and a written guide they can come back to.

Whoever builds the next version, volunteer or agency, these are fair questions to ask before anyone starts:

• Whose name and email will every account be under?
• Which parts of the site can our staff edit on their own, and which need a developer?
• Will you train two of our people, and leave a written guide in plain language?
• If you disappear tomorrow, what would another developer need to take over?
• What does the site cost to keep running each year, and who gets the bills?

A good builder answers these happily. They’ve probably inherited someone else’s mystery project themselves.

The ones we see most often

Most of the trouble comes from a few small decisions that seemed harmless at the time. These are the ones worth checking for now:

• The domain renews on a volunteer’s personal credit card, so the renewal notice goes to someone who no longer reads your mail.
• The contact form sends messages to a former volunteer’s inbox, and nobody notices until a donor asks why nobody wrote back.
• The site runs on plugins or add-ons that nobody has updated since the person who installed them left.
• There’s a newer copy of the site on someone’s laptop that never went live, and nobody knows which version is the real one.

That second one deserves a test. Fill out your own contact form today and see who gets it. We wrote more about this in who reads your website forms.

Keep the volunteer, change the setup

None of this means you should stop working with volunteers. Set things up so their generosity doesn’t turn into a single point of failure. A good handoff is a gift to the next person, and to the volunteer, who would rather not get texts about passwords at airports.

If your volunteer is still around, have the handoff conversation now, while it’s friendly and nobody is in a hurry. Ask them to walk two staff members through the accounts, move each one to the organization’s email and record a short screen video of how they update things. Most volunteers are relieved to be asked. They’ve been quietly worried about the same thing.

If they’ve already left, start with what you can reach. The domain registrar and the hosting company usually have a way to prove you’re the organization. Your own advisor or the provider’s support team can tell you what they’ll need to see. It takes longer than a text to Marcos, so start the week you notice the gap.

If your site depends on someone who isn’t around anymore and you’d like a plan to bring it home, book a 30-minute call and we’ll map out who holds what.

Get new pieces when they land

No schedule and no newsletter template. A short note when there is something worth reading, and nothing else. The list is not shared.

Leave this empty Sign up