Building a Nonprofit Website Your Team Can Maintain

There is a version of this conversation that happens in every organisation, six to eighteen months after a website launch. The new site looked great. The agency was professional. The training session covered the basics. But now the comms coordinator has left, the person who attended the training has forgotten the CMS, nobody can find the login for the hosting panel, and the website that cost £30,000 to build is deteriorating for lack of anyone who knows how to update it.

This outcome is not bad luck. It's bad specification. The brief didn't include maintainability as a requirement — so the agency didn't build for it.

Maintainability Is a Design Requirement, Not an Afterthought

When you specify a website project, the question "can our team maintain this without specialist help?" should appear in the brief, the evaluation criteria, and the acceptance testing. If it doesn't, the agency will optimise for what they're measured on — typically visual quality, technical performance, and on-time delivery — not for the day-to-day reality of your communications team trying to update a programme page eight months after launch.

What "Maintainable" Actually Means

CMS That Matches Team Capability

A CMS is maintainable if a non-technical staff member can use it confidently after a half-day of training. Not a developer. Not someone with digital as their specialist background. A communications coordinator or an operations assistant. If the system requires technical knowledge to operate safely, it is not appropriate for a nonprofit team without dedicated technical staff.

Structured Content, Not Freeform Rich Text

The most maintainable content architecture uses structured fields — separate inputs for headline, body copy, image, and call to action — rather than a single rich text area where everything is formatted manually. Structured fields enforce consistency and reduce the risk of formatting errors that require developer intervention to fix.

Component-Based Page Building

If new pages require a developer to create, your team will stop creating them. A component library — pre-designed, accessible blocks that staff can assemble into any page configuration — means campaign pages, event pages, and programme updates can be published without technical help. This is the difference between a website that grows with the organisation and one that calculates its budget every time it needs a new page.

Documentation That Survives Staff Turnover

Institutional knowledge about how to use the website should live in written documentation, not in the heads of whoever attended the training session. This includes: how to publish different content types, how to update the navigation, where images are stored and what specifications they need to meet, how forms are configured, and who to contact for different types of issues.

Questions to Ask During Agency Selection

The Six-Month Maintainability Test

Before accepting delivery of any website project, ask the agency to demonstrate that a non-technical staff member can perform the following tasks without assistance: publish a new blog post, update a programme page, add a team member to the staff listing, upload a new annual report, change a phone number in the footer, and create a simple landing page for an event.

If any of these tasks require developer involvement, they are not yet complete requirements — regardless of what the project specification said.

Further Reading

• The Real Cost of Developer Dependency in Nonprofit Websites
• NGO Websites Are Governance Problems Not Design Problems
• Website Governance During Nonprofit Leadership Transitions
• Nonprofit Website Design: Governance Before Aesthetics

What Team Independence Actually Changes

Comms teams at organisations with maintainable websites describe the same shift: the website stops being a bottleneck and becomes a tool they control. A campaign page that would have taken two weeks to brief, develop, and launch now takes an afternoon. A programme update that would have sat in a developer's queue for ten days gets published the same day the information changes. Staff onboarding includes the CMS as a standard tool, not a specialist system that only one person knows how to use.

The website still requires investment and attention. But the nature of the investment changes — from reactive firefighting and developer dependency to deliberate, planned content work that the team actually has capacity to do.

Q1: What makes a nonprofit website genuinely maintainable by an internal team?

A maintainable website has four characteristics: a CMS that allows non-technical staff to perform all routine content tasks without developer assistance, structured content fields that prevent layout-breaking mistakes, comprehensive documentation that enables any trained team member to manage the site, and a platform with stable hosting that doesn't require regular technical maintenance. Most nonprofit websites fail on at least one of these — typically because they were built for launch rather than for long-term maintainability.

Q2: What CMS features make nonprofit website management accessible to non-technical staff?

