WordPress Login Security Checker

1. Changing the Default /wp-login.php URL

Default WordPress login paths are targeted by automated brute-force botnets. As documented in WordPress Brute Force Attack Hardening, hiding `/wp-login.php` stops 99% of automated login scans.

2. Disabling XML-RPC via .htaccess

Block access to xmlrpc.php in your server .htaccess file to prevent multicall password guessing. Audit REST API settings in our WordPress REST API Tester.

3. Enforcing Two-Factor Authentication (2FA)

Scan for malware signals in our WordPress Malware Quick Scanner.

4. Immunizing Logins via Nimbica Static Edge

Nimbica pre-renders WordPress content into static HTML served from 300+ global edge locations. Since static edge nodes execute zero server PHP code, brute-force login attempts cannot overload origin server resources.

5. How the Passive Audit Works

The checker performs exactly two read-only HTTP requests against your domain — no credentials are ever submitted. First, it requests {your-domain}/wp-login.php and reads the response status: a 200 OK means the default login form is directly reachable and rendered as-is (exposed); any other status (a 404, or a redirect to a custom URL) is treated as hidden or relocated. Second, it requests {your-domain}/xmlrpc.php and treats both 200 and 405 Method Not Allowed as "exposed," since both confirm the XML-RPC endpoint file exists and WordPress core is actively processing requests to it.

Both requests are fired independently and the results rendered side by side. No login attempt, password guess, or authenticated request is ever made — this distinguishes the tool from an actual penetration test or credential-stuffing simulation, which this explicitly is not.

6. Worked Example: Two Audit Outcomes

Scenario A — a stock WordPress install with no security hardening: /wp-login.php returns 200 and /xmlrpc.php returns 200. Result: both flagged exposed. This is the default, unmodified state of virtually every fresh WordPress install and is the exact fingerprint automated brute-force botnets scan the internet for.

Scenario B — the same site after installing a login-URL-changer plugin and adding an .htaccess block on XML-RPC: /wp-login.php now returns 404 (hidden/custom path), and /xmlrpc.php returns 403 Forbidden (blocked, not just unreachable). Result: both flagged clean. Interpretation: Scenario B has meaningfully reduced its exposure surface to opportunistic automated attacks, though a targeted attacker with your custom login URL could still attempt requests against it.

7. Practical Use Cases

• Post-hardening verification: After installing a security plugin or changing your login URL, confirm the change actually took effect from an outside vantage point.
• Pre-purchase site audit: When buying an existing WordPress site or taking over client hosting, quickly check its baseline login exposure before you have admin access.
• Multi-site fleet spot-checks: Agencies managing dozens of client sites can quickly triage which ones still run default, unhardened login configurations.
• Client security reporting: Use the pass/fail badges as evidence in a monthly maintenance report showing hardening work was applied.

8. Limitations of a Passive Scan

• Two signals only: This audit checks exactly two endpoints. It does not check password strength, 2FA status, security header configuration (HSTS, CSP), user enumeration via ?author=1, or REST API exposure — use the Malware Quick Scanner and a dedicated REST API audit for those.
• Custom 404 pages can mask a live endpoint: A theme or plugin returning a styled "page not found" response with an unusual status code could be misread by any automated status-based check, including this one.
• Not a brute-force simulation: A clean result here says nothing about whether your actual admin password is weak, reused, or has been leaked in a prior breach.
• Point-in-time only: Results reflect the moment of the scan. A plugin update, theme change, or security setting rollback afterward will not be reflected until you re-scan.