WordPress site check, no login required

The tool below fetches the public version of one address and tells you what follows from it. It does not sign in, it does not scan your network, and it does not guess. It reads what your visitor’s browser reads: the status code after redirects, the headers, the HTML, and the assets that HTML tells the browser to fetch before it can paint anything. Those assets it actually downloads and weighs, rather than estimating them.

#What the check actually measures

The first layer is our own HTTP requests from a Cloudflare edge: time to first byte, the status code once redirects have resolved, security headers, cache headers and compression. The second layer is the HTML itself, which yields the title, the meta description, the canonical, the number of top level headings, JSON-LD blocks, the language attribute and how images are declared.

The third layer is the weight of your page start, and it is usually the one that changes a conversation. The check collects every stylesheet and every non-deferred script in the head, which is precisely what a browser has to finish downloading before it can draw anything. Then it fetches them and reports the real kilobyte count, split between CSS and JavaScript, with the time of the slowest one and the list of third-party origins they come from.

For WordPress there are a few things that are public by design and still surprise owners. Plugin and theme asset paths reveal what is installed and at which version, because the version number usually sits in the stylesheet URL. The REST endpoint listing users answers without authentication unless somebody closed it. The file xmlrpc.php often still answers even though most installations no longer need it for anything.

#Why there is no score here

This is a decision, not a missing feature. A score of sixty-two invites exactly one follow-up question, what do I do about it, and the honest answer to that question is another audit. Weight does not have that problem. Nineteen blocking requests is a number an owner can watch go down. A megabyte of JavaScript arriving before first paint is a number that points at a specific plugin. Eleven requests from two external domains points at a font service and a tag manager, and both of those are decisions somebody made and can unmake.

The layer has a ceiling and it deserves naming. It measures weight and response time, not what your users experience. This is not a Core Web Vitals measurement and it does not replace one. Field data is collected from your real visitors over a twenty-eight day window and it is already yours, free, in Google Search Console under the Core Web Vitals report. If you want to know how a phone on a weak connection in Manchester experiences your checkout, that report is the only thing that will answer. Our numbers tell you which part of the page is responsible for what it shows.

#What the check cannot see

The out of reach list is short and worth knowing before you treat the result as a full picture. The check never enters the admin area, so it knows nothing about accounts, roles, or who last signed in from an unfamiliar address. It cannot see the database, so it will not tell you whether your tables are swollen with abandoned transients. It does not check backups, because backups are by definition not public. It does not compare detected plugin versions against a vulnerability database, so a version it reads is a fact, not a risk assessment. And it checks exactly the one address you gave it, not the whole site.

The logged-in view is its own gap. WordPress serves signed-in visitors an entirely different set of queries and usually disables page caching for them. A store that answers a guest in a few hundred milliseconds can take several times longer for a signed-in customer with a full basket. An outside check will not show that, and no tool without account access will.

#How to read each class of finding

High severity findings cost money or security immediately. No HTTPS on the final URL, a robots noindex on a page meant to be indexed, an open user enumeration endpoint, four or more of the five security headers missing, a slow first byte. A heavy start lands here too: fifteen or more blocking requests, or over half a megabyte before first paint. Each of these has one concrete fix, usually in server configuration or in a plugin you already have.

Medium severity findings describe a state you can run for a year without an outage while quietly losing ground. No caching on the HTML, blocking assets served without compression, fonts loaded from Google’s servers instead of your own domain, a missing meta description, no structured data block, images without dimensions, no sitemap. An owner with steady traffic can schedule these for the next review. An owner running a store through a peak season should pull compression, caching and images off that list first, because those reach the basket fastest.

Low severity findings are mostly traces the stack leaves behind: the WordPress version in the meta generator, the server name and version in a header, several top level headings on one page, short cache lifetimes on static assets, images without lazy loading. None of it will take the site down. Tidy them alongside other work, not instead of it.

Confirmations sit apart from all of that. When the tool reports that the security headers are complete, that the HTML came back from cache, that structured data is present and that the page start is light, it is not filler. It answers the question owners actually ask most often, which is whether the last team did the job.

#When the honest answer is that nothing needs doing

This happens more often than the diagnostic tool market suggests. A company site on decent hosting, on a current WordPress, with a full set of headers, sane caching and a light start, needs nothing from us. If the report shows only low severity findings and confirmations, that is this case. Close the tab and come back in six months.

There is also a middle state where the right move is to wait. If you changed theme or host last week, our numbers already describe the new site while your Search Console report will keep describing the old one for another month. Do not commission work on the strength of two sources describing two different sites. Let the window move first.

And a third case: a real finding that is not yours to fix. A missing security header, missing compression or uncached HTML are frequently host configuration rather than site configuration. One message to your hosting support closes those for less than any project would cost.

#What we do with the address you give us

We fetch public pages at the address you submit, we do not sign in anywhere, and we store nothing beyond an anonymous run counter. The report goes on no mailing list, because we never ask for an email address. If you click through to contact, the form arrives prefilled with the address and the three most serious findings, and you see the whole text before anything is sent.

#Where to go if the report found something real

Repeating medium severity findings usually mean no one is minding the site rather than one broken thing, and the answer to that is WordPress website maintenance. A heavy start and a slow first byte lead to speeding up WordPress. An open user endpoint, a responsive xmlrpc.php and absent headers are material for a WordPress security audit, because those three are not worth fixing one at a time.