WordPress Site Redirecting to Spam Sites: How to Fix It

A customer tells you that tapping your site in Google took them to a casino page, or a “you have won a phone” screen. You check on your laptop and everything looks normal. You check again on your phone and it still looks normal. So either the customer is mistaken, or something on the site is being careful about who it redirects.

It is almost always the second one. Spam redirects on WordPress are usually written to hide from the person who owns the site. Once you understand how they choose their victims, they become much easier to find.

Why the redirect only happens to some people

Attackers want the redirect to run for as long as possible before anyone fixes it. The best way to do that is to make sure the owner never sees it. So the injected code checks a few things about each visitor before deciding what to do.

• Only on mobile. The code reads the browser’s user agent and only redirects phones. Owners tend to manage their site from a computer, and mobile visitors are less likely to notice an odd address bar.
• Only from Google. The code checks the referrer, the page the visitor came from. If they clicked through from a search result, they get redirected. If they typed the address or used a bookmark, which is what owners do, they see the real site.
• Only for logged-out visitors. WordPress sets a cookie when you log in. The code looks for it and leaves logged-in users alone, so the administrator browsing the site sees nothing wrong.
• Only once. Some redirects set their own cookie or remember the visitor’s IP address, then skip that person on the next visit. Your customer saw it once, you test from the same phone, and it does not happen again.

Some versions also leave search engine crawlers alone, so the site keeps its rankings and keeps sending real searchers into the scam. The result is that the people most likely to fix the problem are the ones least likely to see it.

Where the redirect code usually hides

There is no single spot. These are the places worth checking, roughly in order of how often they turn up.

.htaccess

On Apache and LiteSpeed servers, the .htaccess file in the site’s root folder can redirect visitors before WordPress even loads. Look for rewrite rules that mention Google, Bing or other search engines as the referrer, or long lists of mobile browser names. Also check for .htaccess files in subfolders, including wp-content and uploads, where they are easy to miss.

wp-config.php and core files

A line added to wp-config.php, or to index.php in the root folder, can load a malicious file on every page view. It is often a single long line of scrambled text, or an include of a file with a harmless-sounding name.

The theme’s functions.php

Every page loads the active theme, which makes functions.php a popular place to add a redirect or inject a script into the page header. Check the parent theme and the child theme if you use one.

The database

A redirect does not need a file at all. Attackers often write a script tag into post content, widgets, or theme options stored in the wp_options table. They sometimes change the site address settings (siteurl and home) too, though that one is rarely subtle, because it breaks the site for everyone.

Injected JavaScript

Code can be appended to the end of legitimate JavaScript files in your theme or plugins, or loaded from an outside domain through a script tag. The redirect then happens in the visitor’s browser, which is why some server-side scans miss it.

Rogue plugins

Some infections install a plugin with a believable name that does nothing except serve the redirect. Others sit in the wp-content/mu-plugins folder. “Must-use” plugins in that folder load automatically, cannot be switched off from the dashboard, and only show up under a separate Must-Use tab on the Plugins screen that most owners never open. An abandoned plugin that never got its security fixes is also a common way in.

How to check safely

Some of these redirects lead to pages that try to install things or collect details. Test carefully.

1. Log out of WordPress, or use a private window. Otherwise the code may simply skip you.
2. Arrive the way a victim would. Search for your business on Google from a phone on mobile data, not your office Wi-Fi, and tap the result.
3. Do not interact with whatever loads. Close the tab. Do not allow notifications, download anything or type anything.
4. Use the URL Inspection tool in Google Search Console and run a live test to see the page as Google fetches it. Code that treats crawlers differently can show up here.
5. Run an outside scan such as Sucuri SiteCheck, and a scan from inside WordPress with a plugin such as Wordfence. Neither will catch everything.
6. Check Search Console’s Security issues report. If Google has flagged the site, your visitors may also be seeing a red “Deceptive site ahead” warning.

If you or a developer are comfortable on the command line, WP-CLI’s wp core verify-checksums compares core files against the official versions, and wp plugin verify-checksums does the same for plugins from the WordPress.org directory. Anything that does not match is worth a look.

The order to clean it up

Order matters here. If you remove the visible redirect but leave a backdoor, the redirect is usually back within a day or two, sometimes within hours.

1. Take a full copy of the current site, files and database, and keep it somewhere safe. It is evidence of how the attacker got in.
2. Change every password: WordPress administrators, hosting panel, FTP or SFTP, and the database. Do it from a device you trust.
3. Remove administrator accounts you did not create.
4. Replace WordPress core with a fresh copy, keeping only wp-config.php and wp-content. Then go through wp-config.php line by line.
5. Reinstall every plugin and theme from its official source, and delete any you do not recognise or no longer use. Empty the mu-plugins folder of anything you cannot explain.
6. Check every .htaccess file and reset the main one to the standard WordPress rules.
7. Look for PHP files inside uploads. That folder should hold media, not code.
8. Search the database for script tags, unfamiliar domains, and functions such as eval or base64_decode in posts, widgets and options.
9. Check scheduled tasks. Some infections add a WordPress cron event or a server cron job that reinstalls the code.
10. Update everything and turn on two-factor authentication before the site goes back to normal.

If you have a backup from before the infection, restoring it can replace several of these steps. You still need to change passwords and close the hole, or the same attacker gets back in the same way. Our step-by-step guide to fixing a hacked WordPress website covers the wider process, including requesting a review from Google if your site has been flagged.

Signs it is really gone

Test again a day or two later, the same careful way, from a phone on mobile data, logged out, arriving from Google. Ask the customer who reported it to try again. Watch for new administrator users or recently modified files over the following weeks. A redirect that comes back after cleaning is the clearest sign that something was missed.

If you would rather not chase it yourself

Conditional redirects are tedious to track down because they are built to avoid you. If you would like us to do it, our WordPress malware removal service finds the code, removes the backdoors and closes the way in. A standard cleanup is a flat ₹2,999. Badly damaged or repeatedly reinfected sites are reviewed first and quoted before we start.

If the redirect keeps returning or you cannot find its source, our redirect hack removal service traces it to the code that creates it. More help for hacked sites is on our hacked website repair page.

Next in this series: Japanese Keyword Hack and SEO Spam: Finding and Removing It