Right now, automated tools are scanning the internet for WordPress login pages. They find wp-login.php, and they start testing passwords — thousands per minute, around the clock, from botnets spread across hundreds of countries. This is not a hypothetical. It is happening to your site today.
The WordPress login page is the single most targeted file on the entire internet. It is publicly accessible by default, universally known, and — on most sites — completely unprotected beyond a username and password. That combination makes it the first thing any attacker probes.
The good news: hardening your login page is not complicated. It requires no advanced technical skill. This guide covers seven concrete steps you can implement today, with the exact code and configuration needed for each one.
1. Change the Default Login URL
Every WordPress site on the planet responds to /wp-login.php and /wp-admin/ by default. Attackers know this. Their automated tools don’t need to search for your login page — they already know where it is.
Renaming the login URL is one of the fastest wins in WordPress security. It doesn’t stop a determined attacker who can fingerprint WordPress, but it eliminates the entire category of automated bots that rely on the default path. In practice, it eliminates the vast majority of brute-force traffic overnight.
You can implement this by adding rewrite rules to your .htaccess file or using a dedicated plugin. The key principle: redirect /wp-login.php to a 404 for everyone except requests coming through your new custom path. Do not just move the URL — make the old one return nothing useful.
What to avoid: Do not use obvious slugs like /admin-login or /wp-signin. Choose something unguessable that you will not forget.
2. Enforce Strong Passwords and Two-Factor Authentication
Brute-force attacks work by testing passwords. The longer and more random your password, the longer it takes to crack. A 20-character random password is mathematically immune to brute-force attacks with current computing power.
WordPress has a built-in password strength indicator, but it does not enforce strong passwords. Beyond password length, two-factor authentication (2FA) is essential for all administrator and editor accounts. Even if a password is leaked in a data breach (credential stuffing), 2FA stops the login cold.
Implement 2FA via an authenticator app (Google Authenticator, Authy, or any TOTP-compatible app). Do not use SMS-based 2FA for high-security accounts — SIM-swapping attacks make it unreliable.
3. Limit Login Attempts
WordPress allows unlimited login attempts by default. A bot can submit 10,000 password guesses per hour without any friction. Login attempt limiting works by temporarily locking an IP address after a threshold of failed attempts — typically 5 to 10 failures.
Important: A plugin-level login limiter still lets requests reach WordPress before blocking them. A WAF-level limiter — one that operates before the request reaches PHP — is significantly more effective. It stops the load on your server entirely.
4. Add CAPTCHA or Honeypot Fields
Bots submit login forms at machine speed without triggering any interaction events. CAPTCHA and honeypot fields exploit this distinction: humans interact with forms in ways bots don’t.
Honeypot approach (invisible to humans, visible to bots): Add a hidden field to the login form that legitimate users will never fill in. If it’s submitted with a value, the request is a bot. Honeypot fields are zero-friction for real users and highly effective against simple bots. For sophisticated bots, combine honeypots with CAPTCHA for layered protection.
5. Use HTTP Authentication as a Second Layer
HTTP Basic Authentication adds a browser-native username and password prompt that appears before the WordPress login form is even displayed. It operates at the web server level — entirely outside of WordPress.
Note for WooCommerce and membership sites: HTTP Basic Auth on the login page will affect all login flows, including customer accounts. Test thoroughly before deploying.
6. Monitor Failed Login Attempts
Hardening is not a one-time event. Without monitoring, you have no visibility into what’s being attempted or whether your protections are holding. Log every failed login attempt with the timestamp, IP address, and username attempted.
Beyond passive logging, set up real-time alerts for threshold events: more than 20 failed logins in an hour from a single IP, or any login attempt using the username admin (which should not exist as an active account on any hardened site).
How SwissWPSuite Handles Login Security
The Security & Firewall module in SwissWPSuite automates the full login hardening stack at the WAF level — before requests reach WordPress, before they consume PHP execution time.
- Brute-force protection: IP-based and distributed rate limiting with progressive lockouts at the WAF layer.
- Credential stuffing defense: AI-powered traffic analysis detects credential stuffing patterns and blocks the source.
- Login hardening: Custom login URL, honeypot fields, and XMLRPC disabling in one step.
- 2FA enforcement: Role-based two-factor authentication for administrators and editors.
- Real-time alerts: Immediate notification on threshold events.
Frequently Asked Questions
How many times per day is a WordPress login page attacked?
Studies of WordPress honeypots show an average of 90,000+ login attempts per month on a newly-created site — roughly 3,000 per day. The attacks are fully automated and never stop.
Is renaming wp-login.php enough?
No. It eliminates the simplest automated attacks, but a determined attacker can fingerprint WordPress. You need multiple protections: custom URL, login limiting, 2FA, and WAF-level traffic analysis.
Does SwissWPSuite replace the need for all these manual configurations?
Yes. The Security & Firewall module implements brute-force protection, login hardening, 2FA, honeypot fields, and real-time monitoring from a single dashboard — all at the WAF level.
Your WordPress login page is being attacked right now. Implement the steps above — or let SwissWPSuite handle the full stack automatically.