Your Complete .htaccess Guide: Including .htaccess Basics and More

Comprehensive .htaccess Guide / .htaccess tutorial - Plesk .htaccess basics - Guides

Bookmark this .htaccess guide for any .htaccess tutorial you may need. We cover all the .htaccess basics and more for your convenience. htaccess configures the way that a server deals with a variety of requests. Quite a few servers support it, like Apache – which most commercial hosting providers tend to favor. htaccess files work at directory level, which lets them supersede universal configuration settings of .htaccess commands further up the directory tree.

Why is it called .htaccess? This type of file was initially used to limit user access to specific directories, and the name has just stuck. It uses a subset of Apache’s http.conf settings directives that give a sysadmin control over who has access to each directory.

It looks to an associated .htpasswd file for the usernames and passwords of those people who have permission to access them. .htaccess still performs this valuable function, but it’s a file that’s grown in versatility to do more besides that. So we’ll have the .htaccess basics and more explained in this article.

Where is the .htaccess file - plesk .htaccess guide

Where will I find the .htaccess file?

An .htaccess tutorial will tell you that you could find one in every folder (directory) on your server. But typically, the web root folder (the one that contains everything of your website) will have one. It will usually have a name like public_html or www. If you’ve got a directory with numerous website subdirectories, you’ll typically find an .htaccess file in the main root ( public_html ) directory. And one in all of the subdirectories (/sitename) too.

Why can’t I find the .htaccess file?

Most file systems – file names that start with a dot ( . ) will be hidden. So by default, you won’t be able to see them. However, you can still get to them. If you look at your FTP client or File Manager, you’ll likely find a setting to “show hidden files.” It may be in some other location depending on which program you use. But you’ll usually find it if you look under “Preferences”, “Settings”, “Folder Options” or “View.”

What if I don’t have an .htaccess file?

The first thing to establish is that you definitely don’t have one. Check that you have set the system to “show hidden files” (or whatever it’s called on your system). So that you can be sure it really isn’t there. You should have a .htaccess file as they’re frequently created by default, but it’s always worth checking.

If you’ve looked everywhere and you still can’t find one, never fear because .htaccess basics are not hard to understand. And we’ve got a .htaccess guide for you here. You can make one by opening a text editor and creating a new document. It should not have the .txt or any other file extension. Just .htaccess, and make sure it’s saved in ASCII format (it shouldn’t be in UTF-8 or anything) as .htaccess. Transfer it to the right directory using FTP or the file manager in your web browser.

Handling an .htaccess error code - Plesk

Handling an error code

One of your simple .htaccess basics is setting up error documents. Any .htaccess guide like this one will tell you that when a server receives a request, it responds by offering a document. Just like with HTML pages. Otherwise, it can pull that response from a particular application (as with Content Management Systems and other web apps).

If this process trips up, then the server reports an error and its corresponding code. Different types of errors have different error codes. And you’ve probably seen a 404 “Not Found” error quite a few times. It’s not the only one though.

Client Request Errors

  • 400 — Bad Request
  • 401 — Authorization Required
  • 402 — Payment Required (not used yet)
  • 403 — Forbidden
  • 404 — Not Found
  • 405 — Method Not Allowed
  • 406 — Not Acceptable (encoding)
  • 407 — Proxy Authentication Required
  • 408 — Request Timed Out
  • 409 — Conflicting Request
  • 410 — Gone
  • 411 — Content Length Required
  • 412 — Precondition Failed
  • 413 — Request Entity Too Long
  • 414 — Request URI Too Long
  • 415 — Unsupported Media Type.

Server Errors

  • 500 — Internal Server Error
  • 501 — Not Implemented
  • 502 — Bad Gateway
  • 503 — Service Unavailable
  • 504 — Gateway Timeout
  • 505 — HTTP Version Not Supported

What Happens by Default?

When there’s no specification on how to approach error-handling, the server just sends the message to the browser. Which in turn gives the user a general error message, but this isn’t especially helpful.

Creating Error Documents

At this point in your .htaccess guide, you’ll need an HTML document for each error code. You can call them anything, but you may want to consider a name that’s appropriate. Such as not-found.html or just 404.html.

Then, in the .htaccess file, determine which document goes with which error type.

ErrorDocument 400 /errors/bad-request.html

ErrorDocument 401 /errors/auth-reqd.html

ErrorDocument 403 /errors/forbid.html

ErrorDocument 404 /errors/not-found.html

ErrorDocument 500 /errors/server-err.html

Just note that each one gets its own line – and you’re done.

Alternatives to .htaccess – .htaccess guide for error-handling

Most CMS, like WordPress and Drupal – and web apps, will deal with these errors codes in their own way.

Password protection with .htaccess - Plesk

Password Protection With .htaccess

As we’ve said, .htaccess files were originally used to limit which users could get into certain directories. So let’s take a look at that in our .htaccess tutorial first.

.htpasswd –  this file holds usernames and passwords for the .htaccess system

Each one sits on its own line like this:


for example:


