A malicious redirect is code that sends visitors from your page to a spam, scam or malware site without their consent. It often fires only for some visitors, which is why owners miss it, and it usually sits in the .htaccess file, a theme file, a JavaScript file or the database. Attackers plant it after they find a weakness. This guide explains why only some people see the redirect, where it hides, how to test for it and how to remove it.
What a Malicious Redirect Is
A malicious redirect is planted code that silently sends a visitor to a different website than the one they requested. Its destination is usually a scam page, a fake login, an ad network or a download of malware. It differs from a legitimate 301 or 302 redirect, which an owner sets on purpose, and from an open redirect, tracked as CWE-601, which is a flaw in your application that lets someone else craft a bouncing link. Attackers plant a malicious redirect after they compromise a site, so the code already runs on your pages. The table separates the four cases by who creates them and where they live.
| Type | Who creates it | Where it lives | Result |
|---|---|---|---|
| Legitimate redirect (301 or 302) | The site owner | Server configuration or CMS settings | A moved page reaches its new address |
| Open redirect (CWE-601) | Nobody, it is an application flaw | Application code that accepts any destination | A crafted link bounces visitors elsewhere |
| Malicious redirect | An attacker | .htaccess, theme files, JavaScript, the database |
Visitors land on spam, scams or malware |
| Conditional or TDS based malicious redirect | An attacker | Injected code plus a remote server that decides per visitor | Each visitor gets a different destination |
Common Symptoms of a Malicious Redirect
A redirect symptom is a sign that visitors or owners notice when a site sends people to the wrong place. Five signs appear most often, and a site can show only one of them. Owners rarely see the redirect first, because the code is built to avoid them, and Wordfence notes that most owners learn of a redirect when a customer complains.
- Notice phones or tablets bouncing to app stores, scam pages or ad sites while desktop visitors see the normal site.
- Hear from customers about redirects that you cannot reproduce on your own computer.
- See clicks from Google results landing on another site, while typing the address directly works normally.
- Find redirects on some pages but not others, or before the page finishes loading.
- Receive reports of spam emails that link to unfamiliar pages on your domain, which GoDaddy documents as a way attackers lure visitors to redirect files.
How a Malicious Redirect Is Delivered
A redirect delivery method is the technical mechanism that moves a browser to another address. Three mechanisms cover most cases: an HTTP response, an HTML meta refresh tag and JavaScript. Each leaves a different trace, so knowing which one fires tells you where to search.
- Check the HTTP response for a 3xx status with a Location header that points to another domain, or an older Refresh header, which Quttera reports is showing up again.
- Search the page HTML for a meta refresh tag that loads another address after a short delay.
- Search JavaScript for code that changes the browser’s location, which is often obfuscated and appended to legitimate files.
Visitor or Site Owner?
A visitor redirect is a redirect you experience on a site you do not own. Its cause is either that site or something on your own device. Emsisoft explains that redirects on a hacked WordPress site come from the website itself, not from your computer, which is why a clean device does not stop them. If you are a visitor, check your browser extensions and remove any you do not recognize, scan the device, and look at DNS and router settings if many unrelated sites redirect. If you own the affected site, investigate both the application and its surrounding infrastructure. Malicious redirects can originate from site files, database content, injected JavaScript, server configuration, CDN rules, DNS changes or hosting level configuration, and a visit from your own browser may never trigger them.
Why Only Some Visitors See the Redirect
Search Engine and Referrer Triggers
A referrer check is a condition in a redirect script that reads where the visitor came from. The script fires only when the referrer is a search engine, so someone who types your address directly sees the normal site. Security researcher Niels Provos documented an .htaccess file that served a rogue installer only to visitors arriving from search results. Google’s hacked site documentation describes conditional redirect hacks that depend on the referrer or the device. This behavior hides the infection from the owner, who usually visits directly or through bookmarks, and from many scanners, which request pages without a search referrer. If customers report a redirect that you cannot reproduce, test with a Google referrer before you decide that nothing is wrong.
Device and Location Conditions
A traffic distribution system, or TDS, is an attacker controlled server that decides where each visitor goes. It sends visitors to different destinations by device, language and location, because those are the traffic the attacker’s partner sites pay for. Palo Alto Networks’ Unit 42 tracked a redirect campaign that it detected on more than 51,000 websites, and the FBI warned in June 2026 that criminals use TDSs to route traffic through chains of intermediate nodes that bypass firewall rules, to filter visitors by IP address, operating system, location, device and browser, and to show safe content to security researchers. A script may redirect only visitors on mobile phones, only visitors from certain countries, or only visitors using particular browsers. If your desktop test is clean but customers on phones complain, test with a mobile device or a mobile user agent.
Cookies and First Visit Logic
First visit logic is a condition that redirects a visitor once, usually by setting a cookie after the first redirect. Other scripts skip logged in users, which means you never see the redirect while working in the admin area. This logic protects the attacker from complaints and explains why the same page behaves differently for you at different times. Test in a private window with no cookies and no login, and repeat the test from a fresh browser profile. The same trigger logic powers cloaking in the Japanese keyword hack, where Googlebot sees spam that visitors do not.
Where the Redirect Hides
A redirect hiding place is a location where injected code can run before the page renders. Start with these five common locations. Work through them in the order below, which moves from quick file checks to infrastructure checks.
- Check the
.htaccessfile in the web root and in every subdirectory for rewrite rules you did not write, especially rules that read the referrer or user agent. - Inspect theme files such as
functions.phpandheader.phpfor injected code, and check the plugin folders for files you did not install. Also look for stray PHP files in random-named directories that contain a redirect line, a pattern GoDaddy documents. - Search JavaScript files, widgets, posts and the page source for script tags that load code from unfamiliar domains, including obfuscated script appended to legitimate files.
- Review the database for injected scripts in posts and options, and confirm that the site URL and home URL settings still point to your domain.
- Review third party ad networks and script providers, then redirects at the CDN, DNS and hosting level, which a file scan never sees.
How to Test Without Being Fooled
A redirect test is a request that reproduces the conditions the attacker’s script checks. Open your pages from a Google result, in a private window and on a phone, because each of those can trigger a different condition. A difference between any two results is the evidence you need, and a clean result from one test proves little. If you have command line access, this request sets a Google referrer and a mobile user agent, and a changed address or location header gives the redirect away. Use the URL Inspection tool in Google Search Console to see the page as Googlebot receives it.
curl -I -e https://www.google.com/ -A "Mozilla/5.0 (iPhone)" https://example.com/Remove the Redirect
Redirect removal is the sequence that deletes the injected code and the backdoor that restores it. It follows the cleanup order in our guide to remove malware from a website. Leaving the backdoor in place is the most common reason a redirect returns. Follow these steps in order.
- Back up the site and preserve the infected files, so you keep evidence and a way to undo a wrong edit.
- Remove the injected code, or replace the infected file with a clean copy from the official source.
- Clean the database entries that hold injected scripts, and correct the site URL and home URL if they were changed.
- Find the web shell or backdoor that restores the redirect, remove it, and rotate hosting, SFTP and database credentials.
- Resubmit the site to Google if a security warning appeared, following the review steps in our Deceptive Site Ahead guide.
Prevent Redirect Reinfection
Redirect reinfection prevention is the work of closing the weakness that let the attacker in. It works because redirects return through the same entry point. Update the CMS, plugins and themes within days of each release, scan your own workstation for signs of compromise because stolen credentials can start the infection, remove software you no longer use, and give every account a unique password with two factor authentication for administrators. Monitor file changes, especially to .htaccess, theme files and the uploads folder, so an edit raises an alert instead of a customer complaint. Block PHP execution in the uploads folder, and compare theme and plugin files with clean copies after each update. A recurring website malware scan checks the pages visitors see, and ScanTitan’s website malware removal service helps if the redirect keeps coming back.
Frequently Asked Questions
Can a Malicious Redirect Give Me Malware?
A malicious redirect is usually the delivery mechanism rather than the final payload. The destination may present phishing, fake update prompts, unwanted downloads, scams or exploit attempts. If an unexpected redirect occurs, close the destination and avoid entering credentials or downloading files. If you entered a password on the destination page, change it on the real service and turn on two factor authentication. If you downloaded a file, scan it before you open it, and report the destination to your browser’s safe browsing feedback form. Treat any unexpected redirect on your own site as a sign of compromise.
Is a 301 Redirect Dangerous?
A 301 redirect is a standard instruction that tells browsers and search engines a page moved permanently, and a 302 says the move is temporary. Site owners use both for ordinary reasons such as changing a URL or moving to HTTPS. Danger comes from who wrote the redirect and where it leads. Review your redirect rules for destinations you do not recognize, especially rules that depend on the referrer or the device, because those are the signs of a planted redirect. A rule you wrote that points to your own pages is fine.
Why Does My Site Redirect Only on Mobile?
A mobile only redirect is a conditional redirect that fires only for visitors on phones. The attacker’s script checks the visitor’s device and redirects mobile users, since that traffic is worth more to the ad networks and scam pages that pay for it. The check may read the user agent or screen width, and it keeps desktop visits clean, so you never see the redirect while working on a computer. Test from a phone, or send a request with a mobile user agent from the command line, and then search the .htaccess file, theme files and JavaScript for the rule that makes the decision. Removing the visible redirect without the rule will not hold.
