The Security Audit
Every site we manage is checked every day against a record of what it looked like when it was known to be clean. Not a malware scanner guessing at signatures — a diff. If your site stops matching itself, we know that morning, and you hear it from us rather than from a customer.
Why a diff instead of a scanner
Malware you have never seen before is invisible to a scanner that looks for malware it has seen before. So we do not primarily look for bad things. We write down what your site is when it is healthy — every external script domain, every plugin and version, every administrator, what each key page returns — and then compare against that record every day. A script pointing at a domain that was not there yesterday is worth a phone call whether or not anyone recognises it.
What gets checked
Every external script, iframe and link domain on your key pages, diffed against a recorded known-good baseline. A domain that was not there yesterday is an alert — whether or not we recognise the payload.
Known link-spam domains, casino and pharma keyword blocks, and hidden-link patterns in the rendered HTML. This is the check that catches injections that are invisible on the page but perfectly visible to Google.
Any new account, or any existing account whose role escalated. A compromise is far more often a quiet extra administrator than dramatic defacement.
New or removed plugins, status flips, version downgrades, and versions that are not real published releases. A version that does not exist upstream is a tampered file.
Every critical page still answers 200 — the homepage, the money pages, the forms.
What Googlebot is served, compared against what a human is served. These can differ, and when they do it is never an accident.
An unreadable endpoint and a site with nothing on it produce the same empty answer. Every check has a third state for ‘could not determine’, so a blind spot reports as a blind spot instead of quietly passing as clean.
What we do when something fires
We diagnose completely before anyone touches anything. Writing to a compromised site destroys the evidence of how it was compromised, and usually does not reach the mechanism doing the damage anyway. So the audit is strictly read-only: it finds, it proves, it packages the fix, and a human with host access applies it. You get the forensics, the remediation steps, and a plain statement of how it got in — because a cleanup that cannot explain the entry vector is a cleanup that runs again next month.
What the incidents taught us
A hidden plugin is not in the plugin list — by design
One backdoor we removed shipped as a plausible-sounding optimisation plugin and filtered itself out of the plugin list, stripped its own action links, and removed itself from update checks. A clean plugin audit meant nothing. It was found by requesting its file path directly and comparing the result against a control path that should not exist. Probe for the thing; do not ask the list.
Payload and repair are two halves
The same compromise carried a dropper in one directory and a hidden fake plugin in another. Remove one and declare victory, and the backdoor rebuilds itself within days. We do not close an incident until we can explain how it would have re-infected.
Cloaking is invisible from a browser
We have found sites answering an error to every human visitor while answering a fully-rendered spam storefront to search engines, complete with a fake sitemap of more than 1,700 URLs regenerated on every request. Clicking around the site would never reveal it. Only comparing the two renders does.
Not every scare is an incident — and saying so is the job
A report came in that a site was serving malware, based on an unusual CAPTCHA screen. Sixteen independent checks came back clean; it was a bot-challenge interstitial from the CDN. The honest answer was no active malware. An audit that can only ever conclude ‘compromised’ is not an audit, it is a sales tool.
An alert that fires every morning is an alert nobody reads
Our own monitor once alerted daily on a paid plugin, because ‘this plugin is not listed upstream’ and ‘the upstream registry did not answer’ printed the same line. Those are opposite facts. Separating them is what turned the alert stream back into something worth reading.
Proving the monitor can actually fail
A check that cannot fail is not a check. Before we trust a clean result on any property, we plant changes against an in-memory copy of the baseline and confirm each one is caught: a rogue administrator, a removed plugin, a tampered version number. Only then does “clean” mean anything. The first time we ran that exercise it immediately exposed a defect in the monitor itself — in a code path that only executes during an upstream outage, which is precisely when the monitor matters most.
Included with every site we run
The security audit is not an upsell. It runs on every property in the network, every day, at no separate charge — because the alternative is finding out from a customer.
Install the audit skills yourself → · The SEO audit that runs alongside it → · How the whole system fits together →