Bots request wp-login.php all day because it is WordPress's standard sign-in endpoint and an easy target to automate. They are usually searching for WordPress sites, testing stolen passwords, or trying common username-and-password combinations. These requests are common on public websites and do not prove that an attacker has logged in. However, repeated attempts can waste server resources and expose weak administrator accounts.
Table of Contents
What the requests mean
The wp-login.php file displays and processes the default WordPress login form. Because its location is predictable, automated scanners can try it across thousands of domains without first confirming that each site uses WordPress. Some bots only check whether the file exists. Others submit login attempts using credential stuffing, which means testing passwords exposed in breaches elsewhere.
Brute-force bots instead cycle through guessed usernames and passwords. A request returning HTTP status 200 usually means the server supplied a page. A 302 response may indicate a redirect, while 403 or 429 often means a security control blocked or limited the request. None of these codes alone confirms a successful login.
Is the site compromised?
Frequent requests are evidence of scanning, not evidence of compromise. The important question is whether the requests led to authenticated sessions, account changes, or modified files.
Check for stronger warning signs: Access logs may show repeated POST requests to wp-login.php, but a POST only means the bot submitted data. Review WordPress activity records, hosting logs, user accounts, and file changes before deciding that a login succeeded.
- Successful logins from unfamiliar locations or devices
- Unknown administrator accounts
- Unexpected plugin, theme, or WordPress core changes
- New scheduled tasks or unfamiliar PHP files
- Redirects, spam pages, or altered search results
How to reduce login attacks
Start by protecting accounts. Use a unique password for every privileged user, enable multi-factor authentication, remove unused accounts, and give administrator access only to people who need it.
Then reduce automated traffic before WordPress must process it: Allowlisting wp-login.php by IP address can work for a small team with stable network addresses. It is often unsuitable for remote teams, changing connections, customer accounts, or membership sites.
- Apply rate limits to repeated login requests
- Use a web application firewall or CDN challenge
- Block abusive addresses temporarily, not as the only defense
- Require additional authentication for administrative access when practical
- Keep WordPress core, themes, plugins, PHP, and server software supported and updated
What not to rely on
Renaming or hiding the login URL can reduce background noise, but it is not a substitute for strong authentication. Bots may discover the replacement through links, redirects, page source, plugin behavior, or other WordPress endpoints. Blocking one address at a time also has limited value.
Automated traffic often comes from rotating networks, compromised devices, and hosting providers, so a long manual blocklist becomes difficult to maintain. Do not delete wp-login.php or edit WordPress core files to stop requests. Those changes can break authentication and disappear during an update. If the site does not use WordPress, configure the web server or firewall to reject the path cheaply rather than sending every request through the application.