Note that this password isn’t the actual one, it’s just a cryptographic hash of the password. This means that it’s been put through an encryption algorithm, and this is what came out. It works in the other direction too. So each time a user logs in, the password text goes through that same algorithm. If it matches with what the user typed, they get access.

This is a highly secure way of storing passwords. Because even if someone gets into your .htpasswd file, all they’re seeing is hashed passwords – not the real ones. And there’s no way to use them to reconstruct the password either, because the algorithm is a one-way-street.

You can choose from a few different hashing algorithms:

  • bcrypt — The securest one but chugging through the encryption process slows it down as a result. Apache and NGINX are compatible.
  • md5 — The latest versions of Apache use this as their default hashing algorithm, but NGINX doesn’t support it.

Insecure Algorithms — These are best avoided.

  • crypt() — was previously the default hashing function, but isn’t a secure option.
  • SHA and Salted SHA.

.htaccess Guide to Adding Usernames and Passwords with CLI

You can use the command line or an SSH terminal to create an .htpasswd file and add username-password pairs to it directly.

.htpasswd is the command for dealing with the .htpasswd file.

Simply use the command with the -c option to create a new .htpasswd file. Then enter the directory path (the actual path on the server, not the URL). You can also add a user if you want to.

> htpasswd -c /usr/local/blah/.htpasswd jamesbrown

This makes a new .htpasswd file in the /blah/ directory, along with a record for a user called jamesbrown. It will then ask you for a password – also encrypted and stored using md5 encryption.

If an .htpasswd file already exists at that location, the new user just becomes part of the existing file. So it won’t create a new one. Otherwise, if you’d rather use the bcrypt hashing algorithm, go with the -b option.

Password hashing without the command line

If you’re only familiar with .htaccess basics, you may choose not to use the command line or SSH terminal. In that case, you can just create an .htpasswd file. Then, just use a text editor to fill everything in before uploading using FTP or file manager.

Of course, that leaves you with the task of encrypting the passwords. But that shouldn’t be a problem because there are lots of password encryption programs online. Many other .htaccess tutorials will probably approve of the htpasswd generator at Because it offers a few choices of algorithms that let you determine how strong the password is. Once you run it, copy your hashed password into the .htpasswd file.

You’ll only need one.htpasswd file for all your.htaccess files. So there’s no need to have one for each. One will do the job for the whole main server directory or web hosting account. But don’t put your .htpasswd file in a directory that anyone can access. So, not in public_html or www or any subdirectory. It’s safer from a security standpoint to put it somewhere that is only accessible from within the server itself.

Quick .htaccess Tutorial: How to use .htpasswd with .htaccess

If you want to have a .htaccess file for every directory, you can assign a set of users to have access to it. To grant universal access, do nothing, because this is enabled by default. If you want to limit who can get access, then your .htaccess file should look like this:

AuthUserFile /usr/local/etc/.htpasswd

AuthName "Name of Secure Area"

AuthType Basic

<Limit GET POST>

require valid-user


Line one shows the location of where your usernames and passwords are. Line two defines the name for the area you want to keep secure, and you can call it anything. Line three specifies “Basic” authentication, which is fine in most instances.

The <Limit> tag defines what is being limited. In this instance, the ability to GET or POST to any file in the directory. Within the pair of <Limit> tags is a list of who is allowed to access files.

In this example, access files can be accessed by any valid user. If you only want certain users to have access you can name them.

AuthUserFile /usr/local/etc/.htpasswd

AuthName "Name of Secure Area"

AuthType Basic

<Limit GET POST>

require user janebrown

require user jamesbrown


You can also grant/deny access based on the group where you put users – which is a real-time saver. You can do this by creating a group file and adding names. Give your group file a name, such as .htpeople, and have it look something like this:

admin: janebrown jamesbrown

staff: zappafrank agrenmorgen

Now it’s become something that you can refer to in your .htaccess file:

AuthUserFile /usr/local/etc/.htpasswd

AuthGroupFile /usr/local/etc/.htpeople

AuthName "Admin Area"

AuthType Basic

<Limit GET POST>

require group admin


The .htaccess guide for .htpasswd alternatives

It only makes sense to use .htaccess/.htpasswd to limit server file access if you have lots of static files. This approach appeared in the early days of websites, where they consisted of lots of HTML docs and other resources. If you’re using WordPress, you’ll have a feature that lets you do this as part of the system.

Enabling Server Side Includes (SSI) – .htaccess Tutorial

SSI is a simple scripting language which you would mainly use to embed HTML documents into other HTML documents. So you can easily re-use frequently-used elements like menus and headers.

<!-- include virtual="header.shtml" -->

It’s also got conditional directives (if, else, etc.) and variables, which makes it a complete scripting language. Although one that’s hard to use if you have anything more complicated in your project than one or two includes. If it gets to that point then a developer will usually be reaching for PHP or Perl instead.

Server Side Includes are enabled by default with some web-hosting servers. If yours isn’t, you can use your .htaccess file to enable it, like this:

AddType text/html .shtml

