Our own site runs on WordPress. So do most of the small business websites we look after across Denton County. That popularity is exactly the point: WordPress is flexible, affordable, and easy to hand off to a marketing person instead of a developer. It is also, for the same reasons, the platform attackers spend the most time studying.
Here is the honest version of how WordPress sites get compromised. It is almost never a dramatic targeted attack on your company. It is an automated scanner, running around the clock, checking millions of sites for one known weakness in one outdated piece of software. Your site is not chosen. It is found. And the routine that prevents almost all of this takes about fifteen minutes a month, which is why we find it frustrating that it so rarely gets done.
Why Plugins Are the Usual Way In
WordPress has three layers that need updating: core, meaning WordPress itself, plus your theme and your plugins. All three matter, but they are not equally risky. Core updates are handled well and, for security releases, often apply on their own. Themes change rarely. Plugins are the problem, because a typical business site runs dozens of them, each written by a different developer with a different level of care and a different appetite for maintaining code they wrote four years ago.
The WordPress security hardening documentation is blunt about where the risk lives. It notes that when a site is compromised, the cause is rarely attributed to the infrastructure and most often attributed to the application itself, and it lists old and outdated plugins and software among the entry points. The same documentation makes the timing clear: once a vulnerability is disclosed, the information required to exploit it is almost certainly in the public domain.
Read that again, because it changes how you think about updates. The disclosure that produces the fix also produces the roadmap. The gap between a plugin update being published and your site installing it is the window everyone races through. The WordPress instruction is direct: make sure your plugins are always updated. We add one caveat from experience. Back up first, then update, then click through your key pages. Updates occasionally break layouts or forms, and finding that out yourself beats hearing it from a customer.
The Plugins You Forgot You Installed
Every WordPress site accumulates. Somebody tried three contact form plugins before picking one. A consultant installed a page builder for one campaign. A slider plugin survived a redesign nobody cleaned up after. On the Plugins screen in the WordPress admin these sit deactivated, and most owners assume deactivated means harmless.
It often does not. Deactivated plugin files still sit on your server, and depending on how they are written they can still be reachable. That is why the WordPress hardening documentation does not say deactivate unused plugins. It says: if you are not using a specific plugin, delete it from the system. Same logic for themes. Most sites need the active theme and one default fallback. The rest is surface area you maintain for no benefit.
Do this audit annually and ask three questions about every plugin: does this do something we still need, has the developer updated it in the last year, and could a feature we already have replace it. Anything failing all three should go. Fewer plugins also means faster pages and fewer things to break on update day.
Accounts That Should Not Exist, and Logins That Should Be Harder
Open the Users screen in your WordPress admin and look at who has Administrator access. Most businesses find at least one name they did not expect. The designer from the last redesign. The intern who wrote blog posts one summer. The agency you stopped paying eighteen months ago. Every one is a working key to your website.
The rules here are simple and they are the same rules that apply everywhere else in your business:
- Delete accounts for people who left. Not disable. Delete, reassigning their content to a current user so nothing disappears.
- Match the role to the job. Someone who writes blog posts needs Author or Editor, not Administrator. Administrator can install code.
- Avoid obvious usernames. The WordPress hardening documentation specifically advises avoiding easily guessed terms such as admin or webmaster, because those are typically attacked first.
- Use long unique passwords from a manager. The same documentation warns against permutations of your own name, username, or company name, and against dictionary words.
- Turn on multi factor authentication. The WordPress documentation recommends enabling two step authentication as an additional security measure, and several well maintained plugins add it to the login screen.
Multi factor matters most on that list, because the second attack pattern the WordPress documentation describes is brute force password guessing: software trying credentials until something works. A stolen password is worthless without the second factor. It is the same defense we recommend against credential theft in our piece on the surge in phishing attacks.
Backups That Do Not Live With Your Host
Your host almost certainly offers backups. Use them. Do not rely on them alone. If your hosting account gets suspended, if the billing card fails, or if you need to leave that host in a hurry, backups stored only inside that account are backups you may not be able to reach.
There is also a technical wrinkle that catches people who think they have a backup and do not. A WordPress site is two separate things. There are files, meaning WordPress itself plus your theme, plugins, and uploads. And there is a database holding every post, page, comment, and setting. The WordPress backup documentation is explicit that the database lives outside your WordPress directory and that you usually cannot back it up by downloading that directory. Copying your files is half a backup, and restoring from half a backup gives you an empty site.
That documentation recommends keeping several recent backups in different locations, for example one on the hosting server, one in cloud storage, and one downloaded locally. It also makes the ownership point plainly: you need to learn how to back up your own site files and restore them. Test a restore once a year on a staging copy. An untested backup is a hope, not a plan, which is the same argument we make about what happens when the cloud goes down.
The Monthly Fifteen Minute Checklist
Put this on a recurring calendar invite with a named owner. Not “someone should.” A person.
- Confirm a current backup exists and that you could actually download it.
- Apply pending updates from the Updates area of the dashboard: core first, then plugins, then themes.
- Click through the site. Homepage, top service pages, and every form. Submit a test form and confirm the email arrives.
- Scan the Users screen for accounts and roles that no longer make sense.
- Note anything abandoned. If a plugin shows no update in over a year, start looking for a replacement before it becomes urgent.
The Bottom Line
WordPress is not insecure. Neglected WordPress is insecure, and the difference is entirely whether someone owns the routine. Update promptly, because disclosure hands attackers the map. Delete what you do not use. Remove accounts belonging to people who are gone. Put multi factor on the login. Keep a backup somewhere your host cannot lose for you. None of this is clever, and that is the point.
If nobody at your company can say with confidence when your site was last updated or where the backups live, that is worth fixing before it becomes an emergency. We handle WordPress maintenance for small and mid sized businesses across Denton County: updates applied and verified, plugins audited, access reviewed, and backups kept independently of your host. Contact us today.
Sources:
Comments are closed