Visitors tell you your WordPress site sends them to a spam page, a casino page, or a page selling something you never sold. You open your own site and everything looks normal. That mismatch is the first clue, not a reason to doubt the report. Redirect malware is built to hide from the site owner, and a misconfigured redirect setting can hide in the same way. This guide shows you how to reproduce what visitors see, work out whether the cause is a setting or malware, find every copy of the redirect code, remove it, and check that it stays gone.
This guide is about one symptom: a WordPress site redirecting to spam. If your site was hacked in a different way, start with our WordPress hacked emergency recovery guide. If a redirect returns after you already cleaned the site once, read our guide on why a WordPress site keeps getting hacked after you finish this one.
Why you may not see the redirect yourself
Most redirect malware checks the visitor before it acts. It often redirects only some visitors and leaves the rest alone, which is exactly why the owner misses it. The common conditions are simple to understand once you know them.
First, the redirect may fire only for visitors who arrive from a search engine. You type your address directly, so you never meet the condition. Second, it may fire only on phones. You check from a desktop computer, so you never meet that condition either. Third, it may fire only on a first visit. A small cookie marks a visitor after the first redirect, so a second visit looks clean. Fourth, it almost never fires for a logged in user. You are usually logged in to WordPress when you check your own site, so the redirect skips you every time.
None of this means the report is wrong. If several visitors describe the same destination, believe them and reproduce their journey instead of your own usual journey.
Work out the trigger before you change anything
Do not start deleting files yet. A few minutes of careful observation tells you where to look, and it stops you from cleaning the wrong layer while the real copy stays in place.
Ask the people who reported it four questions: what device did they use, did they click from Google or another search engine or type the address, were they logged in to anything on your site, and was it their first visit or a repeat visit. Their answers point to the trigger. The table below maps the usual answers to the likely layer.
| What the visitor did | What it usually points to |
|---|---|
| Redirect on a phone, normal on a desktop | A device check in the redirect code, often in a theme file, a plugin file, or a script added to pages |
| Redirect only after clicking a search result | A referrer check, often in the .htaccess file or in a script that reads where the visitor came from |
| Redirect on a first visit, clean on a repeat visit | A cookie check that marks the visitor after the first redirect |
| Redirect for logged out visitors, never for logged in users | Code that skips anyone with a WordPress login, which is why the owner misses it |
| Redirect on every page, for every visitor | A changed site address, a site wide redirect rule, or code added to a file that loads on every page |
| Redirect only on one page or one post | A script injected into that page, a widget, or page builder content for that page |
Write down the destination address exactly as visitors report it, but do not click through to it, and do not enter any detail on the destination page. The destination address itself is useful later: you can search your files and database for part of that address to find copies of the code.
Reproduce what visitors see
Reproduce the visitor journey as closely as you can. Use a phone on mobile data, not your office or home Wi-Fi, open a private or incognito tab, search for your business name, and tap your result in the search results. If the redirect fires, note the destination address and take a screenshot of the address bar before the destination page fully loads.
Then repeat the same test on a desktop computer in a private tab, logged out of WordPress, once by typing your address directly and once by clicking from a search result. Comparing the four results tells you whether the trigger is the device, the referrer, the login state, or a combination of them.
If you cannot reproduce it on any device, that still does not clear the site. The trigger may depend on a first visit cookie you already carry, a location, or a specific search term. Move on to the checks below anyway, and treat the visitor reports as the evidence.
First check: is it a hack, or only a setting
Not every unexpected redirect is malware. Checking the innocent causes first saves a full cleanup on a site that was only misconfigured. Work through these in order, and stop as soon as you find the cause.
Check your site address
In WordPress, go to Settings, then General, and check the two address fields. Both must show your own domain. If either one points to another domain, that alone explains a site wide redirect. Correct it only if you are sure the other address is wrong, and note what it was changed to, because an unexpected change here is itself a sign that someone had access.
Check your redirect rules
Open your redirect plugin, if you use one, and any redirect rules set in your caching plugin or at your host. A rule that was meant to send an old page to a new page can send visitors to the wrong place if the destination was typed wrongly or if a rule is too broad. A legitimate redirect always goes to a page on your own site. A redirect to an unknown domain selling something, or asking visitors to allow notifications, is not a legitimate rule.
Check for a stale cached redirect
Clear your caching plugin cache, your host cache, and any content delivery network cache, then repeat the phone test. A redirect that was fixed in the files can keep showing for a while if an old cached copy is still being served. If clearing every cache ends the redirect, the cause was a stale cache holding an old rule, not live code.
If none of these checks explains it, treat it as malware and work through the cleanup below. Do not reinstall or reset anything yet. The next step is to find the layer the code lives in.
Find the layer: server redirect or page script
A redirect can happen at two very different layers, and the cleanup path depends on which one it is. A server layer redirect fires before WordPress finishes loading, usually from the .htaccess file. A page layer redirect fires inside the page itself, usually from a script added to a theme file, a plugin file, or the database.
You can tell them apart without code knowledge by watching what loads. If the address changes almost at once, before any page content shows, the server layer is the likely source. If the real page starts to show and then jumps away, or if the jump happens after a short delay, a script inside the page is the likely source. A host support team or a developer can confirm this with a header check, which reads the server response without running page scripts. Ask them to check whether the server itself returns a redirect for a phone visitor arriving from a search engine.
This distinction matters because cleaning only one layer leaves the other copy running. Many infections place code in both layers at once, so plan to check every place below even if you find one copy early.
Check every place the code can hide, in order
Work through this list in order, and keep a note of every copy you find. Finding one copy is not the end. Redirect malware is often placed in several places so that removing one copy alone changes nothing.
1. The .htaccess file
Open the .htaccess file in your site root, and every other .htaccess file on the account, through your hosting file manager. A normal WordPress .htaccess file is short: a small WordPress block plus rules from plugins you recognise. Look for lines that mention search engines or phone devices, followed by a rule sending visitors to another domain. Those lines do not belong there. Remove only the lines you can identify as the redirect, and keep a copy of the original file before you edit it, so you can restore it if you remove the wrong line.
2. Theme and plugin files
Open your active theme files, starting with the header, footer, and functions files, and look for added code at the top or bottom of each file that you do not recognise. Then check recently changed plugin files, especially files changed around the date visitors first reported the redirect. A few lines appended to the end of a real JavaScript file are a common hiding place, so check the end of script files too, not only the start.
For any file you doubt, compare it with a fresh copy from the official theme or plugin source. Reinstalling the theme or plugin from its official source replaces a changed file with a clean one. Do not reinstall from a copy downloaded from an unofficial site, because such copies can carry their own hidden code.
3. The database: posts, widgets, and settings
Some redirect code lives in the database rather than in files. Check your posts and pages for script tags you did not add, check widgets and page builder content for the same, and check the site address values again. A script added to a single post explains a redirect that fires only on that post. A script added to a widget or to a site wide element explains a redirect on many pages.
Edit database content carefully, one item at a time, and keep a backup from before you start. If you are not confident editing the database directly, ask your host to help with this step rather than guessing.
4. Fake plugins, must use plugins, and scheduled tasks
Check your Plugins list for a plugin you never installed, and ask your host to list the must use plugins folder, which does not show in the normal Plugins list. A fake or hidden plugin can add a redirect script to every page. Also check scheduled tasks and unknown admin users in WordPress. A hidden admin account or a scheduled task that re-adds the code explains a redirect that returns after cleanup, and both must be removed as part of the same cleanup, not left for later.
5. Other sites on the same hosting account
On shared hosting, an infection on one site can reach another site on the same account. If you run more than one site on the same account, check the others for the same redirect, and tell your host that you suspect cross site spread. Cleaning one site while a neighbour site still carries the code can lead to the same redirect coming back.
Remove every copy, then close the way in
Only after you have listed every copy should you remove them, and remove all of them in the same session. Removing one copy and leaving another means visitors keep being redirected, and you lose the chance to tell which copy was the real one.
Replace changed core files, theme files, and plugin files with clean copies from official sources. Remove fake plugins, hidden admin users, and unauthorised scheduled tasks. Remove injected scripts from posts, widgets, and page builder content. Restore the .htaccess file to the normal WordPress block plus only the rules from plugins you recognise.
Once the code is gone, close the way it got in. Update WordPress core, every theme, and every plugin. Remove themes and plugins you do not use, because unused software can still be exploited. Then change every password connected to the site: WordPress admins, hosting, file transfer, and database accounts, and generate new security keys in the configuration file. Change passwords after the code is removed, not before, because passwords set while malware still runs can be captured again. Our reinfection guide explains this order in full: WordPress site keeps getting hacked.
Clear every cache again after cleanup: your caching plugin, your host cache, and any content delivery network cache. A cached infected page can keep redirecting visitors even after the live files are clean.
Verify the redirect is really gone
Repeat the phone test exactly as before: phone on mobile data, private tab, click from a search result. Then repeat the desktop tests: private tab, logged out, typed address and search click. All four must load your own site with no jump to another domain.
Repeat the phone test again the next day. A redirect that returns overnight means a copy survived, usually a hidden plugin, a scheduled task, or a neighbour site on the same account. Go back to the check list above and look for the layer you missed, rather than repeating only the step that worked last time.
Also check your search results. Search for your own domain and look for unfamiliar pages indexed under it. If spam pages appear under your domain, that is a different symptom from a redirect, and our Japanese keyword hack guide covers the index cleanup side of that problem.
If Google shows a warning for your site
If Google Search Console shows a security warning, or search results carry a hacked site warning, do not request a review until the redirect is provably gone in every test above. A review requested while the redirect still fires will fail, and you will have to request it again.
Once every test is clean, open the Security Issues section in Search Console, read what Google flagged, and request a review from there. It can take some days for the warning to clear after a successful review, even when the site itself is already clean. Keep the phone test routine running during that time, so a returning redirect is caught before visitors report it again.
A routine that stops the next redirect
Redirect infections usually return through the same weaknesses: outdated software, unused plugins, shared passwords, and admin accounts nobody reviews. A short routine closes most of them. Update core, themes, and plugins on a schedule, and test updates on a staging copy first when your store or booking flow depends on them. Remove anything you do not use. Review admin users every month and remove accounts that no longer need access. Keep automated backups that live away from the server, and check sometimes that a backup can actually be restored. If you run a store, keep its care routine alongside this one: our WooCommerce maintenance routine and our WordPress maintenance checklist cover the same habits in checklist form.
For the cost side of getting help, read what a malware removal quote usually covers before you compare any offer, and keep our WordPress security services and WordPress maintenance plans in mind if you would rather hand the cleanup to a team. See all of our services on the services page.
Frequently asked questions
Why does my site redirect only on phones?
Redirect code often checks the visitor device and fires only for phones, because phone visitors are less likely to notice a changed address and site owners usually check from a desktop computer. Test on a phone using mobile data, in a private tab, from a search result, not from your desktop.
Why does it only happen when visitors click from Google?
The code checks where the visitor came from. Redirecting only people who arrive from a search keeps the owner, who types the address directly, from noticing. Some versions also skip anyone who has ever logged in to WordPress, which hides the redirect from the owner a second time.
Can a plugin redirect visitors without the site being hacked?
Yes. A redirect plugin rule, a badly set caching rule, or a changed site address can send visitors to the wrong place without any malware. The difference is the destination: a legitimate redirect goes to a page on your own site, while a malicious one goes to an unknown domain selling something or asking visitors to allow notifications.
I removed the code, but the redirect is back. Why?
Something is putting it back: a hidden admin account, a backdoor file, a scheduled task, a fake plugin, or another infected site on the same hosting account. Check all of those, change every password after the code is gone, and look for how the attacker got in, usually an outdated plugin or a stolen password. Our reinfection guide walks through that order step by step.
Will restoring a backup alone fix it?
Only if the backup was taken before the infection arrived, and only if you also close the way in. Restoring a backup taken after the infection restores the redirect code with it. Restoring a clean backup without updating the vulnerable plugin or changing passwords leaves the same door open for the next infection.
Should I warn my visitors while I clean the site?
If visitors are actively being redirected to harmful pages, limit exposure first. Put the site in maintenance mode while you clean it, so new visitors are not sent to the destination page. Tell regular visitors briefly that the site is under maintenance and will return shortly, without describing the attack in detail.
Conclusion
A WordPress site redirecting to spam looks confusing because it hides from the owner by design. The fix is methodical rather than rushed: reproduce the visitor journey, check the innocent settings first, find the server or page layer, remove every copy in the same session, close the entry point, and verify with the same phone test the next day. Skip any one of those steps and the redirect has a clear way back.
If you would rather not work through file and database checks yourself, talk to Raozan IT first. You can reach us on WhatsApp at +8801735127127, through our contact page, or by email at [email protected]. We will look at what changed, explain the scope in plain words, and confirm the next step before any work starts.
