How to fix a broken .htaccess file

The site was working, you (or a plugin) edited .htaccess, and now every page on it returns a 500 Internal Server Error. This is one of the most reliable ways to take a whole site offline in a single keystroke, because Apache reads .htaccess fresh on every single request — there's no "save and it might work later"; a broken rule fails immediately and fails everywhere at once.

The good news is that this is also one of the fastest problems to fix, because the file is small, it's yours to edit directly, and the fix is almost always a matter of finding one bad line rather than rebuilding anything.

Confirm this is actually the cause

Rename, don't delete, so you can put it straight back if this isn't the problem:

1. Open your file manager

   Navigate to the folder containing the broken site — usually public_html. If you can't see .htaccess, turn on hidden files; a leading dot hides it by default.

2. Rename it

   Change it to something like .htaccess-broken. This removes it from Apache's view without losing its contents.

3. Reload the site

   If it comes back, .htaccess was the cause and you can move on to finding the specific bad line. If nothing changes, rename it back and look elsewhere — you've ruled this out cleanly.

Finding the actual bad line

Check the error log first — it often names the exact directive that failed:

Invalid command 'RewriteEngine', perhaps misspelled or defined by a module
not included in the server configuration

That specific message means a module the rule depends on — mod_rewrite in this example — isn't available or enabled. Other common messages point at a genuine typo, an unclosed bracket, or a directive that doesn't exist at all.

If the log doesn't make it obvious, comment sections out methodically rather than guessing at individual lines:

1. Restore the file

   Rename it back to .htaccess so you can edit it directly.

2. Comment out the bottom half

   Add a # at the start of each line in roughly the second half of the file, then reload the site.

3. Narrow down which half

   If the site now works, the problem is in the commented-out section — uncomment the top half of that section and repeat, halving the range each time until you land on the single line.

4. Fix or remove that line

   Once isolated, correct the syntax, or remove the line entirely if it turns out you don't actually need it.

Common causes worth checking first

A rule copied from a guide written for a different server

Directives that depend on a module not loaded on your server — mod_rewrite, mod_headers, mod_expires, mod_deflate — fail outright rather than being quietly ignored. If a rule was copied from elsewhere, check it against what your hosting actually supports.

An unclosed block

Blocks like <IfModule> or <FilesMatch> need a matching closing tag. A missing </IfModule> anywhere in the file is a very common, very easy to miss cause.

A plugin that wrote a bad rule automatically

Security and redirect plugins often write directly to .htaccess. A plugin update that changed its output format, or a conflict between two plugins both trying to manage the same section, can leave behind invalid or duplicated rules. Look for a block clearly marked with the plugin's name in a comment, and check it for anything obviously malformed.

Encoding or line-ending issues

A file edited on Windows and uploaded without conversion can occasionally introduce characters Apache doesn't expect. If the file looks syntactically correct line by line but still fails, try recreating it in a plain text editor rather than one that might be adding hidden formatting.

Rebuilding cleanly on WordPress

If the site is WordPress and you'd rather not hunt through the file, you can let WordPress regenerate the section it controls: back up the current file, delete it, then go to Settings > Permalinks in wp-admin and click Save. WordPress writes a fresh, valid default block automatically. Any custom rules you had beyond WordPress's own — redirects, security restrictions — will need to be added back afterwards.

If you can't isolate it

Send support the full contents of the file along with the exact error log entry. That's usually enough to spot the invalid line immediately, without needing to work through the halving process yourself.