Many bots attack websites by trying to find an admin login page (such as wp-login.php) and trying to login.

Would an effective way to stop these attacks be to create a fake (non-login) page for the targeted URLs?

Stack Overflow does this by redirecting to YouTube: stackoverflow.com/wp-login.php

  • "and trying to login" Am I misunderstanding things, or are you somehow worried that their attempts to login might succeed? Commented Apr 6, 2020 at 12:49
  • 1
    No, it is not a WP website.
    – Heng Ye
    Commented Apr 6, 2020 at 12:54
  • Just trying to stop the bots from continuing attacks on the site.
    – Heng Ye
    Commented Apr 6, 2020 at 12:54
  • 5
    Instead of returning a 404 for invalid pages, make your web server return an error code 500. This will significantly disrupt most scanners and create thousands of false positives.
    – john doe
    Commented Apr 6, 2020 at 21:08
  • 2
    Or return an error code "50"... not sending the last 0 and end of line. Let the bot time out; hackers aren't known for meticulous error handling.
    – MSalters
    Commented Apr 7, 2020 at 16:19

6 Answers 6


Using non-standard paths for your WordPress login and admin pages would stop automated brute-force attacks scanning for every example.com/wp-login.php, but the practice you describe is just messing around with the attackers and doesn't really do any good nor harm.

Best way to stop the bots is to use strong passwords and Fail2Ban.

A fake wp-login & wp-admin could be used as a honeypot for learning more about the ongoing attacks, though. I like to collect the attempted login credentials to know which leaks are currently popular. I also let the credentials "work" randomly to collect the malware they are trying to install. Of course it doesn't work, because it just looks and acts like WordPress without being one. However, by reverse engineering the malware I'm able to learn how it's trying to hide, which gives me an advantage when cleaning infected sites for customers.

  • With WordPress, you can change the url for logging in, eg mysite.com/let-me-in.php. Does that help much in preventing bot/brute force or is it pretty much security by obfuscation? (Assuming passwords are strong, etc)
    – BruceWayne
    Commented Apr 7, 2020 at 1:58
  • 4
    It doesn't help that much if you are targeted, but there are bots that are constantly scanning every domain for the standard WP login/admin pages and trying common usernames and passwords. Changing the URLs certainly helps against them, despite it's not a replacement for strong passwords. Commented Apr 7, 2020 at 3:55

It is not an effective way to stop bots. Bots will register that link as providing a response. They will not "give up" because the end result is not what they expected.

It would be more effective to have have a fake login page and block any IP that attempts to log in.

  • 2
    How would I block the IP if I have Cloudflare in place?
    – Heng Ye
    Commented Apr 5, 2020 at 19:44
  • 13
    @HengYe CloudFlare should add some headers to the requests containing the originating IP address. Commented Apr 5, 2020 at 23:55
  • 3
    The header is X-Forwarded-For, unless you have an enterprise plan
    – Jon
    Commented Apr 6, 2020 at 22:36

By adding fake login pages you would actually be turning your website into a honeypot, which would attract more bots and actually increase your server load. I don't know why StackExchange redirects to YouTube, maybe it's just for fun (it looks like they redirect you to random 10-hour videos, including a 10-hour trololol song). If you want to avoid attracting any attention, you should return HTTP 404 and at the same time maybe also ban the IP. Note that, as Esa Jokinen pointed out in his comment, you should be careful when you decide to ban IPs, to avoid possible issues that would lead to a denial of service.

  • 29
    Banning every IP address accessing the login page is not wise, as it can be abused easily: e.g. someone adding an <img src="http://example.com/wp-login.php"> will ban everyone accessing that page from your site. In @schroeder's answer only a POST request will trigger the ban. Commented Apr 6, 2020 at 4:14
  • 5
    @EsaJokinen It's not like you couldn't make POST requests via JavaScript either. A simple form, and an onload() click of submit.
    – user163495
    Commented Apr 6, 2020 at 9:09
  • 2
    The defaults for cross-site images and cross-site POST requests are a bit different. Of course there are several extra measures for preventing both, but we have to draw a line on how broad we will take this from the original question. I suppose my honeypot example is already a bit far from it. Commented Apr 6, 2020 at 10:29
  • @EsaJokinen, I hadn't thought of that, I just added a note to my answer. However, as MechMK1 said, you'd have the same problem with any other kind of request, unless you implement specific measures (like preventing CSRF for login requests, etc.)
    – reed
    Commented Apr 6, 2020 at 12:28
  • 2
    Regarding why StackOverflow.com/wp-login.php redirects to YouTube, see meta.stackoverflow.com/a/330161
    – browly
    Commented Apr 7, 2020 at 19:09

