Skip to content
Rescue 404
Rescue

Website Security

WordPress Website Redirects to Spam

Intermediate Risk: high

Last reviewed

Hosting access may not be needed Database access usually not needed

Direct answer

When WordPress sends visitors (or only Googlebot / mobile users) to spam or scam domains, treat it as malware: preserve evidence, find the redirect in `.htaccess`, injected JS, rogue plugins, or the database, restore clean code, rotate credentials, and verify with a logged-out browser before you chase SEO recovery.

Spam redirects are a high-intent compromise pattern: customers land on pharma, phishing, or “congratulations” pages instead of your brand. The redirect may be conditional — desktop fine, phone poisoned — so a quick glance at the homepage can miss it. This WordPress Repair guide walks a safe cleanup path focused on locating and removing redirect payloads, distinct from broader “site hacked” or file-malware checklists.

Intermediate

Key facts

Verifiable numbers and definitions — each claim links to its source.

  • WordPress flags unauthorized redirects and visible hacked content as Indicators of Compromise that belong in an incident report before cleanup. (FAQ My Site Was Hacked)
  • Official remediations call out .htaccess as a frequent abuse target for redirects and other malicious rewrite rules at the site root. (FAQ My Site Was Hacked)
  • After cleanup, WordPress directs owners to hardening measures so the same access path cannot reinfect the site. (Hardening WordPress)
  • Google documents Dangerous Search labeling when Safe Browsing detects malware or social-engineering issues on a site. (Google — site labeled dangerous)

What the error means

Attackers inject redirects because they monetize stolen traffic. Common homes include `.htaccess` RewriteRules, malicious JavaScript in themes or `wp_options`, spam plugins created overnight, and database fields that only fire for certain user-agents or geo targets. Fixing the symptom means removing every redirect source and the backdoor that rewrites it after you “fix” once. Rescue 404 prioritizes visitor safety and credential rotation; we do not publish exploit recipes or instruct anyone to reuse attacker scripts.

Common symptoms

  • Homepage or inner pages bounce to unrelated spam, phishing, or adult domains
  • Redirect happens only on mobile, certain countries, or for Googlebot — desktop owners see a normal site
  • Search results show foreign spam titles/URLs under your domain
  • Browser or security tools warn that the site is deceptive or forwarding to malware
  • Unknown plugins, mu-plugins, or `.htaccess` rules appeared without your approval
  • Affiliates and ads report landing-page mismatches or sudden bounce spikes
  • Logged-in admins see the real site while logged-out visitors get redirected

Most likely causes

  1. 01 Malicious `.htaccess` or nginx rules forcing external redirects
  2. 02 JavaScript or meta-refresh injected into headers, footer widgets, or post content
  3. 03 Compromised or nulled plugin/theme dropping conditional redirect code
  4. 04 Database `siteurl` / `home` or option rows pointing at attacker domains
  5. 05 Rogue admin user or stolen credentials installing redirect malware
  6. 06 Cached CDN/edge rules still serving an old malicious redirect after file cleanup
  7. 07 Infected neighboring site on shared hosting rewriting your document root rules

What changed before the problem started

  • Customers or ads partners reported “your site sends me elsewhere”
  • Google Search Console security or hacked-content alerts arrived
  • New plugin installed or files changed around the first redirect reports
  • Staff password reuse or shared SFTP credentials were exposed
  • CDN/cache purge was skipped after a partial cleanup attempt
  • Traffic analytics show abrupt exits to unknown external hosts

