Get Started
Guides May 4, 2026 6 min read

How to Secure Your WordPress wp-admin Directory with .htaccess

Your WordPress admin area at /wp-admin/ is the most attacked URL on your site. Attackers scan for wp-login.php and /wp-admin/ constantly, running credential stuffing attacks, brute force attempts, and vulnerability probes. The default WordPress setup leaves this critical entry point wide open to anyone on the internet. A quick scan with any WordPress security tool will show you dozens of automated requests hitting your admin directory every hour.

Here is how to lock down your admin area using nothing more than an .htaccess file and a few lines of configuration. These methods work on Apache servers and block most attacks before they reach your login page. No premium plugins or expensive services required.

Restrict by IP Address

The simplest way to protect /wp-admin/ is to allow only specific IP addresses through. If you have a static IP at your office or home, this is the most effective protection you can set up. An attacker cannot guess your IP address, and they cannot brute force their way through a literal network barrier.

Add this code to an .htaccess file inside your /wp-admin/ directory:

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

Order deny,allow
Deny from all
Allow from YOUR_STATIC_IP
Allow from YOUR_VPN_IP

The admin-ajax.php exception is important. Plugins and themes use this file for AJAX requests, and blocking it breaks parts of your site. Without this exception, your frontend features that depend on AJAX stop working. If you are not sure what your static IP is, visit a site like whatismyip.com from your network and note the address.

If you work from multiple locations or your IP changes often, IP filtering alone is not practical. In that case, use a VPN with a static IP or pair IP filtering with a second method below. You can also maintain a small list of trusted IPs and update it when your address changes.

Password-Protect wp-admin with HTTP Auth

Apache’s built-in HTTP authentication adds a second login prompt before you even reach the WordPress login screen. Even if someone guesses your WordPress credentials, they still need the HTTP auth password. This creates a two-layer defense that stops most automated attacks.

First, create a .htpasswd file outside your web root so it is not publicly accessible:

htpasswd -c /etc/apache2/.htpasswd adminuser

This creates a password file and adds a user called “adminuser”. You will be prompted for a password. Choose a strong one that you do not use anywhere else. Then add this to your /wp-admin/.htaccess:

AuthType Basic
AuthName "Restricted Area"
AuthUserFile /etc/apache2/.htpasswd
Require valid-user

Combine this with the IP restriction above for layered protection. Users from your trusted IP skip the HTTP auth prompt entirely, while everyone else must authenticate twice before reaching the WordPress dashboard. This is an excellent setup for sites with a small team working from known locations.

Hide the Login Page by Renaming It

Attackers rely on knowing exactly where your login page is. By moving the login URL to a custom path, you eliminate 99% of automated attacks that target /wp-login.php and /wp-admin/. Bots do not try to guess custom URLs. They go through a list of known paths, and when they hit the default ones, they move on.

Add this to your main .htaccess (in the WordPress root):

RewriteRule ^custom-login$ wp-login.php [L]

Now your login page is accessible only at yoursite.com/custom-login/. The old /wp-login.php URL no longer works. Attackers hitting the default URL get a 404 or 403 error, and they have no way to know where the login page moved to. Keep in mind that some plugins and themes hardcode links to wp-login.php, so test your site thoroughly after making this change.

Use the site_url and login_url filters in your theme’s functions.php to update all internal links. This approach is not foolproof against determined attackers who read your .htaccess file, but it eliminates the vast majority of automated attacks.

Block Plugin and Theme File Access in wp-admin

If you never use the built-in file editor in WordPress admin (and you should not on production sites), disable it completely. This prevents attackers who somehow gain admin access from editing theme or plugin files through the dashboard. It also prevents accidental damage from a compromised admin account.

Add this line to your wp-config.php:

define('DISALLOW_FILE_EDIT', true);

You can also block direct access to sensitive PHP files in /wp-admin/ by adding rules to your .htaccess:

<FilesMatch "(phpinfo|installer|debug)\.php$">
  Require all denied
</FilesMatch>

This blocks files like phpinfo.php that some hosting environments leave behind, as well as installer scripts that should have been deleted after setup. If you need to run a diagnostic script later, temporarily remove this rule.

Rate Limit Login Attempts

Even with IP restrictions and HTTP auth, attackers who slip through benefit from unlimited login attempts. Rate limiting slows them down to a crawl. With unlimited attempts, an attacker can try 10,000 passwords per hour. With rate limiting, that drops to 30 attempts per hour or fewer.

Add this to your /wp-admin/.htaccess to delay repeated requests:

<IfModule mod_rewrite.c>
  RewriteEngine On
  RewriteCond %{REMOTE_ADDR}%{REQUEST_URI} ^(.*)$
  RewriteCond /tmp/wp-rate-limit-%1 !-f
  RewriteRule .* - [E=blocked:0]
  RewriteCond /tmp/wp-rate-limit-%1 -f
  RewriteRule .* - [F]
</IfModule>

This is a basic rate limiter that blocks an IP if it makes too many requests in a short window. For production use, set up fail2ban on your server for better control. Fail2ban monitors Apache logs and automatically bans suspicious IPs at the firewall level after detecting patterns like multiple failed login attempts or repeated requests to wp-login.php.

What Happens If You Skip This

A default WordPress admin area is a soft target. Automated bots scan for vulnerable /wp-admin/ installations constantly. Here is what you face without .htaccess protection:

  • Attackers run credential stuffing attacks using leaked passwords from other breaches against your login page
  • Brute force scripts hammer your login page with thousands of attempts per hour, potentially crashing your server
  • Zero-day exploits against admin-facing plugins target your /wp-admin/ directory directly
  • Your server resources get wasted processing hundreds of fake login requests, slowing down legitimate visitors
  • Failed login attempts fill your error logs, making it harder to spot real issues

According to Wordfence research, over 40% of WordPress site compromises involve weak or stolen login credentials. Simple .htaccess protection eliminates most of these attack vectors without any ongoing maintenance.

The Bottom Line

Securing /wp-admin/ with .htaccess is one of the highest-impact security changes you can make. It requires no additional software and no complex setup, and it blocks the vast majority of attacks automatically. Start with IP restrictions if your setup allows it, add HTTP auth for an extra layer, hide the login URL to throw off bots, and always disable the file editor on production sites. Each layer reduces the chance that an attacker finds a way through. For related protection, secure your WordPress XML-RPC endpoint as well.

Automating Your wp-admin Protections

Manual .htaccess edits work, but they are easy to forget when moving servers or switching hosts. Automate your security configuration by keeping your .htaccess rules in version control and deploying them with your site. Services like Trusti Security offer automated hardening for the admin area, including login URL masking, IP blocking, and rate limiting, all managed from a single dashboard. When you update your IP address or add a new team member, the changes propagate instantly without editing raw Apache config files.

An automated approach also means you never accidentally leave a debug rule enabled or forget to restore protections after a server migration. If you manage multiple WordPress sites, automating admin area security saves hours of manual work per site per year and eliminates the common mistakes that come with manual configuration.

Related Articles