The reassuring green tick
"Your site was scanned today. No threats found." Every maintenance report says it, every security plugin's dashboard shows it, and it feels like the security question is answered. It is a useful sentence and a partial one. Knowing what a scan does and does not do is the difference between a site that is monitored and a site that is secure.
What a scan is
A security scan is software that examines your website looking for signs of a problem. There are two kinds, and most care plans run both.
A file scan runs on the server. It compares every WordPress core, plugin and theme file to the known-good original, flags anything modified or added, and searches for patterns that look like malicious code: obfuscated scripts, hidden redirects, backdoor shells. It also checks for known vulnerable versions of installed plugins.
An external scan visits the site from outside, as a visitor would, and looks for symptoms: spam content injected into pages, redirects to other sites, blacklisting by Google or security vendors, an expired certificate, exposed configuration files.
Together they answer two questions daily: has anything on the server changed that should not have, and does the site look compromised from outside?
What scans catch well
- A hack that has already happened and left files behind. Malware injected into a theme file, a rogue plugin, a backdoor. File scans find these reliably, usually within a day.
- Known vulnerable plugin versions. The scanner cross-references your plugin list against public vulnerability databases. This is the most valuable routine finding: "this plugin has a known hole; update it" before anyone exploits it.
- Visible symptoms. Spam links in your footer, a redirect to a pharmacy site for mobile visitors, a Google "this site may be hacked" warning.
- Configuration slips. Debug mode left on, directory listing enabled, a backup zip sitting in a public folder.
What scans cannot catch
An attack that has not happened yet. A scan finds evidence of compromise. It does not prevent one. Prevention is updates, strong passwords, two-factor authentication, a firewall and limited user accounts.
A vulnerability nobody has published. Scanners know about the holes in their database. A new one, or one in a custom theme written just for you, is invisible to them until it is used and leaves traces.
Stolen credentials. If someone logs in with your actual password, obtained from a phishing email or a reused password from another breach, nothing about it looks malicious to a scanner. They are just an admin, doing admin things. Two-factor authentication is the defence; scanning is not.
Problems at the hosting level. A compromised server, a neighbour on shared hosting being used to reach your account, a host's own breach. Outside the scanner's view.
Anything in third-party scripts. The chat widget, the analytics tag, the fonts loaded from another domain. If one of those is compromised at its source, it runs on your pages and your scanner sees nothing wrong with your files.
Subtle changes to content. A scanner detects a modified file. It cannot tell that a phone number on the contact page was changed to a scammer's, because that is data in the database, edited through the normal editor, and it looks like an edit.
Social engineering. Someone phoning your host pretending to be you. Someone emailing your developer asking for a login "on your behalf".
Why the green tick still matters
A daily scan means that when something does go wrong, you know within a day rather than within a month, when Google flags the site and customers have been redirected to a scam for weeks. Detection time is the difference between a two-hour clean-up and a reputation problem. That is real value, and it is why every care plan includes it.
It just is not the whole job.
What else security involves
On a care plan, the scan sits alongside:
- Updates, promptly and tested. Most WordPress hacks exploit a plugin vulnerability that had a fix available for weeks. Updating within days closes the window.
- Two-factor authentication on every admin account, and on the hosting and domain accounts.
- Fewer, stronger accounts. Removing the developer from 2019, the contractor who left, the generic "admin" user with a guessable password. Every account is a door.
- A firewall in front of the site, blocking known attack patterns, brute-force login attempts and traffic from known bad sources before they reach WordPress.
- Backups, tested, so that if the worst happens the site is restored from a clean copy rather than cleaned by hand.
- Login and change monitoring, so a new admin user or a changed file triggers an alert, not just a line in a report.
- A look at third parties, occasionally: what scripts run on the site, from where, and whether each is still needed.
Reading your report
When your monthly report says "scanned daily, no threats", read it as: "no evidence of compromise this month". Then look for the other lines: updates applied and when, whether two-factor is on, how many admin users exist, whether the backup was tested. If those lines are missing, the scan is the only thing being done, and the site is being watched rather than protected.
Both are part of our care plans. The scan is the easy part to automate and the easy part to show. The rest is what keeps the scan boring.