A WordPress hacked redirect is malicious code that sends some or all of your visitors to a spam, scam or malware site. It usually hides in .htaccess, wp-config.php, a theme file, a rogue plugin, or JavaScript injected into the database. To remove it, reproduce the redirect, find the code, clean it, close the hole the attacker used, then rotate every password and your WordPress salts.
The hard part is that the redirect often skips you. Many of these scripts only fire for visitors arriving from Google, on phones, or on a first visit while logged out. So “it works fine for me” proves nothing.
This post covers redirects that hit real visitors. If your problem is spam pages or Japanese keywords showing up in Google, that’s a different infection, covered in WordPress SEO spam.
Which Redirect Are You Dealing With?
The trigger tells you where a WordPress hacked redirect lives. When I get a redirect report, the first thing I ask is who sees it and when. Here’s the condition map I work from.
| Who gets redirected | Most likely trigger | First place I check |
|---|---|---|
| Everyone, every time | Changed siteurl/home options or a rule in .htaccess | Database options, then .htaccess |
| Only visitors from Google or other search engines | Code checks the referrer | .htaccess, index.php, theme functions.php |
| Only mobile visitors | Code checks the user agent | .htaccess, injected JavaScript, ad scripts |
| Only on first visit | Code sets a cookie so it fires once | Injected JavaScript in posts, widgets or theme files |
| Only logged-out visitors | Code skips anyone with a WordPress login cookie | PHP in theme, plugins or mu-plugins |
Google’s spam policies say this directly. Hackers “might inject malicious code to your website that redirects some users to harmful or spammy pages,” and the kind of redirect “sometimes depends on the referrer, user agent, or device.” That’s why your customers see it and you don’t.
Why Does My Site Only Redirect Some Visitors?
A selective WordPress hacked redirect survives longer. If the owner never sees the problem, nobody fixes it. The logged-out condition is the sneakiest one, because site owners are almost always logged in when they check their own site.
If you’re logged in, open a private window and test again. If it still doesn’t happen, search your own brand on your phone and tap the Google result, using mobile data rather than office Wi-Fi. If that doesn’t trigger it either, ask the person who reported it for the exact path: device, browser, where they clicked from, and the URL they landed on.
There’s one branch that isn’t a hack at all. Google’s Manual Actions help for “Sneaky mobile redirects” says it has seen mobile-only redirects happen without the site owner’s knowledge, and points to third-party scripts, including ad monetization code, as one cause. So if the redirect only happens on mobile and only on pages with ads, check your ad network before you assume your files are infected.
How Do I Reproduce the Redirect Safely?
Don’t keep clicking through a WordPress hacked redirect to the scam site on your work laptop. I reproduce redirects from a terminal with curl, which fetches the response headers and HTML without running any JavaScript or downloading anything the page tries to push.
These commands only request your own page with different headers:
curl -sI https://yourdomain.com/
curl -sI -e "https://www.google.com/" https://yourdomain.com/
curl -sI -A "Mozilla/5.0 (iPhone; CPU iPhone OS 17_0 like Mac OS X)" -e "https://www.google.com/" https://yourdomain.com/
curl -s -A "Mozilla/5.0 (iPhone; CPU iPhone OS 17_0 like Mac OS X)" -e "https://www.google.com/" https://yourdomain.com/ | grep -iE "window.location|document.location|http-equiv=.refresh|<script[^>]+src"
The first is a plain request. The second pretends the visitor came from Google. The third adds a phone user agent. Look for a 301, 302 or 307 status with a Location: header pointing somewhere you don’t own. The fourth pulls the full page as a mobile Google visitor and lists redirect code and external scripts.
If a header redirect appears, the code runs on the server: .htaccess, PHP files, or a plugin. If headers are clean but the grep finds a strange script, the redirect is JavaScript in the browser, and it usually lives in the database or a theme file. If nothing shows in curl, the script may need a real browser to fire. Use the URL Inspection tool in Search Console, run a live test and read the rendered HTML.
Where Does a WordPress Hacked Redirect Hide?
Take a full backup of files and database before you change anything, and store it off the server. The WordPress.org hacked-site FAQ recommends a snapshot even of the infected site, so you have something to fall back on if cleanup breaks the theme. Then work through these spots.
The .htaccess File
In my experience this is the first place to open for any redirect that shows up in the headers. Look for RewriteCond lines that test HTTP_REFERER or HTTP_USER_AGENT for Google or mobile browsers, followed by a RewriteRule pointing to an outside domain. Check subfolders too, since .htaccess files can sit in any directory. The WordPress.org FAQ calls it one of the files most often used for this.
wp-config.php and Root PHP Files
Compare wp-config.php against a clean copy and look for code above the “That’s all, stop editing” line that you didn’t add. Then run wp core verify-checksums. It checks core files against WordPress.org checksums, and a modified index.php or wp-load.php shows up right away.
The siteurl and home Options
If every visitor goes to the same strange domain, check these two values first:
wp option get siteurl
wp option get home
If either shows a domain you don’t own, set it back and then find out how it changed. Someone had admin or database access.
Scripts Injected Into the Database
JavaScript redirects often live inside post content, widgets or theme settings. These read-only queries list the rows that contain script tags (change wp_ if your table prefix differs):
wp db query "SELECT ID, post_title FROM wp_posts WHERE post_content LIKE '%<script%'"
wp db query "SELECT option_name FROM wp_options WHERE option_value LIKE '%<script%'"
Some hits are legit, like tracking codes or embed widgets. What I’m looking for is a script loading from a domain I don’t recognize, or a long obfuscated string.
Theme Files, Plugins and mu-plugins
Check header.php, footer.php and functions.php in the active theme. Then list plugins with wp plugin list and look for anything you didn’t install, especially one with a generic name. Don’t forget wp-content/mu-plugins: “must-use” plugins load automatically and don’t appear in the normal plugins screen, which makes them an easy place to hide code.
For a broader sweep, this lists files with common obfuscation patterns. Expect false positives:
grep -rlE "eval\(|base64_decode\(|gzinflate\(" wp-content/
What Order Should the Cleanup Follow?
I clean up a WordPress hacked redirect in this order, because each step protects the next.
- Back up the infected site so you can roll back a mistake.
- Change hosting, SFTP, database and admin passwords. Delete admin users you don’t recognize.
- Remove the redirect code from the spots above.
- Reinstall WordPress core, then every plugin and theme from WordPress.org or the vendor. The WordPress.org FAQ says
/wp-adminand/wp-includescan be replaced safely with the same version. Delete what you don’t use. - Find the entry point. Outdated plugins, nulled themes and reused passwords are the usual suspects. If you don’t close it, expect the redirect back.
- Rotate the salts and change passwords again. New security keys in
wp-config.phplog everyone out, which kills any session the attacker still holds.wp config shuffle-saltsdoes it in one command. - Re-run the curl tests from mobile and Google referrers, logged out.
On scanners, I use them as a second opinion only. The free Wordfence plugin compares core, theme and plugin files against the WordPress.org repository, though its plugin page says free users get malware signatures 30 days late. Sucuri SiteCheck scans from outside and, by Sucuri’s own description, can’t see server-side files.
What If Chrome Shows “Deceptive Site Ahead”?
That’s Google Safe Browsing. Google’s documentation on social engineering says Chrome “may display a ‘Deceptive site ahead’ warning when visitors view your site.” Other warnings exist for malware, and search results can carry a “This site may be hacked” label.
Check your status first. Look up your domain in Google’s Safe Browsing site status tool and open the Security Issues report in Search Console. Redirect infections often appear there as “Hacked: Code injection.”
Then request a review, once, after the cleanup. Google’s hacked-site guidance says phishing reviews take about a day and malware reviews a few days, while spam hacks can take up to several weeks. Write what you removed and how you closed the hole. Don’t resubmit while a review is pending, because Google’s help page says that can slow things down.
A browser warning also means lost trust, not just lost traffic. I’d tell regular customers or email subscribers that the issue is fixed once the warning is gone.
How Do I Stop the Redirect Coming Back?
When a redirect comes back, my first suspects are always the same three: the original hole was never found, a backdoor was missed, or passwords weren’t changed after the clean.
- Update everything, and delete what you don’t use. An inactive plugin can still be exploited.
- Turn on two-factor authentication for every admin account.
- Disable the file editor with
define( 'DISALLOW_FILE_EDIT', true );inwp-config.php. WordPress’s hardening guide says it won’t stop uploaded malware but “might stop some attacks.” - Keep off-server backups so the next cleanup is a restore, not a hunt.
- Watch Search Console for new Security Issues and unknown owners.
My WordPress maintenance checklist turns these into a weekly and monthly routine. And if the hack left indexing damage behind, my technical SEO checklist is the sweep I run once a site is clean.
Quick Decision Table
| If curl shows | And | Then |
|---|---|---|
| 30x redirect for everyone | siteurl or home is wrong | Fix the options, then find who changed them |
| 30x only with Google referrer or mobile UA | Rule found in .htaccess | Replace .htaccess with a clean version, check subfolders |
| 30x only for logged-out visitors | No .htaccess rule | Check theme files, plugins and mu-plugins |
| No 30x, strange external script | Script in wp_posts or wp_options | Clean the database rows, then find the entry point |
| Nothing at all | Only mobile pages with ads redirect | Test the ad scripts one by one |
| Clean everywhere | Chrome warning still showing | Request a review in Security Issues |
When It’s Time to Get Help
If the WordPress hacked redirect comes back after a full cleanup, stop and bring in someone who does WordPress incident response. The same goes if your host has suspended the account, or the site takes payments or stores customer data. Ask your host whether other sites on the same hosting account are infected, since a shared account can reinfect a clean site.
That’s the kind of job we take on at Skyranko under WordPress care and hacked-site repair. We quote it after a free audit.
Frequently Asked Questions
Why Does My WordPress Site Redirect Only on Mobile?
The redirect code checks the visitor’s user agent and only fires for phones, because site owners rarely test their own site on mobile. It’s often in .htaccess or injected JavaScript. Google has also seen mobile-only redirects caused by third-party ad scripts, so test those too if your files look clean.
Why Do I Get Redirected From Google but Not When I Type My URL?
The code checks the referrer. Visitors arriving from a search result carry a Google referrer, and the hack only redirects them. Reproduce it with curl -sI -e "https://www.google.com/" and your URL, then look for a rule testing HTTP_REFERER in .htaccess or PHP files.
Will Changing My Password Stop a WordPress Hacked Redirect?
No, not on its own. The redirect code keeps running until you remove it, and backdoors don’t need your password. Change passwords at the start and again after cleanup, and rotate your WordPress salts so every existing login session ends.
How Long Does It Take for the Deceptive Site Warning to Go Away?
After you request a review, Google’s guidance says phishing reviews take about a day and malware reviews a few days. Only request it once the whole site is clean, and don’t resubmit while the review is pending.
Last updated: September 2026 by Mizanur Rahman



