Website Redirecting to Spam? How to Stop It

If your website sends visitors to a spam, scam, or gambling site, you've almost certainly been hacked — and the redirect is hiding in one of four places: your .htaccess file, injected JavaScript, your WordPress database or a rogue plugin, or your DNS records. The fix depends entirely on which one it is, so guessing (or just reinstalling your theme) usually doesn't work.

This is for site owners — WordPress, Shopify, or a hand-built site — who've noticed weird redirects, gotten a "this site may be hacked" warning in Google, or had a customer say "your link took me somewhere sketchy." You'll get a step-by-step way to find exactly where the redirect is firing from, plus how to close it, including the sneaky version that only redirects mobile visitors or people coming from Google.

Why "website redirecting to another site" is almost always a hack, not a bug

A legitimate site doesn't randomly start sending people to pill ads, fake tech-support pages, or spam text in another language. When that happens, it's almost always malware planted after your site, a plugin, or your hosting account got compromised — commonly through a stolen FTP/hosting password, an outdated plugin with a known vulnerability, or a compromised admin account. Google's own guidance on hacked sites confirms this pattern and calls out redirect hacks specifically as a common attack type (Google Search Central: hacked sites overview).

The attacker's goal is usually SEO spam or ad fraud: they want your site's existing traffic and search ranking to funnel visitors to their pages, without you noticing for as long as possible. That's why these redirects are almost never "always on" — they're built to hide from you, the owner, while still firing for real visitors and search engines.

The 4 hiding spots, compared

Step 1: Rule out DNS first — it's the fastest check

Before you touch any files, confirm your domain is actually pointing at your own server. If your DNS was hijacked (usually via a compromised domain registrar or DNS provider account, not your website itself), no amount of file cleanup will fix it.

dig example.com A +short
dig example.com NS +short
whois example.com

Compare the A record IP against the IP your host gives you in your hosting control panel. If it doesn't match, or the nameservers (NS records) aren't the ones your registrar or DNS host assigned you, your DNS has been changed — go straight to your registrar, reset that account's password, and revert the records. This is a domain-account problem, not a website problem, so cleaning WordPress won't help.

Step 2: Check if the redirect is conditional (mobile-only or Google-only)

This is the step people miss. Many redirect hacks are deliberately conditional — they only fire for mobile users or for visitors arriving from a search engine, so the site owner checking it on a desktop browser sees nothing wrong. Test it the way an attacker built it to be tested:

# Simulate a normal visit
curl -I https://example.com

# Simulate Googlebot
curl -A "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" -I https://example.com

# Simulate someone clicking through from a Google search on mobile
curl -e "https://www.google.com/search?q=example" -A "Mozilla/5.0 (Linux; Android 10; Mobile)" -I https://example.com

Look at the response headers. If the Googlebot or Google-referrer request returns a 301 or 302 with a Location: header pointing somewhere unfamiliar, but your plain request doesn't, you've confirmed a conditional redirect — and you now know it's checking User-Agent and/or Referer, which narrows the search to .htaccess or JavaScript (the next two steps).

Also check Google Search Console's Security Issues report (Search Console → Security & Manual Actions) — Google flags this exact "cloaked redirect" pattern when it crawls your site, per their hacked-site cleanup guide.

Step 3: Search .htaccess for User-Agent or Referer rules

Open .htaccess in your site's root directory (via FTP/SFTP or your host's file manager) and look for RewriteCond lines referencing HTTP_USER_AGENT or HTTP_REFERER, especially ones mentioning "google," "bing," "yahoo," or "mobile." A legitimate rule rarely needs to check for search engine names. A malicious block often looks like this:

RewriteCond %{HTTP_REFERER} google\.com [NC,OR]
RewriteCond %{HTTP_USER_AGENT} Mobile
RewriteRule ^(.*)$ http://spam-domain.example/landing.php [R=302,L]