AddHandler server-parsed .shtml

Options Indexes FollowSymLinks Includes

This should enable SSI for all files that have the .shtml extension. You can tell SSI to parse .html files using a directive like this:

AddHandler server-parsed .html

Why bother?

Well, this way lets you use SSI without alerting anyone to the fact that you are doing so. On top of that, if you change implementations later, you can hold on to your .html file extensions. The only fly in the ointment here is that every .html file will then be parsed with SSI. And if you have many .html files that don’t need SSI parsing, it makes the server work needlessly harder. Thus, bogging it down for no extra benefit.

SSI on your Index page

To avoid parsing every single.html file without using SSI on your index home, you have to stipulate in your .htaccess file. Because when the web server looks for the directory index page, it will be hunting for index.html by default. If you aren’t parsing .html files, you must name your index page “named index.shtml” if you want SSI to work. Because then, your server won’t automatically look for it. To make that happen just add:

DirectoryIndex index.shtml index.html

This lets the web server know that the index.shtml file is the main one for the directory. The second parameter, index.html is a failsafe. This gets referred when it can’t find index.shtml.

IP blacklisting - IP whitelisting - .htaccess - Plesk

IP Blacklisting and IP Whitelisting with .htaccess

If you’ve had problems from certain users/IP addresses, there are .htaccess basics you can use to blacklist/block. Otherwise, you can do the opposite and whitelist/approve everyone from particular addresses if you want to exclude everybody else.

Blacklisting by IP

This will let you blacklist addresses (numbers are examples):

order allow,deny

deny from 444.33.55.6

deny from 735.34.6.

allow from all

The first line says to evaluate the allow directives before the deny directives. This makes allow from all the default state. In this case, only those which match the deny directives will be denied. If you switched it round to say deny,allow, then the last thing it looked at would be the allow from all directive. This allows everybody, and overrides the deny statements.

Take note of the third line, which says deny from 735.34.6. This isn’t a complete IP address, but that’s okay because it denies every IP address in that block. Ergo, anything that begins with 735.34.6. You can include as many IP addresses as you like, one on each line, with a deny from directive.

Whitelisting by IP

The opposite of blacklisting is whitelisting — restricting everyone except those you specify. As you might suspect, the order directive has to be turned back to front. So that you deny access to everyone at first, but then allow certain addresses after.

order deny,allow

deny from all

allow from

allow from 789.56.4.

Domain names instead of IP addresses

You can also block or allow users of a domain name. This is helpful if people are moving between IP addresses. But it won’t work against anyone who has control of their reverse-DNS IP address mapping.

order allow,deny

deny from

allow from all

This works for subdomains too. In the example above, you will also block visitors from abc

Block Users by Referrer – .htaccess Guide

If a website contains a link to your site and someone follows it, we call it a ‘referrer’. But this doesn’t only work for clickable hyperlinks to your website. Any page on the internet can link to your images directly. This is called hotlinking. It often steals your bandwidth, it can infringe on your copyright – and you don’t even get extra traffic from it. And it’s not just images either. A stranger can link to your other resources like CSS files and JS scripts, too.

This is bound to happen a little bit and most site owners tolerate it. But it’s the kind of thing that can easily escalate into something more abusive. And there are times when in-text clickable hyperlinks can cause you problems too. Like when they’re from troublesome or nefarious websites. These are just a few of the reasons why you may decide to deny requests that originate with particular referrers.

If you need to do this, you’ll have to activate the mod_rewrite module. Most web hosts enable it automatically. But if yours doesn’t, or you can’t tell if they have, you should get in touch and ask. If they’re reluctant to enable it – maybe think about getting a new host.

.htaccess basics – Directives that block a referrer depend on the mod_rewrite engine.

The code to block by referrer looks like this:

RewriteEngine on

RewriteCond % ^http://.* [NC,OR]

RewriteCond % ^http://.* [NC,OR]

RewriteCond % ^http://.* [NC]

RewriteRule .* - [F]

It’s slightly fiddly, so let’s go through it.

RewriteEngine on, on the first line tells the parser that some rewrite directives are on the way. Each of lines 2,3 and 4 blocks a single referring domain. To change this for your own purposes you would alter the domain name part (forinstance) and extension (.com). T

he back-slash in front of the .com is an escape character. The pattern matching used in the domain name is a standard expression. And the dot has a meaning in RegEx. So it must be “escaped” by using “/”.

The NC in the brackets is there to specify that the match shouldn’t be case sensitive. The OR literally means “or”, and indicates that more rules are on the way. As long as the URL is this one, this one or this one, go along with this rewrite rule.

The final line is the rewrite rule itself. The [F] stands for “Forbidden.” If a request comes from a referrer like the ones on the list, then it will be blocked. And a 403 Forbidden error will arrive.

Block bots and web scrapers - Plesk .htaccess Guide

An .htaccess Guide to Blocking Bots and Web Scrapers

