Securing Your Nonprofit’s WordPress Website

Imagine you open your nonprofit website on a Monday morning, and instead of seeing your homepage, you see a page selling something you’ve never heard of—or worse, you see nothing at all, because your hosting company suspended the site overnight.

If you manage your own website, that is not a far-fetched scenario. The good news is that most of the ways it happens are preventable, and you don’t need to be a developer to prevent them.

Welcome to No Stress Web Success. I’m Lisa, and I’ve been building WordPress websites for over 15 years. Today’s episode is for the executive director who also happens to be the person who logs into the website, and for the small marketing team that has been handed the keys to the site and told, “You’ve got this.”

We’re going to walk through the essential elements of a secure WordPress website—ten things in plain language. Some you can do yourself this afternoon. Some you’ll hand to your host or your web person, and I’ll tell you exactly what to ask for. Grab a notepad, because at the end of this, I’ll give you a short checklist.

Why Security Matters for Nonprofits

A lot of people believe, “We’re a small nonprofit—nobody would bother hacking us.” But most website attackers aren’t personal. They’re automated. Bots scan the internet all day, every day, looking for outdated plugins, weak passwords, and known holes. They don’t know or care that you run a food pantry or a youth program. They only care that the door is unlocked.

We’ll start with the mindset, because it changes how you make decisions.

And for a nonprofit, the stakes are specific. Your website is where your donors give, where volunteers sign up, where the people you serve look for help. If the site is defaced or flagged by Google as unsafe, you lose trust—and trust is your currency.

Here’s the thing I want you to hear: WordPress itself is not the weak point. WordPress core is actively maintained and gets security fixes quickly. The real risk lies in the things around it: old plugins, shared passwords, forgotten user accounts, and sites that nobody has looked at in a year.

So security isn’t a one-time purchase. It’s a handful of habits, and we’re going to go through those today.

1. Start with Good Hosting

Everything else sits on top of your hosting, so this should come first.

Cheap, bargain-bin shared hosting often means your site lives right next to hundreds of others, with little isolation between them. If one of those sites gets affected, the problem can spread.

What to look for in a good host:

• Focuses on WordPress
• Runs a firewall at the server level
• Takes daily automatic backups
• Supports current versions of PHP
• Has brute-force protection
• Has real humans you can reach if something goes wrong

Ask them directly: “What happens if my site gets hacked?” That answer will tell you a lot.

2. Enforce HTTPS Everywhere

HTTPS is the little padlock in the browser. It encrypts the connection between your visitor and your site, which matters for login pages, contact forms, and especially donation pages.

Most hosts now include a free SSL certificate, but having a certificate isn’t enough. You need to make sure every visit is sent to the secure version. That means three things:

1. Redirect all HTTP traffic to HTTPS (usually a setting in your host dashboard).
2. Make sure your WordPress Address and Site Address (under Settings → General) both start with HTTPS.
3. Check for mixed content—when a page is secure but still loads an old image or script over an insecure link. That’s what makes a padlock disappear.

I’ll put a link in the description so you can check this on your own website.

One nonprofit-specific tip: Use a trusted, hosted payment processor for donations so card numbers never touch your website at all. That removes an enormous amount of risk.

3. Keep Everything Updated

This is the single most effective habit on the list. Attackers love known vulnerabilities, and an update is usually a fix for one. That covers WordPress core, your plugins, and your theme.

Turn on automatic updates for core and for the plugins you trust. For anything critical (like your donation or event system), take a backup first or test on a staging copy. Then put a recurring weekly reminder on your calendar for a quick check. Ten minutes a week beats a ten-hour emergency.

Also check which version of PHP your site runs. Your host controls this, and old versions stop receiving security fixes.

4. Limit Your Plugins and Themes

Every plugin is code written by someone else. More plugins mean more places for something to go wrong, and plugins are where the majority of WordPress vulnerabilities show up. So be a minimalist.

• Delete what you don’t use. Deactivating is not the same as deleting, and an inactive plugin can still be exploited. Remove it.
• Vet before you install. Look at when it was last updated, how many active installs it has, and whether the developer responds to support questions. A plugin that’s been abandoned for three years is a red flag.
• Never use nulled or pirated premium plugins. They’re common sources of malware. If the paid version is worth it, pay for it.
• Keep one active theme. Keep a default WordPress theme as a fallback if you like, and delete the rest.

Ask: “Does this need to be a plugin?” Sometimes a feature is better handled by your host or a simple tool.

A good exercise for after the show: Open your plugin list and see how many you can remove.

5. Manage Users and Turn On Two-Factor Authentication

Let’s talk about people, because this is where small organizations get caught.

Start with who has access. Open Users in your dashboard and ask three questions:

• Does everyone on this list still work or volunteer here?
• Does everyone need the level of access they have?
• Is anyone sharing a login?

Remove old staff, past volunteers, and that agency from three years ago. Give people the lowest role that lets them do their job. Most content editors don’t need Administrator. And everyone gets their own account—never a shared one.

Now passwords: Use a password manager and make every password long and unique. If your team reuses a password from one site to another and that site gets breached, attackers will try it on yours.

But even a strong password can be phished or leaked. That’s why you turn on two-factor authentication (2FA). After the password, the person has to enter a second thing, like a code from an authenticator app. Even if someone steals the password, they’re stopped at the door.

Practical notes:

• Require it for administrators and editors first, then everyone.
• Authenticator apps or passkeys are stronger than text-message codes.
• Several reputable plugins add this, including the official Two-Factor plugin, and many security plugins include it (such as Wordfence).
• Save the backup codes somewhere safe so one lost phone doesn’t lock you out.