Troubleshooting steps

  1. 01

    Confirm the redirect as a logged-out visitor

    Open the site in a private window (and on a phone if reports are mobile-only). Note the exact destination URL and whether it fires on `/`, a specific page, or after a delay. Do not click through phishing pages — stop at the first hop if possible. Success signal: you have a reproducible path and destination domain written down.

  2. 02

    Contain and preserve before deleting

    Put the site in maintenance or ask the host to block public traffic if visitors are being phished. Download a full file+database forensic copy labeled with the date. Reset passwords on admins you still control. Success signal: archive secured offline and unauthorized logins blocked.

  3. 03

    Inspect `.htaccess`, nginx rules, and DNS-level forwards

    Restore a clean `.htaccess` from a pre-incident backup or default WordPress rules if malware RewriteRules send traffic out. Check host panel redirects and CDN page rules for attacker domains. Success signal: server/edge config no longer references the spam host.

  4. 04

    Remove redirect malware from code and plugins

    Reinstall core and replace plugins/themes from official sources. Delete unknown plugins and mu-plugins. Search theme headers/footers and `wp-content` for the spam domain string — quarantine matches rather than executing them. Success signal: grep/scan no longer finds the destination domain in active code.

  5. 05

    Clean database redirect injections

    Verify Settings → General site URL values. Search options, widgets, and post content for the spam domain; export the DB first and use serialization-safe edits. Success signal: logged-out browse no longer redirects after a cache purge.

  6. 06

    Rotate credentials, purge caches, harden, then review

    Change panel, SFTP, WordPress, database, and CDN credentials. Purge all layers of cache. Enable 2FA, remove unused extensions, and submit Google Security issues review if warnings appeared. Success signal: multiple devices show your real site and scanners stay clean.

When to stop troubleshooting

Stop DIY work if redirects return after each cleanup, you cannot find the conditional trigger, ecommerce checkout traffic is being phished, or database/CDN layers are outside your skill set. Hand Rescue 404 the forensic archive, destination spam URLs, device/user-agent notes, and admin access list — spam redirects burn trust and ad spend by the hour.

Information to collect before requesting help

  • 01 Exact spam destination URLs and which pages trigger them
  • 02 Whether desktop, mobile, or only certain networks are affected
  • 03 Screenshots of the redirect or browser warning
  • 04 First customer/ad report date and any Search Console emails
  • 05 Whether a pre-incident backup exists
  • 06 CDN/hosting provider and recent plugin changes
  • 07 List of users with wp-admin or SFTP access

How a professional repairs the problem

Rescue 404 reproduces the redirect safely, archives the infected state, and removes server, code, and database redirect sources while rotating credentials. We purge CDN/cache layers, verify logged-out and mobile paths, close the entry point that rewrote `.htaccess` or options, and help with Google review when Safe Browsing or Search Console flagged the domain — oriented to getting revenue traffic back on your real pages.

Frequently asked questions

Why do I still see my real site while customers get spam? +
Many redirect kits skip logged-in users, specific IPs, or desktop browsers. Always test logged-out and on mobile before declaring the site clean.
Is this just an SEO “spammy redirect” penalty? +
Search penalties and malware redirects can both exist, but sudden hops to pharma/phishing domains are almost always a compromise. Clean the infection first; then address Search Console manual actions if any remain.
Can I fix it by changing the WordPress site URL only? +
Only if `home`/`siteurl` were altered. Most spam redirects live in `.htaccess`, JS injections, or plugins — changing Settings alone will not stop those.
Will clearing the cache fix a spam redirect? +
Cache purge is required after cleanup so visitors stop seeing old malicious HTML, but purge without removing the payload only hides the problem briefly.
Should I keep running ads while the redirect is active? +
Pause paid traffic until logged-out tests are clean. Sending ad clicks to phishing pages creates chargebacks, blocked accounts, and legal risk.
When is Rescue 404 the right call? +
When every partial fix fails, redirects are conditional, or you need the storefront trustworthy again the same day without risking another poisoned deploy.

Repair dispatch

Still Need Help Fixing Your Website?

If you are not comfortable editing website files, changing server settings, repairing a database, or troubleshooting a live website, professional help may prevent additional damage or downtime. We will review the problem before accepting the repair.

  • You will receive a clear explanation of the likely cause.
  • We will tell you if the issue falls outside our repair scope.
  • No additional work will be performed without approval.
  • A backup should be created whenever access and website condition allow it.
Emergency repair Request diagnosis

Do not share passwords through an unencrypted contact form — use Password Pusher (self-destructing link). Prefer a dedicated Rescue 404 admin account, not your personal owner login; if you cannot create one yet, we will add ours after repair.

Written by Josh

Last reviewed

Platform note: Full rescue available for WordPress and self-hosted sites. Wix, Squarespace, Webflow, Weebly, and similar closed builders have very limited backend access — fixes may not be possible. I will tell you honestly before we start.