Originally published on kuryzhev.cloud
A client site starts sending spam, the host emails a warning, and someone installs Wordfence, clicks "Start New Scan", and finds forty warnings nobody can triage. Most of them are noise, and one might matter. That is the moment Wordfence scan settings stop being a checkbox exercise and become a real decision: how much of your security do you want to delegate to a scanner inside WordPress, and how much to the server and edge around it?
This comparison treats the two approaches as classes. Option A is a tuned in-application scanner and firewall. Option B is hardening at the server, configuration, and edge layers. They overlap less than people assume.
When Wordfence scan settings matter
The choice matters most when you cannot fully control the environment. Shared hosting, agency-managed sites with many plugins, and sites edited by several people all fit. In those setups you often cannot change the web server config, so the plugin is the only place to put controls.
It also matters when scan behavior hurts you. A high-sensitivity scan on a small shared plan can hit PHP execution time limits, trigger host throttling, or flood you with false positives from premium themes that are not in the WordPress.org repository. A typical failure is that the scan times out half done, the admin sees a vague error, and the site goes unscanned for weeks.
Finally, it matters after an incident. Scanners tell you what changed. Hardening tells you whether the attacker could have changed it at all. Those are different questions, and the answers drive different budgets.
Watch out for treating a green scan as proof of safety. A scan compares files and signatures it knows about. It does not prove that a stolen admin password, a leaked API key, or a vulnerable plugin has not been abused.
Option A: Tuned Wordfence scans and firewall inside WordPress
Wordfence offers scan-type presets (Limited, Standard, High Sensitivity, Custom) plus individual toggles. Exact labels and defaults change between releases, so verify with the official Wordfence documentation before copying any setting from a blog post, including this one.
The options that usually deserve attention:
- Core, plugin, and theme file comparison: checks files against the WordPress.org repository copies. It is the highest-value check and cheap to run.
- Vulnerability and abandoned-plugin checks: flags known issues and plugins that have not been updated in a long time. Treat these as a to-do list, not noise.
-
Publicly accessible config, backup, and log files: catches forgotten
.sqldumps anddebug.logfiles. - Scanning outside the WordPress install: useful on hosts where several sites share a parent directory, but slower and noisier.
- Low-resource scanning: stretches the scan over a longer time to reduce load. Useful on constrained hosting.
- Exclusion patterns: suppress known-good paths such as cache directories. Keep these narrow.
Pros: works wherever WordPress runs, gives a readable file-level diff, alerts by email, and bundles a web application firewall and login protection. Extended firewall protection through auto_prepend_file runs before WordPress loads, which is stronger than plugin-level filtering.
Cons: it runs inside the thing it protects. If an attacker has code execution, they may tamper with the plugin or its data. Scans consume PHP resources, and the free tier receives firewall rules and malware signatures on a delay compared with paid tiers (check current terms on the vendor site). Tuning false positives is ongoing work.
Option B: Hardening at the server, config, and edge
This approach assumes something will eventually be vulnerable and limits what that vulnerability can do. The WordPress project documents the baseline in its hardening guide. The controls are mostly configuration, not software.
A starting point in wp-config.php:
<?php
// Disable the theme/plugin code editor in wp-admin
define( 'DISALLOW_FILE_EDIT', true );
// Force HTTPS for the login and admin screens
define( 'FORCE_SSL_ADMIN', true );
// Keep debug output off public pages and out of the browser
define( 'WP_DEBUG', false );
// Stricter: blocks ALL plugin/theme installs AND updates from wp-admin.
// Only enable if updates are handled by CI, WP-CLI, or your host.
// define( 'DISALLOW_FILE_MODS', true );
Next, add a server-level rule that stops uploaded PHP from executing, a common post-exploit foothold. The example uses nginx; adapt it for Apache or your host panel. nginx checks regex locations in the order they appear and uses the first match. Place these blocks above your generic PHP handler, or requests will still reach PHP-FPM.
# Inside the server { } block for the site.
# Put these BEFORE any generic "location ~ \.php$ { ... }" block:
# nginx uses the first regex location that matches.
location ~* ^/wp-content/uploads/.*\.php$ {
deny all; # uploads should hold media, never executable code
}
location = /xmlrpc.php {
deny all; # only if no client (e.g. Jetpack, mobile apps) needs it
}
location ~* /(wp-config\.php|readme\.html|license\.txt)$ {
deny all; # no reason to serve these publicly
}
Add independent verification with WP-CLI, which compares against official checksums without relying on the plugin:
wp core verify-checksums # core files vs wordpress.org
wp plugin verify-checksums --all # only works for plugins hosted on wordpress.org
Pros: works even when the application is compromised, costs little in runtime, and removes whole attack classes. Edge WAF and rate limiting (for example through a CDN) block traffic before PHP is involved.
Cons: requires server access or a cooperative host, is easy to misconfigure, and produces no friendly report. Watch out for DISALLOW_FILE_MODS: it also disables updates from the dashboard, so sites that relied on that path quietly stop patching.
Decision matrix
Match the approach to your constraints, not to which tool feels more serious.
| Situation | Favor | Reason |
|---|---|---|
| Shared hosting, no server config access | A | Plugin is the only control point; use low-resource scans |
| VPS or container you control | B first, then A | Config rules are cheap and survive app compromise |
| Many third-party and premium plugins | A | Vulnerability and abandoned-plugin checks surface risk early |
| Site rarely changes (brochure site) | B | Immutable files and no-exec uploads fit static behavior |
| Multiple editors, frequent changes | A | File-change detection and login protection earn their keep |
| Compliance needs evidence | Both | Scan reports plus documented config baseline |
| Very small server (low RAM) | B, light A | Heavy scans may cause timeouts or throttling |
A quick decision block you can paste into a runbook:
1. Can I edit server config or use an edge WAF? yes -> do Option B baseline
2. Is the host resource-limited? yes -> enable low-resource scanning
3. Are there plugins outside wordpress.org? yes -> expect false positives, add narrow exclusions
4. Who receives alerts? nobody -> fix this before tuning anything
5. Who patches, and how fast? undefined -> define it; it beats any setting
Evidence-based recommendation
The documented behavior of both approaches points to a layered answer, with an order of priority:
- Hardening reduces the number of ways in and limits the damage afterward.
- Scanning shortens the time to detection.
- Timely updates are not replaced by either. Public vulnerability databases attribute the large majority of disclosed WordPress vulnerabilities to plugins and themes rather than core, so patching those promptly remains one of the most important controls.
If you control the server, apply the Option B baseline first:
- no PHP execution in uploads
- file editor disabled
- HTTPS-only admin
- unused endpoints blocked
- least-privilege file permissions
Then add Wordfence with a Standard-level scan, core/plugin/theme comparison enabled, and email alerts routed to a monitored address. Consider High Sensitivity only after you have confirmed the server can finish a scan within its time limit.
If you are on shared hosting, invest more in Option A:
- Enable low-resource scanning.
- Turn on the firewall's extended protection if the host allows
auto_prepend_file. - Enforce two-factor authentication for administrators.
- Remove unused plugins.
Avoid exclusions that cover whole directories. A broad exclusion creates a blind spot where malware can sit undetected.
Watch out for two common mistakes. First, enabling every scan option and then ignoring the results because they are overwhelming. Second, running a security plugin on a site with no backups, since a clean scan does not help if you cannot restore. Keep offsite backups and test a restore.
For more infrastructure and security comparisons, browse kuryzhev.cloud. Whichever mix you choose, re-check it after major Wordfence or WordPress releases, because option names, defaults, and tier limits are version-dependent.
Further reading: official documentation
Top comments (0)