The Healthy Nonprofit Website: An Ownership Guide

Ask who owns your website and most nonprofits point to a line in an old agency contract. But nonprofit website ownership isn’t really a legal question — it’s an operational one. The site is yours when your team can log in, change what needs changing, and recover from a bad day without waiting on anyone’s goodwill. By that test, plenty of organizations don’t own their websites at all; in practice, control sits with a former developer or agency that still has the passwords.

This guide is that test in checklist form: what you should control, the habits that keep a healthy nonprofit website healthy, and a realistic look at what your team can carry versus where outside support makes sense.

The ownership inventory

There are six things to check, and for each one the question is the same: who on your staff could produce it within a day?

If any of these comes back “we’d have to ask our old developer,” fix that before anything else on this page. The rest of this guide assumes your team can actually get in.

The health checklist, by rhythm

A healthy site is mostly the product of small habits done on a schedule rather than bursts of heroic effort.

Weekly. Verify that backups actually completed, because a backup job can fail quietly for weeks if nobody looks at it. Apply CMS and plugin updates, then click through the site’s most important pages to confirm nothing shifted.

Monthly. Load your key pages on a phone and notice what’s slow. Submit every form that matters, donation form included, and confirm the confirmation arrives. Check the month’s new content for accessibility drift: missing alt text, skipped heading levels, low-contrast text. WCAG 2.2 AA is a reasonable baseline to hold, and this kind of gradual drift is usually how sites end up below it.

Quarterly. Read the site the way a stranger would: staff lists, program descriptions, event dates, board pages. Outdated content erodes trust faster than an outdated design. Then do a short security review: remove user accounts that no longer belong, delete plugins you stopped using, and confirm exactly who holds admin rights.

The staffing reality

A communications team can genuinely own most of this: content edits, publishing, images, form tweaks, and the weekly and monthly checks above. None of it requires code, just access, a checklist, and a calendar that someone actually follows.

Some work does need a developer: untangling a plugin conflict after an update, changing templates or theme code, wiring up an integration, responding when the site goes down or gets compromised. That is specialist work at organizations far larger than yours, too, so there’s no shame in needing help with it. The real problem is when those jobs have nobody’s name next to them.

Warning signs of an unhealthy site

These patterns show up again and again in the sites we inherit:

• Simple content changes wait weeks, because nobody feels safe touching the site.
• Everything lives in one person’s head (often a volunteer), and there is no real plan for what happens if that person leaves.
• Passwords are unknown, or sitting in the inbox of someone who left two years ago.
• The domain or hosting is registered to a former agency, and emails about it go unanswered.
• No one can say when a backup was last tested, or whether one exists.

None of these fix themselves, and each one gets more expensive the longer it waits, because the repair eventually has to happen during an emergency instead of before one.

When to bring in support, and what good looks like

Bring in ongoing support when the checks keep slipping, when the person who “did the website” moves on, or when the list of things you’re afraid to touch keeps growing. At that point, a support partner usually costs less than the risk you would otherwise be carrying.

Good support has a shape you can ask for in writing. You want a named human who knows your site rather than only a ticket queue, and response expectations stated plainly, so you know what happens when something breaks on a Friday. You want proactive monitoring, meaning uptime, updates, and backups get watched before you notice a problem, and you want reporting written in plain language. Finally, full ownership should stay with you, so that leaving would be easy. That last item is a useful test of the whole relationship: if a prospective partner resists giving you full access, treat it as a warning.

That’s the standard we hold ourselves to. We’ve worked only with nonprofits since 2007 — more than 1,000 organizations — and we host on Pressable with 99.999% uptime. Whether you end up hiring us or someone else, ask for that same list in writing before you sign.