Troubleshooting guide · website-errors · Published 2026-08-16 · 4 min read
Website redirection to spam or scam pages
Stop a website redirecting to spam or scam pages: find the injected redirect, check providers and plugins, and clean the payload.
- ·Find the redirect layer
- ·Trace the source
- ·Clean and verify
When a visitor types your domain and lands on a pharmacy page, a casino, or a fake download, the redirect is not a WordPress setting. It is injected code. The site owner usually does not see it because the redirect only fires for certain visitors: a specific referrer, a search-engine bot, a device, or an X-Forwarded-For ward. That selectivity is part of the code, and it tells you how to find the payload.
Map the layers that can redirect
A visit can jump at four levels, and the fix differs per layer:
| Layer | What fires | Signal |
|---|---|---|
| Web server | .htaccess RewriteRule, nginx return | Redirect fires for www and bare domains alike, even the homepage |
| Script | index.php include, wp-config require | Redirect fires when the CMS loads |
| Front end | Injected <script> in a page | Visitor sees it only after the page starts |
| DNS/edge | A hijacked DNS record, or provider page | The whole domain flips at once |
Trace which layer fires
- Use
curlto bypass the browser. The browser marks some scripts (like adocument.locationwriter) invisible to a live probe. Test with the headers a search engine sends:
curl -I -A "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" https://example.com/
Compare the same fetch with a plain user agent and from a different network. If the redirect only appears for the bot agent, or only for one referrer, you have a script payload that reads values.
- Open the page source. The injected script sits before your content in the HTML, or a
meta refreshin the head. Search forlocation.href,window.location,document.write, or asetTimeoutwriter. - Check the raw response body. A DNS- or panels-level redirect returns a
301/302header with the spam host, while a payload inside the page returns a200with the script inside.
Check the quiet keepers
- A plugin or theme backdoor in
wp-content: a singlerequirein a plugin'sheader.phpthat triggers only under a user agent. Reinstall plugin files clean and watch for the same line in a successor. - Data injected into the database: an
eval()inwp_optionsor awp_postsrow that echoes a second page. Use the same scan as the malware removal checklist. - A host-level rewrite injected at the control panel. The host sees the redirect in its own layer, before PHP ever runs, so web-level checks miss it. Ask the host to check
mod_rewriteon the domain.
Stop the redirect
- Cut the network first. The page redirects every visitor while it lives, so keep the site behind a maintenance notice or a redirect yourself, offline, while you clean.
- Remove the payload file or row and the sink that reads it. Delete the
.htaccessblock if that is the layer; in nginx, restore thewwwandlocationdirectives from backup. - Scan and clean per the malware removal checklist: reset, reinstall core, reset admin access.
- Verify with
curlfor the bot agent and a normal browser in a private window; a redirect that fights the cloudflare or cache layer is the same payload cached, so purge the edge after the files are clean.
Why it came back
The redirect returns within days because the hole is still open: an unpatched plugin, an exposed wp-cron, or a compromised install directory. If the payload came back to the same file, the entry vector is the door; an exchange of the file only closes the symptom. Track the source IP and probe page in the access log, then fix the underlying weakness (outdated plugin or a leaked credential) before you call it clean.
When to involve a professional
If the redirect follows you across a clean reinstall, or the traffic is being farmed, hand it to a professional response team. They will isolate, clean, and verify the platform's logs, and they can advise a block-list watch while you rebuild.