Snapshot vs Audit: Settings Check or Full File Scan?

mySites.guru checks your WordPress and Joomla sites in two different ways, the snapshot and the audit. Both produce a list of pass/fail checks, and every one of those checks is documented, but they gather their data differently and catch different problems.

The snapshot reads your site’s configuration, users and extensions in milliseconds. The audit reads every file in your webspace looking for threats. They run independently on their own schedules, and the useful question is which one found a given problem, because a clean result from one says nothing about the other. If you manage more than a handful of sites, the multi-site dashboard shows both side by side for every connected site.

How does the mySites.guru snapshot work?

The snapshot is the quick health check. It looks up database settings, reads specific configuration files, checks HTTP response headers and counts things like user accounts and installed plugins. None of it needs a scan of the file system, so it finishes in milliseconds.

There are over 100 individual checks on each platform, grouped into categories like:

• Platform configuration (debug mode, SSL, file editing, XML-RPC, auto-updates, and dozens more, including the WordPress debug constants that leak errors to visitors)
• User accounts (inactive users, unactivated accounts, hashed passwords, admin count, rogue Super Admins)
• Security headers (X-Frame-Options, Content-Security-Policy, HSTS, Referrer-Policy), covered in more detail here
• Extensions and plugins (installed versions, available updates, deactivated plugins still on disk, known vulnerabilities)
• Database integrity (table prefix, user permissions, pending migrations)
• Hosting environment (PHP version against the Joomla technical requirements, disabled functions, error reporting, session configuration)
• Search engine visibility (robots.txt reachability, blocked search and AI answer engines, sitemap declaration)
• Targeted hack detection (a short list of specific compromises that live in the database or the server, covered below)

Snapshots run automatically about twice a day on every connected site, and you can trigger one on demand. Many checks include a one-click toggle, so debug mode left on or user registration accidentally enabled is fixed from the dashboard without logging into the site. You can see what that looks like on the screenshots page.

What does a snapshot set in motion?

A snapshot is also the trigger for several things you would not file under “checking”. Each time one finishes, mySites.guru gathers the full list of extensions and themes, compares each against its update feed, and checks the versions against the vulnerability database. A match raises an alert, which is why a new advisory can reach you within hours of a rule being added rather than at your next manual look.

Automatic extension updates work the same way. They do not run on a clock of their own: when a snapshot sees an update for an extension you have enabled for auto-update, the update goes out. Starting an audit also triggers a snapshot, so the two sets of results are never far apart on the day an audit runs.

Events between snapshots, such as a new admin login or a changed template file, come from near-real-time alerting instead. The snapshot is the twice-daily sweep, and the alerts cover the gaps.

How does the mySites.guru audit work?

The audit reads every file and every line of code in your webspace: PHP, JavaScript, images, archives, hidden files, everything. It matches them against a library of roughly 1,500 regex patterns and a database of known-bad file hashes to identify:

• Malware and backdoors (suspect code patterns, obfuscated PHP, known malicious file hashes)
• Mass mailers (scripts built to send spam from your server)
• Modified core files (WordPress or Joomla core files that have been tampered with)
• Impostor files (files sitting in a folder the CMS owns that the release never shipped)
• Hidden files and folders (dot files tucked into directories you would never think to check)
• Dangerous permissions (files or folders set to 777)
• Suspicious file types (SQL dumps, renamed PHP files, upload scripts in unexpected places)

The audit also builds the file and folder listing that the investigation pages and the file manager’s audit view read from, so it does a second job beyond hack detection: a tool that needs to know what was on disk at the last scan is reading the audit’s output. The file-level checks and folder-level checks are documented one by one, and the guide to finding hacked files walks through reading the results.

How does an audit treat a shared host?

Because every file gets opened, an audit takes minutes where a snapshot takes milliseconds, and a large site takes longer. That is a real load on the server hosting the site, which is why the scheduler is built to go gently.

Only one audit runs at a time per server hostname and the rest queue behind it, so a host with fifty sites is never hit by fifty scans at once. The scan also slows itself down when a host struggles to keep up. A host that is fine at the first attempt runs at full speed, and one that keeps timing out gets a progressively slower scan until it completes. Scheduling is covered here, and you can start one manually whenever you need it.

