First CH Apps / WordPress Quick Audit
Enter a URL and we tell you whether the site runs WordPress, which theme it uses, the version it announces, and how it scores on the common exposures: REST API username enumeration, xmlrpc.php, author archives, the default login URL, readme.html and a public debug log. It is the portable half of the security audit we run against our own sites every week.
We request seven well-known WordPress paths and nothing else — no enumeration, no brute force, no POSTs, no plugin sweeps (the same rule our internal audit follows). If you only need to know the CMS, use the Tech Stack Detector; header grading belongs to the Security Header Grader.
Use it on your own sites or ones you have taken over. Subdirectory installs (example.com/blog/) are detected automatically from the top page.
Only run this against sites you own or are authorised to manage. It performs read-only public GETs, but it is not meant for probing other people's sites.
We fetch the top page once, and only if a WordPress fingerprint was found do we GET the following default paths (in parallel, 8 second limit each). No parameter tampering, no brute force.
/wp-json/wp/v2/usersUsername enumeration (REST API)/?author=1Username exposure (author archive)/xmlrpc.phpxmlrpc.php/wp-login.phpDefault login page/readme.htmlreadme.html (version disclosure)/wp-content/debug.logDebug log/wp-json/REST API root"Exposed" does not automatically mean dangerous. The list includes items that are simply WordPress defaults (the REST API, the login page) because they are worth a decision during a maintenance review. Priority is shown as Fix now / Review / FYI.
Versions are self-reported only. We read what the site announces through its generator tag, the ?ver= on a core asset or readme.html — never a guess. If you can see it here, so can everyone else.
"Closed" is not a clean bill of health. A CDN or WAF in front may be blocking the request while the origin still answers it. "Unknown" means we could not connect or could not read the response.
We only look at the default paths of the single site you enter. Plugin vulnerabilities, theme modifications and admin settings are out of reach of any external check.
If no WordPress fingerprint is found, no exposure checks run at all, so unrelated sites never receive those requests.
Sent: only the URL you type. Our server (Cloudflare Workers) fetches it once with a public GET, and — only if a WordPress fingerprint was found — GETs seven default paths as well (eight requests in total, with no cookies and no credentials).
Stored: nothing. The audit lives entirely inside one request and writes neither the URL nor the result to any database (no KV, no D1). It leaves memory when the request ends.
Returned: the verdict, theme names, version, and each check's HTTP status plus short matched fragments. Neither the fetched pages nor a header dump is re-served — this app cannot be used to browse other sites through us.
Usernames are never returned. Even where the REST API does list your users, all we report is that it is exposed and how many entries there were. The names are counted and discarded inside the request.
Cookies: only Set-Cookie names feed the detection; values are never touched. We fetch public pages exactly as an anonymous visitor would.
Note: public GET only. URLs pointing at internal networks, localhost or private IPs are rejected.
POST /wp-check/api/check with JSON ({"url": "https://example.com/"}) or a form body and you get the same result back as JSON.