.htaccess Repair Generator

On Apache and LiteSpeed servers, .htaccess is read on every request before PHP runs. WordPress uses it for exactly one essential job: rewriting pretty permalinks so that a request for /about/ is handed to index.php instead of returning a 404 for a directory that does not exist. Everything else in the file, from caching headers to redirects to security rules, has been added by plugins or by hand. That is why a corrupted .htaccess produces symptoms that look nothing like each other: 404s on every post while the homepage works, a redirect loop, a 500 error across the whole site, or downloads that suddenly serve as plain text.

The file is invisible by default in most FTP clients and file managers because the leading dot marks it hidden, so the first step is usually to enable 'show hidden files'. It lives in the WordPress root, next to wp-config.php and wp-load.php. Sites running Nginx have no .htaccess at all; the equivalent rules live in a server config file you cannot edit yourself, which is why permalink fixes on Nginx go through the host rather than through a file edit.

Always download a copy before you change anything. The safest repair is to rename the existing file to htaccess-old rather than deleting it, then let WordPress write a clean one by visiting Settings, Permalinks and clicking Save without changing any option. That regenerates only the core WordPress block and nothing else, which immediately tells you whether the fault was in core rules or in something a plugin added.

If the site recovers with a clean file, open the old copy and reintroduce the custom rules a block at a time, reloading after each one. Rules added by caching and security plugins are usually rewritten automatically when you resave that plugin's settings, so in many cases you do not need to copy them back manually at all. Keep custom rules outside the BEGIN WordPress and END WordPress markers, because WordPress rewrites everything between those markers whenever permalinks are saved and your additions will disappear.

Redirect rules are the most common source of self-inflicted outages. A rule forcing HTTPS combined with a host-level rule doing the same thing produces an infinite loop, and so does a www-to-non-www rule pointing at a domain that redirects back. If your site loops, comment out every redirect line by adding a hash at the start, confirm the loop stops, then add them back one at a time.

Two other patterns are worth checking. Blocking access to xmlrpc.php or wp-login.php is reasonable security, but it breaks the mobile app, Jetpack and some payment callbacks, so make sure you actually know what depends on those endpoints. And any directive belonging to a module the server does not have loaded will produce an immediate 500 for the entire site; wrapping such blocks in an IfModule condition means the server skips them safely instead of refusing to serve anything.