The key CMS features for non-technical accessibility are: visual editing (content is edited in context rather than in code), structured content fields (text fields, image fields, date fields rather than a single rich text block), reference fields for relating content items without code, a clear media library for image management, and a publishing workflow that allows draft review before going live. Platforms like Webflow provide most of these natively; many WordPress configurations require additional plugins to achieve the same result.

Q3: How many staff members should be trained to manage a nonprofit website?

At minimum, three people at different seniority levels should have CMS access and training: a primary content manager (typically the communications coordinator), a secondary who can cover absences (typically the communications director or a senior programme staff member), and an administrator with full access for governance changes (typically the communications director or an operations lead). Single-person CMS dependency is almost as risky as full developer dependency — illness, resignation, or leave creates the same access gap.

Q4: What tasks should a nonprofit's internal team be able to perform without developer support?

Internal teams should be able to: create and edit all page content, upload and manage images with basic optimisation, create new blog posts and programme pages, adjust navigation if the CMS allows it, manage forms and update form destinations, publish and schedule content, manage CMS collection items (staff profiles, programme listings, news items), and access analytics. Any task on this list that currently requires developer support is a maintainability failure that should be addressed either through platform choice or training.

Q5: How do you reduce the risk of a team member breaking the website during content management?

Structural safeguards are more reliable than editorial discipline. Structured CMS fields — separate fields for heading, body text, and images rather than a single rich text block — prevent layout-breaking content errors. Component-based page building prevents inconsistent formatting. Image fields with defined aspect ratios prevent distorted layouts. Style guides and editorial guidelines document the standards that structure enforces. The goal is a CMS that makes the right content format the path of least resistance, so that mistakes require deliberate effort rather than careless action.

Q6: What documentation should accompany a nonprofit website for internal team management?

The documentation package should include: a CMS user guide covering every routine task with screenshots, a content governance document specifying who can publish what and what approval is required, a style guide covering writing standards, image standards, and formatting conventions, a vendor contact list for escalating technical issues, a credential register, and a troubleshooting guide for common issues. This documentation should be reviewed and updated every time the platform or governance framework changes.

Q7: How much time should a nonprofit budget for internal website management each week?

For an active nonprofit website with regular content publishing, budget 5-8 hours per week for a part-time content manager role: 2-3 hours for new content (blog posts, programme updates, news), 1-2 hours for content maintenance (reviewing accuracy, updating outdated information), 1-2 hours for analytics review and content performance assessment, and 1 hour for monitoring and miscellaneous tasks. This assumes a purpose-built platform; dependency-heavy platforms can triple this estimate.

Q8: What is the difference between a website your team can manage and one they can maintain?

Management is the day-to-day activity of publishing content and keeping information current. Maintenance is the longer-term activity of keeping the platform stable, the design system consistent, the compliance current, and the governance framework up to date. A team can manage a site without being able to maintain it — they can publish content without being able to address structural drift, design inconsistency, or compliance deterioration. Both capabilities are needed; most teams are trained in management and untrained in maintenance.

Q9: How should a nonprofit plan for staff turnover in its website management?

The safeguard against staff turnover is documentation comprehensive enough to enable a new team member to manage the site independently within their first two weeks. This requires: written process guides for every routine task, a CMS that is self-explanatory enough to supplement the guides, documented governance frameworks that explain not just how to do things but why, and a structured onboarding process for new staff that includes website management training. Organisations that rely on institutional knowledge rather than documentation lose capability every time a staff member leaves.

Q10: What platform features indicate a website is built for team maintainability?

Platform features that indicate genuine maintainability: a visual CMS where changes are previewed before publishing, role-based access control so different team members have appropriate permissions, a revision history that allows mistakes to be reversed, a staging or draft environment for reviewing changes before they go live, clear error messages when content requirements aren't met, and a stable hosting environment that doesn't require regular technical intervention. Webflow's native CMS provides most of these; achieving them on WordPress typically requires multiple plugins.