WordPress .htaccess File: Every Rule You Actually Need

The .htaccess file in WordPress is a small configuration file that sits in your site’s root folder and tells the Apache web server how to handle requests before WordPress even loads. It controls your permalink structure, your redirects, your security headers, and your caching rules, all in a single plain text file that most site owners never look at until something breaks.

If you’ve ever changed your permalink settings in WordPress, you’ve already used .htaccess without knowing it. WordPress writes its own rules to that file every time you save your permalink structure. But the real power of the file is in the rules you can add yourself, from blocking attacks and forcing HTTPS to enabling browser caching and locking down sensitive files. A handful of lines in the right places can replace two or three plugins and run faster because they execute at the server level, before PHP or WordPress even wakes up.

This article walks through every .htaccess rule that’s actually worth adding to a WordPress site in 2026. You’ll see the default code WordPress generates, the security and performance rules that make a real difference, and the exact steps to recover your site when a bad edit triggers a 500 error. If you run WordPress on Apache hosting, and most shared hosts still use Apache, this file is one of the most useful tools you probably aren’t touching yet.

One thing before we start: .htaccess only works on Apache servers. If your host runs NGINX or LiteSpeed, some of these concepts translate but the file itself doesn’t apply. We’ll cover that distinction later so you don’t spend time editing a file your server ignores.

The .htaccess file is a plain text configuration file that Apache reads every time someone visits your WordPress site. It sits in the root directory of your installation, the same folder where you’ll find wp-config.php and the wp-content directory. Apache processes this file before it hands the request to PHP and WordPress, which is what makes it so useful for security and performance rules. When you block an IP address in .htaccess, the server rejects that connection before your database, your theme, or any plugin code even runs.

You won’t see the file if you browse your server’s files through a regular file manager because the dot at the beginning marks it as hidden on Linux and macOS systems. In most FTP clients like FileZilla, you need to enable “show hidden files” in the server settings. In cPanel’s File Manager, there’s a “show hidden files” checkbox in the settings panel at the top right. Once you toggle that on, the file appears right alongside wp-config.php in your root directory.

If you don’t find a .htaccess file at all, it probably means WordPress hasn’t created one yet. Go to Settings, then Permalinks in your WordPress dashboard, and click Save Changes without changing anything. WordPress will generate the default .htaccess rules automatically. You can also create the file manually by uploading an empty text file named .htaccess to your root directory through FTP.

The file uses Apache’s own directive syntax, not PHP or HTML. Each rule is a plain-text instruction that tells the server what to do with specific types of requests. Some rules use modules like mod_rewrite for URL rewriting and mod_headers for setting HTTP headers, and most shared hosting providers have both modules enabled by default.

WordPress writes a small block of rewrite rules to .htaccess when you first enable pretty permalinks. This default code is the reason your URLs show up as yourdomain.com/my-post-title/ instead of yourdomain.com/?p=123, and it’s the only part of the file that WordPress manages on its own.

The block starts with a comment that reads # BEGIN WordPress and ends with # END WordPress. Between those markers, you’ll find the RewriteEngine directive that activates URL rewriting, a RewriteBase that sets the root path, and several RewriteRule and RewriteCond lines. The conditions check whether the requested URL points to a real file or a real directory that actually exists on your server. If the request doesn’t match any physical file or folder, the final rule sends it to index.php, and WordPress figures out which post or page the visitor wanted.

Those comment markers aren’t just labels. WordPress uses them to locate and update its own section of the file every time you change your permalink settings. If you add custom rules between # BEGIN WordPress and # END WordPress, they’ll be overwritten the next time WordPress regenerates that block. Always place your own rules either above or below the WordPress section, never inside it.

A WordPress multisite installation with subdirectories uses a longer version of the same block. It includes extra rewrite conditions that handle routing between your network’s subsites and resolve uploaded files across them. The underlying logic is identical, but you’ll see more lines because each subsite needs its own routing path.

If your .htaccess file only contains the WordPress defaults and nothing else, the file is essentially doing one job: making pretty permalinks work. Every other useful feature, from security rules to caching headers, needs to be added by you or by a plugin that writes to the file on your behalf.

