Scanner
When to scan, which scan type to use, how to read findings, and what schedule makes sense for your site. The Scanner covers more than malware.
What the scanner checks
Go to SiteFort → Scanner.
"Malware scanner" undersells what's actually happening here. Malware is one finding type among several, not the whole job. A full scan also covers:
- Malware indicators and known malicious file signatures
- Unauthorized file changes against a known-good baseline
- Sensitive data exposure: credentials, keys, or config data accessible publicly
- Account and permission issues: unexpected administrators, weak user state
- Database concerns: suspicious options, injected content
- Reputation: whether the site or its IP appears on blocklists
- Known vulnerabilities in plugins, themes, and WordPress core
That range matters once you're actually staring at a findings list. A flagged file sitting in uploads and a flagged option in the database aren't the same kind of problem and don't call for the same response, so it's worth knowing which category you're looking at before deciding what to do about it.
Standard vs Deep Scan
Standard Scan is what runs day to day, and it's enough for the vast majority of scans you'll ever need. Deep Scan exists for the moments when something's actually telling you to look harder, not as an "always better" upgrade you should just leave on by default. It takes longer and costs more in scan credits precisely because it's checking more, so save it for when that depth is actually warranted.
| Situation | Use this scan |
|---|---|
| First scan after installing SiteFort | Standard |
| Routine weekly or daily monitoring | Standard |
| After installing or updating plugins and themes | Standard |
| Suspicious redirects, SEO spam, or unknown admin users | Deep |
| Hosting provider flagged the site for malware | Deep |
| After cleaning up a compromised site | Deep, then Standard for follow-up |
| Pre-launch security check | Deep |
| Standard scan findings suggest something deeper is wrong | Deep |
Scan schedule
Go to SiteFort → Scanner → Scanner Configuration → Scan Frequency.
An unscheduled scanner only tells you about a problem when you happen to remember to run one, which in practice means you find out about a compromise whenever you get around to checking, not when it actually started. A schedule closes that gap. Set the frequency based on how often the site actually changes and how fast you'd genuinely want to know if something went wrong.
| Site type | Recommended schedule |
|---|---|
| Small business or brochure site | Weekly |
| Low-change static site | Weekly or monthly |
| WooCommerce store | Daily or weekly depending on order volume |
| Membership or LMS site | Daily or weekly |
| Recently cleaned compromised site | Daily for the first two to four weeks |
| Agency-managed client site | Match to the client's maintenance plan and risk level |
Manual Only exists as an option, but it's a poor fit for any production site nobody is actively watching. If scanning depends on someone remembering to click a button, problems sit undetected right up until they turn into incidents instead of findings.
Scan notifications
A schedule you never hear from is barely better than no schedule at all. Make sure scan findings and scan failed alerts actually reach whoever's in a position to do something about them, not just whoever set the plugin up originally. See the Security Notifications guide for recommended alert settings.
Handling findings
Open the Findings panel after a scan. Work through Critical and High findings first, every time, before you even look at Medium and Low. It's tempting to clear the easy ones first for a sense of progress, but that's exactly backwards when something Critical is sitting further down the list.
Check severity, file path, and whether a diff is available. Use View file or View diff before you decide anything.
Use Repair when SiteFort can restore a known-good version. Reach for Delete only when the file is clearly malicious or serves no legitimate purpose at all.
Reserve Ignore for confirmed false positives, not findings you're not sure about. Ignored items stay visible under the Ignored filter, so nothing actually disappears, it can be reviewed or reversed later.
Run another scan after any repair, deletion, or update. Don't consider the incident closed until the Dashboard actually shows no unresolved findings left.
Findings that keep coming back
A finding that reappears after cleanup means the source is still active somewhere, not that the cleanup failed to take. Check whether a compromised plugin, theme, scheduled task, or an external deployment pipeline is quietly regenerating the file every time it's removed. Look at the Audit Log and your hosting file modification logs around the time it comes back, that timing usually points straight at the cause. Run a Deep Scan, and if there's any chance an account was involved, rotate administrator passwords rather than assuming the file itself was the whole story.
Severity as a triage guide
| Severity | When to act |
|---|---|
| Critical | Immediately. Don't wait for a maintenance window, this isn't the kind of finding that gets better with time. |
| High | Same day. Worth checking firewall and audit logs for anything else suspicious happening around the same time. |
| Medium | Next maintenance window. |
| Low | During normal updates. Low severity isn't the same as no severity, don't let these pile up indefinitely. |
Scanner configuration
Go to SiteFort → Scanner → Scanner Configuration.
| Setting | Recommended | Watch out for |
|---|---|---|
| Excluded Paths | Exclude cache and build folders only | Don't use exclusions to make an inconvenient finding disappear. An exclusion doesn't fix a problem, it just stops you from being told about it. Only exclude a path you're genuinely certain never needs security review. |
| Quarantine Retention | Long enough for rollback and client review | Shorter retention saves a bit of storage, but it also removes your safety net the moment a repair turns out to have been the wrong call. |
| Scan Intensity | Standard for daily runs, Deep for post-incident | Deep scans take longer and cost more scan credits for a reason. Reserve them for situations a Standard scan genuinely can't resolve on its own. |
| Notifications | Send to whoever acts on findings | An alert sent to an inbox nobody actually checks is functionally identical to no alert at all. See the Security Notifications guide. |