Site Suddenly Redirecting to Spam? Fix a Malicious .htaccess Hack

A customer opens their own website and, instead of their homepage, lands on a fake pharmacy store, a "you've won a prize" page, or a Japanese SEO spam site. Refreshing does nothing. Sometimes it only happens on mobile, or only when the visitor arrives from Google search results. This is almost always a malicious redirect injected somewhere in your site's files, not a DNS or hosting problem — and the fix is usually faster than people expect once you know where to look.

Symptom: What a Redirect Hack Actually Looks Like

There isn't just one version of this. The common patterns we see on cPanel accounts are:

• The whole site redirects to a spam domain for every visitor, every time.
• It only redirects visitors coming from search engines (Google, Bing) — direct visits and logged-in admins see the real site, which is why it goes unnoticed for weeks.
• It only fires on mobile user agents.
• Google Search Console shows a manual action or "Site may be hacked" warning, but the site looks fine to you.
• Random new pages appear in Google's index for your domain (viagra, replica watches, essay-writing spam) that you never created.

That last one is the giveaway: this is SEO spam injection, and the redirect is just one visible symptom of a much bigger set of planted files.

Cause: Where the Redirect Actually Lives

Attackers rarely touch DNS. It's far easier for them to plant a redirect in a file your server already trusts. In order of how often we find it:

1. .htaccess — a RewriteRule or Redirect directive added at the top or bottom of the file, often outside the WordPress # BEGIN WordPress block so it survives permalink resets.
2. wp-config.php or theme functions.php — a snippet using header('Location: ...') or a base64-encoded eval() blob that decodes to a redirect script.
3. A planted file in wp-content/uploads, a random plugin folder, or the site root — something like wp-content/uploads/2023/class.wp.php that has nothing to do with an actual plugin.
4. A compromised plugin or theme file that was auto-modified because the plugin itself was outdated and vulnerable (Slider Revolution, old page builders, and abandoned "SEO" plugins are frequent entry points).
5. A malicious cron job added via WHM/cPanel that periodically re-injects the redirect even after you clean it, which is why the hack "keeps coming back" for some customers.

The entry point is almost always one of: a weak cPanel/WordPress admin password, an outdated plugin with a known vulnerability, or leftover file permissions from a previous compromise that were never fully cleaned.

Fix: Step-by-Step Cleanup

1. Check .htaccess first

SSH or File Manager into your account and open the .htaccess file in your site's document root:

cat ~/public_html/.htaccess

Look for anything referencing an unfamiliar domain, a RewriteCond %{HTTP_USER_AGENT} block targeting "googlebot|bingbot|mobile", or a bare Redirect 301 / https://some-spam-domain.com/ line. Remove only the injected lines — leave the standard WordPress permalink block alone. If you're not sure what's original, compare against a fresh .htaccess generated from Settings > Permalinks in wp-admin (click Save once, don't type anything).

2. Search for suspicious PHP across the account

From SSH, grep for the usual obfuscation fingerprints across your whole account:

grep -rl "eval(base64_decode" ~/public_html
grep -rl "gzinflate(base64_decode" ~/public_html
grep -rl "FilesMan\|c99shell\|WSO" ~/public_html

Any hit outside of a well-known plugin/theme file is worth opening and inspecting. Genuine WordPress core files never contain eval(base64_decode(...)).

3. Diff core files against a clean copy

For WordPress specifically, WP-CLI makes this fast:

wp core verify-checksums
wp plugin verify-checksums --all

Anything flagged as modified in wp-content, wp-includes, or a plugin folder that shouldn't be touched by a normal update is a strong lead.

4. Check for a rogue cron job

In cPanel, go to Cron Jobs and look for anything you didn't create — especially entries that curl a remote URL or run a PHP file with an odd name every few minutes:

crontab -l

Delete anything unfamiliar. This step alone fixes the "cleaned it but it came back an hour later" cases.

5. Change every password touching the account

Once the files are clean, rotate the cPanel password, WordPress admin password(s), database password, and any FTP/SFTP accounts. If the original compromise came through a leaked credential, skipping this step just lets the attacker back in.

6. Update everything, then request a review

Update WordPress core, every plugin, and every theme to current versions, and remove anything inactive you don't actually use — unused plugins get exploited just as easily as active ones. If Google flagged the site, use Search Console's Security Issues tab to request a review once you've confirmed the site is clean.

Prevention: Keep It From Coming Back

• Turn on AutoSSL and force HTTPS, but more importantly keep WordPress core, plugins, and themes updated on a schedule — most of these hacks ride in through a known, already-patched vulnerability.
• Use a security scanner that runs server-side, like ImunifyAV in cPanel, so infected files get flagged even if the site "looks" fine in a browser.
• Set File Manager / SSH permissions correctly — 644 for files, 755 for directories, and never 777 anywhere in public_html.
• Remove unused plugins and themes entirely instead of just deactivating them.
• Keep at least one clean backup outside the account (WHM's remote backup destinations to S3 or similar) so you have a known-good restore point if a future cleanup gets messy.
• Use unique, strong passwords for cPanel and wp-admin, and enable two-factor authentication on both where possible.

Frequently Asked Questions

Why does the redirect only happen from Google, not when I visit directly?

Attackers deliberately check the HTTP referrer and user agent so the hack stays hidden from the site owner while still poisoning search traffic and SEO rankings. This is called cloaking, and it's the most common reason these hacks run for weeks before anyone notices.

I removed the .htaccess redirect but it came back the next day. Why?

There's almost certainly a second infected file re-writing .htaccess, or a cron job doing it on a schedule. Re-check Cron Jobs in cPanel and grep the account for recently modified files with find ~/public_html -mtime -2 -type f to catch anything still actively writing to disk.

Can this happen even if only WordPress plugins are outdated, not WordPress itself?

Yes, and it's actually the more common route in practice. Core WordPress gets patched quickly and updates itself in many cases; third-party plugins, especially free ones from abandoned repositories, are the more common entry point for these redirect injections.

Do I need to reinstall WordPress from scratch?

Usually no. A targeted cleanup — verifying core and plugin checksums, checking uploads for rogue PHP files, and cleaning .htaccess — resolves the vast majority of cases. A full reinstall is only necessary if the infection is deep enough that you can't confidently account for every modified file.

Will this affect my Google rankings permanently?

Not if you clean it up and request a review promptly. Google generally lifts manual actions and "hacked site" warnings within days of a clean re-crawl once the malicious content and redirects are gone and Search Console shows no remaining issues.