Blog · 6 November 2026 · 9 min read

WordPress security: 10 settings you can fix in an hour

Break-ins on small-business WordPress sites are rarely the work of a genius. Almost always it is a script sweeping the internet for the same few holes: an outdated plugin, an “admin” account with a weak password, a login form with unlimited attempts. Below are ten settings that close those doors. None needs a developer, most are a single switch in the dashboard, and the whole list fits in an hour.

Where WordPress break-ins come from

WordPress runs roughly forty percent of the web, so it is the default target – not because it is weak, but because it is everywhere. The core itself is well guarded and patches itself. Almost all vulnerabilities disclosed in the ecosystem (over 90 % according to Patchstack’s yearly reports) are in plugins and themes. The second vector is the login: weak password, no second factor, unlimited attempts. The third is neglected configuration: the file editor in the dashboard, an uploads folder that executes PHP, backups nobody has ever tested.

The good news: a bot that breaks into 10,000 sites a day does not fight any particular one. If your site does not have the three most common holes, the script moves on. You do not need to be a fortress – you just must not be the easiest target on the list.

1. Automatic updates for plugins and themes

Where: Plugins → Installed → “Automatic Updates” column → enable for each; the same under Appearance → Themes.

WordPress core has updated itself for years (maintenance releases since 3.7, and new installs since 5.6 also take major releases). Plugins and themes do not, until you turn it on. Meanwhile the window between a patch being published and mass attacks on unpatched sites is often a matter of hours. Enable auto-updates for everything, and update the exceptions (say, a shop plugin with custom modifications) by hand once a week – not “some day”.

The other half of this point: delete unused plugins and themes, do not just deactivate them. The files of a deactivated plugin are still on the server and can still be called – a hole in an inactive plugin is still a hole. Keep one fallback theme from the Twenty family and remove the rest.

2. The “admin” account and exposed usernames

Where: Users → All Users.

Bots try to log in as admin, administrator, test and as any username they can read off your site. If you have a user called “admin”, create a new administrator with a different username, log in as that user and delete the old one (WordPress will ask whom to attribute the content to – pick the new account).

WordPress reveals usernames in two places: the author archive (/?author=1 redirects to /author/your-login/) and the REST API (/wp-json/wp/v2/users). Give every user a “Display name” that differs from the login, and on a business site without a multi-author blog simply disable author archives (most SEO plugins have a switch; Yoast: SEO → Search Appearance → Archives).

3. Strong passwords and a second factor

Where: Users → Profile → New Password; the Two-Factor plugin (maintained by the WordPress team) or the 2FA module in Wordfence / WP 2FA.

Your WordPress password is the password to your website, your customer list and – through the contact form – your customers’ trust. Require from yourself and every administrator a password from a password manager (WordPress suggests a strong one when you change it) plus a second factor: a code from an app (Google Authenticator, Authy, 1Password) at every login. For convenience, enabling 2FA for the Administrator and Editor roles only is enough.

While you are there, review roles. The person who writes posts does not need an administrator account – Author or Editor will do. The agency that finished the project a year ago does not need an account at all.

4. Login attempt limit and XML-RPC off

Where: the Limit Login Attempts Reloaded plugin (or the brute-force module in Wordfence / Solid Security); XML-RPC – one line of code or the same plugin.

A stock WordPress lets anyone guess passwords forever. A limit (say, 4 failed attempts → the IP is blocked for 20 minutes) turns a dictionary attack from minutes into years. The second side door is xmlrpc.php – the old interface for the mobile app and Jetpack. Its system.multicall method lets an attacker test hundreds of passwords in a single request, bypassing ordinary limits. If you use neither the WordPress mobile app nor Jetpack, turn it off: in your child theme’s functions.php or a plugin like Code Snippets add

add_filter( 'xmlrpc_enabled', '__return_false' );

or block access to xmlrpc.php at the server / Cloudflare level. A one-minute check: open yourdomain.com/xmlrpc.php – if you see “XML-RPC server accepts POST requests only”, it is on.

5. Off-server backups – and one restore test

Where: UpdraftPlus / BackWPup / Duplicator; destination: Google Drive, Dropbox, S3 – anything but the same server.

A backup is the only safeguard that works after a break-in. Three rules: daily (database) and at least weekly (files); off the server (a copy in the same hosting account dies together with the site – in a break-in, a disk failure and an unpaid invoice); tested: once a quarter, restore the backup to a test subdomain or locally. A backup nobody has tried to restore is a hope, not a backup. “My host does backups” does not tick this box – that is their copy, on their terms, on their schedule.

