Back to Article List

WordPress Security 2026: 4 Habits the Unbreached 32% Share

WordPress Sicherheit 2026: 4 Gewohnheiten der sicheren 32 % - WordPress Security 2026: 4 Habits the Unbreached 32% Share

Melapress's 2026 survey landed with a grim number: 68% of WordPress owners have been breached at least once, and 78% are worried about it. If you run a site, you're probably in one of those camps already. The good news is boring and specific — the 32% who stay clean aren't doing anything clever. They do four unglamorous things consistently.

None of this is "install a security plugin and relax." A plugin is a smoke alarm, not a fire department. What follows is a prioritised routine you can set up in an afternoon and then mostly forget. Start at the top; the first habit prevents more break-ins than the other three combined.

And a note on why this matters more in 2026: attackers now use AI to scan, fingerprint and brute-force at a scale that didn't exist two years ago. Your site doesn't have to be a target to get hit — it just has to be reachable and out of date.

Habit 1: Update on a schedule, not on a whim

The single biggest predictor of staying unbreached is keeping core, themes and plugins current. Pull any breach report apart and you rarely find a zero-day genius at work — it's a six-month-old flaw in a plugin nobody updated, with a patch that shipped long ago.

Turn on auto-updates for minor WordPress core releases and for plugins you trust. For the risky ones — anything touching payments, forms or membership — update manually within 72 hours of a release, after a quick glance at the changelog. You can enable auto-updates per plugin straight from the Plugins screen, or set it globally in wp-config.php:

  • define('WP_AUTO_UPDATE_CORE', 'minor'); — security and maintenance releases apply themselves
  • Toggle per-plugin auto-updates on the Plugins page for everything except the few you update by hand
  • Block the calendar: 20 minutes every Monday to clear pending updates and skim changelogs

Before any manual update, take a snapshot so a bad release can't cost you a weekend. If your plugin count has crept past 25, that's your real problem — each one is a door. Delete what you don't use; deactivated plugins still ship vulnerable code that scanners can reach.

Habit 2: Make WordPress logins boring to attack

Lock down authentication and you remove the attack type that fills every server log: automated brute-force against wp-login.php and xmlrpc.php. Bots don't guess — they replay leaked password lists thousands of times a minute.

Three changes stop the overwhelming majority of this, and they are not equal. Do the first two and you've done the real work:

  • Enforce 2FA on every admin and editor account. Use an authenticator app (not SMS). The WP 2FA plugin from Melapress is free and takes five minutes to roll out to all users.
  • Add rate limiting so repeated failed logins get locked out rather than retried forever. This is what actually blunts a brute-force run.
  • Kill xmlrpc.php if you don't use the WordPress mobile app or Jetpack. It's the quiet back door bots love because it allows many password attempts in a single request.

What I'd skip is renaming the login URL. It's security theatre — it keeps your logs tidy and stops the laziest scanners, but anyone running a real attack finds the endpoint in seconds, and you've traded that marginal benefit for a config quirk that breaks plugins and confuses whoever inherits the site. Spend the energy on 2FA instead.

Pair all of that with a password manager and genuinely random 20-character passwords. No shared admin account, no "admin" username, no password that also unlocks your email. One reused credential is how a single leaked database turns into a breached site.

Habit 3: Keep a backup you've actually restored

A backup only counts if you've restored it at least once — an untested backup is a guess, and ransomware or a hacked database is exactly when guesses fail. The corrupt or half-complete backup tends to reveal itself on the worst possible day, never before.

Follow the 3-2-1 rule without overthinking it: three copies, on two types of storage, with one off-site. In practice that's your live site, a daily automated backup held by your host, and a weekly copy pulled to somewhere the server can't reach — because a backup stored only on the same server dies with the server.

  • Automate daily backups of files and the database
  • Keep at least 30 days of history, so you can roll back past a slow-burning infection
  • Store one copy off the server — object storage, a separate account, or your own machine
  • Do a real restore to a staging site once a quarter and time how long it takes

At TPC Hosting we run automated backups and offer free migration, so moving a site onto managed backups doesn't mean a lost afternoon. But wherever you host, the test-restore is the part that saves you — not the backup itself.

Habit 4: Watch for the quiet signs, not just the alarms

The unbreached 32% notice intrusions early because they monitor change, not just block attacks. A breach rarely announces itself — it runs for weeks, quietly sending spam or skimming checkout data, and by the time your site slows down the damage is done.

You don't need a security operations centre. You need a log of who did what, and a weekly two-minute look at it. An activity-log plugin records every login, user creation, plugin install and settings change with a timestamp and IP. A new admin account you didn't create, or a plugin installed at 3am, is the clearest early warning there is.

Round it out with a few free external checks:

  • Run your domain through Google Search Console and switch on security-issue emails
  • Check your file integrity — unexpected changes to core files are a dead giveaway
  • Scan with WPScan or Wordfence monthly for known vulnerable components
  • Set up uptime and defacement alerts so you hear about trouble before a customer does

The afternoon plan, in order

Do these in sequence and you'll have covered more ground than most sites ever will — in roughly three hours.

StepTaskTime
1Clear all pending updates; delete unused plugins and themes40 min
2Enable per-plugin and minor-core auto-updates10 min
3Roll out 2FA to every admin; reset weak passwords30 min
4Disable xmlrpc.php and add login rate limiting20 min
5Confirm daily backups run and pull one off-server copy20 min
6Do a test restore to staging30 min
7Install an activity log; connect Search Console alerts20 min

If a step stalls — a plugin update that white-screens the site, a restore that won't complete — that's worth a message to your host rather than an hour of solo debugging. TPC Hosting keeps AI on chat at any hour with real engineers following up in business hours, so you're not stuck guessing at midnight. We're EU-hosted and GDPR-friendly too, which matters if a breach ever touches customer data.

FAQ

Does a security plugin alone keep WordPress safe?

No — a security plugin helps but can't compensate for out-of-date software or weak logins. It's one layer; the four habits (updates, hardened logins, tested backups and monitoring) do the heavy lifting. Treat the plugin as a smoke alarm, not the whole fire service.

How often should I update WordPress plugins?

Apply security updates within 72 hours of release, and clear all pending updates weekly. Enable auto-updates for trusted plugins and core minor releases, but update anything handling payments or user data manually after checking the changelog, with a backup taken first.

Is it safe to disable xmlrpc.php?

Yes, for most sites — disable it unless you use the WordPress mobile app, Jetpack or a service that depends on it. It's a common brute-force and DDoS vector because it allows many authentication attempts in one request, so turning it off removes a whole class of attack.

Should I rename my WordPress login URL?

It's largely security theatre. Renaming wp-login.php tidies your logs and deters lazy scanners, but it won't stop a determined attacker, and it tends to break plugins and confuse whoever maintains the site next. Spend the effort on 2FA and login rate limiting, which actually stop brute-force attempts.

How many backups should I keep and where?

Keep at least 30 days of daily backups across two storage types, with one copy off the server. A backup stored only on the same server is lost if the server is compromised, and an untested backup may not restore — so run a real test restore each quarter.