.htaccess

The .htaccess file, and what it controls

What the .htaccess file is, when the server reads it, and the handful of rules most sites actually use — redirects, HTTPS, error pages and access.

Ben Johnson · last checked 2026-09-21 · 4 min read

The .htaccess file is a small settings file that the Apache web server reads on every request. It sits in a folder and applies to that folder and everything under it. Almost all shared hosting runs Apache, which is why this one file controls so much of what a site does. This page is the map of what you put in it.

It is powerful and unforgiving in equal measure. A correct line can force HTTPS for your whole site in one stroke. A line with a typo can take the entire site down with a 500 error until you fix it. Both are normal. The trick is to change one thing at a time and to keep a copy of the version that worked.

The rules most sites use

You will never use most of what .htaccess can do. Four jobs cover almost everything a normal site needs.

Redirects. Send an old address to a new one so links and search results keep working. This is the most common use, and getting the difference between a temporary and a permanent redirect right matters for search. The full set of patterns is in .htaccess redirects.

Force HTTPS. Once you have a certificate, a short rule sends every visitor to the secure version. That rule, and where it must go relative to other rules, is covered in force HTTPS.

Custom error pages. Replace the blank browser error with your own page, so a mistyped address shows something useful instead of a dead end. See custom 404 page, including the one setting people get wrong that quietly hurts search.

Access and files. Block a folder, stop a directory listing, or protect a page with a password. These are smaller jobs, but they are where .htaccess earns its keep on a shared server.

Why order and syntax matter so much

Apache reads the file top to bottom and some rules must come before others. A redirect placed after the rule that would have caught it never runs. This is why a rule that looks right can do nothing: it is in the wrong place, not wrong in itself.

Syntax is just as strict. A missing bracket or a stray character does not fail quietly. It fails the whole file, and every page under that folder returns a 500 error until the file is valid again. This sounds alarming and is not, as long as you did the one thing below.

One caveat before you start: .htaccess is an Apache feature. If your site runs on Nginx, or on a static host, or behind a platform that does its own routing, the file is simply ignored and none of these rules do anything. Most shared hosting is Apache, so this usually applies. But if a correct-looking rule has no effect at all, confirm what web server you are actually on before assuming the rule is wrong.

The habit that makes it safe

Before you edit .htaccess, copy the current contents somewhere. If your change breaks the site, paste the old version back and you are live again in seconds. If you would rather not hand-write the rules at all, the .htaccess generator builds the common ones for you, correctly formatted, so there is nothing to mistype.

A wrong rule can also cause a redirect that points at itself, which the browser reports as ERR_TOO_MANY_REDIRECTS. That page covers how to spot the loop and back it out.

Everything .htaccess controls, in order

If you are setting up a fresh site, the sensible sequence is:

1. Save a copy of any existing .htaccess before touching it.
2. Add your redirects for any addresses that have changed.
3. Add the force-HTTPS rule once your certificate works.
4. Set your custom error page.
5. Test the site after each change, not all at once, so a 500 tells you exactly which line to fix.

That is the whole file’s job for a normal site. Each step links to its how-to, and the copy you saved in step one is your undo button. Work in small edits and the file stays friendly; paste in a long block of rules you found online all at once, and a single bad line among them will take the site down with no clue which one it was.