Delete any block you don't recognize, save, and re-run the curl tests from Step 2 to confirm it's gone. Keep a backup copy of the file before editing, in case you need to compare it later.

Step 4: Search for injected JavaScript

If .htaccess is clean but the redirect still fires (especially only on desktop, or only after a delay), the payload is likely JavaScript stuffed into a theme file, a widget, or a compromised plugin's assets. Search your theme folder for obvious obfuscation:

grep -rl "eval(" wp-content/themes/
grep -rl "base64_decode\|gzinflate\|String.fromCharCode" wp-content/themes/ wp-content/plugins/

Real theme code almost never uses eval() combined with base64_decode — that combination is a near-universal signature of injected malware, because it lets the attacker hide the real payload from casual inspection. Also check footer.php and header.php for <script> tags you didn't add. OWASP's guidance on unvalidated redirects and forwards is a good primer on why these injections work so well (OWASP Top Ten): browsers and users trust redirects that appear to come from a site they already trust.

Step 5: Check the WordPress database and plugins

If you're on WordPress, the hack often lives in the database itself, not the files. Two places to check, using WP-CLI:

1. Site URL hijack — run wp option get siteurl and wp option get home. If either points to a domain that isn't yours, that's your redirect source.
2. A rogue or disguised plugin — run wp plugin list and look for anything you don't recognize, or a "legit-looking" plugin name you never installed. Also compare your core files against the official versions with wp core verify-checksums, a built-in WP-CLI command that flags any modified core file.

Malicious code also frequently gets planted directly in the wp_posts or wp_options table as a serialized PHP snippet that runs on init. This is harder to spot by eye than a file, which is one reason a manual, human-led review tends to catch what a quick automated scan misses.

Fix checklist, in order

• [ ] Confirm DNS A/NS records match your actual host (Step 1)
• [ ] Test with curl using Googlebot and mobile User-Agents to catch conditional redirects (Step 2)
• [ ] Remove suspicious RewriteCond/RewriteRule blocks from .htaccess (Step 3)
• [ ] Grep theme/plugin files for eval(, base64_decode, and obfuscated <script> blocks (Step 4)
• [ ] Check wp option get siteurl/home and run wp core verify-checksums (Step 5)
• [ ] Change all passwords — hosting, FTP, WordPress admin, registrar — since redirects usually mean broader access was gained, not just one file
• [ ] Update every plugin, theme, and WordPress core to the latest version
• [ ] Re-check Search Console's Security Issues report after cleanup and request a review

Run our free website security check after cleanup to confirm the redirect and any related malware are actually gone, not just hidden again.

When to stop DIY-ing it

If you've been through all four checks and the redirect keeps coming back, or you're not comfortable editing .htaccess and database values on a live production site, that's the point to bring in a second pair of eyes. Automated scanners are good at flagging known malware signatures but routinely miss custom, hand-placed redirects like the ones above — that gap is exactly why manual review exists; see our comparison of manual vs. automated penetration testing for why it matters here. It's also worth reading is my website hackable to understand what let the attacker in, so you're not just cleaning the symptom and leaving the door open.

Key takeaways

• A spam redirect almost always means compromise, not a bug — and it hides in .htaccess, injected JavaScript, your WordPress database/plugins, or DNS.
• Test with curl using a Googlebot User-Agent and a Google referrer before assuming your site is clean — many redirects are deliberately conditional and invisible on a normal desktop visit.
• Rule out DNS first with dig — if the A or NS records are wrong, no file cleanup will fix it.
• eval() combined with base64_decode in theme or plugin files is a near-certain sign of injected malware.
• After cleaning up, change every password tied to the site (hosting, FTP, WordPress, registrar) — the redirect was a symptom of broader access, not an isolated glitch.

If you've gone through this checklist and still aren't fully sure it's clean — or you'd rather have someone find the exact injection point for you — Bug Circuit's Circuit audit is $49 for a human security engineer to manually trace it, document exactly what was changed and where, and hand you the precise fix. No card needed to start with the free check first.