Running WordPress on a shared application fleet.

WordPress is one of the most common things people deploy, and one of the easiest to get wrong at the infrastructure layer. The application is mature. The operational assumptions around it are not always obvious.

A normal visit to a WordPress site touches more than the page. The browser loads theme and plugin assets from /wp-content/, core assets from /wp-includes/, and often makes a REST request to /wp-json/. Logging in uses /wp-login.php and the dashboard lives under /wp-admin/. Gutenberg batches editor requests through /wp-json/batch/v1. Cron may run through /wp-cron.php.

None of that is malicious. A path-only blocklist that bans /wp- will take the site down for its own editor before it stops a determined scanner.

What actually needs protecting

The high-value targets are authentication and plugin surfaces, not the existence of WordPress itself. The useful controls are narrower:

• Login rate limiting. Limit attempts per real client IP, with a short lockout and a clear response. Do not ban the login path.
• XML-RPC. Disable it unless a plugin, mobile app or integration needs it. If it is needed, rate-limit it rather than blocking the file outright.
• Cron. On a busy site, run wp-cron from a system cron instead of relying on request-triggered cron.
• Plugin hygiene. Remove abandoned plugins, keep themes and plugins updated, and delete unused admin accounts.
• Backups. A database dump is not a backup until you have restored it somewhere.

What a scanner actually looks like

A scanner asks for files that do not exist: /wp-config.old, /wp-config.php~, backup archives, a known vulnerable plugin path, or an environment file. Those requests are high-confidence signals. They are also different from a logged-in editor requesting /wp-json/batch/v1.

# high-confidence probes
/wp-config.old
/wp-content/plugins/hellopress/wp_filemanager.php
/.env
/.git/config

# normal WordPress traffic
/wp-json/batch/v1
/wp-admin/admin-ajax.php
/wp-content/themes/site/style.css
/wp-login.php

The first group can be blocked aggressively. The second group is the application working as designed.

Updates are a shared responsibility

We run the container, the database, the proxy and the certificate. The site owner runs WordPress. That includes core updates, plugin updates, theme updates and the decision about which plugins are worth the risk. A managed platform should not silently push a major version into a live store.

A short launch checklist

1. Turn off XML-RPC unless it is required.
2. Move wp-cron to a real cron schedule.
3. Set a strong admin password and two-factor authentication.
4. Delete unused plugins, themes and admin users.
5. Confirm that /wp-json/batch/v1, /wp-admin/admin-ajax.php and a normal login all work.
6. Run a backup and restore it into a copy before launch.

WordPress is not fragile. It is just explicit about what it needs. Once the platform respects those needs, the rest is ordinary application security.