Note: This is a guest post by my buddy Claude.ai, who helped me figure this out and agreed to write it up as a blog post for me. All credit where credit is due… Click here for a reference-card version
By Claude Sonnet, Anthropic — based on a real debugging session with the sites you’re already reading this on
If you manage a WordPress site on cPanel hosting and your redirects have mysteriously stopped working, or your .htaccess file looks like it was written by several drunk people arguing over a keyboard, this post is for you.
This isn’t a theoretical tutorial. It’s a post-mortem of an actual broken site, with two real .htaccess files as evidence. The short version of what happened: two security plugins were fighting each other, and the redirects got caught in the crossfire. The longer version is worth understanding, because it will happen again on any WordPress site that isn’t set up correctly — including yours.
First: What Is .htaccess and Why Should You Care?
The .htaccess file is a configuration file that lives in the root directory of your WordPress site. Apache — the web server software that most cPanel hosting runs on — reads this file and follows its instructions every time someone visits your site.
It controls things like:
- Redirects — sending a visitor from one URL to another
- HTTPS enforcement — forcing all traffic to the secure version of your site
- Security rules — blocking specific IP addresses, preventing directory browsing, protecting sensitive files
- WordPress permalinks — the rewrite rules that make your pretty URLs work instead of returning 404 errors
The critical thing to understand is that .htaccess is processed top to bottom, and certain instructions can tell Apache to stop reading and act immediately. If something near the top of the file says “stop here,” nothing below it will ever run. This is the trap.
Who Writes to .htaccess?
This is where the chaos begins, because on a typical WordPress site, multiple things write to .htaccess automatically, and none of them coordinate with the others:
WordPress itself writes a block between # BEGIN WordPress and # END WordPress markers. This contains the rewrite rules that make permalinks work. WordPress regenerates this block whenever you save your Permalinks settings.
cPanel’s Redirects tool appends redirect rules when you use the graphical redirect manager in your hosting dashboard. It just tacks them on — it doesn’t check what’s already there or whether the ordering makes sense.
Security plugins write their own blocks, usually marked with their own # BEGIN and # END comments. Some plugins are well-behaved and only touch their own section. Others are aggressive and rewrite large portions of the file whenever they feel like it.
cPanel itself also writes PHP configuration blocks (the # BEGIN cPanel-generated sections) that you should never touch.
The result, on a site that’s been running for a few years with a few plugins installed and changed, is a file that looks like sedimentary rock — layers of stuff deposited at different times by different forces, some of it contradicting other parts, some of it left over from plugins that were uninstalled years ago.
The Two-Plugin Problem
Here’s the specific thing that broke the redirects on the sites I was debugging.
Both sites were running two security plugins simultaneously — one was Really Simple Security (formerly Really Simple SSL), and the other was either Shield Security or Solid Security (formerly iThemes Security). Running two security plugins at the same time is almost always a mistake, for the same reason you don’t want two people editing the same document at the same time without talking to each other.
Each plugin writes its rules to .htaccess. Each plugin, when it updates or when WordPress does something that triggers a file rewrite, may overwrite or reorder what it finds there. The result is a file where the sections end up in an order that breaks things.
Here’s what the broken file looked like, in simplified form:
# BEGIN Really Simple Security
RewriteEngine on
RewriteRule ^(.*)$ https://%{HTTP_HOST}/$1 [R=301,L] ← THE TRAP
# END Really Simple Security
# BEGIN WordPress
(empty — nothing here)
# END WordPress
RewriteRule ^Seasons2025$ "https://www.example.com/?page_id=68851" [R=301,L]
RewriteRule ^Seasons2024$ "https://www.example.com/?page_id=65856" [R=301,L]See the [R=301,L] on the Really Simple Security rule? That L flag means “Last — stop processing rules after this one.” Every single HTTP request coming into the site hits that rule, gets redirected to HTTPS, and Apache stops reading. The custom redirects below it are never reached. They might as well not exist.
This is why adding new redirects through cPanel’s Redirects dashboard appeared to do nothing — cPanel was correctly writing the rules to the file, but the rules were being written below the trap.
The Second Site: A Different Symptom, Same Disease
The second site I looked at had the same two-plugin setup but a different outcome. Its .htaccess file was structured more sensibly — the Really Simple Security HTTPS rule came after the WordPress block, and the custom redirects came after that. So the redirects were probably working fine.
But that file had a different problem: bloat. Solid Security had been banning malicious IP addresses over time and writing each ban to .htaccess. By the time I saw the file, there were 45 banned IP addresses — each one listed three times in one format for compatibility with older Apache, and again in another format for newer Apache. That’s one security plugin contributing nearly 300 lines of IP ban rules to the file, and it will keep growing indefinitely.
This illustrates a broader principle: .htaccess files on WordPress sites accumulate cruft, and nobody ever cleans them out. The file becomes a graveyard of old rules from old plugins, duplicate entries, and orphaned directives.
The Fix: Clean File, Clear Ownership, One Plugin
Here’s how to get to a stable, maintainable state.
Step 1: Pick One Security Plugin and Remove the Other
If you’re running two security plugins, stop. Pick one and fully delete the other — not just deactivate, but delete it entirely from the Plugins menu. Deactivated plugins can still leave their .htaccess rules behind.
For most small to medium WordPress sites, Wordfence (free version) is the right choice. It’s the most widely used WordPress security plugin, has a robust free tier, is well-maintained, and is generally well-behaved about .htaccess — it only writes to its own marked section and leaves everything else alone.
If your main reason for running Really Simple Security was HTTPS enforcement, you don’t need a plugin for that. The HTTPS redirect is a single rule you can put directly in .htaccess yourself (see below), and cPanel/Let’s Encrypt handles the actual SSL certificate.
Step 2: Understand the Sections and Their Order
A clean, correctly ordered .htaccess for a WordPress site on cPanel should look like this, from top to bottom:
- Security plugin block (e.g., Wordfence) — firewall rules, IP blocks
- HTTPS redirect rule — force all traffic to HTTPS
- Your custom redirects — the ones you actually care about
- WordPress block — permalink rewrite rules (
# BEGIN WordPress/# END WordPress) - cPanel PHP configuration — the auto-generated blocks you never touch
This ordering is important. With pretty permalinks enabled, the WordPress block contains a catch-all rule (RewriteRule . /index.php [L]) that grabs any URL that isn’t a real file or directory on disk. Your redirect targets are never real files or directories, so if your custom redirects are below the WordPress block, WordPress intercepts every request first and returns a 404 before your redirects ever fire. They silently do nothing.
Custom redirects above the WordPress block work correctly regardless of whether you’re using plain or pretty permalinks.
The HTTPS rule needs to come before your custom redirects but must not use the [L] flag in a way that swallows everything else. Here’s a safe version:
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTPS} !=on
RewriteCond %{REQUEST_URI} !^/\.well-known/acme-challenge/
RewriteRule ^(.*)$ https://%{HTTP_HOST}/$1 [R=301,L]
</IfModule>This is fine because the [L] flag here only fires for HTTP requests — if the request is already HTTPS, the RewriteCond above it fails and processing continues normally to the rules below.
Step 3: Don’t Use the cPanel Redirects Dashboard
I know it’s tempting — it’s right there in the interface and seems like the easy way. But the cPanel Redirects tool appends rules to .htaccess without any awareness of rule ordering. It will drop your redirects wherever it feels like, which may be after a rule that stops processing.
Instead, add your redirects directly to .htaccess using cPanel File Manager. Open the file, find your custom redirects section (above the WordPress block), and add your rules there. It takes about thirty seconds once you know the syntax:
RewriteCond %{HTTP_HOST} ^.*$
RewriteRule ^YourShortcut$ "https://www.yoursite.com/?page_id=12345" [R=301,L]Replace YourShortcut with the short URL path you want (e.g., Birds to make yoursite.com/Birds redirect somewhere), and replace the destination URL with wherever you want it to go.
Step 4: Let Wordfence Write First, Then Add Your Rules
After you install Wordfence, let it do its initial setup. It will write its block to .htaccess. Then open the file in File Manager and add your custom redirects above the WordPress block. That way you’re building around what’s already there rather than having Wordfence overwrite what you wrote.
Step 5: Don’t Use the cPanel Redirects Dashboard (I’m Saying It Twice)
Seriously. Once you’ve manually set up your redirects in the file, if you later use the cPanel Redirects tool, it will append duplicate rules in the wrong place and you’ll be back where you started.
A Note on “Plain” Permalinks
If your WordPress site is set to Settings → Permalinks → Plain (the default, where URLs look like ?p=123), the WordPress block in .htaccess will be empty — just the markers with nothing between them. This is normal and correct. Plain permalinks don’t need rewrite rules because Apache handles query strings natively. The empty block is not a bug.
Custom redirects still belong above the WordPress block regardless of permalink setting. It’s the safe universal position.
Quick Reference: The .htaccess Cheat Sheet
Who writes what:
| Section | Written by | Touch it? |
|---|---|---|
# BEGIN [Security Plugin] |
Your security plugin | No — let the plugin manage it |
| HTTPS redirect | You, or Really Simple Security | Yes — own this yourself |
# BEGIN WordPress / # END WordPress |
WordPress | No — regenerate via Permalinks save |
| Custom redirects | You, or cPanel Redirects | Yes — manage these in File Manager |
# BEGIN cPanel-generated |
cPanel | Never |
Rule of thumb for ordering: Security → HTTPS → Your redirects → WordPress → cPanel
When something breaks:
- Open
.htaccessin File Manager and look at the order of sections - Check whether any rule near the top has
[L]and is catching all traffic - Make sure your custom redirects are above the WordPress block
- Check whether you have two security plugins installed
When you add a new redirect:
- Use File Manager, not the cPanel Redirects dashboard
- Add it in the custom redirects section, above
# BEGIN WordPress - Test it immediately after saving
What This Doesn’t Cover
This post is specifically about Apache/cPanel hosting. If your host uses Nginx instead of Apache, .htaccess files don’t apply at all — Nginx uses a completely different configuration system that you usually can’t edit directly on shared hosting. In that case, use a plugin like Redirection to manage redirects from within WordPress instead.
It also doesn’t cover WordPress Multisite, which has its own .htaccess requirements, or situations where the file permissions on .htaccess are wrong (should be 644 on most hosts).
The Bigger Lesson
The .htaccess file is one of those things that works fine until it doesn’t, and when it doesn’t, the failure mode is invisible — your redirects just silently do nothing, with no error message to tell you why. The root cause is almost always that multiple things are writing to the same file without coordination, and the ordering ended up wrong.
The fix isn’t complicated, but it requires understanding what the file actually does and taking deliberate ownership of it rather than letting plugins and cPanel tools manage it by committee.
Once you’ve got a clean, correctly ordered file and a single security plugin that knows its lane, it stays fixed. These aren’t the kind of problems that recur on their own — they recur because the conditions that caused them (too many plugins writing to the same file, using the cPanel Redirects tool) are still in place.
Clean it up once, manage it deliberately going forward, and you won’t have to think about it again.
Claude Sonnet is an AI assistant made by Anthropic. This post was written based on a real debugging session analyzing .htaccess files from two WordPress sites running on cPanel hosting. The author does not have a tractor and cannot help you fix yours.
