.htaccess is a plain-text config file that Apache-compatible web servers read on every request to the folder it sits in (and every folder below it). No restart, no rebuild: edit the file, save it, the next request picks up the change. On shared hosting it's the main lever you have for URL rewriting, redirects, access control, and per-directory server settings without touching the main server config.
The fix for most ".htaccess isn't working" problems is one of three things: the file isn't in the right directory, a directive is misspelled or unsupported, or a syntax error earlier in the file is causing the server to ignore everything after it (or return a 500). Start there before assuming the feature itself is broken.
Where it lives and how it's read
Place .htaccess in public_html/ to affect your whole site, or in a subdirectory to scope rules to just that folder. Rules cascade: a directive in a parent directory applies to child directories too, unless a child's own .htaccess overrides it. The leading dot makes it a hidden file, so if you're not seeing it in an FTP client or file manager, turn on "show hidden files."
Comment lines start with #. A typo in a directive name, or a rule that references a module that isn't loaded, can cause a 500 Internal Server Error for the whole directory, not just a warning. Edit with a backup copy saved, and test in a private browser window since redirect rules get cached hard.
Redirects
The two directives you'll use constantly:
Redirect(mod_alias) for simple one-to-one redirects.RewriteRule(mod_rewrite) for pattern-based redirects using regular expressions.
Simple single-page redirect:
Redirect 301 /old-page.html /new-page.html
Redirect an entire old domain path to a new one, preserving whatever comes after:
RewriteEngine On
RewriteRule ^old-folder/(.*)$ /new-folder/$1 [L,R=301]
Always use R=301 for permanent moves, not R=302. Search engines cache 301s and transfer ranking signals to the new URL; a 302 tells them the move is temporary and they'll keep indexing the old one. If you're setting up redirects as part of a broader move (domain change, restructure, or consolidating pages), it's worth reviewing all of them together rather than adding one-offs as you notice broken links.
Forcing HTTPS
If you only need HTTP traffic to redirect to HTTPS, don't hand-roll it: check forcing HTTPS on your site first, since managed plans handle this automatically and there's a toggle in cPanel for accounts that predate that default. The .htaccess version is for edge cases where you need more control than the toggle gives you:
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
Put this block near the top of the file, before other rewrite rules, so it fires first. If your site still shows "Not Secure" after adding this, it's almost always mixed content (HTTP images, scripts, or stylesheets loading on an HTTPS page), which the linked article covers in more depth.
Blocking access
Block a single IP address:
Require not ip 203.0.113.5
Password-protect a directory (pair with a separate .htpasswd file outside public_html/ for the actual credentials):
AuthType Basic
AuthName "Restricted area"
AuthUserFile /home/username/.htpasswd
Require valid-user
Block direct access to a specific file type, useful for keeping raw .log or .sql files out of reach if they ever end up in a web-accessible folder:
Require all denied
These directory- and file-level rules are one layer. They don't replace a web application firewall watching for exploit patterns across the whole site, which is a different job, and one we run at the server level.
Custom error pages
Point specific HTTP status codes at your own pages instead of the server default:
ErrorDocument 404 /errors/not-found.html
ErrorDocument 500 /errors/server-error.html
The path is relative to your document root. Use a full page, not a bare message fragment, and keep the file small and dependency-free: if the error page itself fails to load (broken image path, missing CSS), visitors see a blank screen instead of a helpful one. Test each code directly by requesting a URL you know doesn't exist, rather than trusting that the directive "looks right."
When to open a ticket
A syntax error that 500s your whole site, a rewrite rule that loops and won't resolve, or password-protection that's locking out legitimate visitors are worth escalating rather than debugging live. Open a ticket from Support → New ticket in the portal, or use live chat. Real people look at the actual file and server logs, which is faster than guessing blind from a copy-pasted rule.