My Site Keeps Redirecting to Another URL

This is a different problem than a browser warning

It's worth separating two things that get confused constantly. If your browser itself is showing a full red-screen "Deceptive site ahead" interstitial, that's Google Safe Browsing flagging your site at the browser level — we cover that specific flag, and how to get it lifted, in our guide to that warning.

This article is about something upstream of that: the actual mechanism that sends a visitor away from your site in the first place. A redirect hack can exist — and be actively harming your traffic and reputation — long before (or even without) Google ever flagging it. Getting rid of the redirect is what eventually stops the flag from happening, or from coming back.

How the redirect actually gets injected

A malicious redirect isn't magic — it's code that got added somewhere in your site by an attacker, and it typically lands in one of a few well-documented places:

• Modified .htaccess rules. Apache's .htaccess file can rewrite or redirect entire URL patterns before WordPress even loads. Attackers frequently append rewrite rules here specifically because they run at the server level, invisible to anything that only inspects your page's rendered HTML.
• Injected JavaScript in theme files. Your theme's header.php or footer.php are common targets — a few lines of obfuscated (often base64-encoded) script dropped into a file that loads on every single page will do it.
• A compromised plugin option or database value. Some attacks don't touch files at all — they write directly into WordPress's database, into an option a vulnerable plugin reads and trusts, or into a redirect rule stored by a legitimate SEO/redirect-management plugin.
• wp-config.php tampering. As a core configuration file loaded on every request, it's another realistic target for the same kind of injected, obfuscated code.

In every case, the pattern is the same: code that shouldn't be there, running on every page load, sending some fraction of your visitors somewhere else.

Why you might not be able to reproduce it yourself

This is the detail that trips up most site owners: you visit your own site, refresh a few times, see nothing wrong, and conclude the report was a false alarm. That's frequently exactly what the attacker designed.

Redirect hacks commonly use conditional targeting to stay invisible to the one person most likely to notice and fix them — you:

• Referrer-based targeting. The injected code checks where the visitor came from and only redirects traffic arriving from a search engine results page — someone who clicked a Google or Bing listing — while leaving direct visits and normal browsing untouched.
• Admin evasion. Some variants specifically detect a logged-in WordPress administrator and serve clean, normal content to that session, precisely so the person with the power to fix it never sees the problem.
• User-agent and device targeting. Others check the visitor's device or browser and only trigger for mobile visitors, or only for a specific operating system, while a desktop visit (which is how most site owners check their own site) looks completely fine.

This is a well-documented pattern in redirect-hack research, not a rare edge case — it's specifically why "I checked and my site looks fine" is one of the least reliable signals here. Server-side redirects like these are also frequently invisible to remote automated scanners, since a scanner's request often doesn't match whatever narrow condition the malicious code is checking for.

How to actually find the injection point

1. Check .htaccess for unfamiliar rewrite rules. Compare it against a known-clean backup if you have one, or look for RewriteRule lines you don't recognize and can't explain, especially ones pointing at an external domain.
2. Check your theme's header.php and footer.php. Look for injected <script> tags, especially ones containing long obfuscated or base64-looking strings, sitting outside your theme's normal code structure.
3. Review your active plugin list for anything you don't recognize installing. A plugin you never knowingly added is a strong signal, and some redirect hacks arrive bundled inside a fake or trojanized plugin.
4. Check redirect-management or SEO plugin settings. If you use a plugin that stores its own redirect rules in the database, look through its rule list for entries you didn't create.
5. Test with a different referrer and device — try opening the site from a Google search result rather than typing the URL directly, and try it on mobile as well as desktop, since a conditional redirect may only appear under one of those conditions.

A concrete example of what this looks like

Say a store owner starts getting messages from customers saying that clicking a product link from a Google search result sends them to an unrelated site selling knockoff sneakers, but the owner clicks the exact same link directly and lands on the normal product page every time. That mismatch — works fine when typed or bookmarked, breaks specifically when arriving from search — is close to a textbook case of referrer-conditional targeting. The injected code is checking the HTTP referrer header on every request, and only firing the redirect when it sees a search-engine domain in that header. Nothing about a direct visit will ever surface it, no matter how many times the owner checks.

The same logic applies to reports that only come from customers on their phones, or only from people using a specific browser. The instinct to dismiss a report because "it works fine when I check it" is understandable, but for this specific class of hack, it's exactly the wrong conclusion — the redirect was built not to work fine for you.

Why cleaning up the visible symptom isn't the whole job

It's tempting to delete the offending script tag or rewrite rule the moment you find it and consider the problem solved. In practice, that only removes the current version of the payload. If the attacker still has a way back in — a stolen admin password, an outdated plugin with a known vulnerability, a webshell tucked in an unrelated directory — the redirect (or something worse) tends to reappear within days, sometimes hours. Treat the redirect as a symptom of a break-in that needs a full response, not as an isolated bug to patch.

What to do once you've found it

Removing the redirect script or rule itself is necessary but rarely sufficient — the same access an attacker used to inject it once is usually still open, which means the fix needs to include closing that door, not just deleting the symptom. Our full malware removal guide covers the proper order of operations for that. And if your site has already picked up a Google Safe Browsing flag as a result of the redirect, our guide to that specific warning covers getting it lifted once the underlying cause is actually gone.