The safest way to edit .htaccess is to make a backup copy first, add one rule at a time, and keep your FTP connection open so you can undo changes instantly if the site goes down.

Start by connecting to your server through an FTP client like FileZilla or through the File Manager in your hosting control panel. Download a copy of your current .htaccess file and save it on your computer with a descriptive name that includes the date. This backup is your safety net: if a new rule breaks the site, you upload the backup copy to replace the broken file, and the site is back to normal in under a minute.

Open the original file in a plain text editor. On Windows, use Notepad or Notepad++ rather than Word, which adds formatting that corrupts server config files. On macOS, TextEdit works if you switch it to plain text mode first. Add your new rules above the # BEGIN WordPress block, save the file, and upload it back to your server, overwriting the existing version. After uploading, load your site immediately, check a few pages, and try the WordPress admin to make sure everything still works.

There are WordPress plugins like Htaccess File Editor and Redirection that let you edit the file from your dashboard. They’re convenient for quick changes, but they add a layer between you and the actual file that can make troubleshooting harder. For most site owners, learning to edit through FTP is a better long-term skill because it still works when WordPress itself won’t load, which is exactly when you’ll need it most.

One rule to follow every time: test changes one at a time. If you add five rules at once and your site breaks, you won’t know which one caused the problem. Add a single rule, test, confirm it works, and then move on to the next one. It takes a few extra minutes, but it saves you from staring at a blank screen wondering which of your edits went wrong.

Adding a few targeted rules to your .htaccess can block some of the most common WordPress attacks before they reach your site’s code, and these protections run at the server level where they’re both fast and hard to bypass.

The first rule worth adding protects your wp-config.php file, which holds your database credentials and security keys. You don’t want anyone requesting that file through a browser. Add a <Files wp-config.php> block with order allow,deny and deny from all between the tags. Apache will block every direct HTTP request to that file while WordPress continues reading it internally through PHP’s file system, which doesn’t go through the web server at all. This is one of those WordPress security basics that costs nothing and closes a real gap.

Next, add Options -Indexes on its own line. This single directive disables directory browsing, which is a default Apache behavior that lets visitors see a list of files in any directory that lacks an index file. Without this rule, someone could open your /wp-content/uploads/ folder in a browser and scroll through every file you’ve ever uploaded. That single line removes the directory browsing risk from your entire site.

If you don’t use the WordPress mobile app or Jetpack, block the xmlrpc.php file the same way you blocked wp-config.php. XML-RPC was built for remote publishing, but almost nobody uses it for that purpose anymore, and it’s one of the most common targets for brute-force login attacks. Security plugins often disable it with a PHP filter, but an .htaccess block is more efficient because it stops the request before PHP loads at all.

You should also prevent PHP files from executing inside your uploads folder. The /wp-content/uploads/ directory should only contain images, PDFs, and other media files. If an attacker finds a way to upload a malicious PHP script through a plugin vulnerability, you want to make sure it can’t actually run. Create a separate .htaccess file inside the uploads directory with a <Files *.php> block that denies all access. That single rule acts as a last line of defense even if your other protections fail.

These four rules cover the most impactful attack vectors, and each one takes less than a minute to add. For deeper protection beyond what server-level rules can offer, application-level defenses like two-factor authentication and login rate limiting work well as a second layer. The strongest security setups use both .htaccess rules and plugin-based protections together.

Yes, and the performance gains from server-level caching and compression rules are some of the easiest wins you’ll find, because they execute before WordPress and its PHP stack process anything at all.

The most impactful rule is browser caching. When a visitor loads your site, their browser downloads images, CSS files, and JavaScript. Without caching headers, the browser downloads those same files again on every single page view. With ExpiresByType directives in your .htaccess, you tell browsers to store those files locally for a set period. Images typically get cached for a month or more, CSS and JavaScript for a week or two, and HTML for shorter periods. The visitor’s second page load becomes noticeably faster because their browser already has most of the assets it needs.

