.htaccess Hacked: Finding and Fixing Malicious Redirect Rules

By Glenn Lyvers · Updated July 16, 2026 · 6 min read

When your .htaccess file is hacked, attackers have added rewrite rules that redirect your visitors somewhere else — usually spam, scams, or malware downloads. The nasty part is that the rules are often written to fire only for visitors arriving from Google, or only for mobile users, so when you type your address into the browser, the site looks perfectly fine. And cleaning the one file you know about usually isn't enough, because attackers scatter copies through your folders.

I see hacked .htaccess files constantly. It's one of the first places I look on any cleanup, and one of the most common reasons a site owner tells me "my customers say the site redirects them, but it works for me."

What .htaccess actually does

On most WordPress hosting, .htaccess is a configuration file the web server reads before serving anything. It controls how URLs map to files, and it can redirect, block, or rewrite any request. That power is exactly why attackers love it. Two or three lines in this file can hijack every visitor to your site without touching a single page of content.

The file starts with a dot, which means it's hidden by default in many file managers and FTP clients. Plenty of owners have never seen it. Turn on "show hidden files" and it's sitting right in your site root.

Why the redirect doesn't happen for you

Attackers don't want you to notice, so the injected rules are conditional. The pattern I find over and over checks where the visitor came from: if the referrer is a search engine, redirect; if not, serve the normal site. You visit your own site directly, so you never trip the rule. Your customers click a Google result and land on a pharmacy page.

Other variations key off the device (mobile users get redirected, desktop doesn't), the time of day, or whether the visitor has been redirected before, using a cookie. Some rules do the opposite of redirecting: they block security scanners and search-engine crawlers by user-agent, to keep the infection off the radar longer.

So test the way your visitors arrive. Search for your site on Google and click the listing, ideally from a phone, in a private window. If that redirects while a direct visit doesn't, you've found the behavior. My indicators guide covers more of these cloaking tricks.

What healthy looks like, and what injected looks like

A standard WordPress .htaccess is short and recognizable. It's the block that begins with # BEGIN WordPress and ends with # END WordPress, containing a handful of rewrite lines that send pretty URLs to index.php. On a typical site, that block plus maybe some caching or security lines added by a plugin is the whole file.

Injected rules look different once you know the shape. A defanged example of the kind of thing I pull out of infected files:

RewriteCond %{HTTP_REFERER} (google|bing|yahoo) [NC] followed by RewriteRule ^(.*)$ http://bad-domain-example/go.php?q=$1 [R=302,L]

A condition that mentions search engines by name, followed by a redirect to a domain you've never heard of. Also watch for: rules that route requests through a strange local file like wp-content/uploads/x.php, a wall of blank lines pushing code below the visible window (attackers pad hundreds of empty lines so the file looks normal when you open it — scroll all the way down), and ErrorDocument lines pointing 404s at an unfamiliar script.

The trap: there's never just one file

.htaccess files apply to their folder and everything beneath it, and the server honors every one it finds along the path. Attackers know this, so they drop copies in wp-content, wp-includes, the uploads folders, theme folders, sometimes twenty or thirty of them. I cleaned a site last year with malicious .htaccess files in over forty directories. The owner had fixed the root file three times and couldn't understand why the redirect kept coming back.

So the job is never "fix the file." It's "find every one of them." On a cleanup I list every .htaccess across the whole account and read each one. Legitimate ones do exist in subfolders (some plugins add protective rules to uploads, for example), which is why I read them instead of mass-deleting.

Other symptoms a poisoned .htaccess causes

Redirects get the headlines, but a tampered .htaccess shows up in stranger ways too. A malformed injected rule can take the whole site down with a "500 Internal Server Error" — if your site died at the same moment weird rules appeared, the file is the first suspect, and it's one of the few hacks that accidentally announces itself. Redirect loops ("this page redirected you too many times") are another classic, usually from two injected rules fighting each other or a rule colliding with your SSL redirect.

I've also seen injected rules that lock the owner out of wp-admin by IP, rules that silently disable a security plugin by blocking its files, and AddHandler lines that make the server execute image files as PHP — which turns an innocent-looking "photo" in your uploads folder into a live backdoor. That last one matters: if you find an AddHandler or SetHandler line you didn't add, treat every file in that folder as suspect.

One caveat while you're checking: not every unfamiliar line is malicious. Caching plugins, security plugins, and hosts add legitimate blocks, usually fenced with their own BEGIN/END comments. When in doubt, search the exact line — the legitimate ones are documented all over the web. The malicious ones tend to search-return either nothing or a malware writeup.

Worth knowing: if your host runs Nginx rather than Apache or LiteSpeed, .htaccess does nothing at all — so this whole attack class doesn't apply, and a redirect on an Nginx site means the malware lives somewhere else, usually in PHP or the database.

Cleaning it, and keeping it clean

Replacing the root file with the standard WordPress block gets your site behaving again, and for a stressed owner that's a fine first move. Keep a copy of the infected version first — it's evidence, and the redirect target sometimes helps identify the malware family.

But understand what you've done: you've treated a symptom. Something wrote those rules, and it can write them again tonight. The writer is usually a PHP backdoor elsewhere in the account, which is a separate hunt I've described in my piece on WordPress backdoor removal. Until that's gone, the .htaccess will keep regenerating, and owners end up in the loop I describe in why sites keep getting reinfected.

After the real cleanup, it's reasonable to tighten permissions on .htaccess so casual writes fail, and to put the site under monitoring so a regenerated file triggers an alert instead of a customer complaint.

If the redirect has already earned you a warning screen in browsers or a "this site may harm your computer" label, that's a blacklist problem stacked on top of the hack — my blacklist removal service handles that side. And if you'd rather someone else read forty rewrite files this week, hand it to me. Finding these is genuinely my idea of a good morning.

Common questions

How do I know if my .htaccess file is hacked?

Open it (turn on hidden files first) and compare it to the standard WordPress block that starts with # BEGIN WordPress. Rules that mention search engines in a RewriteCond, redirects to domains you don't recognize, hundreds of blank padding lines, or references to PHP files in uploads are all strong signs of injection. Also check subfolders — attackers plant copies.

Why does my site redirect visitors from Google but not me?

The injected rules are conditional. They check the visitor's referrer and only redirect people arriving from search engines, sometimes only on mobile. You visit your site directly, so you never trigger the rule. Test by clicking your own Google listing from a phone in a private browsing window.

Can I just delete the .htaccess file?

On most WordPress sites you can delete it and WordPress will regenerate a clean one when you re-save permalinks, though pretty URLs may 404 until you do. That fixes the symptom. It does not remove whatever wrote the malicious rules, so expect them to return until the underlying backdoor is found and removed.

Why do the malicious redirect rules keep coming back?

Because a separate piece of malware, usually a PHP backdoor somewhere in your account, rewrites the file automatically. Some strains check every few minutes. Cleaning .htaccess without finding that backdoor is like mopping under a leaking pipe. The file is the symptom; the writer is the disease.

Where else should I look for hacked .htaccess files besides the site root?

Everywhere. Common spots are wp-content, wp-includes, every uploads subfolder, and inside theme and plugin directories. The server honors every .htaccess along a request's path, so one overlooked copy can keep the redirect alive. List all of them across the account and read each one before deciding what stays.