Sometimes it isn’t even people trying to eat up your bandwidth, it’s robots. These programs come and lift your site information, typically to republish under some low-quality SEO outfit. There are genuine bots out there, such as the ones that come from the big search engines. But others are almost like cockroaches, scavenging and doing you no good whatsoever.

To date, the industry has identified hundreds of bots. You won’t ever be able to block them all, but at least, as many as possible. Here are some rewrite rules that will trip up 350+ known bots.

Specifying a Default File for a Directory

When a server receives a URL request but with no specified file name, it assumes the URL refers to a directory. So, here is a .htaccess guide on what to do. If you request http:, Apache (and most servers) will look for the domain in the root directory. Typically /public_html or something like it, such as /forinstance-com – in order to find the default file. The default file will be called index.html by default. Because when the Internet was young, websites were often just a bunch of docs bundled together. And “home” pages were often no more than an index, so that you knew where everything was.

Of course, nowadays you might not want index.html to be the default page. Perhaps because you may want a different file type. So index.shtml, index.xml, or index.php might be more appropriate. Or maybe you don’t think of your home page as an “index,” and want to call it something else. Like home.html or primary.html.

Set the default directory page - .htaccess

Set the Default Directory Page

One of the .htaccess basics is letting you set the default page for a directory with ease:

DirectoryIndex [filename goes here]

If you want your default to be home.html it’s as simple as using:

DirectoryIndex home.html

.htaccess Guide to Setting More Than One Default Page

You can also set more than one DirectoryIndex:

DirectoryIndex index.php index.shtml index.html

The way this works is that the web server looks for the first one first. If it can’t find that, it looks for the second one, and on it goes. But why would you need to do this? Wouldn’t you know which file you wanted to use as your default page? Keep in mind that one of the .htaccess basics is that it influences its own directory. And each subdirectory too until it’s overruled by a more local file.

So, an .htaccess file in your root directory can give instructions for lots of subdirectories. And in turn, they could all have their own default page names. So, imagine you put all those rules into just one .htaccess file in the root. Then, it spares you the tedious work of duplicating all the directives it contains at the level of every directory.

.htaccess Guide to URL Rewriting and URL Redirects

An important part of this .htaccess guide is that the most common uses of .htaccess files is URL redirects. So, for example, the URL for a document or resource may have changed. Perhaps because you’ve moved things around on your website, or you’ve changed domain names. Then, in that case, URL redirects can help you.

301 or 302

There are two types of redirect error codes that the server will generate, namely 301 and 302.

301 tells you that something has “Permanently Moved.” Meanwhile, 302 means it “Moved Temporarily.” In most cases, 301 does a perfectly good job. And perhaps more importantly, it gets SEO brownie points since the original URL may pick up from the new page.

It will also make most browsers update their bookmarks and cache the old-to-new mapping. This consequently lets them request the new URL when the original is being looked for. For a permanently changed URL these are all the responses you want.

There’s not much you can gain from using 302 redirects. Mainly, because there’s rarely a reason to change a URL on a temporary basis. Changing one at all is not something that anybody should really want to do. However, sometimes you just have to do it. And there are usually better options to changing it only to change it back later. At least, at the time of writing this .htaccess guide.

Redirect or Rewrite

You can change a URL with .htaccess directives in a couple of ways — the Redirect command and the mod_rewrite engine. The Redirect command tells the browser which other URL it should be looking out for. The mod_rewrite tool will normally “translate” the URL that’s in the request. Turns it into something the file system or CMS can understand. Then, it treats the request as though the translated URL was the one that was requested.

From the perspective of the web browser it’s business as usual. It gets the content it requested and carries on as if nothing happened.

The mod_rewrite tool is also able to produce 301 redirects that work like the Redirect command. But with a greater number of possible rules instead. Including elaborate pattern matching and rewriting instructions – which is beyond what Redirect can do.

Basic Page Redirect – .htaccess guide

For redirecting one page to another URL, the code looks like this:

Redirect 301 /relative-url.html

A single space separates each of the four parts of this one-line command, so you have:

  1. the Redirect command itself
  2. its type ( 301 – Moved Permanently )
  3. the original page’s relative URL
  4. the full URL of the new page.

The relative URL is relative to the directory that contains the .htaccess file. Which will normally be the web root, or the root of the domain.

So, if had been moved to, the code would be:

Redirect 301 /blog.php

Redirecting a large section – .htaccess guide

Have you made changes to your directory structure yet? If you haven’t change your page names, redirect all requests for a particular directory to the new one.

Redirect 301 /old-directory

Redirecting an entire site – .htaccess guide

But how about if your entire site has moved to a new URL? No problem.

Redirect 301 /

Redirecting www to non-www – .htaccess guide

More and more websites are turning their back on the www subdomain. There’s never really been a need for it. It’s a throwback to when website owners used a server to look after many of their own documents. And the www directory was where they put anything they wanted to offer others.

Some still use it to this day, but many have moved on. It’s become such a habit for users to type “www.” in front of every URL. Therefore, making it tricky for you if yours has been short of those letters. However, the mod_rewrite module can help you with this. And you probably have one on your web host’s dashboard already.

