Free WordPress Security Configuration Checker

It observes eight public configuration areas: XML-RPC, wp-login.php, debug output, directory listing, WordPress version disclosure, six security headers, the REST API user endpoint, and selected sensitive WordPress paths.

No. The checker sends bounded public HTTP requests only. It does not exploit vulnerabilities, test passwords, enumerate plugins or themes, inspect source code, or look up known software vulnerabilities.

Not always. XML-RPC can support publishing clients, integrations and pingbacks. If nothing you use needs it, restrict or disable it; if it must stay public, protect it with rate limiting and monitoring.

No. The standard login page is normally public, so reachability is a review item rather than proof of a defect. Use strong passwords, multi-factor authentication, rate limiting and monitoring instead of relying on a hidden URL.

It looks for recognizable PHP and WordPress error signatures in the captured homepage and public debug.log response. It never displays or stores the raw log or configuration-file contents.

The checker requests selected wp-content directories and looks for an actual generated index page, such as an Index of page with a parent-directory listing. A normal application response is not labeled as directory listing.

A page can disclose a WordPress version through its generator metadata. Removing that metadata reduces easy fingerprinting, but installing security updates remains the important control.

No. The REST API is a normal WordPress feature. The relevant observation is whether the public users endpoint returns account identifiers; the checker reports REST availability and user enumeration separately.

The bounded path set covers the public readme and license files, the install and setup screens, debug.log, and one common wp-config.php backup name. Only recognized content is labeled exposed, and raw sensitive content is discarded.

No. It only means the selected public observations did not show those configuration exposures at that moment. Plugin vulnerabilities, authorization flaws, malware, weak accounts and server-side issues require separate authorized testing.