Let me say the kind thing first, because it's true: I love WordPress. I've built dozens of sites on it. It powers a huge share of the internet, it's free to start, and there's a plugin for nearly anything you can imagine. For a long stretch it was simply the answer when someone asked how to put a website together. I'm not here to mock it, and if you're running a church on WordPress today, you haven't done anything foolish — you picked the tool everybody pointed you to.
But I want to be honest with you, pastor to pastor, about why I stopped building churches on it. Because there's a difference between a tool that's powerful and a tool that's right for your situation — a church with no IT department, a volunteer or two, and a pastor who already has more than enough to carry. In that situation, WordPress slowly turns from a gift into a burden. I watched it happen on my own sites and on churches who came to me after it happened on theirs. So I changed how I build. Let me tell you what went wrong, and what I do now instead.
The trouble isn't WordPress itself — it's everything bolted onto it
Here's the thing most people don't understand about a WordPress site. It isn't one thing. It's a stack of moving parts all running live on a server, around the clock:
- The WordPress software itself, which has to be kept updated.
- A database humming behind it, storing all your content.
- A "theme" that controls the look — itself a chunk of software.
- And then the plugins. A typical church site runs a dozen or more — one for the contact form, one for security, one for the calendar, one for the sermon player, one for caching, one for backups, and on it goes. Each one is software written by a different person somewhere in the world.
Every single one of those parts is a door. And every door has to be locked, watched, and updated forever — or it becomes a way in. That's not a knock on any one plugin. It's just the nature of a site that's a living, running machine instead of a finished, settled thing. Which brings me to the part that actually costs churches sleep.
The hacking is real, and churches are easy targets
I don't say this to frighten you. I say it because I've cleaned it up. A church site sitting on out-of-date WordPress with a couple of stale plugins is, frankly, low-hanging fruit for the automated bots that crawl the internet all day looking for exactly that.
The bots aren't targeting your church because of anything you believe. They're targeting it because it's an unlocked door, and they knock on millions of doors a day.
When they get in, you don't usually get a dramatic ransom note. What you get is quieter and uglier: your church's site quietly turned into a billboard for spam — pharmacy ads, gambling links, things you'd be mortified to have your name near — often hidden so you don't even notice until a member calls, or until Google flags your site as "deceptive" and slaps a red warning screen in front of every visitor. Now the very tool meant to welcome people is turning them away at the door, and your church's good name is tangled up in it.
And the spam doesn't even need a full break-in. Leave a contact form or a comment section open on WordPress and the junk pours in on its own — bots filling your inbox and your pages with garbage faster than a volunteer can delete it.
The other headaches that pile up
Even when nothing gets hacked, the day-to-day grind wears you down:
- A plugin update breaks the site. This is the classic. You — or your host — update something, and suddenly the homepage is blank, or the giving button is gone, and it's Saturday night. Because all those parts depend on each other, one bad update can knock the whole thing over.
- It gets slow. WordPress builds every page fresh for every visitor, which is heavy work. So people bolt on "caching" plugins to speed it up — another layer of complexity that, when it's misconfigured (and it often is), shows visitors a stale page or breaks the site in confusing ways.
- It can get knocked offline. Because every visit makes the server do real work, a flood of traffic — whether a genuine surge or a malicious one (what's called a DDoS attack) — can drag the site to a crawl or take it down entirely. For a busy little church server, it doesn't take much.
- The misconfiguration tax. Settings, permissions, security rules, backups — there are a hundred knobs, and getting any one of them wrong leaves a gap. Most churches don't have anyone whose job it is to know which knob is which.
None of these are catastrophes on their own. But add them up and you get a website that needs babysitting — a thing that breaks, costs money to fix, and gives you one more low-grade worry in the back of your mind. A pastor shouldn't have to think about server security between hospital visits.
A real example: the cure that made things worse
Let me give you a true case, because it shows how one of these problems leads straight into another. A church I know was getting hammered — the constant bot traffic and attacks I described were dragging their WordPress site down and threatening to knock it offline. So, on the advice of whoever was helping them, they put a heavy security wall in front of the site to fend off the attacks (the tool was Cloudflare, set to an aggressive "challenge everyone" mode).
It stopped the attacks. It also, quietly, did something far worse.
The same wall that blocked the bad bots blocked Google's bot too. So Google could no longer read the site to list it in search results. Overnight, for all practical purposes, the church became invisible online.
Think about what that costs. Every family in town searching "church near me," every visitor checking service times before driving over, every soul Googling the church's name after a friend mentioned it — none of them could find it anymore. The site was still "up," but it had vanished from the one place people actually look. All the work that had gone into the website, all its reach into the community, was simply gone — not because the site broke, but because the desperate fix for one WordPress problem created a bigger one. That's the trap with a fragile site: you end up patching the patches, and each patch has its own price.
A site that doesn't get attacked in the first place never needs a wall like that. It stays fast, stays safe, and stays perfectly visible to Google — all at once, with no trade-off.
So here's what I build instead: a "static" site
When churches come to me now, I don't build them a living, running machine. I build them what's called a static website. The name sounds boring, but stay with me, because the idea is wonderful in its simplicity.
Instead of a site that rebuilds itself from scratch for every single visitor, I build the finished pages once — ahead of time — and then simply hand those finished pages out to everyone who comes. Like printing the bulletins on Saturday instead of writing each one by hand as people walk in the door.
Picture the difference. A WordPress page is like a kitchen that cooks every meal to order the moment you ask — lots of equipment, lots that can go wrong, and a line out the door when it gets busy. A static page is like a plate that's already made, sitting ready. A visitor shows up and instantly gets the finished plate. There's no kitchen running in the background to break, to hack, or to overwhelm.
That one change fixes almost everything I described above — not by patching it, but by removing the thing that caused it.
Why this quietly solves the headaches
- There's almost nothing to hack. No database sitting open, no login page for bots to hammer, no dozen plugins with stale doors. There's no "kitchen" running behind your site to break into. You can't pick the lock on a door that isn't there. This alone takes the single biggest worry off your plate.
- The spam dries up. No open comment system, and contact forms handled in a modern, locked-down way instead of a vulnerable plugin. The junk simply has nowhere to pour in.
- It's blazing fast — everywhere. Because the pages are already finished, they load almost instantly, even on a phone with a weak signal in a church parking lot. No caching plugin to misconfigure; speed is just built in.
- A traffic surge can't take it down. Handing out a finished page is so light that a flood of visitors — friendly or hostile — barely registers. The kind of overload that knocks a WordPress site offline doesn't faze a static one.
- There's nothing to babysit. No weekly updates that might break things, no security settings to get wrong. The site just sits there and works, Sunday after Sunday, while you do the actual work of ministry.
"But how do I change it, then?"
This is the fair question, and it used to be the real catch. In the old days, static sites were sturdy but hard to update — you needed a developer for every little change. That's no longer true, and this is where the new technology genuinely shines.
I build these sites with modern tools — the same kind the biggest, fastest companies on the internet use (the technical names, if you ever hear them, are things like Node.js for building the site and GitHub for safely storing it). You don't need to know any of that. What it means for you is two things that matter:
- Editing is easy — you just ask. I've set my church sites up so that you can change a service time, swap a photo, post a sermon, or update an announcement by simply telling an AI what you want in plain English — no logins, no dashboards, no fear of breaking anything. (I wrote a whole separate walkthrough on exactly how that works.)
- There's a safety net under everything. Because of how the site is stored, every change is tracked and every change can be undone. There's no Saturday-night "I broke the website and I don't know how to fix it" — you can always step right back.
And the hosting is just as simple. A static site doesn't need a powerful, fussy, expensive server constantly running a kitchen in the back. It runs on modern, plain hosting that's both more reliable and cheaper than the heavyweight setups WordPress demands — and it's spread across the globe so it's fast for a visitor in your town and a missionary overseas alike.
The questions pastors ask me
"I already have a WordPress site. Is it ruined?" Not at all. If it's serving you and it's kept up to date, there's no emergency. This is about which direction to go when you're building new or finally fed up with the upkeep — not a reason to panic about what you have today.
"Will I lose my content?" No. The words, the photos, the sermons — all of that comes across. What gets left behind is the fragile machinery underneath, not your church's actual content.
"Don't I give up flexibility?" A little, and honestly it's the right little. WordPress's endless plugins are its blessing and its curse — that's exactly where the breakage and the security holes come from. A church website needs to do a handful of things superbly: tell people who you are, when you meet, how to come, and let them reach you. A static site does all of that beautifully. You're not giving up things you need; you're giving up the clutter that was putting you at risk.
"Is this just the latest fad?" I understand the instinct — you've been burned by "the new thing" before. But static sites are, in a sense, the oldest idea on the web, brought back with modern polish. It's a return to something simple and sturdy, not a leap onto something untested.
Why I care enough to switch
I didn't move away from WordPress because I stopped liking it. I moved because I kept watching the same sad story: a church gets a website, it works for a while, and then slowly it becomes a source of worry instead of a help — a thing that breaks, gets hacked, costs money, and steals attention from the work that actually matters. That's backwards. A church's website should be one of the least worrisome things you own.
If you're tired of babysitting a website, or you just want the next one to be something you never have to think about again, that's exactly what I build now.
Pastor Eli builds modern websites for churches — designed by a fellow pastor, with no agencies, no contracts, and no jargon. Sturdy, fast, and safe by design, with no plugins to break and no servers to babysit. See examples, request a free demo, or ask any question at elijahdesent.com.