Options +FollowSymlinks

RewriteEngine on

RewriteCond % ^ [NC]

RewriteRule ^(.*)$$1 [R=301,NC]

But be careful! Many other .htaccess and mod_rewrite guides will give you some version of this code to achieve this:

Options +FollowSymlinks

RewriteEngine on

RewriteCond % !^ [NC]

RewriteRule ^(.*)$$1 [R=301,NC]

Can you see what’s wrong with it?

All subdomains are redirected to the primary domain! Which means not just, but others like and too. Not ideal behaviour!

Redirecting to www – .htaccess guide

So, what happens if you’re using the www subdomain? You should probably set up a redirect to make sure people get to where they’re trying to go. Especially now that fewer people are likely to automatically add that www to the beginning of URLs. All you need to do is reverse the code to achieve this.

RewriteEngine On

RewriteCond % ^ [NC

RewriteRule ^(.*)$1 [R=301,NC]

One thing not to do:

A number of .htaccess guides recommend redirecting 404 errors to your home page. While this is possible, we’re writing here in our .htaccess guide that it’s actually an awful idea. Because it leaves visitors confused. They will be expecting another page, and instead get your homepage. A 404-error page would have told them exactly what they needed to know – whereas this does not. And anyway, what’s the problem with admitting that a page can’t be found? There’s no shame in it.

Why use the .htaccess basics in this .htaccess guide rather than other approaches? Redirects can be set up with server-side scripting, like in PHP files. They can also be set up from within your CMS – which is pretty much the same thing. But using .htaccess is usually the fastest type of redirect. With PHP-based redirects, or other server-side scripting languages, the entire request must be completed. And the script is actually interpreted before a redirect message is sent to the browser.

As any .htaccess guide will tell you, using .htaccess redirects are much faster. Mainly because the server responds to each request directly. However, be aware that some CMSs handle redirects by updating the .htaccess file in a programmatic way. Like WordPress, for example. This gives you the speed benefits of directly using .htaccess combined with the convenience of managing it from inside your application.

.htaccess Basics – Hiding Your .htaccess File

One of the .htaccess basics in this .htaccess guide is that the file shouldn’t be visible from the web. There’s just no reason for it, aside from maybe wanting to locate your .htpasswd file. And as another rule of the .htaccess guide, random strangers shouldn’t be able to look at details of your implementation. Including rewrite rules, directory settings, and security. Hiding all of that stuff makes it more difficult for hackers to work out ways into your system. Luckily, you can hide your .htaccess file fairly easily using this code:

<Files .htaccess>

order allow,deny

deny from all


MIME types - .htaccess - Plesk

.htaccess guide to MIME types

MIME types are file types – originally for email (“Multipurpose Internet Mail Extensions”). But don’t just think of them as “file types” because MIME suggests a specific format for specifying them. If you’ve ever written an HTML doc, you’re likely to have specified a MIME type. Probably even without realising it:

<style type=”text/css” src=”/style.css” />

The type attribute refers to a particular MIME type.

MIME types on your server

Occasionally you might find that your web server isn’t set up to deliver a specific file type. And any requests for that type of file just don’t work. Usually, you can get around this by putting the MIME type in your .htaccess file.

AddType text/richtext rtx

This directive has three space-separated parts:

  1. The AddType command
  2. The MIME type
  3. The file extension.

You can associate a number of different file extensions with the same MIME type on one line.

AddType video/mpeg mpg MPEG MPG  

Force Download by MIME Type

Want every link to a type of file to automatically download, rather than just open in your browser? Then, use the MIME type application/octet-stream, like this:

AddType application/octet-stream pdf

As before, you can include numerous file extensions:

AddType application/octet-stream rtf txt pdf docx doc

List of File Extensions and MIME Types – .htaccess basics

Here’s an incomplete list of file formats and associated MIME types. If you manage your own website, you may already know your file types. Therefore, you don’t need to paste the whole list into your .htaccess file. But if you run a site with others who could be uploading all sorts of stuff, then yes. This might help to avoid any potential publishing mishaps. This particularly relates to file sharing or project management sites where folks are bound to be sharing lots of files.

AddType application/macbinhex-40 hqx

AddType application/netalive net

AddType application/netalivelink nel

AddType application/octet-stream bin exe

AddType application/oda oda

AddType application/pdf pdf

AddType application/postscript ai eps ps

AddType application/rtf rtf

AddType application/x-bcpio bcpio

AddType application/x-cpio cpio

AddType application/x-csh csh

AddType application/x-director dcr

AddType application/x-director dir

AddType application/x-director dxr

AddType application/x-dvi dvi

AddType application/x-gtar gtar

AddType application/x-hdf hdf

AddType application/x-httpd-cgi cgi

AddType application/x-latex latex

AddType application/x-mif mif

AddType application/x-netcdf nc cdf

AddType application/x-onlive sds

AddType application/x-sh sh

AddType application/x-shar shar

AddType application/x-sv4cpio sv4cpio

AddType application/x-sv4crc sv4crc

AddType application/x-tar tar

AddType application/x-tcl tcl

AddType application/x-tex tex

AddType application/x-texinfo texinfo texi

AddType application/x-troff t tr roff

AddType application/x-troff-man man

AddType application/x-troff-me me

AddType application/x-troff-ms ms

AddType application/x-ustar ustar

AddType application/x-wais-source src

AddType application/zip zip

AddType audio/basic au snd

AddType audio/x-aiff aif aiff aifc

AddType audio/x-midi mid

AddType audio/x-pn-realaudio ram

AddType audio/x-wav wav

AddType image/gif gif GIF

AddType image/ief ief

AddType image/jpeg jpeg jpg jpe JPG

AddType image/tiff tiff tif

AddType image/x-cmu-raster ras

AddType image/x-portable-anymap pnm

AddType image/x-portable-bitmap pbm

AddType image/x-portable-graymap pgm

AddType image/x-portable-pixmap ppm

AddType image/x-rgb rgb

AddType image/x-xbitmap xbm

AddType image/x-xpixmap xpm

AddType image/x-xwindowdump xwd

AddType text/html html htm

AddType text/plain txt

AddType text/richtext rtx

AddType text/tab-separated-values tsv

AddType text/x-server-parsed-html shtml sht

AddType text/x-setext etx

AddType video/mpeg mpeg mpg mpe

AddType video/quicktime qt mov

AddType video/x-msvideo avi

AddType video/x-sgi-movie movie

AddType x-world/x-vrml wrl

Block hotlinking - .htaccess - Plesk

Block Hotlinking – .htaccess Guide

Hotlinking is where you link to resources from other domains rather than hosting the files yourself. A good example would be a video that you really like on someone else’s site. You can either download it, upload it to your site (assuming no copyright, of course) and embed in your page.

<img src=””>

The hotlinking route saves you the bother and the bandwidth. And no, that doesn’t mean we condone it—quite the opposite in fact.

<img src=””>

This kind of thing also goes on with CSS and JS files – but it mostly happens with pictures and video. Sites like Wikipedia don’t really mind you doing this. And there are others who want you to do it because it helps their SEO needs. Then there are the likes of JQuery, which uses a CDN to share their JS libraries so you don’t have to host them yourself. But a lot of web hosts see hotlinking as a way of stealing their material and hogging their bandwidth.

If your site’s not really big, then you don’t want to be getting thousands of requests every day. Especially considering they don’t bring visitors to your site or benefit you in any way. So, if hotlinking is only raising your blood pressure, then you can block it. Simply by adding some mod_rewrite rules to your .htaccess file.

RewriteEngine on

RewriteCond % !^$

RewriteCond % !^http://(www.)?*$ [NC]

RewriteRule .(gif|jpg|jpeg|png|js|css)$ - [F]

Don’t forget to change in line 3 to your genuine domain name. This way, we catch any requests that don’t originate from your domain. And check them to see if they match one of the file extensions you’ve identified in line 4. If there’s any match – request denied. You can also easily add other file extensions to the list by editing the final line.

Enabling CGI Everywhere

CGI – Common Gateway Interface, is a server-side method that includes non-HTML scripts (like SSI or Perl) in web pages. CGI scripts are normally in a folder named /cgi-bin. The server’s configurations are to treat any resource in that directory as a script, instead of a page.

The problem is URLs which reference CGI resources must have /cgi-bin/ in them. So they can place implementation details into your URL – an inverse pattern you should steer clear of for a few reasons. Meanwhile, an elaborate site may need a better structure than just having loads of scripts crammed into one/cgi-bin folder.

For your server to parse CGI scripts, regardless of directory location, just put this in your .htaccess file:

AddHandler cgi-script .cgi

Options +ExecCGI

If you have other file extensions you’d like to process as CGI scripts, just add them to the first line.

Scripts as Source Code

Most of the time, all the scripts go in your web directory because they need to run as scripts. But maybe you want site visitors to be able to view the source code, instead of just executing it. Your .htaccess file can help you do this by stripping the script handler for particular types of file. And then putting them in a handler for text instead.

RemoveHandler cgi-script .pl .cgi .php .py

AddType text/plain .pl .cgi .php .py

Alternatively, you can specify for these file extensions to download by default, instead of just appearing on display.

RemoveHandler cgi-script .pl .cgi .php .py

AddType application/octet-stream .pl .cgi .php .py

Be on your guard with both of these, though. Because if you’re still using these scripts for the rest of your website, that directive in your web root’s .htaccess file is going to cause you headaches. You’re better off putting scripts you only want to display into their own designated directory. And then putting the directive into an .htaccess file in that same folder.

PHP settings - .htaccess - Plesk

Configuring PHP Settings

Sometimes you need to tweak PHP settings, and this is best done using a file called php.ini. The thing is, some hosting companies, particularly shared hosters, won’t let their customers do that. But you can get around this, by embedding php.ini rules in your .htaccess file. Here’s the syntax:

php_value [setting name] [value]

So, let’s say you want to increase the maximum file upload size. You’d just say:

php_value upload_max_filesize  12M

You can’t specify every PHP setting in a .htaccess file. For instance, you can’t disable_classes like this. To see a full list of all php.ini settings, check out the official php.ini directives guide.

When Not to Use .htaccess

When you first edit your .htaccess file you can suddenly feel as powerful as a sysadmin. But try not to let absolute power corrupt you. Because you may find yourself misusing the .htaccess file. When all you have is a hammer, then every task can start to look like a nail. But at least sometimes, when something seems like an .htaccess task, your directive is better off somewhere else.

Further Up the Tree

When you feel like putting a directive in an .htaccess file, you should probably choose the httpd.conf file instead. It’s a configuration settings file for the whole server. The proper home of PHP settings too is the php.ini file, and most languages have their own equivalents.

So say you put directives higher up in the tree, in the httpd.conf, php.ini, or other appropriate file for that language. Then, you can embed those settings in the server’s parsing engine. With .htaccess, you must check and interpret the directives every time there’s a request.

This isn’t so bad if you’re running a low-traffic site with just a few .htaccess directives. But it isn’t difficult to see if your site is traffic-heavy and has to churn through lots of directives. You’re effectively putting the brakes on the whole thing.

It’s a shame that a lot of shared hosting providers won’t let their customers into the httpd.conf or php.ini files. Hence, forcing them to settle for the slower .htaccess file.

This doubly penalizes them when you compare them side-by-side with custom VPS configurations. Because shared hosting is also usually under-resourced. That’s why a site with a decent level of traffic is probably better off with VPS instead of shared hosting.

.htaccess troubleshooting basics - Plesk

Setting Up NGINX and Apache Virtual Host Configuration Files

Setting Up NGINX and Apache Virtual Host Configuration Files - Plesk

Plesk for Linux uses the Apache web server for website hosting. By default, NGINX makes it stronger so as to achieve a higher level of performance. The Apache web server doesn’t directly operate hosted websites – but it does manages virtual hosts. So what are Virtual hosts? Web resources with an assigned host or IP. Hence, as soon as the admin creates a site under Plesk, the system adds a new virtual host to Apache. So let’s talk about NGINX and Apache virtual host configuration files.

In summary, the configuration settings for each virtual host are stored in configuration files which you’ll find in the /var/www/vhosts/system/<domain_name>/conf/ directory. The ones you’re looking for are:

  • <version>_httpd.conf – Apache virtual host configuration
  • <version>_nginx.conf – NGINX configuration

The final Apache virtual host configuration will include all httpd.conf and nginx.conf files from all virtual hosts.

Where to Find Virtual Host Configuration Files

Plesk always remembers how it was set up before. Because we record all previous configuration states in a virtual host configuration file. Therefore, if you’re an administrator or domain owner, you may want to check what changed and when. Alas, you can certainly find details of current file states here – last_httpd.conf and last_nginx.conf.

Every time you make a change in a virtual hosting configuration, like domain hosting type, the system regenerates the config files. So, while editing httpd.conf and nginx.conf files yourself, changes will be lost after changing virtual host settings in Plesk UI. To prevent this, use extra files to outline custom configuration for domains:

  • vhost.conf and vhost_ssl.conf – custom Apache directives for two situations. First, when clients access the site over HTTP and second, HTTPS. These files go into httpd.conf.
  • vhost_nginx.conf – custom NGINX directives. This file goes into nginx.conf.

Ultimately, you’ll find the files with custom per-domain configuration in the /var/www/vhosts/system/<domain_name>/conf/ directory.

Notice that a lot of the settings in these files take precedence over the server-wide configuration of a virtual host (httpd.conf and nginx.conf). For instance, you may include directives which already exist in the site’s current httpd.conf file. In this case, the system will use your values from the vhost.conf and vhost_ssl.conf files.

Editing Virtual Host Configuration Files

Editing Virtual Host Configuration Files - Plesk

When you want to edit virtual host configuration files, you have a couple of choices:


You can add custom directives to the following files from /var/www/vhosts/system/<domain_name>/conf/ directory:

  • vhost.conf and vhost_ssl.conf
  • vhost_nginx.conf

Using Plesk GUI

Go to Websites & Domains > select a website > Web Server Settings tab you can specify:

  • Common Apache settings: Most commonly used directives (like MIME types or index files). These directives will be included in httpd.conf.
  • NGINX settings: Directives that define the scope of NGINX’ role in serving different types of website content (static and dynamic).
  • Extra Custom Apache directives: Add several simultaneously in the Additional directives for HTTP and Additional directives for HTTPS fields.
    These fields correspond to vhost.conf and vhost_ssl.conf files respectively.
  • Additional NGINX directives: You can add several custom NGINX directives at once in the Additional NGINX directives field.
    This field corresponds to vhost_nginx.conf file.

The changes you made in the web server configuration will apply automatically.

Just upgraded from an older Plesk version?

If you did and are now configuring vhost.conf and vhost_ssl.conf files,  you need to use the httpdmng utility. That way you can apply changes from your config files. For example, to generate web server configuration files for a website, run the command: /usr/local/psa/admin/sbin/httpdmng –reconfigure-domain <domain_name>

HTTP to HTTPS – Here’s What to Do


HTTP to HTTPS is the key to making your customers feel safe from the bad guys out to steal their data. Here’s how to secure your site and your business.

Some of the major web browsers have begun to warn users when they visit websites without SSL certificates. Firefox is one. Chrome is another. But why should that bother you? Well, because anyone who visits your site will be told that it’s unsafe, and they might want to turn back, so a redirect from HTTP to HTTPS becomes a way to make sure you don’t start losing visitors.

Why Do We Need SSL Certificates Anyway?

Information Encryption

Everything you send over the Internet goes through other computers before it gets to the one that hosts the website you’re trying to reach, so all of your private and financially sensitive stuff could be stolen by others unless it’s disguised through encryption. That’s what an HTTP to HTTPS gives you: scrambled info that can only be unscrambled by the intended recipient.

Protection from Cybercriminals

Consultancy firm Cybersecurity Ventures predicts that by 2021, cybercrime will cost the world more than $6 trillion, a figure that’s hard to imagine, but to put it into perspective, that will be more than the amount generated by the world’s entire illegal drug trade. That’s serious!

With so much money to be made, criminals are getting more and more sophisticate. They know that there are rich pickings to be had from penetrating networks. To them, it’s a crime with far fewer risks than many of the other evil schemes they might pursue, and it offers potentially greater rewards.

That’s why they’ve been making efforts to intercept your information while it’s on route—in what are called transit-based attacks—and that’s why HTTP to HTTPS have become so important.

Security = Trust in Your Brand

Trust is one of those intangibles that every brand needs and earning it means making sure that every touch point in your customer’s journey builds on that trust. Have you ever noticed the little lock icon that sometimes appears in your address bar? Or sometimes how there’s red line through the name of the website you’re visiting instead? The first one means you’re connected safely thanks to HTTP to HTTPS and you’ve got well-trusted encryption. The second one means the connection isn’t protected. From a customer’s point of view, if they see the first one then their trust in your brand will grow. If they see the second one, then you can say goodbye to them.

Legit Referral Data

Since Google Analytics is not showing HTTPS to HTTP referral data – you will loose significant part of statistical data. Imagine that someone placed a link to your website on old and reputable website with huge amount of traffic. This site resides under HTTPS, yours – under HTTP. The referrer data in this case is completely lost, the traffic from linking website will be represented as Direct inside Google Analytics and is not really useful for any further marketing analysis.  So, migrating your website to HTTPS solves this issue and after migration referral data is passed properly from any linking site – under HTTP or HTTPS.

HTTP to HTTPS – implementation how-to

The first thing you need to do is to edit .htaccess file. This is a configuration file used by Apache web server software to provide a way to make configuration changes on a per-directory basis. Apache is one of the most popular web servers in the world, developed and maintained by Apache Software Foundation.

How to edit the .htaccess file

The .htaccess file contains information that tells the server what to do under various circumstances, so it has the capacity to change the functionality of your website. It does things like:

  • Redirects
  • URL Rewriting

Ways you can change an .htaccess file

  • Change the file on your machine and upload it to the server via sFTP/FTP
  • All FTP/sFTP/SCP apps have an “Edit” feature which allows remote editing of files.
  • Use a text editor and SSH to alter the file.
  • Use the file manager of Plesk Onyx or cPanel to amend the file.


Redirecting HTTP to HTTPS

Redirect All Web Traffic

If there’s existing code already in your .htaccess file, add the following:

RewriteEngine On
RewriteCond %{SERVER_PORT} 80
RewriteRule ^(.*)$$1 [R,L]

Redirect a Specific Domain Only

To redirect a specific domain to use HTTPS, add this:

RewriteEngine On
RewriteCond %{HTTP_HOST} ^yourwebsite\.com [NC]
RewriteCond %{SERVER_PORT} 80
RewriteRule ^(.*)$$1 [R,L]

Redirect a Specific Folder Only

Use this to redirect HTTP to HTTPS for a particular folder:

RewriteEngine On
RewriteCond %{SERVER_PORT} 80
RewriteCond %{REQUEST_URI} yourfolder
RewriteRule ^(.*)$$1 [R,L]

How To Setup HTTP to HTTPS redirection using Plesk Onyx

You can avoid manual modifications of .htaccess using the power of Plesk Onyx UI. To setup HTTP to HTTPS redirect you need valid and functioning SSL certificate on your website. The rest is about 5 easy steps:

  1. Log in to Plesk and click Websites & Domains in the left sidebar
  2. Choose the domain to configure and click Hosting Settings
  3. Select SSL/TLS support and Permanent SEO-safe 301 redirect from HTTP to HTTPS checkboxes under Security
  4. Select corresponding SSL certificate from the Certificate drop-down list
  5. Confirm changes by clicking OK button

From this moment your site is using a secure connection for all web page requests