Protecting admin login pages: Crawl Audit check 166

Short answer: bots try passwords on well-known login addresses like /wp-admin/ all day. What stops them is two-factor login and limits on failed attempts, not a hidden address. Check 166 tests whether the default WordPress admin path answers on your site.

What Crawl Audit checks

• It runs only in the full audit, and only when the site owner has agreed to it. The free check shows that it runs in the full report.
• It requests /wp-admin/ and follows any redirects.
• Warning: the address loads (a 200 or 300-range response).
• Pass: it doesn't.

Every standard WordPress site will warn here, because /wp-admin/ redirects to the login page. Read the warning as "make sure this login is well protected", not "you've been breached". It only tests the WordPress path, not /admin or other platforms' logins.

What the sources say

• WordPress: "Security through obscurity is generally an unsound primary strategy." And: "Obscuring the login URL can reduce noise but should not be your only defense."
• WordPress: "Enable two‑factor authentication (2FA) for all administrator accounts". Core WordPress doesn't include it, so it needs a plugin or your identity provider.
• WordPress: "Rate‑limit login attempts at the edge (WAF/CDN) or the web server."
• OWASP: "Multi-factor authentication (MFA) is by far the best defense against the majority of password-related attacks, including brute-force attacks".

Protecting it

• Turn on two-factor login for every admin account.
• Limit failed attempts, at your host, CDN or with a plugin.
• Use unique, long passwords and remove admin accounts nobody uses.
• If only your team logs in, restrict the admin area to your office or VPN addresses.

On devmarde.com

We don't run WordPress. On 6 October, /wp-admin/ on our site ended in a 403 (refused), so it passes.

Sources

• WordPress, Hardening WordPress and Brute force attacks (updated 25 February 2026).
• OWASP, Authentication Cheat Sheet, checked 6 October 2026.