.htaccess internal server error

Symptoms

Every page or a whole directory returns 500 Internal Server Error at once. The site works on other hosts or devices, then breaks the moment a .htaccess file is present. The error can appear after a copy-paste of rules from a snippet site, a plugin that wrote a rule, or a move between hosts with different modules.

Why a .htaccess error is a full-page failure

Apache parses .htaccess on every request before serving the file. A single bad line, a syntax error in a rewrite condition, a missing module, or a directive not allowed in per-directory context makes Apache refuse the whole block, and the request dies as an internal server error before any of your site code runs. That is why a one-line typo can take the homepage and the admin down at once.

The most common causes

• Syntax error: a mismatched RewriteRule flag, an unclosed IfModule, or a directive Apache does not know in this context. The error log names the line.
• An unsupported method: a condition that depends on a module the host does not load, or a directive that only works in a vhost while the host runs a shared config.
• Permission problem: Require all granted (or the reverse) blocks the directory, or the .htaccess itself has permissions Apache refuses, producing a 500 or a 403.
• A rewrite that loops or recurses: a rule matching its own output so the request stack overflows into a 500, very similar to the loop article.
• Trailing newline or encoding: an invisible byte, a UTF-8 BOM, or a stray carriage return at the top of the file can make Apache refuse the whole thing. The fix is to rewrite the file, not edit it in place.

Diagnose in order

1. Rename the file out of the way. The fastest test: mv .htaccess .htaccess.bak. If the site comes back, .htaccess is the cause.
2. Read the error log. Apache writes the exact line and reason one request at a time. The message says "unknown directive" or names the file line.
3. Test the syntax.

# Apache syntax check, where the host gives you a shell
apachectl -t

Most shared hosts do not expose that. Instead use a trustworthy syntax checker and keep the previous working version to diff.

1. Restore from a backup, then reapply the intended edit in a small isolated copy and retest. The one-line change that broke it is usually the diff, and so the answer.
2. Rebuild the file deliberately, especially after any editor that might have added a byte-order mark: create it as a plain ASCII file in a plain editor or with the host's own editor.

Retest correctly

The moment the page loads, do not declare victory yet: check the redirect shape against the 301 redirect plus the redirect map article, then verify that every path using the rule behaves. One of the quiet bugs is a 500 that only fires on a deep path while the homepage looks fine.

When to involve a professional

If the host strips or re-enables the file on restart, or the error repeats after a clean rewrite, the web server is a step beyond the file: modules, per-directory permissions, AllowOverride and the vhost policy decide what your .htaccess is even allowed to do. There is no shortcut from 500 to "done"; the 500 article lists the other server-side causes when the .htaccess is not the culprit.