6. The dashboard file editor disabled

Where: wp-config.php (via FTP / your host’s file manager), above the line “That's all, stop editing!”.

define( 'DISALLOW_FILE_EDIT', true );

By default every administrator can edit the site’s PHP code in the dashboard (Appearance → Theme File Editor). That means anyone who obtains an administrator password – or exploits a plugin flaw that grants those privileges – can plant a backdoor in two minutes. This one line removes that ability from the dashboard; you can still change code over FTP, which is a second, separate password. Nobody on a business site edits PHP in a browser, so you lose nothing.

7. File permissions and an uploads folder that cannot run PHP

Where: your host’s file manager or FTP; a .htaccess file in wp-content/uploads/.

The standard: directories 755, files 644, wp-config.php – 640 or 600 (host-dependent; if the site shows an error after the change, go back to 644). Never 777, not even “just for a moment because a plugin asked”. Second: the uploads folder accepts files from forms and the media library, so it is the favourite place to drop a script. Forbid PHP execution inside it – on Apache / LiteSpeed (most shared hosts) create wp-content/uploads/.htaccess containing:

<FilesMatch "\.(php|phtml|php[0-9])$">
Require all denied
</FilesMatch>

Also make sure the server does not list directory contents (open yourdomain.com/wp-content/uploads/ – you should get a 403 error, not a list of folders). If you see a listing, add Options -Indexes to the main .htaccess.

8. HTTPS enforced and security headers

Where: Settings → General (both addresses with https://); headers – hosting panel, Cloudflare or .htaccess.

A certificate is only the start. Both addresses in WordPress settings must begin with https://, otherwise some assets load unencrypted (mixed content) and the login can travel in plain text. Then the headers: HSTS, X-Content-Type-Options, X-Frame-Options, Referrer-Policy, Permissions-Policy – six lines that protect your visitors from content tampering on open Wi-Fi and from your dashboard being embedded in someone else’s frame. How to enable them without breaking the site is covered step by step in HTTP security headers in plain English, and what else breaks behind the padlock in HTTPS is not enough.

9. Registration off, comments under control

Where: Settings → General → “Anyone can register”; Settings → Discussion.

On a business site no stranger should be able to create an account. Untick “Anyone can register” and leave “New User Default Role” at Subscriber – in case some plugin switches registration back on. Comments: if you do not run a blog, disable them globally (Discussion → untick “Allow people to submit comments on new posts”) and close them on existing posts. If you do run one – “Comment must be manually approved” plus Akismet. Spam comments with links are not just clutter: Google treats them as your outbound links, and the comment form is one more place where plugins have had vulnerabilities.

10. Current PHP and a monthly look at Site Health

Where: hosting panel → PHP version; in WordPress, Tools → Site Health.

WordPress runs on PHP, and PHP has expiry dates: version 8.1 stopped receiving security fixes at the end of 2025, 8.2 loses them at the end of 2026. A site on old PHP is exposed to bugs nobody will ever fix – and switching versions in the hosting panel is one click (take a backup, switch to 8.3 or newer, click around the site; if something breaks, the culprit is usually one old plugin). Once a month open Tools → Site Health: WordPress itself will list inactive themes, old PHP, missing HTTPS, disabled auto-updates and several other items from this list.

What not to do

• Do not install three security plugins at once. One (Wordfence, Solid Security, SecuPress – any reputable one) is enough; two can block each other, and each is more code to maintain.
• Do not replace 2FA with a “hidden” login URL. Renaming /wp-login.php to /secret-door filters out the dumbest bots, but it is not security – the address leaks in links, e-mails and the page source.
• Never use “free” copies of paid themes and plugins (so-called nulled). The vast majority ship with a backdoor – it is the simplest way to install your own break-in.
• Do not trust the padlock. A certificate encrypts the connection. It does not patch plugins, guard your password or make backups.

The one-hour plan

1. 0–10 min: auto-updates on, unused plugins and themes deleted (1).
2. 10–25 min: new administrator account, old “admin” removed, roles reviewed, 2FA enabled (2, 3).
3. 25–35 min: login limit plugin, XML-RPC off, registration and comments configured (4, 9).
4. 35–50 min: off-server backup configured and run for the first time (5).
5. 50–60 min: DISALLOW_FILE_EDIT, .htaccess in uploads, PHP version, https addresses in settings (6, 7, 8, 10).

Leave the security headers and the restore test for a second evening – but put them in the calendar, not on the “some day” list.