And since accessibility is what I do: Choose a 2FA method that works for all your team members. Some login challenges (like image-based puzzles) are hard or impossible for people using screen readers. Test it with real users and offer an alternative if needed.

6. Protect the Login Page

The WordPress login page is the front door, and bots knock on it constantly, trying thousands of password guesses.

• Limit login attempts so that after a handful of failures, an address gets locked out for a while. Many hosts and security plugins do this automatically.
• Don’t use “admin” as a username. It’s the first one bots try. If your site still has one, create a new administrator with a different name and remove the old one. (Make sure you reassign anything written under the old admin account to the new user.)

You may hear advice about hiding or renaming your login URL. It can reduce noise in your logs, but treat it as a nice extra, not as protection. Passwords, 2FA, and login limits do the real work.

7. Know What to Disable (XML-RPC and the REST API)

XML-RPC is an older feature that lets outside apps talk to your site. Years ago, it was how mobile apps and some publishing tools connected. Today, most things use newer methods, but XML-RPC is still switched on by default. The problem is that attackers can use it to try many passwords in a single request, which sneaks past simple login limits.

For most nonprofits, the answer is to disable it. The exceptions are if you rely on a tool that specifically needs it. Ask your web developer or check your tool’s documentation, then turn it off with a security plugin or at the server level.

The REST API is a little different. Some guides say “disable the REST API.” Please don’t—or at least not entirely. Modern WordPress uses it behind the scenes. The block editor, many plugins, and many form tools depend on it, and turning it off can break things in confusing ways.

What you should do is restrict it. By default, the REST API can list your site’s usernames to anyone who asks, which hands attackers half of the login puzzle. Have your developer or a security plugin limit it so that user information is only available to logged-in users. The same goes for author archive pages that expose usernames.

The principle: Disable what you don’t use, and restrict what you do.

8. Basic Hardening Your Host or Developer Can Handle

A few more items that are quick for a professional. You don’t need to understand the details—only to ask:

• Turn off the built-in file editor in the dashboard. It lets anyone with admin access change plugin and theme code directly, which is exactly what an attacker wants.
• Make sure file permissions are set correctly and that directory browsing is off, so nobody can view lists of your files.
• Add a web application firewall (WAF). This filters out malicious traffic before it reaches your site. Some hosts include one; others are available as a service or plugin.
• Check your security headers and site configuration as part of a periodic review.

If you remember one phrase, make it this: “Can you confirm these basics are in place on our site?” A good provider will happily say yes or fix it.

9. Backup—and Test Your Backup

Here’s the truth about security: You can do everything right and still have a bad day. Backups are what turn a disaster into an inconvenience.

A good backup setup has a few features:

• It’s automatic (daily for an active site).
• It’s stored off the server (a backup that lives on the site that just got hacked is gone along with it).
• It covers both the files and the database.

Then comes the step almost everyone skips: Test the restore. Ask your host or your web person to show you how you would bring the site back and how long it takes. A backup you’ve never tested is a hope, not a plan.

Also keep a short written “If something goes wrong” page: Who do we call? Where do we log in to our host? Who can approve spending money on a fix? Put it somewhere other than the website itself.

10. Monitor for Vulnerabilities and Trouble

The last habit is staying informed so you hear about problems before your visitors do.

When a flaw is found in a plugin or theme, it’s published in vulnerability databases. Services like Patchstack, Wordfence Intelligence, and others offer free plans or plugins that alert you when something you’ve installed is affected. Set up alerts and send them to someone who will actually read them. If an alert says a plugin has a serious flaw and no fix is available, the safest move is often to deactivate and replace it.

A few other monitoring tools are worth having:

• Uptime monitoring (which texts or emails you when the site goes down—some have free tiers)
• An activity log that records who changed what
• Google Search Console (it will tell you if Google detects malware or hacked content on your site)
• Scheduled malware scans from your host or a security plugin

And please, once a quarter, do a quick audit: users, plugins, backups, and alerts. Put it on the calendar.

Your Security Checklist

1. Choose a host that focuses on WordPress, with backups and a firewall.
2. Force HTTPS on every page, and use a hosted payment processor for donations.
3. Keep WordPress core, plugins, and your theme updated.
4. Delete unused plugins and themes, and vet the ones you keep.
5. Review your users, remove old accounts, and use the lowest role needed.
6. Turn on two-factor authentication, starting with administrators.
7. Limit login attempts and retire the “admin” username.
8. Disable XML-RPC if you don’t need it, and restrict (not remove) the REST API.
9. Ask your host or developer to confirm the basics: file editor off, correct permissions, and a firewall.
10. Run automatic off-site backups, test the restore, and set up vulnerability and uptime alerts.

If that feels like too much, here’s where I’d start this week: Updates, users, and 2FA. Those three close the most common doors.

And remember: None of this is about perfection. It’s about making your site a harder target than the next one and being ready if something does go wrong.

You don’t have to do it alone either. Hand the technical items to your host or a trusted web professional, and keep the habits (like the weekly update checks and the quarterly reviews) for your team.

If this episode was helpful, share it with the person on your team who handles the website password—and maybe the person who has been keeping it on a sticky note.

If you want to leave a comment, or if you have questions about our web services, support, and coaching, feel free to visit us at fivepennyweb.com.

And as always, I’d ask that you leave a review on our podcast. Let us know what you think and how we’re doing.

In the meantime, I’m Lisa, and this has been No Stress Web Success. Thank you for listening, and I will see you next time.