Your site, looked after every month.

Four things, done on a schedule: keeping the software current (the platform, its plugins or add-ons, and the server language underneath), backing the site up somewhere other than the server it lives on, watching it (uptime, security scans, broken links, forms that quietly stopped sending), and making the small content changes that pile up. A good plan also includes a short monthly report so you know what was done and what's coming.

Because everything around it has. The software the site runs on gets security fixes constantly, browsers change, and the tools it connects to update their APIs. A site that hasn't been touched in a year is usually running software with known, published holes. In 2025 alone, security researchers logged 11,334 new vulnerabilities across the WordPress ecosystem, 91 percent of them in plugins, and nearly half had no patch available when they were disclosed.

Three things, in rough order of likelihood. The site gets slower and pieces stop working as the software drifts out of date. Then it gets compromised: attackers scan for known plugin holes automatically, and for the most heavily exploited ones the median time from disclosure to mass exploitation was about five hours. Finally, the host notices the malware and suspends the account, and the site is simply gone until someone cleans it up and proves it. For a nonprofit, that usually happens the week of an appeal or an event.

Security updates as they come out, which in practice means a weekly review and same-day action for anything serious. Backups daily, kept for at least a few weeks, stored off the server, and tested occasionally by actually restoring one. Larger updates, like a new major version of the platform, get done on a copy of the site first so a problem is found before your visitors find it.

The organization, always. Registrar, hosting, and site admin logins should be in an account the organization controls, with at least two current people able to get in, and never solely in the name of a volunteer, a board member, or a past developer. Getting these accounts back after someone leaves is one of the most common projects I get called for, and it's entirely avoidable.

A structured look at what the site is actually doing and what it costs to keep doing it. It covers speed, security posture, the plugins and services the site depends on, what the hosting plan includes versus what you use, accessibility basics, and how well the site holds up on a phone. You get a written summary with a short list of fixes, ranked by impact, and a recommendation on whether to tune what you have or rebuild.

Often, yes, and sometimes the answer is dramatic. Many small organizations pay for managed hosting sized for a much busier site, or for add-ons they never turned on. The review looks at what the site really needs: how much traffic it gets, whether it takes payments or logins, and whether it has to run server software at all. A site that is mostly pages and forms can frequently live on modern static hosting for a small fraction of a managed WordPress plan, and in some cases for nothing beyond the domain. For reference, shared hosting typically runs a few dollars a month, managed WordPress hosting tens of dollars, and the cost climbs from there with traffic and add-ons.

Usually the site. Oversized images, too many plugins, page builders that load everything on every page, and third-party scripts (chat widgets, trackers, embedded feeds) are the common causes. Hosting matters less than people assume until traffic is high. The review measures it rather than guessing, so you don't pay for a faster server to fix a problem that was a 4 MB photo on the home page.

Almost never. Sites accumulate plugins the way closets accumulate coats. Each one is code someone else maintains, or has stopped maintaining, and each one is a possible way in. Part of any cleanup is listing every plugin, what it does, when it was last updated by its author, and whether the site would notice if it were gone. Fewer plugins means fewer updates, fewer conflicts, and a smaller attack surface.

It depends on what the site does, and the honest answer for a lot of small organizations is no longer an automatic yes. WordPress still makes sense when you publish a lot of content with several editors, run a real online store, or depend on a specific WordPress tool with no equivalent elsewhere. If your site is a set of pages, a blog you update a few times a year, a donation form, and an events list, you are carrying the maintenance burden of a publishing platform to do the job of a brochure, and that burden is where the security risk and the monthly cost come from.

The modern approach for a site like that is to build it as a set of pre-built pages served from a global network, with no database and no server software running behind it. There is nothing to patch on a schedule, nothing for an automated attack to log into, and hosting is inexpensive or free. Content is edited through a simple editor that writes to the site, so staff can still change a page or post an update without touching code. Forms, donations, and events come from the tools you already use, embedded into the site rather than bolted on with plugins. The result loads faster, costs less to run, and doesn't need a weekly update cycle to stay safe.

Yes, and that is a requirement for any rebuild I do. Whatever the site is built on, the people who run the organization need to be able to change text, swap a photo, post a news item, and update a date without opening a ticket. Training and a short written guide are part of the handoff.

They are reasonable choices for very small organizations that want zero maintenance and can live inside the template. The trade is flexibility and integrations: connecting them deeply to a donor database or a line-of-business system is limited to whatever embeds the vendor allows. If your site is simple and will stay simple, they can be the right answer, and the review will say so.

Not stuck, but a rebuild is a bigger decision. A real store or a member portal with logins is exactly the case where WordPress still earns its keep, or where a dedicated platform for that function (a store platform, a membership platform) may serve you better than a general-purpose site trying to do everything. The review looks at each of those pieces separately rather than treating the site as one thing.

Yes, at one of three levels, and picking the right level saves a lot of money. The simplest is embedding: your CRM or donation platform provides a form or a widget, you place it on a page, and the data lands in the CRM directly. The middle level is a plugin or connector the vendor maintains, which can add things like single sign-on or synced event listings. The deepest is a custom connection through the vendor's API, for things like member portals or personalized pages. For most nonprofit sites, embedded forms are enough, and that is the recommendation of people who do this work every day.

Most of the platforms small nonprofits use (Little Green Light, Bloomerang, Neon, DonorPerfect, Network for Good, and others) offer hosted or embeddable forms that work on any site. Neon and Bloomerang also have solid APIs for custom work when it's warranted. Donation platforms like Donorbox and Givebutter sit in front of the CRM and sync gifts to it, and Donorbox alone connects to Salesforce, Bloomerang, Little Green Light, Neon One, HubSpot, and others, plus QuickBooks and Mailchimp. The practical question is rarely "can it connect" and more often "which one should be the system of record."

Same three levels, different vendors. Most small business platforms (accounting, scheduling, CRM, point of sale) offer either an embeddable widget for the site or a connector through an automation service like Zapier or Make. Where a true two-way sync is needed, for example inventory that has to be accurate on the site, that is API work and gets scoped as its own project. The rule is to keep one system as the source of truth and have the website read from it, rather than making the website a second copy of your data.

For contact and volunteer forms, sending the submission to the CRM (or to an inbox and a spreadsheet) is fine. For donations and registrations, the form should come from the platform that owns that data, so the record is created correctly from the start. Building custom forms that push into a database by hand is the integration most likely to break silently, and silent is the expensive kind of broken.

Vendors change their APIs, embed codes get updated, an authorization token expires, or a site update changes how a page loads a script. The failure is usually quiet: the form still looks fine, but nothing arrives. Part of maintenance is testing the connections that matter on a schedule, not just the pages. Under a care plan, that testing and the fix are included; without one, it's a support request.

Embed a form from your donation platform or CRM, and keep the gift data there rather than in the website. This gives you recurring gifts, receipts, and donor records without building any of it, and it means card details never touch your server, which keeps you out of most payment-security obligations. A giving page built by hand inside the website is slower to change and puts you on the hook for security you don't need to own.

Usually, and this is where the platform choice matters. Donation tools like Donorbox sync gifts to Bloomerang, Little Green Light, Neon One, Salesforce, and others, and to QuickBooks or Xero for bookkeeping, with Mailchimp for follow-up. Many CRMs have their own forms that do the same thing natively. The setup is a project; the ongoing part is making sure the connections still work each month and reconciling when they don't.

All of these exist as features of the fundraising platforms rather than the website, and the site's job is to present them well and get people there in one click. Event registration and peer-to-peer campaigns in particular are worth running on a platform built for them rather than on a general web form. Matching gift lookups are available as add-ons that embed on the donation page.

Yes, when it's done as above. The site's role is to host the page and the embedded form; the payment itself happens with the payment processor. What you should still expect from maintenance is a valid security certificate, a monitored site so a compromise doesn't go unnoticed, and periodic testing of the donation flow end to end, because a broken donate button costs more than any other broken button on the site.

Core, theme, and plugin updates tested after each round, security monitoring and uptime alerts, backup verification, a monthly test of your forms and donation links, a broken link scan, a monthly visitor report, a quarterly site review, and up to 3 hours of requests. It starts with a one-time onboarding month ($750 to $1,500, depending on the state of the site), then runs from $225 a month for a standard informational site, or from $795 a month for Website Care Plus, which covers working sites with a store, events, donations, member areas, or a database, and includes ten hours of requests. For nonprofits, your anniversary month is on me every year.

No. Most sites I take on were built by someone else. The first month is usually a cleanup: get the accounts in the organization's name, bring everything current, remove what isn't used, set up proper backups, and document how the site is put together.

Yes, and it's common. What's needed is access: the registrar, the hosting account, and an admin login. If you don't have those, that's the first thing to fix, and there is usually a path to recovering them.

You get a same-day acknowledgment so you know I've seen it, and a response within two business days. If the site is down or compromised, it jumps the queue.

I always ask before going over, and I tell you what the extra work would cost first. Most months the three hours are plenty; if you find you need more every month, we adjust the plan instead of billing extras.

Send me a few sentences about the site and what's worrying you. If you're not sure whether to tune, rebuild, or move, the technology and systems assessment on the consulting page is the structured way to get an answer.