Most nonprofit websites were built once, by someone who has since moved on, and have been quietly decaying ever since. Staff listings are out of date. Programs that ended are still described. Programs that launched last year are not. Everyone knows it needs attention, and it never rises above the work that has a deadline attached.
It is worth being precise about what that costs, because the site is doing more work than most organizations give it credit for.
Four people arrive, and they want different things
A nonprofit website serves audiences that have almost nothing in common, often on the same page, usually within a few seconds of each other.
- Someone who needs your help. A family, a participant, a caseworker making a referral. They want to know whether they qualify, what happens next, and how to reach a human. They are often on a phone, often in a difficult moment.
- A funder doing diligence. Before a conversation and certainly before an award, someone will look you up. They are checking whether you look like an organization that can manage money: current programs, real outcomes, a named leadership team, a board.
- A potential partner. Another agency deciding whether to refer to you, collaborate, or write you into a proposal. They want to understand what you actually do and how it differs from what they do.
- Someone considering joining you. A job applicant, or a board candidate being recruited. They are deciding whether this looks like a serious organization worth their time.
A site built only for the first audience fails the other three. A site built only to impress funders fails the person who needed help today. The work is serving all four without making any of them hunt.
What a dated site actually costs
The cost is rarely a lost visitor you can point to. It is quieter than that, which is why it goes unaddressed for years.
- Funders draw conclusions you did not intend. A site that last changed three years ago suggests an organization with no capacity, whether or not that is true. Nobody writes that in a decline letter.
- People who needed you give up. If eligibility and intake are not obvious, some proportion of people simply leave. You never learn their names, so the loss never appears in any report.
- Staff absorb the gap. Questions the site should answer arrive by phone and email instead, one at a time, forever.
- Good candidates self-select out. Strong people have options and read your site before applying.
The damage from a weak website is almost entirely invisible, because it is made of people who quietly decided not to contact you.
Good does not mean beautiful
Design awards are not the measure here. A good nonprofit website is one where each of those four people finds what they came for quickly, on the device they are holding, and knows what to do next. That rests on a handful of unglamorous things.
- Structure built around the visitor. Navigation organized by what people came to do, not by how the organization is departmentally arranged.
- Plain language. Internal vocabulary is the most common barrier on nonprofit sites. People search for the words they use, not the words in your logic model.
- One obvious next step per page. Apply, refer, donate, call, download. A page that ends without an action wastes the attention it earned.
- Mobile first, genuinely. Most visitors arrive on a phone, and the person in the most urgent circumstances is the most likely to be on one.
- Accessibility. Contrast, heading structure, alt text, keyboard navigation. For an organization serving people with disabilities it is also a credibility question.
The pages that quietly do the most work
If you only have budget and energy for a few, these are the ones that earn it.
- A real page per program. Who it serves, eligibility, what happens, how long, how to start. Not a paragraph: the specifics someone needs to decide whether it is for them.
- Leadership and board. Funders look for this first. Names, roles, photos. Its absence reads as something to hide.
- Outcomes, not just activities. One honest number beats a page of adjectives. If you know what changed for the people you served, say so.
- An obvious way to make contact. A phone number that is not three clicks deep, and a form someone actually monitors.
Maintainability is the whole game
This is the part that determines whether any of the above survives. A site your staff cannot update is a site that will be out of date within a year, no matter how good it looked at launch. Every stale nonprofit website was once a new one.
So the questions worth asking before any rebuild are not about design. Who will update this? Can they do it without calling a developer? Is the software still receiving security updates? Is there a backup? If a rebuild does not answer those, you are buying the same problem again with a newer typeface.
How to tell whether yours is working
You do not need to guess. Free analytics will tell you, and the questions are simple.
- Where do people enter? It is often not the home page. Whatever page people land on most is your real front door, and it should be your best page.
- What do they do on a phone versus a desktop? If mobile visitors leave faster, the mobile experience is the problem, not the content.
- Do they reach the action? Track the things that matter: contact form sent, application started, resource downloaded. Pageviews alone tell you very little.
- What did they search to find you? This tells you what people think you do, which is sometimes a surprise, and shows which words belong on your pages.
Start with that last one. Organizations are often being found for something other than the work they most want to be known for, and the fix is usually a page that does not exist yet.
A reasonable place to begin
You do not need a rebuild to make progress. Pick the three pages that get the most traffic and bring each one current: accurate program detail, a named contact, one clear next step. Fix the staff and board page. Confirm your phone number is right on every page it appears.
That is a short afternoon and it addresses most of what a visitor actually judges you on. A rebuild is worth doing when the structure itself is wrong or the software is no longer supported, but it is not a prerequisite for being clearer than you are today.
Related Service
The Website Development Engagement
See how a CAMPBELL engagement approaches this work, including the phases, the deliverables, and how to get started.
Explore the engagement →