Compression is the other big improvement. Adding mod_deflate rules to your .htaccess makes Apache compress text-based files like HTML, CSS, JavaScript, and XML before sending them to the visitor’s browser. The compressed files are typically 60 to 80 percent smaller, which means faster transfers and less bandwidth usage. Almost every modern browser handles gzip decompression automatically, so there’s no compatibility concern. If your host runs a CDN like Cloudflare or BunnyCDN, the CDN handles compression at its edge, but the .htaccess rule still helps for requests that bypass the CDN or for assets that aren’t cached yet.

You can also disable ETags with Header unset ETag and FileETag None. ETags are an older caching validation method that can actually hurt performance on some setups because the tag changes between servers in a load-balanced environment, causing browsers to re-download files they already have. Removing ETags and relying on Expires headers instead gives you cleaner, more predictable caching behavior.

The practical effect of these three changes combined, browser caching plus gzip compression plus ETag removal, is that your site feels faster to returning visitors and uses less server bandwidth overall. They don’t replace a proper caching plugin or a thorough image optimization strategy, but they’re a solid foundation that works at a layer most plugins can’t reach. If your site speed still needs work after adding these rules, the bottleneck is probably in your theme, your hosting, or your image sizes rather than in your server configuration.

A 500 Internal Server Error after editing .htaccess almost always means a syntax mistake, a rule your server’s Apache version doesn’t support, or a module that isn’t enabled on your host. The fix is simple if you prepared properly before making changes.

If your site goes down right after uploading a new .htaccess file, connect to your server through FTP immediately. Your WordPress admin won’t load during a 500 error, but FTP always works because it connects directly to the file system, not through Apache. Find the .htaccess file in your root directory and either upload the backup copy you made before editing, or rename the current file to something like .htaccess_broken. Renaming the file tells Apache to ignore it entirely, and your site will come back up using default settings. Your permalinks might show 404 errors at that point, but the site itself will load, and you can regenerate a clean .htaccess by visiting Settings then Permalinks in your dashboard and clicking Save.

The most common syntax mistakes are missing closing tags (every <IfModule> needs a matching </IfModule>), mistyped directive names, and using directives that require a module your host hasn’t enabled. If you test a mod_headers rule and your host doesn’t have that module loaded, the rule triggers a 500 error instead of being quietly ignored. Wrapping your rules in <IfModule mod_headers.c> blocks prevents this problem: if the module isn’t available, Apache skips the entire block instead of crashing.

There are also situations where .htaccess isn’t the right tool at all, and knowing when to step back saves you real headaches. If your host runs NGINX instead of Apache, .htaccess files are completely ignored, and you’ll need to add equivalent directives through your host’s NGINX configuration panel or support team. On managed WordPress hosts like Kinsta, Flywheel, or WP Engine, .htaccess changes are often restricted or overridden because those hosts handle caching, security, and redirects at the infrastructure level. Check your host’s documentation before spending time on rules they don’t support.

One more thing to keep in mind: every plugin that writes redirect rules, adds security headers, or sets caching policy is probably writing those rules to .htaccess behind the scenes. If you have a caching plugin, a security plugin, and a redirect plugin all editing the same file, their rules can conflict with each other and with anything you’ve added manually. When you hit a 500 error and you haven’t edited the file yourself, deactivating plugins one at a time through FTP by renaming each plugin’s folder is the fastest way to find which one broke things. If you’ve been through a WordPress recovery situation before, you’ll recognize the process.

The .htaccess file is one of those tools that either saves you time or creates your next emergency, depending entirely on whether you backed up before editing. Every rule in this article follows the same workflow: copy the current file, make one change, test, and move on. If you treat the file as something you adjust carefully rather than something you dump rules into all at once, you’ll avoid the vast majority of 500 errors and white screens that give .htaccess its reputation as risky.

Start with the security rules because they offer the most protection per line of effort. Add the performance rules next if your host supports mod_deflate and mod_expires, and most Apache hosts do. Skip anything your host already handles at the server level, and don’t add a rule just because a blog post recommended it. Add it because you understand what it does and you’ve confirmed that your server supports it. That’s the difference between a file that protects your site and one that takes it offline.