What the WordPress security scanner checks
The scanner reads the public home page and a small number of public files, making about a dozen requests. It does not log in, submit forms, guess passwords, upload files, exploit vulnerabilities or make changes to the website.
From those public responses it can identify the WordPress version where exposed, the active theme and its visible version, and plugins that reveal themselves through files loaded on the page. Those versions are checked against our live WordPress vulnerability database, which is updated every 10 minutes from public CVE records.
The malware checks look at the page returned to a visitor for indicators commonly associated with compromised WordPress sites. These include hidden spam links, suspicious spam terms, obfuscated scripts, scripts loaded from suspicious addresses, hidden iframes, Japanese keyword hack content and redirects that may be presented to visitors arriving through Google.
The scan also checks practical security signals around the site, including HTTPS and its SSL certificate, relevant security headers, publicly readable debug.log files, directory listing, listable WordPress usernames, XML-RPC exposure and readme.html. These findings do not all mean that a site has been hacked. Some are configuration choices, while others increase the amount of information available to an attacker.
For wider guidance on reducing WordPress exposure, see our website security information.
How to read your malware and vulnerability results
The score out of 100 is a quick summary, not a certificate of security. Read the individual findings because two sites with similar scores can have very different risks.
Vulnerable plugins, themes or WordPress versions deserve prompt attention. A vulnerability record means the detected version has a publicly documented security issue. Check whether a fixed version exists and whether the component is still maintained before deciding how to update or replace it.
Signs of hacking need closer investigation. Hidden links, injected scripts, unfamiliar iframes or spam text can be evidence of compromise, particularly when they appeared without an authorised change. Google notes that hacked sites may contain injected code or pages and that attackers can use cloaking to make malicious content harder for the owner to see.
Security configuration findings such as an exposed debug.log or directory listing show information that is publicly retrievable. They should be reviewed in context rather than treated as proof of infection.
The scanner also works as a basic WordPress theme detector and plugin detector. It identifies components only when their names or file paths are visible in the public page source or linked assets. That is useful when checking an unfamiliar installation, but it is not an inventory of everything installed on the server.
What a public WordPress malware scanner cannot see
A clean scan is useful evidence, but it does not prove that a WordPress website is clean. This scanner operates from outside the server and therefore cannot inspect the complete filesystem, database, WordPress administration area or hosting account.
Malicious PHP can be hidden in files that are never requested by the home page. Injected database records might appear only on particular URLs, for particular visitors or after a specific action. Backdoors can also exist without changing the public page that the scanner reads.
The same limitation applies to software detection. A plugin may be installed and active without loading a recognisable CSS, JavaScript, image or other file on the home page. Admin-only plugins and functionality triggered only on checkout, account, search or other internal pages may therefore remain invisible. A theme or plugin can also hide its version number.
Google similarly warns that automated security checks can miss some forms of hacked content. If you have unexplained administrator accounts, unexpected files, changed content, Google Search Console security warnings, recurring redirects or malware that returns after removal, a server-side investigation is appropriate even if this scan reports no obvious problem.
What to do if the security scan finds a problem
Before editing files, updating software or making database changes, take a complete backup of both the website files and database. If possible, also retain the existing compromised copy until the cause is understood. Updating software can close a vulnerability, but it does not automatically remove malware or an existing backdoor.
- Record the findings. Note the affected plugin, theme or WordPress version and any malware indicators before changing the site.
- Prioritise known vulnerable components. Where a safe fixed release exists, test the update on staging where practical. Then update WordPress core and the remaining supported plugins and themes, checking the site after each meaningful change.
- Remove software you no longer need. An abandoned plugin or theme can remain a risk even when it is not actively used.
- Investigate signs of compromise. Check files, the database, administrator accounts, scheduled tasks and hosting logs rather than assuming an update has cleaned the infection.
- Change credentials after the environment is clean. Do not send WordPress, hosting, database or email passwords by ordinary email or include them in a support ticket.
If malware is already present, our Hacked Site Rescue is £349. For a broken site or a specific urgent incident, an Emergency Fix is £249 with a response within 2 working hours. Ongoing care plans start at £59 a month, with further details on our pricing page.