WordPress .htaccess File Corrupted: How a Single File Takes Down Your Entire Site

Why .htaccess is the most dangerous file on your server

The .htaccess file is not a WordPress file. It is an Apache server configuration file that WordPress happens to use. Every time someone requests any URL on your site — a page, an image, a stylesheet, a font file — Apache reads the .htaccess file first, processes its rules, and then decides what to do with the request. WordPress uses it primarily for permalink rewrites: turning human-readable URLs like /about-us/ into the actual PHP request that WordPress processes behind the scenes.

But .htaccess does far more than permalinks. Security plugins write firewall rules into it. Caching plugins write browser caching directives. Redirect plugins write rewrite rules. SSL plugins force HTTPS redirects. Performance plugins add compression rules. Your hosting provider might inject their own rules for server-level caching or security. By the time a busy WordPress site has been running for a year, the .htaccess file can contain hundreds of lines from a dozen different sources — and none of them know about each other.

The file has no syntax validation. No linting. No error checking before it goes live. When a plugin writes a bad rule, or when you make a typo during a manual edit, or when a file transfer corrupts a character — Apache does not warn you. It does not fall back to a safe default. It reads the broken file, cannot parse it, and returns a 500 Internal Server Error on every single request. Your entire site is down because of one bad line in one file.

How plugins corrupt .htaccess

Most .htaccess corruption is caused by WordPress plugins that write directly to the file. This is standard behaviour — WordPress provides APIs for plugins to modify .htaccess, and hundreds of plugins use them. The problem is that these write operations can go wrong in several ways.

Conflicting rewrite rules

Two plugins both add rewrite rules that match the same URL pattern. Apache processes rewrite rules sequentially. When two rules conflict, the request can enter an infinite rewrite loop (which Apache detects and terminates with a 500 error), get rewritten to a non-existent file (404 or 500), or match the wrong rule and serve the wrong content. Security plugins and SEO plugins are common culprits because both want to control URL redirects and access rules.

Interrupted write operations

A plugin starts writing to .htaccess and the process is interrupted — the server times out, the user navigates away from the settings page, or PHP hits its memory limit mid-write. The result is a partially written file: some rules are complete, some are cut off mid-line, and closing tags or brackets are missing. Apache cannot parse the incomplete file and returns 500 on everything.

Plugin deactivation not cleaning up

A security plugin adds complex rewrite rules to .htaccess. You deactivate the plugin, but the plugin does not remove its rules from .htaccess (many do not). Later, a WordPress or Apache update changes how those directives are interpreted. Rules that worked before now cause syntax errors. The plugin is no longer installed, so you have no way to manage or remove its rules through the WordPress dashboard — you have to manually edit the file.

Manual edit typos that kill your site

You need to add a redirect. Or a security header. Or an IP block. You open .htaccess in your hosting file manager or FTP client, add the rule, and save. One typo — a missing closing bracket, an extra space where Apache does not expect one, a directive name misspelled — and your site is down. You might not even realise the file saved with the error because the hosting file manager does not validate .htaccess syntax.

Common manual edit mistakes that cause 500 errors:

• Missing </IfModule> closing tag after adding a rule inside an <IfModule> block
• Typo in a directive name: RewriteRulr instead of RewriteRule
• Missing space between the rewrite pattern and the replacement URL
• Using Windows-style line endings (CRLF) instead of Unix line endings (LF) — some Apache configurations reject CRLF
• Pasting rules from a web page that includes invisible Unicode characters (smart quotes, zero-width spaces, em dashes instead of hyphens)
• Adding a directive that requires a module that is not enabled on your server (like mod_deflate or mod_expires without an IfModule check)

Encoding issues from file transfer

You download .htaccess via FTP to edit it locally. You open it in a text editor on Windows, make your changes, save it, and upload it back. The file now has Windows-style line endings (CRLF instead of LF). Depending on your Apache configuration, this can cause parsing errors. Or your text editor adds a BOM (Byte Order Mark) at the beginning of the file — an invisible three-byte sequence that Apache does not expect and cannot handle.

Or worse: you open the file in a word processor instead of a plain text editor. The word processor silently converts straight quotes to curly quotes, hyphens to em dashes, and spaces to non-breaking spaces. These characters look identical on screen but are completely different to Apache. A rewrite rule with a curly quote instead of a straight quote is a syntax error. A directive with a non-breaking space instead of a regular space is a syntax error. And you will stare at the file for an hour without seeing the problem because the characters look the same.

Always edit .htaccess with a plain text editor that shows invisible characters. Notepad++ on Windows, VS Code, or nano on Linux. Never use a word processor. Always save with Unix line endings (LF). Always save as UTF-8 without BOM.

How to regenerate .htaccess when your site is down

When .htaccess is corrupted and your site is returning 500 errors, you cannot access wp-admin because wp-admin is part of your site — it is also returning 500. You need to fix the file at the server level.

Step 1: Access your server via FTP or file manager

Use your hosting provider's file manager (usually in cPanel or Plesk) or connect via FTP using FileZilla or similar. Navigate to your WordPress root directory — the folder that contains wp-config.php, wp-content/, and wp-admin/.

Step 2: Rename the corrupted .htaccess