It obviously doesn't work for bots, but based on looking at logs I've found that bored script kiddies are effectively discouraged by redirecting the query to https://www.fbi.gov/investigate/cyber

For the bots, a lot depends on whether or not you have a good host or control over your own hosting environment. There are Apache ModSecurity rules that will block repeated login failures. You can couple this with ConfigServer's lfd daemon, which can be configured to scan the ModSecurity logs and put a longer term block in place for repeat offenders.


Create a fake admin login page that when you log in, redirects you to a fake admin dashboard that looks much like the real one and has the same-looking pages as the real, but make all of that fake admin user stuff do nothing real. This can confuse bots. Also remember on config change you must change the URL to have a parameter called action to be set to the (fake) action.


Is your website a WordPress website ? You said "no" in your comments.

So there is no threat of successful login to your "WordPress" login page !

The only threat I can see in your case, is the resources that these bots are consuming, which could be increased by a 200 OK response for your fake /wp-login.php , and the worst scenario is that these scanning bots continue to scan your domain till they find another vulnerability.

If your website is not a WordPress website, I think the best solution is what SO does by redirecting them to another server that can handle load like youtube.

Or if you want to be more aggressive, On my non WordPress website I block any IP for 24 hours that requests these pages like /wp-login.php, I know my small site well and I have no links to /wp-login.php, and I'm sure that whoever requests this page is a scanning bot, so I block them for a while.

  • A bot is not a user with a browser. It doesn't follow the link to YouTube and watch the whole 10h video. Even if it did, you'd be redirecting the abusive traffic to an unrelated 3rd party, so the reasoning behind sending them to a page that "can handle the load" would probably be illegal. Commented Apr 8, 2020 at 10:35
  • Also, replying 200 OK vs. 403 Forbidden or 404 Not Found consumes relatively same amount of resources, which is next to nothing. (403 might save you from an extra file system access, though.) It's just a short reply to a short request. It's not like the bots are flooding requests; e.g. in the last 24 hours my honeypot has got 248 POST request, which is approximately 10 attempts in an hour. Most certainly any web server can handle this background noise of the Internet. Commented Apr 8, 2020 at 10:44
  • " It doesn't follow the link to YouTube and watch the whole 10h video", most of bots will follow the redirecting at least for the maximum redirects they are configured to. And yes redirecting to a 3rd party is kind of evil, but this is YouTube :) it's nature of business is like being under a DDOS 24/7 Commented Apr 8, 2020 at 11:40
  • 1
    "Also, replying 200 OK vs. 403 Forbidden or 404 Not Found consumes relatively same amount of resources" 200 OK will make the bot thinks it's the WordPress loging which will make it go for the next step and try to login, but 404 or other error response could make the bot stop at this step, that is what I meant by a 200 OK will increase the traffic that this bot is doing Commented Apr 8, 2020 at 11:43
  • 1
    There's a spin-off question related to the consumed bandwidth and other resources. On my answer there I've been taken this a bit further by explaining how the bots are currently operating. From there you can see why the bandwidth won't be a problem. Commented Apr 8, 2020 at 11:48

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .