Published on
What .htaccess is - and where it lives
.htaccess is a text file with instructions for the web server. It lives in your domain's document root, usually in httpdocs, and applies to this directory and everything below it. Changes take effect immediately - no restart is needed.
The name starts with a dot, which is why many programs treat it as a hidden file. In the Plesk file manager, it is visible; in FileZilla, you may first have to show hidden files. If none exists yet, simply create a new one.
Take a copy before every change.
A typo in .htaccess brings the entire site down with a 500 Internal Server Error - immediately and for everyone. Download the file first or copy it in the file manager; then the previous state is restored in ten seconds.
301 or 302 - the difference matters
Every redirect carries a status code that tells search engines how to handle it:
| Code | Meaning | When |
|---|---|---|
| 301 | moved permanently | The normal case: relaunch, new address structure, domain change. The old address's ranking passes to the new one. |
| 302 | temporary | Only for real interim solutions - maintenance page, time-limited promotion. The old address stays in the index. |
The most common mistake in a relaunch is a 302 instead of a 301. Search engines then keep the old addresses in the index and do not transfer the ranking that has been built up - the new site practically starts from zero. So when in doubt, always R=301.
Unify www and HTTPS
A site should be reachable under exactly one address. If there are four - with and without www, with and without HTTPS - the ranking is spread across several variants of the same page.
From www to the variant without www:
RewriteEngine On
RewriteCond %{HTTP_HOST} ^www\.(.+)$ [NC]
RewriteRule ^(.*)$ https://%1/$1 [R=301,L]
The other way round, to the www variant:
RewriteEngine On
RewriteCond %{HTTP_HOST} !^www\. [NC]
RewriteCond %{HTTPS} on
RewriteRule ^(.*)$ https://www.%{HTTP_HOST}/$1 [R=301,L]
Which variant you choose does not matter - the main thing is that you decide on one and stick with it. Then also enter it as the site address in the CMS, otherwise the two work against each other.
Better to enforce HTTPS in Plesk.
For redirecting HTTP to HTTPS, Plesk has a setting for a permanent redirect for the domain. Use it instead of your own rule - and then only it. If HTTPS is enforced at the same time in Plesk, in .htaccess and in the CMS, the classic redirect loop results, see Set up an SSL certificate.
Redirect individual pages after a relaunch
If the address structure changes in a relaunch, every old address needs a target. For individual pages, the simple form is enough:
Redirect 301 /old-page.html /new-page/
Redirect 301 /products/old-product /products/new-product/
For a whole directory including subpages:
RedirectMatch 301 ^/blog/(.*)$ /magazine/$1
And for a domain change where the paths stay the same:
RewriteEngine On
RewriteCond %{HTTP_HOST} ^old-domain\.com$ [NC]
RewriteRule ^(.*)$ https://new-domain.com/$1 [R=301,L]
Do not redirect everything to the home page across the board. Anyone who was looking for a specific subpage and lands on the home page instead usually leaves again - and search engines rate such catch-all redirects similarly to an error page. Every old address belongs on its matching counterpart in terms of content. When moving a whole site, the redirects are part of the process described in Migrate a website.
Further useful rules
Custom error pages:
ErrorDocument 404 /errors/404.html
ErrorDocument 403 /errors/403.html
Switch off directory listing. Without an index file, the server otherwise shows the content of a directory:
Options -Indexes
Block a single file. Useful for backups or configuration files that ended up in the web directory by mistake:
<Files "secret.txt">
Require all denied
</Files>
For real password protection of a directory, it is better to use directory protection in Plesk - it creates the necessary files itself and manages the users without you maintaining password files by hand.
Typical mistakes
- 500 Internal Server Error right after saving. A syntax error - usually a missing bracket, a typo in a directive or a rule this server does not know. Restore the copy and go through the change line by line.
- Redirect loop. Two places redirect against each other, such as Plesk to HTTPS and .htaccess back to HTTP. Exactly one place may handle the redirect.
- The rule does not take effect. The order matters: directives are processed from top to bottom, and
[L]ends processing. If your rule is below a block that already ends it, it is never reached. - WordPress rules overwritten. WordPress manages its own block between
# BEGIN WordPressand# END WordPress. Your own rules belong above it - inside the block, they are removed the next time the permalinks are saved. - The change seemingly has no effect. Browsers stubbornly remember 301 redirects. Test with a private window or another browser before you keep tweaking the rule.
- Encoding of the file. Save .htaccess without a byte order mark. Some editors set it automatically, which leads to 500 errors that are hard to track down.
Browser caching for faster delivery is also set via .htaccess - the rules for it are in Speed up your website.
Frequently asked questions
Full control over delivery
On the web hosting, your own .htaccess rules take effect - for redirects, error pages and access protection. Everything is managed via Plesk, without a command line.
View web hosting plans & pricesRent web hosting
from €1.99 / month
Prepaid without a contract, Plesk included, hosted in Frankfurt am Main.
View plans & pricesRead more
- Web hosting - plans & prices
- Set up an SSL certificate
- Connect a domain
- Set up FTP access
- Migrate a website
- Fix WordPress errors
Discover more