Malicious Redirects: Why the Site Looks Normal to You but Sends Visitors to Spam

You open the client's homepage. It looks normal.

The client opens it. Also normal.

A visitor arriving from Google on a mobile phone gets sent to a casino, fake antivirus page, or
phishing site.

That is not an impossible bug. Conditional redirects are a common way to hide a compromise from the
people most likely to investigate it.

Why ordinary checks miss the redirect

A malicious redirect may trigger only for:

• mobile user agents;
• visitors arriving from a search engine;
• a specific country or network;
• first-time visitors without a cookie;
• a particular landing page;
• one request in several;
• users who are not logged in to WordPress.

The attacker wants revenue or traffic without making the compromise obvious to the site owner.

Google's spam policies explicitly describe hacked redirects that depend on referrer, user agent, or
device. The site can appear normal during a direct desktop visit and behave differently for search
visitors.

Where the redirect can live

Common locations include:

• injected JavaScript;
• a compromised plugin or theme;
• modified .htaccess or Nginx rules;
• database content;
• a tag manager or ad script;
• a service worker;
• DNS or CDN configuration;
• a stolen third-party dependency.

Removing the visible redirect is not enough. The vulnerability and persistence mechanism must also
be found.

How to monitor conditional redirects

Check from multiple regions

Geo-targeted behavior will not appear from one probe location.

Vary the user agent

Test desktop and mobile profiles. If the site serves materially different redirect chains,
investigate.

Test direct and referral traffic

Use controlled referrer scenarios for critical landing pages. Never automate queries against search
engines in violation of their terms; reproduce the request context you own.

Record the full redirect chain

Store:

• every status code;
• every location;
• the final URL;
• protocol changes;
• host changes;
• timing.

"The page is up" is useless when the final URL belongs to another domain.

Check expected content

Some compromises replace the page instead of redirecting. Verify a stable marker that should exist
on the final page.

Confirm before paging

One abnormal response may be an edge or network error. Repeat from another probe, but do not wait
so long that real visitors remain exposed.

What a useful alert includes

Unexpected cross-domain redirect
URL:
https://client.example/services
Expected host: client.example
Final host:
suspicious-example.tld
Trigger: mobile user agent, search referrer
Regions confirmed:
Frankfurt, Virginia
First detected: 08:14 UTC

This gives the responder evidence and a reproducible condition.

Immediate response checklist

1. Preserve the redirect chain, headers, response body, and timestamps.
2. Put the incident owner and communication owner in place.
3. If visitors are at risk, disable the affected path or site safely.
4. Check Search Console Security Issues and hosting/security alerts.
5. Inspect recent plugin, theme, server, DNS, CDN, and tag-manager changes.
6. Rotate compromised credentials and revoke unknown sessions.
7. Remove malicious code and the original entry point.
8. Purge CDN and application caches.
9. Retest across devices, regions, and referrer conditions.
10. Document impact and prevention.

Do not publicly claim "no data was affected" until that is verified.

Legitimate redirects still need an expected state

Not every redirect is malicious:

• HTTP to HTTPS;
• www to apex;
• an old URL to its replacement;
• locale selection;
• login routing.

The monitor should compare the observed chain with an allowed destination, not treat every 301 or
302 as an incident.

Alert on:

• a new external host;
• a redirect loop;
• too many hops;
• HTTPS downgrade;
• destination content mismatch;
• device- or referrer-specific divergence that is not expected.

Frequently asked questions

Why can't the agency reproduce the redirect?

The malicious rule may exclude logged-in users, known cookies, desktop devices, or direct
traffic. Reproduce the original visitor context.

Can an uptime check detect a malicious redirect?

Only if it validates the redirect destination and content. A basic checker that follows
redirects and accepts the final 200 response may mark the attack as healthy.

Should the site be taken offline?

It depends on visitor risk and the ability to isolate the affected path. Protect users first
and coordinate the decision with the incident owner.

Sources

• Google Search spam policies: hacked content and sneaky redirects
• Google: detecting unwanted mobile redirects
• Google: helping webmasters with hacked sites

---

Originally published at pingvera.com.