The .htaccess file tells the server how to handle requests before WordPress sees them. A single malformed line takes down everything. It also accumulates: caching plugins, security plugins, redirect plugins and migrations all write to it, often without removing what they added last time. Repairing it means keeping what is needed and dropping what is not.
Before you buy, a word of caution
The common advice is to rename .htaccess and let WordPress write a fresh one. That does work, and it also silently discards every custom rule the file contained — redirects, security rules, caching directives, and anything a previous developer added.
If the file is short and you can read it, take a copy first. If it is long, or you are not sure what is in it, leave it alone. Recovering rules nobody kept a record of is much harder than fixing the file.
Corrupted .htaccess repair
A broken .htaccess rule is stopping the site from serving. We repair it, keep the rules that matter, and remove what is conflicting.
- Full backup taken before we start
- If we can’t fix it, you get your money back
- We never ask for your own password
This or something else?
| 500 error and .htaccess was recently changed | This fix covers it |
| 500 with no server config change | HTTP 500 internal server error |
| Inner pages 404, homepage fine | Permalink repair |
| Redirect loops after an SSL change | Too many redirects after SSL change |
| Site runs on nginx, not Apache | Server configuration — still covered |
What you are seeing
- A 500 error across the whole site, often right after a plugin change
- Or 404s on every page except the homepage
- It may have started after installing a caching or security plugin
- Removing the file fixes it but breaks redirects or caching
Common causes
- A malformed rule written by a plugin, or by two plugins at once
- Duplicate rewrite blocks from repeated plugin installs
- Rules referencing an Apache module the server does not have enabled
- Directives left behind by a plugin that was removed
- A migration copying rules from a server with different capabilities
What we do
- Take a full backup, including the current .htaccess, before touching anything
- Test the file in isolation to confirm it is the cause
- Read every rule and identify which are needed, which are duplicated, which are broken
- Rebuild the file with the necessary rules and correct syntax
- Verify redirects, caching and security rules still behave as intended
- Load-test the front end, the admin, and any custom routes
What is included
- A working .htaccess with the rules you actually need
- A copy of the original, kept for 30 days
- A note listing what was removed and why
- Redirects and caching verified rather than assumed
Not included
- Recreating rules that were lost before we were involved and have no record
- Full redirect map rebuilds, which are a separate service
- Server configuration on hosts that do not use .htaccess and give no equivalent access
- Design changes or content work
Questions about this fix
Can I not just delete it?
You can, and WordPress will write a basic replacement that gets the site loading. What that discards is every custom rule the file held — redirects from an old URL structure, security rules, caching directives. Those often only reveal themselves as missing weeks later.
How does it get broken in the first place?
Usually more than one plugin writing to it. Each adds a block, and if one is removed carelessly or two write at once, the syntax breaks. It is one of the few files in WordPress that several plugins all edit.
My site runs on nginx. Does this apply?
The file itself does not exist there, but the equivalent problem does — nginx rules live in server configuration instead. We handle both; the diagnosis is the same and only the location changes.
Will you keep my redirects?
Yes, that is most of the point. We read every rule before rebuilding rather than starting from a blank file, and the note tells you exactly what was kept and what was dropped.
Can you tell which plugin added a specific rule?
Often, yes — most plugins mark their own sections with a comment. Rules with no such marker usually came from a developer by hand or a plugin that's since been removed, and we note which is which in what we send back.
Related fixes
If this is the second time this year
A bad update breaking the site is a symptom of updates not being tested first. Care plans run every update on a staging clone before it reaches your live site, which is the actual fix for this happening again.
Your access, your rules
Create a separate admin account for us and delete it when we are done. For anything else, we get in touch and agree a method — never a form field on this site, never by reply to an email.
We back up first, always
Before anything is touched we take a full backup and keep it for 30 days. If a fix goes wrong, we put the site back exactly as it was.
If it is not what you bought
If the problem turns out smaller than what you ordered, we refund the difference. If it is bigger, we stop and send a quote before doing any extra work.
If we cannot fix it
You get back what we received. Diagnosis is on us — you only pay when the problem is actually solved. The payment processor takes its fee before the money reaches us, so we never hold it and it is not ours to return. That is true here as everywhere else.
If it comes back
Reply within seven days of delivery and we put it back on the bench at no cost. The fix is not finished until it holds.
What we are responsible for
If something goes wrong with a fix, our responsibility is limited to what you paid for it. We take a full backup first so mistakes can be undone, and we tell you before doing anything outside what you bought.