WordPress .htaccess Guide: Security Rules, Redirects & Performance Optimization

What Is .htaccess and How Does WordPress Use It?

The .htaccess (Hypertext Access) file is a directory-level configuration file for Apache web servers. WordPress uses it primarily for permalink rewrite rules, but its capabilities extend far beyond URL routing. It can enforce security policies, set HTTP headers, control caching, block malicious traffic, and redirect URLs — all at the server level before PHP even loads.

Unlike PHP-based security plugins that execute after WordPress boots, .htaccess rules are processed by Apache itself. This means they can block a malicious request before it consumes any PHP processing time, database connections, or memory. For high-traffic WordPress sites, this distinction between server-level and application-level processing can mean the difference between a responsive site and one that buckles under bot traffic.

The default WordPress .htaccess file contains only the rewrite rules needed for pretty permalinks. Everything else — security hardening, performance optimization, redirect management — needs to be added manually or generated with a purpose-built tool.

Essential Security Rules for WordPress .htaccess

A production WordPress .htaccess file should include at minimum these security directives:

Protect wp-config.php — Block direct browser access to your database credentials and security salts. Even if PHP processing fails temporarily, Apache will return a 403 Forbidden instead of serving the file as plain text.

Disable directory browsing — The Options -Indexes directive prevents Apache from listing folder contents when no index file exists. Without this, attackers can enumerate your plugin versions, theme files, and upload structure.

Block PHP execution in uploads — The wp-content/uploads/ directory should never execute PHP files. Attackers who manage to upload a PHP shell disguised as an image are stopped completely by this rule.

# Protect wp-config.php
<Files wp-config.php>
    Order Allow,Deny
    Deny from all
</Files>

# Disable directory browsing
Options -Indexes

# Block PHP in uploads (add to wp-content/uploads/.htaccess)
<Files "*.php">
    Order Allow,Deny
    Deny from all
</Files>

These three rules alone close the most commonly exploited WordPress attack vectors. They should be present in every production installation without exception.

Setting Up 301 Redirects in .htaccess

When you change URL structures, rename pages, or migrate content, 301 redirects preserve your SEO equity by telling search engines that a page has permanently moved. Without proper redirects, you lose accumulated PageRank, backlink value, and organic traffic overnight.

The RedirectMatch and RewriteRule directives handle different redirect scenarios. Simple one-to-one redirects use Redirect 301, while pattern-based redirects (like redirecting an entire category structure) require RewriteRule with regex matching.

# Simple 301 redirect
Redirect 301 /old-page /new-page

# Regex-based category redirect
RewriteRule ^blog/(.*)$ /articles/$1 [R=301,L]

# Force HTTPS
RewriteCond %{HTTPS} !=on
RewriteRule ^(.*)$ https://%{HTTP_HOST}/$1 [R=301,L]

Blocking Malicious Bots and Vulnerability Scanners

A typical WordPress site receives hundreds of requests per day from automated vulnerability scanners, scrapers, and spam bots. Tools like WPScan, Nikto, SQLMap, and dozens of others probe your site for known vulnerabilities, attempting to exploit outdated plugins, weak passwords, and misconfigured server settings.

While sophisticated attackers can spoof User-Agent strings, the majority of automated scanning tools use their default signatures. Blocking these at the .htaccess level prevents them from consuming server resources and cluttering your access logs. This is particularly important for shared hosting environments where CPU and memory are limited.

Beyond User-Agent blocking, you should also restrict access to WordPress-specific probe targets: wp-admin/install.php, wp-admin/setup-config.php, and the readme.html file that reveals your WordPress version number.

Adding HTTP Security Headers

HTTP security headers instruct browsers on how to handle your content. Setting them in .htaccess ensures they apply to every response — including static assets like images and CSS files that PHP-based solutions miss.

The essential headers for WordPress include X-Content-Type-Options: nosniff to prevent MIME-sniffing attacks, X-Frame-Options: SAMEORIGIN to prevent clickjacking, Strict-Transport-Security to enforce HTTPS, and Referrer-Policy to control information leakage. Together, these headers address the most common browser-side attack vectors.

Browser Caching and Performance Optimization

Browser caching directives in .htaccess tell browsers how long to store static assets locally. When configured properly, returning visitors load your site significantly faster because their browser reuses cached CSS, JavaScript, images, and fonts instead of downloading them again.

The mod_expires and mod_headers modules control cache lifetimes. Images and fonts should have long expiration times (1 year), CSS and JavaScript shorter (1 month with versioned filenames), and HTML pages should not be aggressively cached to ensure content updates are visible immediately.

Additionally, enabling Gzip or Brotli compression in .htaccess reduces the size of text-based responses by 60–85%. This is one of the highest-impact performance improvements available and takes effect immediately across the entire site.

Common .htaccess Mistakes That Break WordPress

The .htaccess file is powerful but unforgiving. A single syntax error can take your entire site offline with a 500 Internal Server Error. Here are the most common mistakes:

• Placing rules below the WordPress rewrite block — WordPress’s # BEGIN WordPress / # END WordPress section is managed by WordPress itself. Custom rules placed inside this block will be overwritten. Always add your rules above or below this section.
• Missing RewriteEngine On — Redirect and rewrite rules silently fail without this directive. It only needs to appear once, before any RewriteRule or RewriteCond.
• Redirect loops — Rules that don’t properly check for existing conditions (like already being on HTTPS) create infinite redirect loops. Always use RewriteCond guards.
• Not testing incrementally — Add rules one at a time and verify each before adding the next. A backup of the previous working version should always be on hand.

Frequently Asked Questions