Download .htaccess file for wordpress

The WordPress core uses .htaccess for two things: Permalinks and Multisite. This means that .htaccess is only required if you have enabled either of these features. Otherwise, .htaccess is entirely optional for default WordPress installations.

Beyond the WP core, many plugins also use the .htaccess file for custom directives involving rewrites, redirects, custom headers, file compression, and much more. In many cases, such plugins add their .htaccess rules to your .htaccess file automatically, behind the scenes.

So even if you haven’t enabled Permalinks or Multisite, your site may be using .htaccess rules added by WordPress plugins for various types of functionality. That’s one of the cool things about .htaccess: it can be configured and customized to improve your site’s performance, security, and usability. To help you get started, this tutorial provides a collection of .htaccess techniques that are useful for any WordPress-powered site. Combined into a blank .htaccess file, these techniques serve as a great starting point for creating your own custom .htaccess file for WordPress.

Menu

Before diving in..

Before making any changes to your site’s .htaccess file(s), remember to make a backup copy. That way you can quickly restore original functionality should anything unexpected happen. These rules are all well-tested and commonly used, but in this line of work anything can happen, so it’s best to be prepared with good working backups just in case.

Disable directory views

With this technique, we increase security by disabling directory views, which also are known as “directory indexes” or “directory listings”. Many web hosts disable directory views by default, but it’s important to know for sure. If your files are visible, here is an effective way to lock things down.

Here we disable via the directive. Then we specify the just in case. So technically it’s fine to just do this:

I include the additional rules because they are related, and some people may find them useful. To learn more about customizing directory views, check out my tutorial, Better Default Directory Views with HTAccess.

Set default encoding

Setting your site’s default encoding as helps browsers and devices correctly interpret your page content.

This directive helps to improve the accuracy and consistency of your web pages. It’s also possible to set the character encoding for specific file types. For example, here we are setting encoding for all CSS and JavaScript files:

For more possibilities, check out the “Add mod_mime suport” section of my tutorial, Useful .htaccess rules for all websites.

Add Vary header

According to Google and others, publicly cacheable, compressible resources should include the following header:

This is to prevent certain public proxy services from delivering compressed versions of your files to clients that do not support compression. Sending a Vary header for compressed resources helps resolve this issue by instructing the proxy to cache both compressed and uncompressed versions. To implement, add this code to your site’s root .htaccess file:

This code sends the necessary Vary header for CSS, JavaScript, gzip, and XML files. If your site serves other compressed resources, you can add their respective file types to the list, like so:

Here we have added the ZIP file format, .

Add security headers

There are lots of useful headers that can be added to any website. For example, here are three headers that provide some great security benefits:

• Protect against XSS attacks
• Protect against page-framing and click-jacking
• Protect against content-sniffing

Amazingly, you can add these security benefits with a simple slice of .htaccess:

No edits need made for this code. Simply add to root .htaccess and enjoy the extra protection. You can learn more about this technique by visiting my tutorial, Increase Security with X-Security Headers.

Protect sensitive files

By default, all WordPress installs include the following files:

• – WP configuration file
• – WP license information
• – WP install & version information

Of these, should by default NOT be publicly accessible. The other two files, and , are by default publicly accessible. All three of these files contain information about your WordPress-powered site. By blocking public access to these files, you prevent bad actors from obtaining and using the information when crafting their attacks. Here is the code to make it happen:

This simple technique uses to target each of the files that should be denied access. You can protect any other loose or sensitive files by adding them to the directive.

Leverage browser caching

Browser caching plays an important role with all websites, especially WordPress. This technique ensures that your site is taking advantage of browser caching by setting optimal HTTP headers.

This code helps to optimize performance by setting expires headers for the most common file types. You can adjust the cache times to suit your needs, and add more file types as required. For more information, check out Google’s article, Leverage Browser Caching.

Enable file compression

File compression reduces the amount of data that is sent to the client, so it is a great way to improve performance. Fortunately, Apache enables compression via its Deflate module, which can be implemented with the following slab of .htaccess:

This code first enables compression for all CSS and JavaScript files. It then enables compression for many other types of files. Feel free to customize the file formats that should be compressed. For more information, check out .htaccess enable compression.

Block external POST requests

POST requests are required when submitting certain forms. For example, the comment form, login form, and most contact forms all submit their data via the POST request method. Normally, POST requests are initiated by users who are visiting your site. But it’s also possible for bad actors to submit malicious POST requests from another domain or source, in an attempt to hack your stuff. To prevent this, we can deny access to all POST requests that are not initiated from your domain. This can be accomplished with the following slice of .htaccess:

Remember to change to match your own domain. Once implemented correctly, this code does the following:

1. Checks if the request is POST
2. Checks if the request is for the comments form or the login form
3. Checks if the request is not from your domain, or if the user agent is empty
4. If these conditions are true, the request is denied via 403 “Forbidden” response

In doing this, the above technique helps to keep your site secure by blocking any POST requests that do not originate from your domain. This helps to reduce spam, brute-force login attacks, and lots of other malicious mischief.

Note that you can protect other POST forms as well. For example, if you have a contact form located at , you can add it by modifying the directive like so:

Remember to test well before going live with any changes. More info: Block Spam by Denying Access to No-Referrer Requests.

Enable WordPress permalinks

Last but not least, if you have enabled Permalinks for your site, you must include the required .htaccess directives. There are two possibilities here: WordPress installed in the site’s root directory, or WordPress installed in a sub-directory. Depending on where WordPress is installed, you will want to include one of the following sets of directives.

WordPress in site root directory

Here is the code to use if WordPress is installed in the site’s root directory:

No modifications are required for this code.

WordPress in a subdirectory

Alternately, here is the code to use if WordPress is installed in it’s own (sub) directory (e.g., a subdirectory named ):

For this code, you will need to edit both instances of with the path/directory in which WordPress is installed. For example, here at Perishable Press, WordPress is installed in a directory named , so I replaced with .

For more information about either of these techniques, check out my tutorial, The htaccess Rules for all WordPress Permalinks.

Bonus tip!

As a bonus, you can add the following directive (just after the first ) to automatically redirect all requests to the actual WP Login Page:

For more information on this trick, check out Chris Coyier’s DigWP post, Simpler Login URL. This is a useful technique for client sites :)

Download ’em all

The techniques presented in this article are not dependent on each other. So you can use them separately, as desired; or you can combine them all into a single .htaccess file to create a solid .htaccess file for WordPress. To make things easier, here is a text file that contains all of the techniques from this tutorial:

Going further

Intentionally, the techniques provided in this article are kept as general and as widely applicable as possible. There are thousands more useful techniques that could be added, but keeping it simple with only the essentials is optimal when first getting started. I encourage you to go further with your .htaccess file. Here are some recommended resources that are worth exploring.

Questions and comments always welcome :)

Jeff Starr = Designer. Developer. Producer. Writer. Editor. Etc.