WordPress Errors

Corrupt .htaccess File (WordPress Repair)

Intermediate Risk: medium

Last reviewed August 7, 2026

Hosting access often needed Database access usually not needed

Direct answer

A corrupt or broken `.htaccess` file breaks Apache rewrite rules WordPress depends on, which usually shows up as sitewide 500 errors, 403 Forbidden, post/page 404s with a working homepage, or redirect loops. Rename the damaged file out of the way, confirm the site loads, then re-save Permalinks in wp-admin so WordPress writes a fresh default block — and only re-add custom redirects afterward, one rule at a time.

On Apache (and many LiteSpeed) hosts, WordPress stores pretty-permalink rewrite rules in a root `.htaccess` file. Bad edits, plugin hardening snippets, incomplete migrations, or truncated uploads can leave that file invalid so the server fails requests before PHP runs. This WordPress Repair guide shows how to isolate the bad file safely, regenerate WordPress defaults, and restore custom rules without locking the site again.

Intermediate

Key facts

Verifiable numbers and definitions — each claim links to its source.

Apache documents .htaccess as a per-directory configuration file the server reads when AllowOverride permits it for that path. (Apache .htaccess howto)
WordPress documents the default Apache rewrite rules it expects in .htaccess for pretty permalinks on httpd. (WordPress httpd / .htaccess)
WordPress permalinks documentation explains that saving Settings → Permalinks regenerates the WordPress rewrite block when the root is writable. (Using Permalinks)

What the error means

`.htaccess` is a per-directory Apache configuration file. WordPress writes a `# BEGIN WordPress` … `# END WordPress` block that sends non-file requests to `index.php` so pretty permalinks work. Anything else in the file — HTTPS force redirects, www canonicalization, security Deny/Require lines, cache rules, or malware — is evaluated by the web server on every request. A single syntax error, an unfinished `IfModule` block, a recursive redirect, or a blanket deny can produce 500 Internal Server Error, 403 Forbidden, ERR_TOO_MANY_REDIRECTS, or “pretty URL” 404s while `index.php?p=123` still works. The file is not the WordPress database; renaming it does not delete posts, but it does remove custom redirects until you restore them carefully.

Common symptoms

Homepage loads (or shows a host error page) while posts and pages return 404
Browser or host page shows 500 Internal Server Error after an `.htaccess` edit
403 Forbidden across the site or only on certain paths right after security hardening
ERR_TOO_MANY_REDIRECTS or endless HTTP↔HTTPS / www↔non-www bouncing
Error log mentions AH00124, rewrite, or “.htaccess: Invalid command”
wp-admin is unreachable or redirects oddly while static files still load
Problem started immediately after a redirect plugin, “security” snippet, or host migration

Most likely causes

01 Manual edit that left a syntax error, truncated line, or unmatched directive
02 Redirect or security plugin writing conflicting RewriteRule / RewriteCond blocks
03 Hardening snippets (`Deny from all`, bad `Require`, wrong `RewriteBase`) pasted without testing
04 Migration or restore that copied an old domain’s redirects or wrong `RewriteBase`
05 Malware injecting redirect or backdoor rules into `.htaccess`
06 File truncated or zero-byte after a failed File Manager upload or disk-quota issue
07 Custom HTTPS/www redirects fighting Cloudflare, host SSL, or WordPress siteurl/home

What changed before the problem started

Someone edited `.htaccess` in File Manager, FTP, or a “quick redirect” tutorial
A security, cache, or redirect plugin was installed or updated
Site was migrated or restored from a backup that included old rewrite rules
Hosting panel “force HTTPS,” hotlink protection, or directory privacy rules were toggled
Malware cleanup or infection that rewrote root config files
Permalink structure changed while the file was not writable, leaving a partial update

Troubleshooting steps

01
Download a backup of the current `.htaccess` first
In File Manager or FTP, open the WordPress document root (same folder as `wp-config.php` and `index.php`). Download `.htaccess` to your computer before changing anything. If the site is down, this copy is how you recover custom redirects later.
02
Rename `.htaccess` instead of deleting it
Rename the file to something like `.htaccess.bak` or `htaccess-broken.txt`. Do not chmod the whole tree. After the rename, reload the homepage and a pretty permalink URL. If errors clear, the damaged file was the cause.
03
Confirm the homepage and a post URL behave as expected
With the bad file aside, the homepage often works on “plain” permalinks even if pretty URLs 404. That is expected until WordPress regenerates rules. If the site is still fully down, the problem is elsewhere (PHP fatal, DNS, host suspension) — do not keep editing rewrites blindly.
04
Re-save Permalinks to write a fresh WordPress block
Log into wp-admin → Settings → Permalinks. Leave the structure as-is (or choose your intended structure) and click Save Changes once. WordPress recreates the default `# BEGIN WordPress` rewrite block when the root is writable. If WordPress shows rules to paste manually, create a new `.htaccess` with only those rules.
05
Warn and inventory custom redirects before restoring them
Open your `.htaccess.bak` and list every non-WordPress block: domain redirects, HTTPS forces, www rules, security denies, cache headers, and malware-looking RewriteRules. Do not paste the whole backup back in one shot — custom redirects are the most common way a “fixed” site immediately loops or 403s again.
06
Re-add custom rules one block at a time and retest
Add one logical block below (or above, only if required) the WordPress markers, save, and test homepage, a post, wp-admin, and HTTPS. Prefer redirect plugins or host SSL tools for HTTPS/www when possible so WordPress can keep owning its rewrite block.

