Securing wp-admin with Directory Protection – When It Works

The WordPress login is the most attacked piece of your website: bots try passwords around the clock, on busy days by the second. Directory protection puts a second door in front of it – at server level, before WordPress even loads. It is one of the most effective walls there is. And one that, set up wrongly, can cripple a shop.

This article shows both: the variant that almost always works, and the cases where the protection breaks. The fundamentals – how .htaccess and .htpasswd play together – are covered in the general directory protection article; this one is about the WordPress special case.

Why the second door is so effective

The usual login protection – attempt limits, two-factor – works inside WordPress: every bot attempt starts PHP, loads WordPress, queries the database. Directory protection works before WordPress: the server demands a username and password before it even executes wp-login.php.

That has two effects. First, security: even an unknown vulnerability in the login process is unreachable while the server door is shut. Second, load: thousands of bot attempts per day no longer cost PHP processes or database queries – a noticeable difference on weaker hosting.

The crucial misconception: wp-login.php is not inside wp-admin

Hearing “protect wp-admin”, most people naturally protect the /wp-admin/ folder. Two problems:

1. The login file lives elsewhere. wp-login.php sits in the WordPress root directory, not in the folder. Folder protection leaves the actual attack surface open.
2. The folder contains admin-ajax.php. Despite its name, that file also serves the frontend: countless plugins call it for regular visitors – cart updates, product filters, forms, live searches. Put a server password in front of it, and visitors get errors that look like plugin bugs and are nearly impossible to trace as such.

Hence the rule: protect the file, not the folder.

The recommended variant: protect only wp-login.php

The <Files> rule places the server password exactly in front of the login file – admin-ajax.php and everything else stays untouched. The generator on this page starts in the right mode:

The generated .htaccess rule belongs in the existing .htaccess in the WordPress root – added at the top, without touching the WordPress block (# BEGIN WordPress …). Save the .htpasswd at the path from AuthUserFile, ideally outside the web root. Step-by-step instructions including path discovery: in the fundamentals article.

Two practical notes:

• One shared server password is enough. It is the door before the door – the actual sign-in remains the WordPress login with personal accounts. The server password may therefore be shared within the team.
• Locked out? Remove the rule from the .htaccess (via FTP or the hosting file manager) and everything is as before. The protection is fully reversible – if more than that is stuck.

When it doesn’t work (that easily)

WooCommerce and other shops. The file variant works here too – the customer account runs via /my-account/ on the frontend and normally never touches wp-login.php. But: some setups actively send customers through wp-login.php (redirect plugins, custom login flows, some membership plugins). Then the server password would suddenly stand in front of paying customers. Check first: where do customers land when they click “log in”?

Folder protection only with an exception. If you still want to protect the whole /wp-admin/ folder (legitimate for plain company sites without frontend Ajax), you need the exception for admin-ajax.php – a separate .htaccess inside the wp-admin folder:

AuthType Basic
AuthName "Restricted area"
AuthUserFile /path/to/your/webspace/.htpasswd
Require valid-user

<Files "admin-ajax.php">
  Require all granted
</Files>

And even then: after setting it up, click through the frontend thoroughly – forms, filters, search. If something breaks, a plugin is loading more from wp-admin than just Ajax.

Sites with many logged-in user groups. On sites where editors, members, or course participants log in through wp-login.php daily, the shared server password quickly becomes friction. Here the classic login protection with 2FA and attempt limits is the better primary route.

nginx hosting. Without .htaccess support, the route leads through the host’s server configuration – details in the fundamentals article.

What this protection does not replace

The second door is a layer, not a whole concept: strong passwords and two-factor in the WordPress login remain mandatory – the server password is shared and doesn’t protect against a compromised editor account. And it doesn’t help at all against attacks through vulnerable plugins; that is what updates and virtual patching are for. How the layers work together is covered in the security overview.

An honest conclusion

For the typical company site with a handful of editors, protecting wp-login.php via a <Files> rule is one of the best security moves available: ten minutes of effort, bot attacks bounce off the server, fully reversible. Shops with customer logins and frontend Ajax need the careful look first – and anyone protecting the whole folder without thinking of admin-ajax.php will later debug plugin errors that aren’t any.

Rather have your WordPress site secured than edit .htaccess yourself? Login hardening is part of our WordPress maintenance – along with updates, tested backups, and virtual patching. Drop us a line.