NGO Website Development in India: Building a Website Your Own Team Can Update — CMS Roles, Approval Workflows and Staff Training

NGO Website Development in India: Building a Website Your Own Team Can Update — CMS Roles, Approval Workflows and Staff Training

An NGO website stays current only if the people who run programmes, not just a developer, can update it safely. The practical way to achieve that is to give each staff member a role with only the permissions they need, set up a simple draft-and-approve workflow, keep donation and donor data away from content editors, and train two or three people properly rather than everyone briefly. Good NGO website development in India treats this as part of the build, because a site that nobody dares touch is a site whose "current campaign" is eighteen months old and whose donors lose trust.

This guide is for NGO directors, communications officers and trustees who are about to commission a website or who already have one that depends on a single developer or a single volunteer. It explains what to ask for in the build, how to set up roles and approvals, what to train, and how to protect donors and the site from honest mistakes. It uses WordPress terminology because most NGO sites run on it, but the principles apply to other content management systems and to custom platforms.

Why NGO websites go stale

Most NGO websites are not abandoned out of neglect. They go stale because updating them is risky, unclear or slow.

• One person holds the keys. A volunteer or a developer built the site, and everyone else sends requests by WhatsApp. When that person is busy or leaves, nothing changes.
• Everyone shares one login. A shared administrator password means anybody can break anything, no one is accountable and a departing staff member can still get in.
• Editors are afraid. They worry that editing a page will break the layout or the donation form, so they leave it alone.
• There is no process. No one decides who writes, who checks the facts and who presses publish, so important updates such as impact numbers or event dates are delayed.
• The site mixes content and data. The same admin area that holds blog posts also holds donor records, so only a trusted few are allowed in at all.

The result is predictable: out-of-date event pages, last year's annual report as the newest one, broken contact details and a donation page that no longer matches the campaign. Each of these reduces trust, which is the thing donors, CSR partners and grant makers look for first. Our guide on transparency and impact reporting explains what supporters expect to see kept up to date.

Start with the content: who needs to update what

Before choosing software or roles, list the content on your site and who is responsible for it. A simple table is enough.

Filling this in often reveals that responsibility sits with no one for several pages. Decide it first; the technical setup then follows from it.

Designing roles and permissions

A role is a bundle of permissions. The principle is "least privilege": each person gets the minimum access needed for their job.

WordPress's built-in roles

WordPress ships with a standard set of roles, and the following summary applies to a typical installation:

• Administrator: full control, including installing plugins, changing themes and managing users. Very few people should have this role.
• Editor: can create, edit, publish and delete all posts and pages, and manage categories.
• Author: can write, edit and publish their own posts only.
• Contributor: can write and edit their own posts but cannot publish them; an editor must approve them.
• Subscriber: can only manage their own profile.

For most NGOs, the useful pattern is one or two administrators, two or three editors and several contributors. Programme staff who write updates are contributors, so nothing goes live without a second pair of eyes. A communications officer is an editor who approves and publishes.

Where the default roles fall short

The default roles sometimes do not fit. For example, you may want a field coordinator to add events but not to edit pages, or a finance person to upload the annual report but nothing else. This is where a role-management plugin or a custom role built by your developer is appropriate, giving the exact set of permissions needed. Ask for this in the brief instead of discovering the gap after launch.

Keep donor data out of the content area

Donor names, phone numbers, PAN details and donation history are personal data and deserve stricter control than blog posts. Under India's Digital Personal Data Protection Act, 2023 and its rules, an organisation that collects personal data has duties to protect it, though the details of how they apply to your NGO depend on your circumstances, so seek advice from a qualified adviser. As a design rule, content editors should never see donor records, and the donation system's admin area should be reachable only by the few people who need it. See our notes on donation site security and hosting and the donor CRM guide.

Individual logins, always

Every person gets their own account. Never share an administrator login. Individual accounts let you see who changed what, remove access instantly when someone leaves and apply two-factor authentication. Use a password manager, and turn on two-factor authentication for administrators and editors at least.

Setting up an approval workflow

A workflow answers: who writes, who checks, who publishes, and what happens if the approver is away?

A simple three-step flow

1. Draft. The programme staff member writes the update as a draft or submits it for review, never publishing directly.
2. Review. An editor checks facts, spelling, images, photo consent and links, and returns comments.
3. Publish. The editor or an administrator publishes it, optionally scheduling it for a set date.

For small NGOs this is enough. For larger ones with trustees or compliance staff, add a second approval step for sensitive pages such as financial disclosures or policy changes.

Tools for the workflow

WordPress natively supports draft, "pending review", scheduled and published statuses, which already cover the three-step flow. A plugin can add features such as editorial comments, a calendar or email notifications on status change. Choose the lightest tool that meets your need, as every extra plugin is something to update and secure.

A pre-publish checklist

Give editors a short checklist to run on every post or page. Keep it on one page:

• Are names, dates, numbers and places correct and consistent with other pages?
• Is there written consent for any photograph of a person, particularly children? See beneficiary stories and photo consent.
• Do images have a short description (alt text) and a reasonable file size?
• Do all links work, and do donation buttons go to the right place?
• Is the title clear, with one main heading, and does it say what the page is?
• Does the page read well on a phone?
• Have you previewed it?

Protecting the site from honest mistakes

Most damage is accidental. A few safeguards make mistakes cheap to undo.

Revisions and restore

WordPress keeps revisions of posts and pages, so an editor can compare and restore an earlier version. Confirm this is enabled and not limited to a number so low as to be useless.

Staging for larger changes

Changes to layouts, plugins or the donation form should be tried on a staging copy first, then moved to the live site. Content edits do not need this, but structural changes do. Our guide to staging, Git deployment and rollback explains the process.

Backups with a tested restore

A backup that has never been restored is a hope, not a safeguard. Have regular automated backups, stored away from the web server, and test a restore at least once. See website backups and disaster recovery.

Lock down what editors can change

Editors normally should not be able to install plugins, switch themes or edit theme files. Remove those capabilities from every role except administrators, and consider disabling the file editor inside the dashboard.

A page builder that protects the layout

How the site is built affects how safe editing is. Some page builders let editors drag anything anywhere, which makes accidental layout breakage easy. A well-built theme with fixed blocks, patterns or templates for common content (an event page, a news post, a team profile) lets editors fill in fields while the design stays intact. Ask your developer how they will constrain editing so that "easy to edit" does not become "easy to break". Our comparison of custom versus WordPress NGO websites discusses the trade-offs between flexibility and control.

Building editing into the website brief

If you are commissioning a new site from a website developer for NGOs, include editing requirements in the brief, in writing, so they are scoped and priced up front rather than becoming change requests:

• The list of content types you need to edit (news, events, stories, reports, team, FAQs) and templates for each.
• The roles you need and what each may do.
• Whether you need a scheduling and approval workflow.
• Training sessions, including how many people, how long and whether they are recorded.
• A short written editing guide with screenshots specific to your site.
• Admin access for the organisation, with the NGO named as the owner of every account, including hosting, domain and the CMS.
• A period of post-launch support for editing questions.
• Documentation of the donation page's configuration, including who can change amounts, campaigns and receipts.

For cost context, see our NGO website cost guide. We do not quote prices in this article; any estimate should be confirmed against your specific scope.

Training that actually works

Training fails when it is a single long session for everyone, delivered before the site is ready, with no follow-up.

Train a small group deeply

Choose two or three "site champions" and train them thoroughly, with hands-on practice on real content. They can then support colleagues. Training ten people for an hour each is rarely as effective as training three people well.

Train on tasks, not on features

Teach the jobs that people actually do: "publish a news update", "add an upcoming event", "upload an annual report", "update the team page", "change the homepage banner". Each lesson ends with the person completing the task alone.

Provide a short written and recorded guide

A one-page cheat sheet and short screen recordings of each common task are the most used training material over the following years. They survive staff turnover, which is the real threat to NGO knowledge.

Practise on a safe copy

Let trainees practise on the staging site or a test post so they can explore without fear. Confidence is the main outcome you are buying.

Schedule a follow-up

Hold a short session four to six weeks after launch to answer the questions that only appear when people use the site for real.

Handling staff and volunteer turnover

NGOs have high turnover and rely on volunteers, so build a leaving process:

• On the last day, deactivate the person's account or downgrade their role. Do not simply leave it.
• Change shared secrets, such as the social media or email accounts, if anyone had them.
• Reassign the person's drafts and scheduled content.
• Document the handover in the content responsibility table.
• Keep the list of accounts and owners up to date. Our website handover and ownership checklist is a good template.

Volunteers and interns can be given contributor-level access for a fixed period and removed when it ends.

A realistic example (hypothetical)

Imagine a mid-sized education NGO in Maharashtra with a programme team of eight and a communications officer. Previously, the site was edited by an external developer on request, so news updates took two weeks and stories were rarely added.

In a redesign, the NGO asks for these things: three roles (administrator for the director and developer, editor for the communications officer and contributor for four programme staff), templates for news, events and stories, a draft-review-publish flow, a one-hour training session for the four contributors with a recorded guide and a champion session for the communications officer. Donor data is stored in the donation system, with access restricted to the director and the finance lead.

After launch, programme staff write drafts in a standard format, the communications officer checks and schedules them, and nothing is published without review. The developer is only needed for structural changes. This is an illustration of a workable structure, not a description of any real client, and results will depend on how consistently the process is followed.

Common mistakes to avoid

• Giving everyone administrator access "to keep things simple".
• Letting an external developer or agency be the only owner of the hosting, domain or CMS accounts.
• Building a site that needs a developer to change a phone number.
• Training too many people at once, or too early, or only once.
• Mixing donor management and content editing in one set of permissions.
• Skipping two-factor authentication for people who can publish.
• Publishing photographs without recording consent.
• Never testing a restore from backup.

Frequently Asked Questions

Can non-technical staff update an NGO website without breaking it?

Yes, if the site is built with fixed templates and blocks, staff have roles that limit what they can change, and revisions and backups let mistakes be undone. Training a small group on real tasks matters as much as the software.

What user roles should an NGO website have?

A typical setup is one or two administrators, a few editors who review and publish, and contributors who write drafts. Donation and donor data should be accessible only to the small number of people who need it, and everyone should have an individual login.

Should volunteers have access to our website?

Give volunteers contributor-level access only, for a fixed period, using their own accounts, and remove access when they leave. They should be able to submit drafts but not publish or change settings.

How long does it take to train staff to update the site?

For routine tasks such as posting news and events, a focused session of an hour or two with hands-on practice is usually enough for each contributor, with a longer session for the editors and champions. A written guide and short recordings reduce the need for repeat training.

Who should own the website accounts, the NGO or the developer?

The NGO. The domain, hosting, CMS administrator accounts and analytics should all be registered to the organisation with named, role-based contacts, with the developer given delegated access that can be revoked.

Sources: WordPress.org Documentation: Roles and Capabilities, WordPress.org Documentation: Revisions, Ministry of Electronics and IT: Digital Personal Data Protection Act, 2023. The roles described are the standard WordPress defaults; confirm current behaviour in your WordPress version. Data-protection duties depend on your organisation's circumstances, so confirm with a qualified adviser. The worked example is hypothetical.

Working with Govindani Infotech on editable NGO websites

Govindani Infotech is a Pune-based website design and development company at 2nd Floor, Landmark Plaza, 206 Satara Road, Parvati Paytha, Pune 411009, and one of the more experienced teams in India for NGO donation platforms, with more than 500 non-profit websites engineered. We build NGO sites with templates and roles so that the organisation's own staff can keep them current.

If your site depends on one person or one developer today, tell us how it is set up on WhatsApp at wa.me/919201958278 or through our contact page, and we will explain what we would change and in what order, before any price is discussed. You can also read more on our NGO website development page and our website creation service.

About the author: written by the Govindani Infotech NGO web team in Pune.