Download a backup of the current `.htaccess` first

In File Manager or FTP, open the WordPress document root (same folder as `wp-config.php` and `index.php`). Download `.htaccess` to your computer before changing anything. If the site is down, this copy is how you recover custom redirects later.

Rename `.htaccess` instead of deleting it

Rename the file to something like `.htaccess.bak` or `htaccess-broken.txt`. Do not chmod the whole tree. After the rename, reload the homepage and a pretty permalink URL. If errors clear, the damaged file was the cause.

Confirm the homepage and a post URL behave as expected

With the bad file aside, the homepage often works on “plain” permalinks even if pretty URLs 404. That is expected until WordPress regenerates rules. If the site is still fully down, the problem is elsewhere (PHP fatal, DNS, host suspension) — do not keep editing rewrites blindly.

Re-save Permalinks to write a fresh WordPress block

Log into wp-admin → Settings → Permalinks. Leave the structure as-is (or choose your intended structure) and click Save Changes once. WordPress recreates the default `# BEGIN WordPress` rewrite block when the root is writable. If WordPress shows rules to paste manually, create a new `.htaccess` with only those rules.

Warn and inventory custom redirects before restoring them

Open your `.htaccess.bak` and list every non-WordPress block: domain redirects, HTTPS forces, www rules, security denies, cache headers, and malware-looking RewriteRules. Do not paste the whole backup back in one shot — custom redirects are the most common way a “fixed” site immediately loops or 403s again.

Re-add custom rules one block at a time and retest

Add one logical block below (or above, only if required) the WordPress markers, save, and test homepage, a post, wp-admin, and HTTPS. Prefer redirect plugins or host SSL tools for HTTPS/www when possible so WordPress can keep owning its rewrite block.

When to stop troubleshooting

Escalate if renaming `.htaccess` does not change symptoms, you cannot reach File Manager/FTP or wp-admin, redirect loops continue after a clean WordPress-only file, logs point to ModSecurity or a host WAF instead of rewrite syntax, or custom redirect rules are business-critical and you are unsure which block is safe to restore. A bad deny rule can lock recovery paths — hand off before mass-editing production config.

Information to collect before requesting help

01 Exact browser/host error (500, 403, 404 on posts, redirect loop) and affected URLs
02 Copy of the current/broken `.htaccess` contents
03 Whether renaming `.htaccess` improved or changed the symptom
04 Recent edits, plugin installs, migrations, or “force HTTPS” changes
05 Hosting type (cPanel, Plesk, managed WP) and whether Cloudflare is proxied
06 Whether wp-admin is reachable and Permalinks can be saved
07 Apache/LiteSpeed error-log lines around the failure time

How a professional repairs the problem

A technician backs up and removes the broken `.htaccess`, confirms the outage is rewrite-related rather than PHP or DNS, regenerates WordPress’s default permalink rules, then reconstructs needed custom redirects surgically while testing homepage, posts, admin, and HTTPS. They check for malware injections, fix `RewriteBase` after migrations, and leave a known-good copy plus notes so the next edit does not recreate the outage.

Frequently asked questions

Will renaming `.htaccess` delete my content? +

No. Posts, pages, and media live in the database and uploads folder. Renaming only changes how the web server routes URLs until WordPress writes a new file.

Why do posts 404 after I rename `.htaccess`? +

Pretty permalinks need rewrite rules. Without `.htaccess`, Apache may not send those URLs to WordPress. Saving Permalinks recreates the default rules so post URLs work again.

Should I copy a full `.htaccess` from a tutorial site? +

Avoid megasnippets. Start with WordPress’s generated block only, then add the specific redirect or security lines you actually need, testing after each change.

Can a corrupt `.htaccess` cause a WordPress critical error screen? +

Usually no — critical errors are PHP fatals. `.htaccess` problems show as server status codes (500/403/404) or redirect loops before WordPress runs. You can still see both if a plugin and rewrites fail together.

What about nginx hosts with no `.htaccess`? +

nginx ignores `.htaccess`. Permalink issues there are server-block rewrite rules or host panel equivalents. This guide applies to Apache/LiteSpeed-style setups that honor `.htaccess`.

How do I keep custom redirects from breaking the site again? +

Keep a dated backup of working rules, put custom blocks outside the WordPress markers, and never paste HTTPS/www redirects that duplicate what Cloudflare or the host SSL tool already does.

Repair dispatch

Still Need Help Fixing Your Website?

If you are not comfortable editing website files, changing server settings, repairing a database, or troubleshooting a live website, professional help may prevent additional damage or downtime. We will review the problem before accepting the repair.

You will receive a clear explanation of the likely cause.
We will tell you if the issue falls outside our repair scope.
No additional work will be performed without approval.
A backup should be created whenever access and website condition allow it.

Emergency repair Request diagnosis

Do not share passwords through an unencrypted contact form — use Password Pusher (self-destructing link). Prefer a dedicated Rescue 404 admin account, not your personal owner login; if you cannot create one yet, we will add ours after repair.