Why is my WordPress website redirecting to spam sites?

If visitors tell you that your website sends them to another site, such as a fake prize page, a gambling or pharmacy site, a "your device is infected" warning or a page asking them to allow notifications, your WordPress website is very likely redirecting traffic without your permission.

The redirect can affect:

• every visitor
• only visitors on mobile phones
• only people who arrive from Google or social media
• only first-time visitors
• only some pages
• visitors who are not logged in to WordPress

That last point is important. Many malicious redirects are designed to hide from the site owner. You may open the website, see that everything looks normal and conclude that the customer was mistaken. Often they were not.

A redirect like this is usually a sign that something has been added to the website: a script, a rule, a database entry or a file. It does not necessarily mean that your content, orders or customer data have been lost. However, it should be treated as a security incident until the cause has been found.

This guide explains why the redirect may be invisible to you, where it is usually hidden, which legitimate causes to rule out first, what you can check safely and when it is better to ask for technical support.

What does it mean when WordPress redirects to spam?

A redirect tells the browser to leave the page it requested and open a different address. Redirects are normal when a page moves, a site switches to HTTPS or a domain changes.

The problem starts when the redirect:

• sends visitors to a domain you do not own
• was not created by you or your team
• appears only in certain conditions
• changes destination over time
• comes back after you think you removed it

In most cases, this is the visible part of a compromise. Someone has found a way to add code to the website, and they use your traffic to send people to pages that earn them money or try to deceive visitors.

Why does it work for me but not for my customers?

This is the most common source of confusion.

Malicious redirects are often written to activate only for certain visitors. This technique is known as cloaking. The aim is to avoid being noticed by the site owner, the developer and sometimes security scanners, so the redirect can stay active for longer.

The code may check:

• whether the visitor is logged in to WordPress
• whether the visitor is using a phone or a computer
• whether the visitor arrived from a search engine or a social network
• whether the visitor has been on the site before, often using a cookie
• the visitor's country or IP address
• the time of day, or a random chance

So the person most likely to test the website, an administrator who is logged in, visits often and types the address directly, is exactly the person least likely to see the redirect.

"It works for me" is not proof that the website is clean.

Take reports from customers seriously, and ask them for details: which device, which browser, how they reached the website and where they ended up.

Rule out legitimate causes first

Not every unexpected redirect is malware. Before assuming the worst, consider whether one of these applies.

A redirect plugin or rule was misconfigured

Many websites use a plugin to manage redirects, for example after a redesign. A rule with a typo, a wildcard that matches too many pages or an old rule pointing to a domain that has since expired can send visitors somewhere unexpected.

An expired domain is worth noting: if a redirect points to a domain nobody renewed, someone else may have registered it and filled it with spam.

The site address is wrong after a migration

WordPress stores two addresses: the WordPress Address and the Site Address. If a migration or a domain change was not completed correctly, the website may keep sending visitors to an old domain, a staging address or a temporary hosting URL.

This usually affects every visitor, including you, which makes it easier to tell apart from a malicious redirect.

An advertising network or third-party script

If your website shows ads, an advertisement can sometimes open another page or redirect visitors. Embedded widgets, chat tools, tracking scripts and other external code can do the same if the service behind them is compromised.

In this case your WordPress files may be completely clean, but the problem is still on your pages and still needs to be addressed.

A CDN, hosting or DNS rule

Redirects can also be configured outside WordPress: in the hosting panel, in a CDN such as Cloudflare or at the domain registrar. A rule added there, by mistake or by someone with access to that account, applies before WordPress is even involved.

If none of these explains what visitors describe, treat the redirect as malicious.

Where is a malicious redirect usually hidden?

You do not need to find the code yourself, but it helps to know that a redirect can live in several places. This is also why removing one piece is often not enough.

Common locations include:

• injected JavaScript added to pages, posts, widgets or theme settings, often loaded from an external domain
• server rules in the .htaccess file, which can redirect visitors based on their device or the site they came from
• database settings, such as the WordPress Address and Site Address, or theme and plugin options that store scripts
• a malicious plugin, sometimes with a convincing name, sometimes hidden from the plugin list
• modified theme files, such as the header or the functions.php file
• modified WordPress core files or extra files placed among them
• scheduled tasks that put the redirect back after it is removed
• unknown administrator accounts that let the attacker return

A single incident often uses more than one of these. For example, a script in the database may do the redirect, while a hidden file elsewhere puts the script back every time it is deleted.

What can anyone check safely?

These checks do not require technical skills and do not change anything on the website.

Try to reproduce the redirect like a visitor

Test in conditions that resemble those of a real visitor:

• log out of WordPress, or use a private or incognito window
• use a mobile phone, ideally on mobile data rather than your office Wi-Fi
• search for your business on Google and click your own result instead of typing the address
• try a few different pages, not only the homepage
• ask a colleague or friend to test from their own device

If the redirect appears, do not interact with the destination page. Do not allow notifications, download anything or enter any information. Close the tab, and note the address it showed if you can.

Write down what triggered it: device, browser, how you arrived and which page.

Check Google Search Console

