Website Security Check

Monthly for a small brochure site, weekly for anything transactional, and immediately after a platform migration, plugin change or agency handover — those transitions are when configuration regressions appear.

• Owners who suspect a compromise but have no idea where to start looking.
• Small teams without a security function who need a prioritised list rather than a raw scan dump.
• Agencies performing due diligence on a site they are taking over.
• Anyone re-verifying a site a week after a cleanup, when reinfection typically shows up.

Each individual signal has a blind spot. Header checks say nothing about injected content. A spam check says nothing about transport security. A redirect trace from one device misses conditional payloads. Combining search-side, content-side, redirect and header evidence is what turns a set of isolated observations into a defensible answer about whether a site is compromised.

• Search-side signals show what Google sees, which is often ahead of what the owner sees.
• Content signals reveal injected markup, hidden anchors and language mismatches.
• Redirect signals expose conditional behaviour that only affects some visitors.
• Header signals measure how much damage a future injection could do.

• It has no filesystem or database access, so it cannot enumerate backdoors, modified core files or rogue accounts.
• It cannot see anything behind a login, a WAF challenge or an IP allowlist.
• It cannot date the compromise; server access logs are the only reliable source for that.
• It is not a vulnerability scanner and does not attempt exploitation of any kind.
• It cannot replace incident response on a site handling payments or personal data — treat those cases as reportable incidents from the outset.

1. STEP 01

   Separate compromise findings from hardening findings

   Injected content, unexpected redirects and crawler-only output are incidents. Missing headers and weak policies are hardening work.

2. STEP 02

   Handle the incident first

   Preserve evidence, remove persistence, clean content, rotate credentials, then verify — in that order.

3. STEP 03

   Close the entry point

   Patch the platform and every extension, remove unused plugins and themes, and enforce MFA on administrative accounts.

4. STEP 04

   Then apply the hardening list

   Headers, least-privilege CMS roles, backup verification and monitoring, so the next attempt has a smaller blast radius.

5. STEP 05

   Schedule re-checks

   Re-run at 24 hours, one week and one month. Reinfection almost always happens inside that window if persistence was missed.