The WordPress + WooCommerce Audit focuses on speed, plugin footprint, theme choice, and cart-fragments. That's most of what a WP owner needs to keep pages fast. It doesn't cover the second half of "healthy WordPress," which is hardening: exposure surface, update discipline, and the server-level configuration that separates a stable install from one that's a monthly incident. The WordPress Security + Stability Audit is that second tool.
Where the two overlap (and where that matters): the WP+Woo audit already flags XML-RPC presence and REST API user enumeration, because those are the two WP security issues that hit performance audits too often enough to belong there. The security audit digs deeper around both, plus adds checks the performance tool doesn't care about.
What the security tool probes
- XML-RPC endpoint reachability and whether Jetpack or a known client justifies keeping it open.
- REST API
/wp-json/wp/v2/usersendpoint. Counts exposed users. Fails loud if the endpoint returns an array. - wp-login.php reachability at default path. Not a fail on its own (people need to log in), but a flag to consider WPS Hide Login or equivalent.
- /wp-admin/ directory indexing. If your host permits an Index of /wp-admin/, attackers can enumerate core files.
- readme.html and license.txt public reachability. Both leak the exact core version. Neither should be publicly served after install.
- /wp-content/debug.log public reachability. If WP_DEBUG_LOG was ever left on in production, this file can be 100 MB of error text including query bodies and file paths.
- wp-config.php backup patterns: wp-config.php.bak, .old, .save. PHP only parses .php; the backup copies get served as text, exposing DB credentials and auth salts.
- /wp-content/uploads/, /plugins/, /themes/ directory indexing. Plugin-enumeration-by-directory is a known reconnaissance pattern.
- /wp-admin/install.php reachability. If it shows an installer form instead of "already been installed," that's a site-takeover vector.
- Security header coverage: HSTS, CSP, X-Content-Type-Options, Referrer-Policy, Permissions-Policy, X-Frame-Options.
- WordPress version exposure in meta generator and in ver query strings on enqueued assets.
What it doesn't probe (on purpose)
- Plugin CVE matching. That requires a database of known-vulnerable versions, which the tool doesn't ship. Use WPScan or Patchstack for that layer.
- Login brute-force testing. The tool never attempts a login. Ethical audit baseline: only probe public, unauthenticated URLs.
- File-system permissions. Requires SSH or cPanel access the tool doesn't have.
- Database integrity. Same.
- Backup health. Same.
If the audit finds issues the tool can't fully resolve from its vantage point (specific plugin vulnerabilities, encrypted backups, mail-auth DNS records), the fix prompt explicitly names what the site owner needs to verify themselves.
The fix prompt
Copy-paste-ready hardening output. For each finding: server rule (.htaccess snippet plus nginx alternative), plugin recommendation when a plugin is the cleaner fix, and a curl -I verification command so you can confirm the fix shipped. Plus three hardening baselines that apply regardless of findings: WordPress admin hardening (DISALLOW_FILE_EDIT, FORCE_SSL_ADMIN, 2FA, limit-login), stability baseline (automatic minor-core updates, staged plugin updates, production debug off), and server-rule block (.htaccess and nginx) that covers the common hardening rules in one paste.
WooCommerce cross-over
When WooCommerce is detected, the prompt adds a WooCommerce section: PCI-scope notes (Stripe Elements or equivalent keeping card data off your server), checkout-page HTTPS enforcement, payment-gateway webhook signature validation, and admin separation between store admin and WP super-admin. These are not checks the tool runs automatically; they are recommendations that apply every time Woo is present, because running a store with a blurred admin boundary is the most common pre-breach condition.
When to run
Before going live on a new WP host. Quarterly on any production site. After any major plugin or theme change. After any CVE announcement in a plugin you run. Before migrating off WordPress, as part of capturing what the old site was doing so the new site replicates (or explicitly declines to replicate) each behavior.
Related reading
- WordPress + WooCommerce Audit, speed and plugin footprint
- Additional WordPress Audits, the eight deeper checks
- Site Migration Capture, if the right fix is to leave WordPress
Fact-check notes and sources
- WordPress Core documentation on DISALLOW_FILE_EDIT, FORCE_SSL_ADMIN, WP_DEBUG_LOG constants.
- Public WPScan vulnerability-database methodology for CVE matching (noted as out-of-scope).
- OWASP WordPress Security Implementation Guideline for the hardening baseline recommendations.
- PCI DSS 4.0 scope reduction guidance for the Stripe Elements recommendation.
This post is informational, not security-consulting, legal, or compliance advice. Only run the audit against sites you own or have explicit written authorization to test. Hardening recommendations are general; always test on staging before applying to production.
