What this article covers
- Why the real way in for attackers is plugins and themes, not WordPress core
- Fifteen measures, in order of impact
- How to check each one on your own site, from outside (or from the admin)
- Which PHP version to use as of October 2026
Security articles often list “change your login URL” and “update your plugins” as if they mattered equally. Their real effect is very different.
This article ranks fifteen measures by impact, each with a way to check it on your own site. Only run these checks on sites you manage yourself. Trying to log in to someone else’s site can be treated as unauthorised access.
Why WordPress sites really get attacked
According to Patchstack’s report “State of WordPress Security in 2026”, 11,334 new WordPress-related vulnerabilities were found in 2025, up 42% on the previous year. 91% were in plugins and 9% in themes. WordPress core had just six, all low risk.
Small businesses in Japan show the same pattern. In IPA’s 2024 survey of information security at small and medium-sized businesses (2024年度 中小企業における情報セキュリティ対策の実態調査), 48.0% of unauthorised access cases were caused by “vulnerabilities such as unapplied patches”, and 36.8% by “stolen IDs and passwords”.
So the order of priorities is clear: updates first, then logins.
The top five: updates, removal, PHP, backups, monitoring
1. Keep core, plugins and themes up to date
Most vulnerabilities already have a fix released. The single best measure is not leaving open a hole that an update would close.
How to check: In the admin, go to Dashboard → Updates (ダッシュボード → 更新) and see whether any updates are waiting. From outside, version numbers shown in the page source are a clue (see also item 11).
2. Delete plugins and themes you don’t use
A deactivated plugin still has its files on the server. “Abandoned” plugins that haven’t been updated in a long time may never get a fix when a vulnerability is found.
How to check: In the Plugins list, delete the deactivated ones. For those you keep, check the “Last updated” date in the official directory. If one hasn’t been updated in over a year, look for a replacement.
3. Use a supported PHP version (8.3 or later as of October 2026)
Each PHP version has an end-of-support date, after which it gets no more security fixes. According to php.net:
| PHP | Security fixes until |
|---|---|
| 7.4 / 8.0 / 8.1 | Already ended |
| 8.2 | 31 December 2026 |
| 8.3 | 31 December 2027 |
| 8.4 | 31 December 2028 |
| 8.5 | 31 December 2029 |
WordPress also officially recommends PHP 8.3 or later. Support for 8.2 ends in about two months, so if you’re upgrading now, choose 8.3 or 8.4.
How to check: Go to Tools → Site Health → Info → Server (ツール → サイトヘルス → 情報 → サーバー) to see your PHP version. You switch versions in your hosting control panel. We’ll walk through the steps in our article on upgrading PHP.
4. Keep backups off the server too, and test that they restore
When a site is hacked or a server fails, backups are your last line of defence. But backups kept only on the same server can be lost along with it.
How to check: Check the date and storage location of your latest backup. Ideally, once or twice a year, actually restore one to a staging site or similar. More in our article on backups.
5. Track vulnerability reports for the plugins you use
If you only wait for updates, you won’t notice vulnerabilities that don’t have a fix yet.
How to check: Search for your plugins by name in databases such as JVN iPedia, WPScan and Patchstack. Some of these services can send you email alerts.
Four measures to protect logins
6. Hard-to-guess passwords, and one account per person
With shared accounts, you can’t tell who did what, and you can’t cut off staff who have left.
How to check: Look through the Users list for former staff or admins you don’t recognise. Limit admin rights to the people who really need them.
7. Turn on two-factor authentication
Even if a password leaks, nobody gets in without the second factor. Given that stolen IDs and passwords made up 36.8% of cases in the IPA survey, this is a high-impact measure.
How to check: Log out, log back in, and check that you’re asked for the second factor.
8. Limit login attempts
Attacks that try passwords by brute force still arrive almost daily.
How to check: On your own site, deliberately enter the wrong password a few times. If you get locked out after a set number of attempts, it’s working.
9. Protect the login page (changing the URL is only a supplement)
Changing the login URL does cut down automated attacks. But once someone knows the URL, it offers no protection, so don’t rely on it alone. Where possible, combine it with IP address restrictions or an extra authentication step in front of the login page.
How to check: Open your site’s login page in a private window. You’ll see whether anyone can open it, or whether it’s restricted.
About SiteGuard: SiteGuard WP Plugin, widely used in Japan, is strong on login protection like items 8 and 9. But it doesn’t handle plugin updates, backups, PHP or server-side protection. Having it installed doesn’t mean you’re covered. More in our article on SiteGuard.
Three measures to stop information leaking
10. Don’t expose the usernames used to log in
Out of the box, WordPress can reveal usernames through author pages or the REST API. Once attackers know a username, they only have to guess the password.
How to check: Open a post on your site and look at the author name and the URL it links to. You can change the displayed name under Users → Profile, with the “Display name publicly as” setting. The URL, however, is built from the login name, so you can’t change it on the profile screen. Instead, disable author pages if you don’t use them, or keep separate accounts for writing posts and for administration.
11. Hide version information and unneeded public files
A visible version number tells attackers which vulnerabilities they can use.
How to check: View the page source in your browser and search for “generator”. If your WordPress version appears, it can be hidden. Also try opening /readme.html on your site. If a WordPress information page appears, delete it or block access to it.
12. Turn off directory listing
If folder contents can be listed, your uploaded files and your plugin setup are on full display.
How to check: Open /wp-content/uploads/ on your site. If you see a list of files, disable directory listing on the server.
Three measures on the server side
13. Turn on HTTPS and HSTS
Encrypted connections are now a given. Adding HSTS makes browsers always connect over HTTPS.
How to check: Type a URL starting with http:// and see whether you’re redirected to https://. You can check HSTS with the tool in the next item.
14. Set security headers
Headers such as Content-Security-Policy (CSP) and X-Content-Type-Options limit the damage if your site is tampered with or embedded in another site. JPCERT/CC has reported cases where a fake login form was injected into a legitimate site and visitors’ details were stolen.
How to check: Enter your site’s URL at securityheaders.com to see a list of the headers that are set. You can also see them in the Network tab of your browser’s developer tools.
15. Use a WAF, and tighten things up inside the server
A WAF blocks traffic that looks like an attack before it reaches your site. Many Japanese shared hosting plans include one for free, or you can put a service such as Cloudflare in front. Also set the following two things, which make it harder for an intrusion to spread:
- Disable the feature that lets you edit theme and plugin files from the admin
- Stop programs from running in the uploads folder where images and other files go
How to check: In your hosting control panel, check that the WAF is set to “on”. File editing is disabled if no “File Editor” (ファイルエディター) appears under Appearance or Tools in the admin.
The 15-item checklist
| # | Measure | Can you check from outside? |
|---|---|---|
| 1 | Updating core, plugins and themes | Partly (version display) |
| 2 | Deleting unneeded plugins and themes | No (admin) |
| 3 | PHP 8.3 or later | No (Site Health) |
| 4 | Off-server backups and restore tests | No |
| 5 | Monitoring vulnerability reports | No |
| 6 | One account per person, tidy permissions | No (Users list) |
| 7 | Two-factor authentication | Check by logging in yourself |
| 8 | Limiting login attempts | Check on your own site |
| 9 | Protecting the login page | Yes |
| 10 | Not exposing usernames | Yes |
| 11 | Hiding version info and readme.html | Yes |
| 12 | Turning off directory listing | Yes |
| 13 | HTTPS and HSTS | Yes |
| 14 | Security headers | Yes |
| 15 | WAF and server settings | Partly |
If you’re unsure where to start, begin with 1 to 5 and 7. Those six cover most of the causes of damage.
What we actually do on this site
wpexperts.jp itself runs on WordPress, and uses the measures in this article. We publish each measure and how to check it on our “How this site is protected” page, so you can use it to compare notes.
Want to check your site all at once?
The items you can check from outside (the “Yes” rows in the table) can all be checked at once with our free security check. Just enter a URL. It looks only at public information and gives you a score. It doesn’t run any tests that put load on your site.
If you’re not sure how to read the results, or you’d like us to check the admin side too, get in touch through the contact form or LINE.