Right now, a bot is running a single command against a website and reading the first few lines that come back. Maybe yours. It is not personal. The bot is working down a list of a few hundred thousand WordPress sites, and any given site is on it because WordPress runs more than 40% of the web and the same small set of mistakes shows up on most of them.
You can read exactly what that bot reads. It takes about ten minutes, the tools are already on your machine, and none of it is hacking. Every check below runs against your own site and looks only at what your server already hands to every visitor who turns up. Just keep them to a site you own or have permission to test.
Read your own response headers
curl -sI https://yourwebsite.com
That returns the headers your server sends with every page. Two things matter.
First, version leaks. A line like x-powered-by: PHP/8.1.34, or a server: header carrying a full version number, hands over your exact software build. An attacker can then look up known vulnerabilities for that precise version without ever touching your site again. There is no real upside to leaving it on display, so it is worth switching off.
Second, missing security headers. Look for strict-transport-security, x-frame-options, x-content-type-options, and content-security-policy. If they are absent, you are missing basic defenses against protocol downgrade, clickjacking, and content-type tricks. Most take minutes to add.
Check whether xmlrpc.php is open
curl -sI https://yourwebsite.com/xmlrpc.php
A 200 or a 405 Method Not Allowed, rather than a 404, means the file is live. xmlrpc.php is a legacy feature almost no modern site needs, and attackers love it: it lets them attempt hundreds of password guesses in one request, and it can be abused to bounce denial-of-service traffic at other sites. If you do not use it, disable it.
See if your usernames are public
Open this in a browser: https://yourwebsite.com/wp-json/wp/v2/users
If it returns a list of names and login slugs, that is half of every login on view. Author pages at /?author=1 leak the same thing. Usernames were never meant to be secret the way passwords are, but a full list of accounts still gives brute-force and credential-stuffing a head start. Both are easy enough to lock down.
Find out if anything is actually guarding the door
Look again at the headers from step 1. A cf-ray line, an x-iinfo line, or a security vendor’s name in the server field means traffic passes through a protective layer before it reaches WordPress. A bare server: Apache or server: nginx, with your domain resolving straight to your hosting IP, means the opposite. Nothing is filtering anything. Every probe, every exploit attempt, every bad bot lands directly on your application.
It is fair to wonder whether a small site is even worth an attacker’s time. The bots do not weigh that up. They are not after your business in particular, they are after a vulnerable version number, and they look for it in the same places you just did.
Check which plugin and theme versions you expose
View your homepage source and search for ?ver=. Plugin and theme files often load with their version attached, like revslider.js?ver=6.5.5. Take that name and version, search it alongside the word “vulnerability”, and you will know in a minute whether you are running a build with a publicly documented flaw. Old slider and page-builder plugins are among the most exploited components on the entire web, precisely because so many sites leave a stale version sitting in place.
Look for files you forgot to delete
A few URL checks catch the usual leftovers:
https://yourwebsite.com/readme.htmloften reveals your exact WordPress version.https://yourwebsite.com/wp-content/uploads/should not return a browsable file list.- A stray
.zipbackup or a visibledebug.login your content folders is worth clearing out.
If any of these load, they are straightforward to remove or block.
Let a free external tool do the rest
Three reputable services read only public information and grade it for you in seconds. securityheaders.com scores your headers and tells you what to add. SSL Labs at ssllabs.com/ssltest checks your HTTPS setup. Wappalyzer, as a browser extension, lists the technologies and versions your site exposes. None of them touch anything private. They just sort the same public signals you have been reading by hand.
What this check will not catch
These checks have real limits, and it is worth being clear about them. They find the obvious, high-frequency exposure that automated attackers go for first: leaked versions, open endpoints, missing headers, stale plugins. That is how a lot of small WordPress sites get breached, so the ten minutes are well spent.
It will not find the deeper class of problem. A logic flaw in a custom checkout. An injection bug in a bespoke form. A broken access control that lets one customer read another’s order. Those need proper dynamic scanning, and for higher-risk sites, a human review. This pass is good hygiene, not a clean bill of health.
And there is a harder problem underneath all of it. Fix everything above, and new vulnerabilities in WordPress core, plugins, and themes keep arriving every week. The gap between a flaw going public and bots weaponising it is now measured in hours. Patching that fast, every time, across every component, with a small team, is a tall order. Most of us cannot keep it up by hand for long.
Where AppTrana fits
That last problem is the one AppTrana exists to solve for teams without a security function of their own.
Rather than leaving WordPress to take every request head-on, AppTrana puts a managed Web Application and API Protection layer in front of it. The signals you just read by hand get handled for you.
Exposure contained at the edge
Leaked versions, open xmlrpc.php, user-enumeration endpoints, and bad bots are filtered before they reach WordPress, so probing your site stops paying off.
DAST scan from day one
It starts with a DAST scan, so you find the exploitable flaws this self-check cannot, on day one rather than after a breach.
Full protection in block mode from day one
With a zero false-positive commitment. No multi-week learning period where the site sits half-covered.
Virtual patching in hours
When a vulnerability drops in something you run, AppTrana can block the exploit at the edge while you update on your own schedule. Defended before you have patched.
24×7 managed team
Handles the tuning and the incident response, which is the part a small team can never really staff.
It starts at $99 per application per month with every module included, which is what makes managed, enterprise-grade protection realistic for a small business rather than a luxury.
Either way, the ten-minute check is a good place to start. It costs nothing and it tells you where you stand today. From there, it is worth weighing whether keeping up with every patch by hand is sustainable for your team, or whether a layer built to do the watching would take more off your plate.
Related Resources
- Managed WAF Deployment Guide for WooCommerce Stores
- CVE-2026-1357: Remote Code Execution in WPvivid Backup & Migration
Stay tuned for more relevant and interesting security articles. Follow Indusface on Facebook, Twitter, and LinkedIn.