That load falls on your hosting account, which is why the daily-versus-weekly question below matters.

How do they compare side by side?

Joomla and WordPress in numbers

The two platforms do not have the same number of checks, because they do not have the same things to check. Counting the check library in October 2026 gives this:

Joomla has more snapshot checks mostly because its configuration surface is larger, with around fifty configuration checks on their own. The audit counts sit much closer together, because a file scan looks much the same on either platform: a PHP file in the wrong place is a PHP file in the wrong place. If you run both, the Joomla and WordPress multi-site pages describe how each is managed day to day.

What each scan finds on a real site

The easiest way to hold the difference in your head is to ask where a problem physically lives. If it lives in the database or in a setting, the snapshot sees it. If it lives in a file on disk, only the audit does.

Two things follow from that table. A clean snapshot can still sit on a hacked site, because it cannot see a malicious file on disk. And the audit has company as a hack detector: the database-resident compromises that Joomla attackers favour are what the snapshot’s targeted checks look for. Those checks cover specific known compromises. A general scan of your database is still on the roadmap.

Four incidents, and the scan that caught each

Abstract tables only go so far, so here are four compromises we have written up, sorted by which scan is the one that sees them.

An attacker who creates their own Super Admin account is a snapshot finding. The rogue Super Admin check matches the account names and generated identities that known attacks use, and the walkthrough on finding rogue admin accounts shows what the result looks like on a live site.

A backdoor hidden in Joomla’s scheduler is also a snapshot finding. A scheduled-tasks row sits in the database and does nothing without a routine to run it, so the malicious scheduled task check reads the scheduler on every snapshot and judges each task by the routine it names. The same family includes locked scheduled tasks that stop legitimate jobs running.

Malware that survives its own deletion is the third. On Linux, deleting a file does not stop a process that is already running it, and the snapshot’s resident process check reports PHP processes whose code is no longer on disk. The post on malware you thought you deleted explains why reinfection within seconds of a cleanup points here.

The fourth is the one the audit exists for: a file that should not be there. Impostor files in core folders are PHP files sitting among a release’s files that the release never shipped, and only a scan that reads the folder against the release notices them.

Three of the four are snapshot findings. A daily audit would not have found any of the first three sooner, because the audit reads files and these problems are not in files.

Why a daily audit rarely earns its server load

We recently began writing to customers who had daily audits scheduled and asking them to switch most sites back to weekly or monthly. A hosting company that was about to connect around 700 sites asked whether it was an automated email, and then whether our servers could take that volume on a weekly or monthly schedule. They can, with room to spare. The reason for the email was the data: when we looked, about 99% of audits that run on a daily schedule were never opened by anyone.

Your server takes that load as much as ours does. Every audit reads every file on your host, and a scan whose results no one reads costs you that load for nothing.

The published audit data shows what turns up when the file scan does run across a wide spread of sites, and the customer reviews describe how people use the dashboard day to day.

How often should each one run?

Leave the snapshot alone. It runs about twice a day by default, it costs your server almost nothing, and it is what powers update alerts and vulnerability warnings.

For audits, weekly suits most sites and is the default for new ones. Monthly suits dormant sites that no one edits. Daily is worth choosing for a site you are actively watching, for example in the days after a cleanup, where you want to know quickly whether anything came back. Switch it back once the site has been quiet for a couple of weeks.

If you manage a lot of sites, the bulk scheduler changes the period on many at once. Combined with a weekly default, it spreads the file-level work over the week while the snapshot keeps the daily watch. If a site does get hacked, the recovery walkthrough covers what to do next, and the Joomla and WordPress hacked-site pages cover the first hour.

Start with a free audit and see where your sites stand, or look at the pricing if you are managing more than a handful.

Further reading

• WordPress hardening guide - the WordPress project’s own advice on securing an install
• WordPress security documentation - the wider security section of the WordPress developer handbook
• Joomla security documentation - the Joomla project’s security section in the official manual
• MDN guide to Content Security Policy - how CSP works, one of the headers the snapshot reads
• OWASP Web Security Testing Guide - the standard reference on how web application security testing is structured

Snapshots and audits are both covered in our complete security guide.