WordPress site redirecting to spam? Why only your visitors see it

Why is my WordPress site redirecting to spam when I cannot see it?

Because the code doing it was written so you would not. A WordPress site redirecting to spam has usually been hacked, and the injected code checks who is asking before it acts. Logged-in users, search engine crawlers and repeat visitors get the real site. Strangers from Google and people on phones get sent away.

So a customer says your site went to a pill shop, you check from your office, and it looks fine. Both of you are right.

Finding that code on a copy of the site, so the live one keeps taking orders, is part of our WordPress maintenance work.

How did we test it?

On 17 Oct 2026 we set up WordPress 7.1.3 on PHP 8.3.33 in WordPress Playground. We wrote one small PHP file that behaves like the redirects we find on hacked sites, and copied it into wp-content/mu-plugins. Its target was spam-shop.invalid, a reserved name that cannot reach anything, and the address was hidden behind base64_decode the way real injections hide theirs.

The file followed four rules. Skip logged-in users. Skip Googlebot and Bingbot. Act only on visitors who came from a search engine or are on a phone. Act only once per browser, using a cookie. A server rule that checks the user agent is also how a site turns AI crawlers away, which we tested in AI crawlers blocked on WordPress.

Then we asked for the same pages with curl, changing only who we claimed to be.

Who got sent to the spam site?

Before the file went in, every request got the normal page with a 200.

With the file in place:

The login page also loaded normally on the iPhone, so the owner could log in, look around and find nothing.

Google’s spam policies, read on 17 Oct 2026, list this trick under sneaky redirects. Their example: “Showing desktop users a normal page while redirecting mobile users to a completely different spam domain.” Treating Googlebot differently from people is cloaking on the same page.

Why does the redirect seem to come and go?

Because it fires once. In our lab the iPhone’s first visit got the 302. The second visit, carrying the cookie from the first, got the normal page with a 200.

That is why these reports are hard to pin down. A customer gets bounced once, tries again and lands on your site. It looks fixed. It is not.

Where did the code hide?

In wp-content/mu-plugins. The must-use plugins guide says files there are enabled automatically and “cannot be disabled from wp-admin”. They do not show in the normal Plugins list.

Our Plugins screen showed All (2), and the file was not one of those two. It sat on a separate Must-Use (1) tab, listed by its file name only, because it had no plugin header.

Real injections use other places too. WordPress.org’s hacked site guide says to look at .htaccess first, then index.php, header.php, footer.php and the theme’s functions file, because a change there runs on every page.

How do you find the redirect file?

Search wp-content for the functions redirects need. We searched every PHP file there for base64_decode, wp_redirect and HTTP_REFERER.

The search found 7 hits in 4 files. Three were our planted file. The other four were in Akismet, doing its normal job, since plenty of honest plugins read the referrer and redirect.

So a hit alone proves nothing. What gave the planted file away was its date: it was changed 22 seconds after the Akismet files, which were written when the lab was set up. On a real site, sort by modified date and read anything newer than your last update first.

When you test from outside, use a private window, stay logged out, and try a phone on mobile data. Click through from a Google search for your own business name, since many injections only act on search traffic.

How do you fix a WordPress site that redirects to spam?

In our lab, deleting the file ended it. The next iPhone visit from Google, in a fresh browser, got the normal page with a 200.

On a real site, deleting the file is the easy part. The person who put it there still has a way back in, through an old plugin, a stolen password or a second file you did not find. Our guide to what to do in the first hour after a WordPress hack covers the backup, the host call and the password resets that come before the cleanup.

We do this as a single fix. On a copy of the site we find every injected file and database entry, close the way in, reset access and new secret keys, and hand the site back with a list of what we removed.

If Google flagged the site, its Security Issues report in Search Console lists sample affected addresses and is where you request a review once every page is clean.

What did we not test?

• .htaccess and server-level redirects. Playground serves PHP itself, with no Apache.
• JavaScript redirects that run in the browser, and code stored in the database.
• Real malware. Our file was written for the lab and pointed at an address that cannot resolve.
• Security scanner plugins.
• The Security Issues report on a live flagged site.

Is your site sending visitors somewhere else right now?

Tell us which pages redirect and where they go, and we will say where to look first.

Not sure what else changed? Send your site address for the free site check, and a written reply comes within 2 business days.