Observation, not exploitation
The checker recognizes selected public response signatures. It sends no attack payload, login attempt, password test or component enumeration request.
Free tool, no account required
Free WordPress Security Checker: Eight Live Configuration Checks
The WordPress security checker observes eight public configuration areas on a live WordPress site, from XML-RPC and the login path to debug leakage and sensitive files. No passwords are tested and no plugins are enumerated.
Also known as: WordPress hardening checker, XML-RPC and REST API test
Evidence shown with sourceNo account requiredNo invented metrics
Run a real check above
Submit a public URL, domain, or keyword. Novaverb will show only the evidence this tool can actually retrieve or measure.
Definition
What is a WordPress security checker?
A WordPress security checker is a tool that looks at how a WordPress site is configured from the outside. The Novaverb WordPress Security Configuration Checker sends a bounded set of public HTTP requests to the submitted origin and reports eight named configuration observations, each on its own evidence and without a composite security score.
Scope
What does the WordPress security checker check?
The WordPress security checker checks eight areas: XML-RPC status at xmlrpc.php, access to wp-login.php, WP_DEBUG leakage, directory listing in three wp-content directories, WordPress version disclosure in generator metadata, six security response headers, REST API user enumeration and six sensitive public paths, among them debug.log and one common wp-config.php backup name.
Who it is for
Who is the WordPress security checker for?
The WordPress security checker is for anyone responsible for a public WordPress site. A site owner checks whether a debug log or setup file was left reachable. A developer confirms that a hardening change is live after deploying it. An agency records the starting configuration of a site it is taking over.
Why it matters
Why use a WordPress security checker?
A WordPress security check finds exposed configuration before someone else reads it. A public debug.log shows PHP and WordPress errors, a wp-config.php backup can expose configuration secrets, an open directory index lists files, and a users endpoint can return account identifiers. Each one answers any anonymous request until access is restricted.
Method
How does the WordPress security checker work?
The WordPress security checker works in a fixed sequence. The submitted address is fetched through a pinned public-IP safety check, and every redirect destination is checked again. A bounded WordPress path set is requested and exact response signatures are recognized. The homepage is read for version signals and six headers. Raw response bodies are then discarded.
- We fetch the submitted public address through a pinned-IP safety check and re-check every redirect destination.
- We request a bounded WordPress path set and recognize exact login, XML-RPC, REST, directory-index, debug and sensitive-file signatures.
- We read the homepage for WordPress version signals and six selected browser security headers.
- We discard raw response bodies and report eight named configuration observations without creating a composite security score.
Input
What do you enter into the WordPress security checker?
Enter a public WordPress domain or any URL on that site into the WordPress security checker. The address is normalized to the final public origin before WordPress paths are requested. Private and reserved targets, localhost included, are refused. A site that hides every recognizable public signal can return a result reading WordPress not confirmed.
Use it like this
your-wordpress-site.comA public WordPress domain works, and the checker normalizes the address before the bounded requests.https://www.your-wordpress-site.com/blogA full page URL works too; WordPress configuration paths are checked at the final public origin.Avoid this
localhost / 10.0.0.8Private and internal targets are refused by the public-IP safety boundary.Expecting a vulnerability scanThis tool checks selected public configuration evidence only; it does not exploit, authenticate, or enumerate installed components.Result
What does the WordPress security checker report contain?
The WordPress security checker report contains a summary and eight numbered cards. The summary counts how many areas need review, how many showed no selected exposure and how many could not be concluded. Each card names the area and path checked, shows its state and gives a next action when something was observed.
Reading it
How do you read a WordPress security check result?
Read a WordPress security check result one area at a time, because no composite score exists. A clean header result cannot cancel an exposed debug log, and an unavailable response never becomes a pass. A reachable wp-login.php is normal WordPress behavior and a review item, not proof of a defect. Exposed logs and sensitive files come first.
How to read this WordPress configuration result
No composite security score
Each of the eight areas stands on its own evidence. A clean header result cannot cancel an exposed debug log, and an unavailable response never becomes a pass.
Fix, deploy, re-check
Prioritize exposed logs and sensitive files, then public user enumeration and unnecessary endpoints. Re-run the exact check after deploying each configuration change.
Source
Where does the WordPress security checker get its data?
The WordPress security checker gets its data from bounded live HTTP observations of the submitted public WordPress origin. Requests go to the homepage, xmlrpc.php, wp-login.php, the REST discovery and users endpoints, three wp-content directories and six sensitive paths. The result describes what those public responses returned on one origin at one moment.
Limits
What does the WordPress security checker not tell you?
The WordPress security checker does not tell you that a WordPress site is secure. The review is non-intrusive and covers selected public HTTP responses only. Passwords are not tested and vulnerabilities are not exploited. Plugins and themes are not enumerated, source code is not inspected, and accounts, databases, malware and known software vulnerabilities are outside the check.
Evidence
What does a WordPress security check result prove?
A WordPress security check result proves that a specific public response matched, or did not match, a recognized signature at that moment. An exposed finding means recognizable content was returned, not merely an HTTP 200. A clean result means the selected observations showed no exposure, while plugin vulnerabilities, weak accounts and server-side issues remain untested.
1. Source
Bounded live HTTP observations from the submitted public WordPress origin. The result identifies where its evidence came from.
2. Boundary
This is a non-intrusive configuration review of selected public HTTP responses. It does not test passwords, exploit vulnerabilities, enumerate plugins, or prove that a WordPress site is secure.
3. Next action
Use the finding to verify a problem, then connect a workspace when you need history, monitoring, or site-wide analysis.
Standards
Which standards does the WordPress security checker apply?
The WordPress security checker applies WordPress documentation, an IETF specification and an OWASP project. WordPress documentation defines XML-RPC and REST API behavior. RFC 9110 defines the HTTP statuses read on each bounded path. The OWASP Secure Headers project supplies the six selected response headers. None of these turns a public response into proof of a vulnerability.
WordPressXML-RPC
WordPress XML-RPC support
Recognizes whether the standard public XML-RPC endpoint answers with a WordPress XML-RPC signature.
Read the specificationWordPressREST API
WordPress REST API
Checks REST discovery separately from whether the public users endpoint returns account identifiers.
Read the specificationIETFRFC 9110
HTTP Semantics
Reads each bounded path's response status while preserving unavailable and restricted outcomes.
Read the specificationOWASPSecure Headers
OWASP Secure Headers Project
Reports presence of the six selected response-header controls without claiming their policy values are complete.
Read the specificationWe list a standard only where this tool genuinely reads or measures against it. Where a signal is outside a live check, the result says so instead of implying coverage.
Verification
How can you verify a WordPress security check result yourself?
Verify a WordPress security check result by requesting the same public paths in a private browser window while signed out. Open the reported path, a wp-content directory for instance, and see whether an index page or file content comes back. View the homepage source and look for a generator meta tag that carries a WordPress version.
Example
What does a typical WordPress security check finding look like?
A typical WordPress security check finding is a site with WordPress signals observed and several areas marked for review. XML-RPC returns a recognizable response, the login form is publicly reachable, the generator metadata discloses a version and some of the six headers are not observed. Directory listing, debug leakage and sensitive paths show no selected exposure.
Cost
Is the WordPress security checker free?
The WordPress security checker is free and needs no account to run. An account is needed for what follows the check: a free workspace can crawl the site you choose, retain evidence over time and re-check configuration changes after you deploy them, so each fix is confirmed by a fresh observation.
In a workspace
What does a Novaverb workspace add to the WordPress security checker?
A Novaverb workspace adds retained evidence and whole-site coverage to the WordPress security checker. Site Trust & Security continues the job as a bounded scorecard for captured site trust signals, headers and supported external probes. The site is crawled, results are kept over time, and a configuration finding moves into a task that is rechecked.
When to go further
When is a free WordPress security check not enough?
A free WordPress security check is not enough when the question goes beyond eight public observations on one origin. Plugin vulnerabilities, authorization flaws, malware and weak accounts require separate authorized testing. A site spread over several origins needs each one checked. A site that changes often needs recurring observation, because a result holds only for its moment.
Next step
What should you do after running the WordPress security checker?
After running the WordPress security checker, act in priority order. Remove exposed logs, backup files and setup files from the web root. Restrict anonymous access to user data on the REST users endpoint. Disable or restrict XML-RPC when no publishing client or integration requires it. Add missing headers at the server or edge. Re-run the check after deploying.
Related tools
Which free tools pair with the WordPress security checker?
The WordPress security checker pairs with free tools that cover what a WordPress path check leaves out. The Website Security Checker adds the TLS certificate and selected TCP-port probes for the same hostname. The Website Safety Checker looks the URL up on Safe Browsing threat lists. The Website Monitor runs a live availability check after a change.
Website SEO CheckerHomepage status, indexability, title, headings and links from one live scan
Keyword Research ToolFree keyword research tool: monthly searches, cost per click, ad …
SERP CheckerFree SERP checker: the organic results for a keyword in …
Website Security CheckerFree website security checker: a limited outside check of a …
Server Response Time CheckerFree server response time checker: one live request from Germany, …
Backlink CheckerFree backlink checker: see the referring domains, link totals, follow …
Robots.txt CheckerFree robots.txt tester: fetch a site's live robots.txt and see …
Sitemap CheckerFree sitemap checker: find a site's XML sitemaps from robots.txt …
Meta Tag CheckerFree meta tag checker: a page's live title, meta description, …
HTTP Status & Redirect CheckerFree redirect checker: trace every hop of a URL's redirect …
Website MonitorFree website status checker: one live request to your address …
HTTP/2 TestFree HTTP/2 test: opens one live TLS connection to a …
HTTP/3 TestFree HTTP/3 test: attempts a real QUIC connection to a …
Website Performance TestFree website performance test: time one request to your URL …
GEO CheckerFree GEO checker: retrieve, quote, cite and graph signals from …
Core Web Vitals CheckerFree Core Web Vitals checker: real-user LCP, INP and CLS …
PageSpeed CheckerFree PageSpeed checker: a Lighthouse lab audit of a public …
Website Safety CheckerFree website safety checker: see whether a URL is listed …
Knowledge Graph CheckerFree Knowledge Graph checker: look up a brand or name …
Keyword Gap CheckerFree keyword gap analysis: keywords a competitor ranks for and …
Competitor Top PagesFree competitor top pages tool: a domain's leading pages by …
Questions
What do people ask about the WordPress security checker?
The WordPress security checker FAQ answers whether the tool is a vulnerability scanner, whether XML-RPC should always be disabled and whether a public wp-login.php page is automatically insecure. Other answers explain how exposed debug output is detected, what counts as directory listing, how WordPress discloses its version and which sensitive paths are requested.
What does the WordPress Security Configuration Checker inspect?
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.
Is this a WordPress vulnerability scanner?
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.
Should XML-RPC always be disabled?
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.
Is a public wp-login.php page automatically insecure?
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.
How does the checker detect exposed WP_DEBUG output?
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.
What counts as WordPress directory listing?
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.
How can WordPress disclose its version?
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.
Is the WordPress REST API unsafe?
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.
Which sensitive WordPress paths are checked?
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.
Does a clean configuration result prove the site is secure?
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.