Rename .htaccess to .htaccess-broken. Do not delete it — you might need to reference the old rules later. The moment you rename it, Apache no longer reads it, and your site should start responding again. Pages will load, but your permalinks might not work correctly because the rewrite rules are gone.

Step 3: Regenerate .htaccess from WordPress

Now that your site is accessible again, log into wp-admin. Go to Settings > Permalinks. Do not change anything. Simply click Save Changes. WordPress will write a fresh .htaccess file with the correct rewrite rules for your current permalink structure. Your permalinks will start working again.

Step 4: Re-add custom rules carefully

Open the old .htaccess-broken file and identify any custom rules you had — redirects, security headers, caching directives, IP blocks. Add them back one at a time, testing your site after each addition. If a specific rule causes the 500 error to return, that rule is the problem. The WordPress documentation provides the default .htaccess rewrite rules for reference if you need to verify your base configuration.

Step 5: Let plugins regenerate their rules

Go into each plugin that writes to .htaccess — your security plugin, caching plugin, SEO plugin — and re-save their settings. This triggers each plugin to re-write its rules to the fresh .htaccess file. Do them one at a time, checking the site after each, so you can identify which plugin writes the problematic rule if the error returns.

How Uptrue HTTP monitoring catches .htaccess errors instantly

A corrupted .htaccess file causes a 500 Internal Server Error on every request. This is one of the easiest failures for HTTP monitoring to detect — but only if you have monitoring in place before it happens. Here is how to set up Uptrue to catch .htaccess errors the moment they occur.

Step 1: Set up HTTP monitoring

1. Sign up at uptrue.io/signup (free plan available)
2. Click Add Monitor from your dashboard
3. Select HTTP/HTTPS as the monitor type
4. Enter your homepage URL
5. Set expected status to 200
6. Set the check interval to 1 minute
7. Configure alerts — Slack, email, or Microsoft Teams

When .htaccess is corrupted, Uptrue's check receives a 500 status code instead of the expected 200. Uptrue performs a confirmation check from a secondary region to eliminate false positives. If the second check also returns 500, you receive an alert immediately. You know your site is down before any visitor has time to contact you.

Step 2: Monitor wp-admin separately

1. Click Add Monitor again
2. Select HTTP/HTTPS
3. Enter your wp-admin URL: https://yourdomain.com/wp-login.php
4. Set expected status to 200
5. Set the interval to 5 minutes

While a full .htaccess corruption takes down everything (including wp-admin), some .htaccess issues only affect specific URL patterns. A bad redirect rule might break your frontend while leaving wp-admin accessible, or vice versa. Monitoring both gives you complete visibility.

Step 3: Add keyword monitoring for partial failures

1. Click Add Monitor
2. Select Keyword as the monitor type
3. Enter your homepage URL
4. Set the keyword to a visible heading or text on your page
5. Set alert condition to keyword NOT found
6. Set the interval to 5 minutes

Some .htaccess errors do not cause a 500 — they cause incorrect redirects, serve the wrong page, or strip content. Keyword monitoring catches these subtle failures that HTTP status code monitoring misses.

Step 4: Configure alerts for fast response

• Slack — instant notification when the site returns 500
• Email — written record with timestamp and response details
• Microsoft Teams — visibility for the operations team
• Webhook — trigger automated incident response

Preventing .htaccess corruption

Back up .htaccess before every change

Before you install a new plugin, update a security plugin, or manually edit .htaccess, download a copy. Name it with the date: .htaccess-2026-03-28-backup. If the change breaks the file, you can restore the backup in seconds instead of trying to regenerate and re-add all your custom rules.

Use IfModule wrappers for every directive

Always wrap directives in <IfModule> checks so they only execute if the required Apache module is loaded:

<IfModule mod_rewrite.c> around all rewrite rules. <IfModule mod_deflate.c> around compression rules. <IfModule mod_expires.c> around caching rules. Without these wrappers, a directive that references an uninstalled module causes a 500 error.

Test after every plugin activation

After activating or updating any plugin that modifies .htaccess — security plugins, caching plugins, redirect plugins, SEO plugins — immediately test your site in an incognito window. Do not wait. Do not assume it worked. Check the homepage, an inner page, and wp-admin. If anything returns a 500, deactivate the plugin immediately and check .htaccess for conflicting rules.

Audit .htaccess regularly

Every few months, open your .htaccess file and read through it. Remove rules from plugins you no longer use. Consolidate duplicate rules. Remove commented-out blocks that are no longer relevant. A clean .htaccess file is less likely to develop conflicts and easier to debug when something goes wrong.

The fix takes two minutes — finding the problem takes hours

Renaming .htaccess and regenerating it from WordPress takes less than two minutes. The actual fix is trivial. The problem is not the fix — it is knowing that .htaccess is the cause. A 500 Internal Server Error from a corrupted .htaccess looks identical to a 500 from a PHP fatal error, a database connection failure, or a server misconfiguration. Without checking .htaccess specifically, you might spend hours debugging PHP code, restarting services, and checking database connections while the answer is sitting in a hidden file in your root directory.

Uptrue HTTP monitoring does not tell you that your .htaccess is corrupted — it tells you that your site is returning 500 errors, within a minute of it happening. That early alert is the difference between two minutes of downtime (rename the file, regenerate, done) and two hours of downtime (notice from a customer, start debugging, check PHP logs, check database, finally check .htaccess, fix it).

Frequently asked questions