Secure your WordPress site with essential .htaccess configurations. Learn how to block threats, prevent directory browsing, and optimize your site’s security.
One misconfigured file can hand an attacker your database password, or lock you out of your own dashboard. On Apache servers, that file is .htaccess. It sits in a directory and quietly rewrites how the server answers every request that touches it, which makes it one of the sharpest security tools you have and one of the easiest to get wrong.
This guide covers the rules that earn their place in a WordPress .htaccess: locking down sensitive files, killing directory listings, and cutting off the endpoints bots love to hammer. One caveat before you copy anything: .htaccess is an Apache feature. If you run Nginx, none of this applies, and the same rules go in your server block config instead.
Table of Contents
- What is an .htaccess File?
- Why is .htaccess Important for Security?
- Basic Setup of .htaccess
- Essential Security Rules for .htaccess
- Preventing Directory Browsing
- Restricting Access to Sensitive Files
- Blocking Suspicious User Agents
- Mitigating DDoS Attacks with Rate Limiting
- Troubleshooting .htaccess Issues
- Conclusion
What is an .htaccess File?
The .htaccess (Hypertext Access) file is a per-directory configuration file that Apache reads on every request. It lets you set rules for URL rewriting, access restrictions, error handling, and caching without touching the main server config. On a WordPress site it lives in the root directory, and WordPress already uses it to make pretty permalinks work.
Why is .htaccess Important for Security?
Because Apache applies these rules before WordPress or PHP ever runs, you can stop bad requests at the door. A well-built file lets you:
- Restrict access: Control who can reach sensitive files and directories.
- Block unwanted traffic: Deny specific user agents, IPs, or referrers.
- Shut down common attack paths: Prevent directory listing and lock off endpoints like
xmlrpc.php. - Reduce load: Add caching and compression so the server does less work per hit.
Basic Setup of .htaccess
Find or create the .htaccess file in your site’s root directory. Your host needs to allow .htaccess overrides, and the Apache module mod_rewrite has to be enabled for permalinks and rewrite rules to work.
Here’s the default WordPress block that handles permalinks:
Example of the code
# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress
Leave everything between # BEGIN WordPress and # END WordPress alone. WordPress rewrites that block automatically, so anything you add inside it can get wiped the next time permalinks are saved. Put your own rules above or below those markers, never between them.
Essential Security Rules for .htaccess
Add the following rules outside the WordPress block. One heads-up on syntax: the Order / Allow / Deny directives below are Apache 2.2 style. They still run on Apache 2.4 through mod_access_compat, but they’re deprecated. The modern equivalent is Require all denied (or Require all granted). The old syntax is shown because most hosts and tutorials still ship it, and it works on both.
1. Deny Access to wp-config.php
wp-config.php holds your database credentials and secret keys. It should never be reachable over the web:
Example of the code
<Files wp-config.php>
order allow,deny
deny from all
</Files>2. Prevent Directory Browsing
If a folder has no index file, Apache will happily list its contents to anyone who asks. This one line turns that off site-wide:
Example of the code
Options -Indexes3. Block XML-RPC Access
xmlrpc.php is a favorite target for brute-force and amplification attacks. Unless you rely on it (Jetpack and some remote-publishing apps do), block it:
Example of the code
<Files xmlrpc.php>
order deny,allow
deny from all
</Files>
The same <Files> approach works for locking wp-login.php or wp-admin down to your own IP, which is worth doing if your admins log in from a fixed address. And if you want one more high-value rule: block PHP execution inside wp-content/uploads, so a malicious file that gets uploaded can’t be run.
4. Prevent Image Hotlinking
This isn’t a security rule so much as a bandwidth one. It stops other sites from embedding your images and billing the traffic to you:
Example of the code
RewriteEngine On
RewriteCond %{HTTP_REFERER} !^https://yourdomain\.com/ [NC]
RewriteCond %{HTTP_REFERER} !^$
RewriteRule \.(jpg|jpeg|png|gif)$ - [F]
Swap yourdomain.com for your real domain, or the rule will block your own images too.
Blocking Suspicious User Agents
You can turn away bots by their user-agent string. Be honest with yourself about how far this gets you: a determined bot just lies about its user agent. It’s still useful against noisy, honest scrapers:
Example of the code
SetEnvIfNoCase User-Agent "BadBot" bad_bot
SetEnvIfNoCase User-Agent "SpamBot" bad_bot
Deny from env=bad_bot
That Deny from line is Apache 2.2 syntax again; on 2.4 the modern form uses Require with an expression, but the old style keeps working through mod_access_compat.
Mitigating DDoS Attacks with Rate Limiting
Here’s a correction worth making, because a lot of guides get this wrong. The block below does not rate-limit anything. <Limit> restricts which HTTP methods are allowed and from where, so this example simply denies GET and POST to everyone except one IP range:
Example of the code
<limit GET POST>
Order deny,allow
Deny from all
Allow from 192.168.0.0/24
</limit>
Replace 192.168.0.0/24 with the range you want to allow. Real rate limiting (throttling by request volume) isn’t something plain .htaccess does. That needs an Apache module like mod_ratelimit for bandwidth or mod_evasive for flood protection, and a real DDoS wants a CDN or firewall in front of the server, not a config file behind it.
Troubleshooting .htaccess Issues
A bad .htaccess takes the whole directory down with a 500 error, so give yourself a way back:
- Back it up first: Copy the working file before you touch it.
- Read the error log: Apache’s log names the exact line and directive that broke.
- Restore the default: If you’re stuck, drop back to the stock WordPress block above and add rules back one at a time.
- Keep custom rules outside the WordPress block: Otherwise a permalink save can silently erase them.
Conclusion
A tuned .htaccess shuts a lot of doors before an attacker ever reaches WordPress: sensitive files hidden, directory listings off, noisy endpoints blocked. It won’t replace strong passwords, updates, or a firewall, but it’s a cheap, fast layer that runs at the server level.
Test every change on staging before it hits production, keep your custom rules outside the WordPress markers, and if you’re on Apache 2.4 reach for Require over the old Order / Deny / Allow. Get those right and the file works for you instead of against you.