We used to build client sites on WordPress. We do not any more. The decision was driven by security, and then the performance turned out to be such a large improvement that we would have made the change anyway. Here is the whole argument, including the parts that do not favor us.
What Made Us Change
A WordPress site is not one thing. It is a database, a PHP application, a theme, and a stack of plugins written by different people with different standards and no obligation to keep maintaining any of it. A typical small business site runs somewhere between fifteen and thirty plugins. Each one is code running on your server with access to your database.
That is a lot of surface for a business whose website exists to show its hours, its services and its phone number.
The failure we kept seeing was never exotic. A plugin the owner installed in 2019 for a contact form, abandoned by its author in 2021, with a known hole published in 2023 that the owner never heard about because nobody told them. The site gets used to serve spam pages, Google notices before the owner does, and the first symptom is a ranking collapse rather than an error message.
The owner did nothing wrong. They were sold a site with an admin panel and nobody explained that owning one is a standing maintenance obligation for as long as the site exists. That is the part of the sale that usually goes unmentioned.
Maintenance Is Not Optional and Nobody Does It
The honest answer to plugin risk is to patch everything, promptly, forever. In practice that means somebody checking monthly, testing that the updates did not break the layout, and fixing it when they do. For a business with twelve employees and no technical staff, that work simply does not happen, and the site quietly rots.
We were selling sites that needed ongoing care we could not guarantee and the client could not perform. That is a bad product regardless of how it looks on launch day.
What Actually Gets Attacked
In order, from what we have seen and cleaned up.
- Plugins with known holes. The overwhelming majority. The hole is public, the fix exists, and the site never got it
- The login page. Every WordPress site has one at a predictable address. Automated attempts against it are constant and relentless, and weak passwords are still everywhere
- Themes bought once and never updated. Especially the ones bundling their own page builder and their own copies of other libraries
- Old PHP. Cheap hosting that never moved the site forward, running a version that stopped getting security fixes years ago
Now hold that list against a static site. There are no plugins. There is no login page, because there is nothing to log into. There is no PHP running and no database to reach. Most of the list simply does not apply, not because the static site is cleverer but because the parts that get attacked are not there.
This is the whole security argument and it is not subtle. You cannot breach a database that does not exist.
The Part That Made It Worth It
Security made us change. Speed is why nobody here wants to go back.
A WordPress page is assembled on every request. The server runs PHP, queries the database several times, builds the page, and sends it. Caching plugins exist to avoid that work, which tells you how expensive the work is. A static page is a file. The server finds it and sends it.
Our locksmith build at ABC Lock and Safe is 56 files and loads in well under a second. The customer it is built for is locked out of a car, standing somewhere unpleasant, with three tabs open. In that situation a second is not a metric. It is the difference between your phone ringing and the next shop's.
The Compounding Effect
Static builds also remove the things that usually make a site slow, because there is nowhere for them to hide. No page builder shipping four hundred kilobytes of JavaScript to render a button. No plugin adding its own stylesheet to every page including the ones it is not used on. What is on the page is what somebody deliberately put there.
Test on a real phone on cell data, not on office wifi in a desktop browser. Nearly every speed problem we have fixed was invisible in the developer tools and obvious the moment somebody loaded the page outdoors.
There Is Also Nothing to Go Down
A database driven site can be down while the server is perfectly healthy, because the database is not answering. A static site on a content delivery network has no such failure mode. For a trade that sells emergencies, being reachable at 2am is a feature worth more than most of the ones in a plugin directory.
What We Gave Up
This is the part most articles like this leave out.
- The client cannot edit the site themselves. This is the real trade. In practice most owners never logged in anyway, and the ones who did often broke the layout. But it is a genuine loss and we should say so
- Publishing is slower. Adding a post means a build rather than a form. For a business publishing weekly that is fine. For a newsroom it would be absurd
- Some things are genuinely harder. User accounts, comments, a real store with live inventory. We build those as software when a client needs them, which is a bigger job than installing a plugin
- Forms need somewhere to go. A static page cannot process a submission by itself, so it needs a service behind it. That is a solved problem but it is a thing you have to set up rather than assume
If your business genuinely needs daily publishing by several people, or a store with stock levels, the trade goes the other way and you should stay where you are.
Who Should Ignore All of This
Plenty of people, honestly.
- Anyone publishing several times a week with multiple authors
- Anyone running a real store with inventory and variants
- Anyone whose team is comfortable in WordPress and who genuinely has a patching routine that happens on schedule
- Anyone whose site is working, fast, maintained and earning
A working site is a working site. We are not suggesting anyone rebuild something that is doing its job. The argument here is about what to choose for a service business that is starting again or whose current site has stopped earning, which is most of the ones that call us.
How to Move Without Losing Rankings
Migrations lose rankings when they are done carelessly, not because migration is inherently dangerous. The careful version is not complicated, it is just work nobody enjoys.
- Export every URL that currently exists. All of them, including the ones nobody remembers. Pull the list from Search Console as well as from the site itself, because the two never agree
- Find which of them actually earn. Sort by impressions and clicks. Some of your best earning URLs will be pages you forgot about. On one client site, 132 of their old redirects still carried impressions, 21,627 of them, years after the pages moved
- Map every one to its new home before you switch anything. Not to the home page. A redirect to the home page is treated as a soft 404 and throws away whatever that page had earned
- Keep the content that earns. A rebuild is a good time to improve pages and a terrible time to delete them
- Have the rollback ready before you switch. Know exactly how you put the old site back, and have tested it, before DNS changes
- Verify by loading the real site, not by reading the deploy log. A deploy that says it succeeded has told you nothing about what the visitor gets
Measure the render, not the source. Almost every problem that has reached a live site for us was invisible in the code and passed every build check. Load the page. Look at it. Then believe it.
We build the website and we host it, at no cost. SEO starts at $800 a month, month to month, and that is the whole invoice. Before you pay anything we will build your real site and send you the link. Here is how that works.
Common Questions
Is WordPress insecure?
WordPress core is reasonably well maintained. The risk is almost never core. It is the plugins, the themes and the login page, and a typical small business site runs fifteen to thirty plugins written by people with no obligation to keep maintaining them.
What is a static site?
Plain HTML, CSS and images, built ahead of time and served as files. There is no database and no admin login. The page a visitor gets is a file sitting on a server, not something assembled fresh on every request.
How do I update a static site without a login?
You ask us, and we make the change. For a service business that changes its hours twice a year and its prices annually, that is a better trade than owning an admin panel that has to be patched every month forever.
Will I lose SEO by moving off WordPress?
Not if every old URL is mapped to its new home before the switch and a rollback is ready. Rankings are lost in migrations that skip that step, not in migrations as such.
Who should stay on WordPress?
Anyone who genuinely publishes several times a week with multiple authors, anyone running a real store with inventory, and anyone whose team is already comfortable in it and has a patching routine that actually happens.