File integrity: what is checked, and what a finding means

Something changed a file on your site. It might have been you, it might have been your host's hardening script, it might have been a plugin writing its own cache — and it might have been none of those. The file scan does not try to tell you which; it tells you what changed and when it first appeared, so you can answer that question yourself instead of finding out from a customer.

When it runs

Scanning is part of every paid plan: weekly on Pro and Agency, monthly on Starter. There is a Scan now button on the site's File integrity tab as well. The work happens on the site, in small time-budgeted steps, so it finishes even on shared hosting that will not let a request run for long; only the differences come back to the panel. Your file list never leaves your server.

What gets compared, and against what

• WordPress core — against the file list wordpress.org publishes for exactly the version you are running. wp-config.php is never read and never reported.
• Plugins from wordpress.org — against the checksum list wordpress.org publishes for that plugin and version. readme.txt is left out: wordpress.org rewrites it when it builds the download, so it never matches even on an untouched plugin.
• Themes, premium plugins, mu-plugins and drop-ins — there is no official list for these anywhere, so the first scan records what is there and later scans report what moved.
• wp-content/uploads — nothing is compared here. Uploads is a folder for data, so the scan only looks for files that could be executed in it.

What a finding says

• Changed / missing / extra — the official list for this component does not agree with what is on disk.
• Baseline changed / added — there is no official list, and this file is not what it was the last time we looked.
• Executable file in uploads — a .php file inside the uploads folder.
• Does not match the published package — most of a component's files disagree at once. That is usually an install whose declared version is not the package on disk (a half-finished update, or a Pro build sharing a slug), not a hundred separate edits, so it is reported as one line.

A component we could not verify is listed separately and in a neutral colour. “We could not check this” is not “this does not match”, and every site has at least one custom theme or paid plugin — if they shared a colour, that colour would be on every screen.

Acknowledging a file

When you recognise a file, mark it as known. It stays on the list — so you can always see what you accepted, and so nothing can hide behind a decision you made once and never see again — but it stops producing alerts and stops costing Site Health points.

Nothing is deleted or quarantined for you. If you do decide to put a file back, the site's last backup is one button away on the Backups tab.

What lands in your inbox, and in the score

New findings are summarised once a day, per account, in one email: a line per site with the totals and how many of them need a look. File paths stay in the panel; the email's job is to say “go and look”. A finding that you already acknowledged never produces an email, and the same finding does not email you again next week.

The result is also the fifth part of the site's Site Health score, worth 12 points. Findings that need a look weigh more than the rest. A site that has never been scanned is not scored zero — the component drops out of that site's score entirely, and the panel says there is no data.