If your website is connected to Google Search Console, open:

Security & Manual Actions → Security Issues

Google may report hacked content, malware or deceptive pages, with example URLs. These are samples, not a complete list.

The URL Inspection tool can also be useful. Testing the live URL shows how Google fetches the page, which may differ from what you see in your browser.

If you do not have access to Search Console, ask whoever manages the website or its marketing.

Check the WordPress dashboard for obvious signs

If you can log in, look for:

• plugins you do not recognize under Plugins → Installed Plugins
• administrators you do not recognize under Users → All Users
• recently added redirect rules in any redirect plugin you use
• the WordPress Address and Site Address under Settings → General

Note what you find, but do not delete anything yet. Unknown users and plugins are evidence, and removing them can make it harder to understand what happened.

What can you safely try?

The right approach depends on what you found and how important the website is to your business.

Option 1: fix a legitimate redirect

If the cause is clearly a redirect rule you or your team created, a wrong site address after a migration or a rule in the CDN or hosting panel, correcting it may be all that is needed.

Make one change, then test again from a private window and a mobile device.

If you are not completely sure the redirect is legitimate, do not stop here: treat it as malicious until proven otherwise.

Option 2: contact your hosting provider

Your hosting provider may be able to tell you whether:

• their scanner has flagged files on your account
• suspicious files were quarantined
• other websites on the same account are affected
• a backup from before the problem exists

Hosting support can help contain the incident, but they may not clean WordPress completely or find how the attacker got in.

Option 3: limit the damage while the cause is investigated

If many visitors are affected, consider pausing paid ads and email campaigns that send traffic to the website, and warn your team so they can reassure customers. These are precautions, not a fix.

Option 4: consider a backup, carefully

Restoring a backup from before the redirect started can remove the malicious code. However, it may also:

• bring back the same vulnerability that let the attacker in
• contain code that was already present but not yet active
• overwrite recent orders, form entries or content
• remove evidence of what happened

Do not restore a backup until you know roughly when the problem started and what data would be lost. After any restore, the original entry point still has to be found and closed.

What should you avoid doing?

Avoid:

• assuming the reports are wrong because you cannot see the redirect
• clicking through to the spam site to "see what it is"
• deleting files or plugins at random
• removing only the one script you found and stopping there
• installing several security plugins at once
• changing many settings at the same time
• publishing logs, screenshots of settings or credentials in public forums
• sending passwords by ordinary email

Change one thing at a time, keep a record of what you did and test after each step.

If you are unsure, stopping is safer than continuing. D4Hub can take over from any point, including after a cleanup attempt that did not work.

When should you ask for technical support?

Technical support is recommended when:

• you cannot find a legitimate explanation for the redirect
• customers keep reporting it after you made changes
• Google Search Console reports a security issue
• you found unknown administrators, plugins or files
• the redirect comes back after being removed
• the website handles payments, subscriptions or personal data
• several websites share the same hosting account
• you do not have a clean, recent backup
• you are not comfortable working with files or the database

You do not need to reproduce the redirect or identify the code before asking for help. A clear description of what visitors experience is enough to start.

What information should you collect?

Useful details include:

• the website URL
• where visitors are sent, if known
• which devices and browsers are affected
• how visitors reached the website, for example from Google
• whether you have been able to reproduce it
• when the first report arrived
• any Search Console notification
• recent changes to the website, hosting or DNS
• whether WordPress is accessible and a recent backup exists
• any steps already taken

Do not send passwords, private keys or full credentials through unsecured channels. D4Hub can explain how to share access safely.

How D4Hub can help

The goal is not only to stop the redirect today, but to make sure it does not come back next week.

Depending on the situation, D4Hub can help with:

• reproducing the redirect under the conditions visitors describe
• ruling out legitimate causes such as redirect rules, migrations, CDN settings or ads
• checking WordPress files, the database, users and scheduled tasks
• reviewing server rules, including the .htaccess file
• identifying malicious plugins, theme changes and injected scripts
• removing the redirect and anything that reinstalls it
• finding and closing the original entry point
• updating vulnerable components and securing accounts
• evaluating backups and planning a restore without losing recent data
• coordinating with your hosting provider
• supporting a Google security review if a warning was issued

You can ask for support at any stage: when the first customer reports it, after your hosting provider has scanned the site or after a cleanup that did not hold.

wp option get siteurl
wp option get home

define( 'WP_HOME', 'https://example.com' );
define( 'WP_SITEURL', 'https://example.com' );

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

curl -sI -A "Mozilla/5.0 (iPhone; CPU iPhone OS 17_0 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/17.0 Mobile/15E148 Safari/604.1" -e "https://www.google.com/" https://example.com/

curl -s -A "Mozilla/5.0 (iPhone; CPU iPhone OS 17_0 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/17.0 Mobile/15E148 Safari/604.1" -e "https://www.google.com/" https://example.com/ -o page.html

wp db search '<script' --all-tables

wp db search 'suspicious-domain.example' --all-tables

wp core verify-checksums
wp plugin verify-checksums --all

wp user list --role=administrator
wp cron event list