Skip to content

SiteRepairManual

WordPress repairs run on a throwaway install before they are written down.

Fix a 500 error from a corrupt .htaccess file in WordPress

Checked 11 November 2026 · WordPress 7.1.4 · PHP 8.3.6 · MariaDB 10.11.14 · Apache 2.4.58 + PHP-FPM · WP-CLI · Read time: 6 minutes

Case file

Symptom
Every page returns HTTP 500 after a bad .htaccess edit
Cause
An invalid directive in .htaccess — Apache refuses the whole file
Fix
Restore a clean .htaccess, or delete it and re-save permalinks
Result
Homepage and posts return HTTP 200

The break · What you need · The diagnosis · The fix · Verify · If that didn’t work · What happened · Where this came from

The break

.htaccess is Apache's per-directory configuration file, and WordPress uses it to make pretty permalinks work — the rewrite rules that turn /hello-world/ into a post live there. Apache reads the file on every request, so one bad line in it breaks every page at once, not just one post. A mistyped directive, a rule copied from another server, or a plugin's bad addition are the usual ways it happens.

This guide reproduces the break first. A disposable install running Apache 2.4.58 with PHP-FPM had one invalid directive added inside the WordPress block. The homepage and a post both went from HTTP 200 to HTTP 500, and Apache answered with its own stock 500 page — no WordPress page at all, because Apache refuses the request before WordPress ever runs.

What you need

The diagnosis

1. Confirm the symptom

Load the homepage and a post and note the status codes. In the reproduction, both returned HTTP 500, and the body was Apache's stock error page:

Output — homepage with the corrupt .htaccess

HTTP 500
<title>500 Internal Server Error</title>
<h1>Internal Server Error</h1>
<p>The server encountered an internal error or
misconfiguration and was unable to complete
your request.</p>

Key result: every page fails, including the homepage, and the page is Apache's own error page rather than a WordPress page. That combination points at the server configuration, not at a plugin or a post — and the first suspect is .htaccess.

2. Read the Apache error log

The log names the exact bad line, so you do not have to guess which edit broke it. In the reproduction, one line per request said:

Output — Apache error log

[core:alert] /path/to/site/.htaccess: Invalid command
'ThisIsNotAValidDirective', perhaps misspelled or defined
by a module not included in the server configuration

That is the whole diagnosis: the file has a directive Apache does not recognise, and Apache refuses the entire file. If the log says something else — a PHP fatal error, a permissions error — the cause is not .htaccess, and this guide is not the fix.

Key result: the log names the file and the bad directive. Fix the file and the site comes back; nothing else needs changing.

The fix

3. Restore a clean .htaccess

The fastest fix is a known-good file. Rename the corrupt one out of the way first, so you keep it for reference, then restore the backup — or paste the stock WordPress block, which the official .htaccess documentation gives as the file to restore a corrupted one with:

Command — rename the corrupt file, restore the backup

mv .htaccess .htaccess_bad
cp .htaccess.clean-bak .htaccess

Code — the stock WordPress block, if you have no backup

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

In the reproduction, restoring the clean file brought the homepage and the post back at once: both HTTP 200, with no other change.

4. Or delete it and re-save permalinks

If you have no backup, delete the file and let WordPress write a new one. The official common-errors guide gives this as the fix: rename .htaccess to .htaccess_old, check the site loads, then visit Settings > Permalinks and save — the save generates a new .htaccess for you.

Command — move the corrupt file out of the way

mv .htaccess .htaccess_old

With no .htaccess at all, the reproduction showed a split result: the homepage returned HTTP 200 — it needs no rewrite rules — but the post returned HTTP 404, because pretty permalinks need the rules to reach the post. That split is expected, and it is the proof the file was the problem: the 500 is gone, only the permalinks are missing.

Trap: the permalinks save silently does nothing if the site root is not writable by the web server. The reproduction proved it: the first save in wp-admin reported success, but no .htaccess appeared and the post stayed at 404 — WordPress only writes the file when the directory is writable by PHP. Check that first, with the owner and permissions of the site root, and make it writable by the web server user (on a VPS that is often www-data) — or ask the host to. In the reproduction the fix was chgrp www-data plus chmod 775 on the site root; the next save wrote a 523-byte .htaccess owned by www-data, and the post returned HTTP 200.

Do not try to regenerate the file with WP-CLI instead: wp rewrite flush --hard cannot write .htaccess from the command line, because WordPress checks for the Apache module with a function that does not exist under CLI or PHP-FPM. The wp-admin save works because the server identifies itself as Apache. Use the dashboard save.

Verify the site is back

Load the homepage and a post and check both status codes — the post matters, because the homepage loads even without the rewrite rules. In the reproduction:

StepHomepage statusPost status
Corrupt .htaccessHTTP 500HTTP 500
After restoring a clean fileHTTP 200HTTP 200
No .htaccess at allHTTP 200HTTP 404
After re-saving permalinksHTTP 200HTTP 200

If that didn’t work

If the 500 stays after a clean .htaccess

Then .htaccess was not the cause. Read the error log again: if it no longer mentions .htaccess, the problem is elsewhere — a plugin, the theme, or file permissions. The official guide's next steps for a 500 are deactivating all plugins and switching to a default theme, which are separate repairs.

If permalinks still 404 after regenerating

Check that Apache's mod_rewrite is enabled — the official guide notes it may not be enabled by default, and without it the rewrite rules in the new file do nothing. On shared hosting that is the host's setting to change.

What happened

One invalid directive in .htaccess made Apache refuse the whole file, so every page returned HTTP 500 with Apache's own error page. The error log named the exact bad line. Restoring a clean .htaccess brought the site back at once; separately, deleting the file and re-saving permalinks regenerated it — but only after the site root was made writable by the web server, because the first save silently wrote nothing.

Where this came from