Does a security plugin make a WordPress site secure?

It helps with some categories, such as login brute-forcing, and it does nothing about the most common cause, which is a known vulnerability in an installed plugin or in the core. A firewall in front of unpatched software still fronts unpatched software, so updates come first and the plugin second.

Is hiding the WordPress version worth doing?

Very little. Version fingerprints leak from several places at once, including asset URLs and readme files, and mass scanning does not bother fingerprinting anyway: it fires the exploit at every site and keeps whatever answers. Time spent hiding a version is better spent changing it.

How often should a WordPress site be checked?

After every core or plugin update, and on a standing schedule otherwise. Updates are when the exposure changes on purpose, and the standing check is for the changes nobody makes: a new CVE published against an installed version, a certificate expiring, a blacklisting.

Can the scan check plugins and themes one by one?

The passive scan flags an outdated core with known CVEs and detects vulnerable libraries a plugin or theme bundles into the page. A full inventory of installed plugins requires active probing, which runs only on a domain verified as belonging to the requester.

← All guides

Is a WordPress site secure?

WordPress runs a large share of the web, which makes it the most automated target on it. Almost nothing that hits a small site is a person: it is a script working through a list of known vulnerabilities in specific plugin and core versions, and it finds sites by scanning, not by choosing them.

Short answer

Exposure can be measured, security cannot be proven

No tool can prove a site is secure, and any tool that claims to is overselling. What can be settled in about a minute is the opposite and more useful question: whether a site is currently exposed on the things those scripts look for.

That means an outdated core or plugin with published CVEs, front-end libraries with known flaws, missing security headers, a broken or expiring certificate, and a blacklisting. Those five account for most of what actually gets exploited on small WordPress sites, and every one of them is visible from outside without touching the site.

Start with what an outsider can already see

The useful first move is to look at a site the way an automated scanner does, because that view is free, instant, and exactly the one an attacker starts from. A passive scan reads only what the site shows every visitor: the version fingerprints in the markup, the libraries the page loads, the response headers, the TLS certificate, and public reputation lists.

That view answers most of the question. It cannot see inside the admin, and it does not need to: the vulnerabilities that get exploited at scale are in software versions that announce themselves from the outside.

An outdated core with published CVEs, counted against the running version rather than as a lifetime total. (WordPress security check)
Vulnerable front-end libraries, which on WordPress usually arrive inside a plugin or theme rather than being added deliberately. (Vulnerable JavaScript libraries)
Missing security headers, the most common failure of all and the cheapest to clear. (Core security headers)
A certificate that is invalid or close to expiry, which caps the score and stops visitors at a browser warning. (SSL certificate)
A listing on Safe Browsing or a DNS blocklist, which usually means a compromise already happened. (Blacklisting & Safe Browsing)

The five habits that matter more than any plugin

Most WordPress compromises trace back to the same small set of causes, and none of them is solved by installing another security plugin on top of an unpatched site.

Update the core, plugins, and themes on a schedule, and turn on automatic updates for security releases. A known CVE in an installed plugin is the single most common way in.
Delete what is not used. A deactivated plugin still sits in the filesystem and is still reachable by its files, so unused plugins and themes are removed rather than switched off.
Install only from sources with a maintenance record. Abandoned plugins never get the patch, and nulled or pirated themes routinely ship a backdoor as the actual product.
Give every account its own login, with a unique password and two-factor authentication on anything holding administrator rights. Shared logins make a breach impossible to trace afterwards.
Keep backups somewhere the web server cannot serve, and restore one occasionally to confirm it works. A backup inside the document root is a download waiting to be found. (Directory listing covers how those get discovered.)

What only a deeper look can answer

Some of the worst findings are invisible from outside by definition, because detecting them means requesting files that nothing links to. Whether a site serves its .git directory, leaves an editor backup of wp-config.php in the web root, or lists the contents of its uploads folder cannot be established by reading the public page.

CheckWeb runs those checks in the Deep Audit, after domain ownership is verified, which is the same boundary the terms describe: passive reading for anyone, active probing only for a site whose owner asked. The practical consequence is worth stating plainly, because it is easy to misread a clean free report as an all-clear.

A clean passive scan means nothing exposed was visible from outside. It is not evidence that a site has no exposed files. (Exposed .git directory explains why the free scan stays out of this.)
Enumerating installed plugins, finding admin panels, and probing for backup archives all belong to the same verified layer.

Once is not an answer

A security check describes one moment. The stack does not change that day, but the list of known vulnerabilities in it does: a plugin that was clean this morning gets a CVE published against its exact version this afternoon, and nothing on the site has to change for it to become exploitable.

That is why the useful cadence is a re-check after every plugin or core update, and a standing check otherwise. Certificates expire on a schedule, blacklistings arrive without warning, and both are cheap to catch early and expensive to notice late.

Re-scan after each update, and confirm the CVE count actually dropped rather than assuming it did.
For a standing check rather than a manual one, a watch can email when something slips. (Continuous monitoring)

What CheckWeb does not do

CheckWeb diagnoses. It reports what is exposed, counts the CVEs that reach the running versions, and says what to fix in what order. It does not remove malware, does not clean a compromised site, does not restore backups, and is not a firewall or a plugin that runs inside WordPress.

For cleanup and incident response, the established specialists are Sucuri, Wordfence, and MalCare, and a site that is already flagged as compromised is better served by one of them than by another scan. Diagnosis and cleanup are separate jobs, and a tool doing both well is rare enough to be worth doubting.

Check a WordPress site now

Paste the address for the outside view in seconds: core CVEs by version, vulnerable libraries, headers, certificate, and reputation. Free, no signup, and nothing is sent to the site beyond a normal page request.

Check my website

FAQ

Does a security plugin make a WordPress site secure?: It helps with some categories, such as login brute-forcing, and it does nothing about the most common cause, which is a known vulnerability in an installed plugin or in the core. A firewall in front of unpatched software still fronts unpatched software, so updates come first and the plugin second.
Is hiding the WordPress version worth doing?: Very little. Version fingerprints leak from several places at once, including asset URLs and readme files, and mass scanning does not bother fingerprinting anyway: it fires the exploit at every site and keeps whatever answers. Time spent hiding a version is better spent changing it.
How often should a WordPress site be checked?: After every core or plugin update, and on a standing schedule otherwise. Updates are when the exposure changes on purpose, and the standing check is for the changes nobody makes: a new CVE published against an installed version, a certificate expiring, a blacklisting.
Can the scan check plugins and themes one by one?: The passive scan flags an outdated core with known CVEs and detects vulnerable libraries a plugin or theme bundles into the page. A full inventory of installed plugins requires active probing, which runs only on a domain verified as belonging to the requester.