Check what a WordPress site shows at its front door.
Whether it gives away its version and user names, whether its pages really come from a cache, how fast it answers, and what to fix first. It takes about five seconds, needs no login and stores nothing.
Or try wordpress.org or woocommerce.com.
What it checks
Twenty-two possible findings in five areas. Each finding says what was seen, why it matters and how to fix it.
- What it leaks
- The WordPress version in the generator tag or in
readme.html, account names listed by/wp-json/wp/v2/users, and whetherxmlrpc.phpanswers.A typical finding:User names are listed by the REST API
- Security headers
- HTTPS and Strict-Transport-Security,
X-Content-Type-Options, protection against framing,Referrer-Policyand a Content-Security-Policy.A typical finding:No Strict-Transport-Security header
- Caching
- Whether this request was served from a page cache or CDN (Cloudflare, LiteSpeed, Kinsta, Sucuri, Vercel and others), the
Cache-Controlpolicy, time to first byte and redirect hops.A typical finding:A cache is present but this request missed it
- Page weight
- The size of the HTML, scripts and stylesheets in the head, images without width and height, the emoji script, jQuery Migrate and third-party script hosts.A typical finding:
12 scripts in the head
- Footprint
- The theme and the plugins that load files on the page, read from their
wp-contentpaths.A typical finding:23 plugins load assets on this page
How a check runs
You give it an address
A domain such as
example.comor a full URL. Private, local and non-standard-port addresses are refused before anything is fetched.It knocks, like a visitor
Five public GET requests: the page,
/wp-json/, the users endpoint,/xmlrpc.phpand/readme.html. Each has eight seconds, and redirects are followed one hop at a time, five at most.You get the fixes in order
Scores for security, caching and page weight, every finding with what was seen, and the five fixes that matter most at the top.
Fix guides
Each finding in a report links to the guide that fixes it, with the code, the server settings and a command to confirm the fix. The limits of the check are on how it works.
- Hide the WordPress version numberThe version shows in the page's generator tag and in the stock readme.html. Both can go in a few minutes.
- Stop the WordPress REST API listing user namesThe users endpoint answers anonymous requests with account slugs, which are usually the login names.
- Turn off XML-RPC in WordPressxmlrpc.php still answers. Unless Jetpack or a publishing app needs it, block it at the server.
- The WordPress security headers the checker readsFive response headers and HTTPS itself. Set them once at the server or CDN and every page carries them.
- Is your WordPress page really cached?A cached page skips PHP and the database entirely. The response headers tell you whether that happened.
- Read and reduce time to first byte on WordPressUnder 300 ms looks like a cached page. Over 800 ms usually means PHP and the database are doing work on every visit.
- Trim WordPress page weight: scripts, styles and pluginsMost of a WordPress page's weight is plugins loading files on pages that do not use them.
Questions
Is it safe to check a site I do not own?
Yes. The checker makes the same public requests any browser or search engine makes. It never logs in, never tries a password, never submits a form and never sends anything but GET requests. The site sees five ordinary page loads.
How do I stop WordPress announcing its version?
Remove the generator tag with add_filter('the_generator', '__return_empty_string'); in a small plugin or the theme, or with the switch most security plugins have. Then delete readme.html after every core update, or block it at the server, because it names the version too.
Why can anyone see my user names?
WordPress lists the authors of published posts at /wp-json/wp/v2/users to anonymous visitors. The login names it reveals are half of what a password-guessing attack needs. Most security plugins can limit the endpoint to logged-in users, or a rest_authentication_errors filter can.
Should I turn off XML-RPC?
Usually. It is an old remote-publishing interface that password-guessing tools like, because one request can try many passwords. Keep it only if Jetpack or the WordPress mobile app needs it. The xmlrpc_enabled filter turns off the methods that need a login; blocking xmlrpc.php at the server stops it answering at all.
How does it know whether a page was cached?
It reads the response headers: cache status headers from CDNs and hosts such as cf-cache-status, x-litespeed-cache or x-kinsta-cache, and the Age header. It also looks for the signature of caching plugins like WP Rocket or W3 Total Cache in the HTML. A cache that is installed but missed on this request is reported separately from no cache at all.
How are the scores worked out?
Each area starts at 100. A problem takes off 25 and a warning takes off 10. The overall score weights security at 40% and caching and page weight at 30% each. The fix-first list ranks problems above warnings.
Why is the time to first byte different from what I see?
It is measured from the checker's server on the final hop, so the distance to your host counts. Under 300 ms is what a cached page usually looks like; a first byte well over that points at PHP and database work on every request.
Is anything stored, and is there an API?
Nothing is stored: every report is built fresh from the responses and forgotten. When Jev is switched on, the page's title, description and visible text go to it once to read what kind of site it is, unless the page carries text aimed at AI readers. The same report is available as JSON at /api/check?url=example.com, limited to ten checks a minute per address.