Securing WordPress: Hardening, Updates, Plugins and Backups

You secure WordPress lastingly with six building blocks: reduce the attack surface, protect access with minimal permissions and two-factor authentication, choose plugins carefully, apply updates on a fixed schedule, test backups and monitor for anomalies. Updates offer the biggest lever: disclosed vulnerabilities mostly affect plugins and themes, not the WordPress core.

Why Even Small Companies Need to Secure WordPress

“We are too small to be interesting” – we hear this often. The problem: most attacks are not targeted. Bots scan the web around the clock for known vulnerabilities in plugins and themes and strike wherever a gap is open. Whether a corporation or a craft business is behind the site makes no difference.

The consequences are tangible: injected spam pages, redirects to third-party offers, browser warnings, harvested form data or an unreachable website. If personal data is affected, a duty to notify the data protection authority may also arise – the GDPR generally provides for 72 hours from becoming aware.

Reducing the Attack Surface and Protecting Access

Clean up and configure

Every line of code on your server is potentially vulnerable. The most effective hardening therefore starts with leaving things out: delete unused themes and plugins completely. Even deactivated extensions remain on the server, and their files can sometimes be called directly. The same goes for old default themes installed just “in case”.

In addition there are settings at server and WordPress level that limit the damage if something does slip through:

Measure	Effect	Note
Disable the file editor in the backend (DISALLOW_FILE_EDIT in wp-config.php)	Anyone gaining backend access cannot modify code there.	Installing plugins remains possible.
Block PHP execution in the uploads folder	Injected files cannot be executed.	Via server configuration, not via plugin.
Set restrictive file permissions, protect wp-config.php in particular	Database credentials and keys are not readable by other processes.	Suitable values depend on the hosting.
Disable XML-RPC if not needed	An entry point for automated login attempts is removed.	Some plugins and apps use XML-RPC.
Debug output and directory listing off in live operation	Visitors see no paths, error details or file lists.	Debugging only in staging.

Protect access

• Individual accounts: every person gets their own account; shared logins such as “admin” for the whole team make changes untraceable.
• Roles by task: anyone writing posts does not need administrator rights; old accounts are removed regularly.
• Strong credentials and two-factor authentication: long, individual passwords from a password manager and 2FA for all administrators, via a maintained plugin or central login.
• Application passwords for integrations: interfaces and automations get their own revocable credentials instead of the main password.
• Login protection: rate limiting or lockout after repeated failed attempts so brute-force attacks go nowhere.

Choosing Plugins and Themes Carefully

Every plugin is third-party code with far-reaching access to your website. Before installing a new one, a short check is worthwhile:

• Maintenance: is it updated regularly and compatible with your WordPress and PHP version? Take warnings in the plugin directory about long-unmaintained extensions seriously.
• Vendor: is there a traceable developer behind it who responds to security reports?
• Scope: do you need the full package if you use only one feature? Two plugins for the same job increase load and risk of conflicts.
• Origin: no “free” copies of premium plugins from unofficial sources – a well-known entry point for malicious code.

For recurring requirements, a lean, custom-built extension is often the better choice than a universal plugin. That is a focus of our WordPress development.

Updates: Routine, Priority and Staging

Updates are the most important single measure – and the one most often left undone in daily routine. A fixed rhythm takes the topic out of gut feeling. WordPress installs minor core updates for security and maintenance automatically by default; for plugins and themes, automatic updates can be enabled per item.

Category	Example	Guideline
Critical or actively exploited security flaw	vendor reports an attack in the wild or a high risk	immediately, within 72 hours at the latest; until then deactivate the plugin or shield it with a firewall
Security and maintenance updates	patch release of core or plugin	weekly or automatically, with a backup and monitoring in place
Feature updates	new features of a plugin	in a fixed maintenance window, large plugins in staging first
Major updates	new WordPress major version, WooCommerce release, PHP change	test in staging first, then apply in a planned window

Testing major updates in the staging environment

We test larger version jumps of WordPress, WooCommerce or central plugins first in a staging environment, a copy of the live website. For complex WooCommerce shops with many extensions, we typically plan one to two sprints of lead time. That way conflicts in checkout or interfaces surface before customers notice them.

Backups that can really be restored

Before every update there is a current backup of files and database, stored outside the web server. What matters is not that backups exist but that restoring them is tested regularly – otherwise you learn in an emergency that the backup is incomplete.

When a Vulnera­bility Is Disclosed: The Process

1. Check whether the affected plugin or theme is installed and active at all and which version is running.
2. Check whether the vendor provides a patch and what the severity is.
3. Trigger a backup and, if needed, quickly test the update in staging.
4. Apply the update. If there is no patch: deactivate the extension, replace it or shield it with a firewall rule.
5. Check logs and file changes for signs of an earlier attack, including newly created administrator accounts.

Hosting and Monitoring: The Second Line of Defense

Isolated websites prevent one compromised project from dragging others on the same server down with it. A web application firewall filters typical attack patterns before they reach WordPress. Add site-wide HTTPS, security headers such as HSTS and X-Content-Type-Options (a strict Content Security Policy only after thorough testing, because it can break themes and plugins) and a currently supported PHP version: PHP 8.1 and older no longer receive security updates, and PHP 8.2 reaches its end in late 2026. Fewer plugins and a current PHP version also make the site faster – more in the article Core Web Vitals in practice.

Hardening is not a one-off project. Lean monitoring makes anomalies visible early:

• availability of the website and expiry date of the SSL certificate
• changes to core files, themes and plugins
• clusters of failed login attempts
• newly created administrator accounts
• security notices in Google Search Console

Practical Example and Checklist

Craft business with a grown website

Suppose a craft business has run a WordPress site for years with about 30 plugins, two inactive themes, a shared “admin” login and only the host’s nightly backup. A sensible roadmap:

1. Full backup, staging copy and inventory of all plugins with version, purpose and maintenance status.
2. Clean up: delete inactive themes and unused and duplicate plugins, replace abandoned extensions.
3. Updates in staging first, then live; update the PHP version.
4. Reorganize access: personal accounts, suitable roles, 2FA for administrators.
5. Set up hardening, firewall and login protection, external backup with a restore test and monitoring.

Side effect: with fewer plugins and current PHP, the site usually becomes noticeably faster.

Checklist: securing WordPress in ten steps

1. Delete unused themes and plugins completely.
2. Set restrictive file permissions, disable the file editor in the backend.
3. Assign user roles by task, remove old accounts.
4. Enable 2FA for all administrators.
5. Vet plugins by maintenance, vendor and benefit.
6. Apply critical security updates within 72 hours.
7. Test major updates in staging first.
8. Use a currently supported PHP version.
9. Store backups externally and test restoring.
10. Set up monitoring for availability, file changes and logins.

For custom-built web applications beyond WordPress, you will find further starting points in the OWASP checklist for web security.

How Nano Concepts Supports You

Would rather not keep an eye on this yourself? As part of WordPress maintenance we take over updates, backups and monitoring for your website; we implement the hardening of your installation as WordPress security hardening. In the free initial consultation we clarify the current state and what to do first. This article does not replace legal advice.