WordPress Redirect Hack: How to Find It, Remove It and Stop It Coming Back

You open your site. It looks perfect. Then a customer emails: "Your site sent me to a page selling fake sneakers." You try it yourself and nothing happens. You start to wonder if they are mistaken.

They are not. This is the WordPress redirect hack, and the fact that you cannot see it is not a coincidence. It is the whole design.

Let's walk through why it behaves this way, where it hides, how to find and remove it, and (the part most guides skip) why it so often comes back.

What the WordPress Redirect Hack Actually Does

A redirect hack is malware that sends your visitors to a site you do not control. The destination is usually spam, a scam, a fake "update your browser" download or a page full of ads. The attacker earns money for every visitor delivered, and your site is the free traffic source.

The clever part is the targeting. The malicious code checks who is visiting before it decides what to do. It will often skip:

• Anyone logged in to WordPress (so you, as the admin, never see it).
• Visitors on desktop computers.
• Repeat visitors, using a cookie to redirect each person only once.
• Search engine crawlers, so Google keeps seeing your normal site.

And it often targets exactly the people most valuable to you: new visitors arriving from a Google search, and people on phones. That is why the first report usually comes from a customer, not from a dashboard.

Imagine a bouncer who lets the owner and the police walk in freely, but quietly steers strangers into the shop next door. That is how this works.

How to Confirm a Redirect Hack

Before you dig into files, confirm that what you are chasing is real. Three quick tests:

1. Visit as a stranger. Use a private window, log out, and use your phone on mobile data. Try the home page and an inner page.
2. Arrive from search. Search for your site name in Google and click your result. Many redirects fire only when the referrer is a search engine.
3. Check Search Console. Open the Security Issues report. If Google has noticed, it lists the problem there. Google's page on malware and unwanted software explains how those warnings and reviews work.

If you see odd behaviour in any of them, you very likely have a WordPress redirect hack. For a broader checklist of what else an infection can look like, see the signs your WordPress site has been hacked.

Where the Redirect Hides

Redirect code needs to run on every page load, so it lives in places that load every time. Here are the usual suspects, roughly in the order worth checking.

Here is the short version, before the detail:

The .htaccess File

On Apache and LiteSpeed servers, .htaccess is a small settings file in your site's root folder. Attackers love it because a few lines can redirect traffic before WordPress even starts. Look for RewriteRule lines that send visitors to a domain you do not recognise, often wrapped in a condition that checks for mobile browsers or a search engine referrer.

A normal WordPress .htaccess is short. If yours has dozens of unfamiliar lines, or a block of code you did not add, that is a red flag. Also check subfolders, because attackers sometimes drop extra .htaccess files inside wp-content or uploads.

Your Site Address in the Options Table

WordPress stores your site's addresses in the database, in two options called siteurl and home. If an attacker changes them, the whole site can bounce to another domain.

You can see them in Settings, then General, as "WordPress Address" and "Site Address". If you cannot reach the admin, the values live in the wp_options table (your table prefix may differ), and you can check them in phpMyAdmin. Both should be your exact address and nothing else.

Injected JavaScript in Theme Files

A few lines of JavaScript can redirect a browser. Attackers add them to header.php, footer.php, functions.php or a theme's JavaScript files. Look for <script> tags pointing at unfamiliar domains, and for long, scrambled strings of letters and numbers, often paired with functions like eval, atob or base64_decode. These are ways of hiding what the code does.

<!-- Example of what to look for: a script loaded from a domain you do not recognise -->
<script src="https://unfamiliar-domain.example/loader.js"></script>

Injected JavaScript in the Database

This is the one that fools people who "cleaned" their theme files and still see the redirect. The script can live inside post content, widget text, or theme options in the database, so no file on disk looks wrong.

You can search the database for <script in posts and options using phpMyAdmin or a search-and-replace tool. Look for scripts you did not write, especially ones that load from external domains.

Rogue or Hijacked Plugins

Two versions of this. In the first, an attacker installs a plugin of their own, often with a bland name that looks legitimate. In the second, a real plugin (usually an outdated one with a known weakness) is modified, so it behaves normally while also running attacker code.

Compare your plugin list with what you installed on purpose. Delete anything unfamiliar after you have taken a backup, and reinstall the real ones fresh from WordPress.org or the vendor.

Includes in wp-config.php

wp-config.php runs on every request, which makes it a favourite. Look for include or require lines near the top or bottom that load a file you do not recognise, or a huge block of encoded text. Careful here: this file also holds your database login, so do not paste it into forums or share screenshots.

How to Find and Remove It, Step by Step

Here is the order that works for removing a WordPress redirect hack. The key idea is to change as little as possible until you have a safety net.

Step 1: Back Up the Infected Site First

Pro tip: Label the infected backup clearly, for example "INFECTED, do not restore", so nobody puts it back live by accident.

Take a full copy of files and database exactly as they are. It feels odd, but it gives you a reference for what changed, a way back if a clean-up step breaks something, and evidence if your host asks questions later. If you also have an older clean backup, keep it separate and clearly labelled. If you decide a restore is quicker than a clean-up, follow how to restore WordPress from backup so you do not bring the infection back.

Stack Guard Free can take a manual full or database-only backup that is verified before it counts, and it restores with one click that is staged and checked first. You get 7 days to keep or roll back after a restore.

Step 2: Scan to Get a List of Suspects

A scan turns "somewhere on my site" into "these files". Stack Guard's malware scanning looks for the patterns of known back doors, web shells, hidden redirects and injected code, and compares every WordPress core file with the official copy for your version. Manual scans and the report are in Free. Our guide to scanning WordPress for malware walks through reading the results.

A scanner will not catch everything (database-only injections are a classic blind spot), so treat its list as a starting point, not a verdict.

Step 3: Fix the Easy, High-Value Spots

Work through the hiding places in this order:

1. Replace .htaccess with a clean WordPress default (or restore it from a clean backup).
2. Check and correct the site address in Settings, then General.
3. Look at wp-config.php for includes or encoded blocks that do not belong.
4. Check the Users screen for administrators you do not recognise.

Step 4: Replace Files Instead of Editing Them

Hand-editing infected files is slow and easy to get wrong. It is safer to replace them with known-good copies:

• WordPress core: download a fresh copy of the same version from WordPress.org and replace wp-admin and wp-includes.
• Plugins and themes: delete and reinstall each one from its official source.
• Anything custom: restore it from your version control or clean backup.

If a core file has been changed, Stack Guard Pro can restore it from WordPress.org with one click, and can quarantine other suspect files (move them somewhere they cannot run, remembering where they came from). Quarantine is the safe alternative to deleting a file you are not sure about.

Step 5: Clean the Database

Search post content, widgets and options for injected <script tags and unfamiliar domains. Remove only what you can identify as malicious. If you are not comfortable editing the database, this is a good moment to ask your host or a developer, since an overzealous search-and-replace can damage real content.

Step 6: Reset Every Credential

Change the passwords for WordPress administrators, your host account, SFTP and the database. Then rotate your security keys, which signs everybody out, including anyone still logged in with a stolen session. Our broader walkthrough, how to recover a hacked WordPress site, covers the full order.

Step 7: Test Like a Stranger Again

Repeat the confirmation tests from earlier: private window, phone on mobile data, arriving from Google. Do it a few times over a day, because some redirect code only fires occasionally.

Why the WordPress Redirect Hack Keeps Coming Back

This is the part that makes people lose their weekend. You clean everything, the redirect stops, and three days later it is back. There are two main reasons.

A Backdoor Is Still There

A backdoor is a small piece of code that lets the attacker back in without a password. It may be a single PHP file with an innocent name, tucked into the uploads folder, a plugin directory or a theme. If you remove the redirect and miss the backdoor, the attacker simply re-installs the redirect.

This is why scheduled checks matter. File change monitoring, a Pro feature, takes a fingerprint of your code files and tells you when one is added, changed or removed. After a clean-up, creating a fresh baseline means a returning backdoor shows up as a change instead of going unnoticed.

The Attacker Still Has a Way In

If the original entry point was a stolen password, a weak administrator login or an outdated plugin, cleaning the site does not close it. Update everything, remove plugins and themes you are not using, and tighten sign-in. Two-factor authentication means a stolen password is no longer enough, and it is included in Stack Guard Free, along with brute force lockouts and a hidden sign-in address.

It also helps to know how they got in. An activity log shows sign-ins, user changes and settings changes, which gives you a timeline to match against the first redirect report. Free keeps core events for 7 days.

Ask Google to Review Your Site Afterwards

If Google flagged your site, you will see warnings in Search Console's Security Issues report, and possibly a "This site may be hacked" label or a red browser screen. Cleaning the site does not always clear those on its own.

Once you are confident the site is clean:

1. Open Search Console and go to the Security Issues report.
2. Check that the listed problems no longer exist on the site.
3. Select the option to request a review.
4. Explain briefly what you found and what you fixed.

Google says that after you fix the problems, you can request a review from that same report. Be honest in your request, and only submit when you are sure. A review that finds the problem still there can slow things down.

Reviews take time, so use the wait to double-check the site and set up the protections above. The full walkthrough is in our guide to removing the "This site may be hacked" warning.

A Quick Prevention List

You do not need to become a security engineer. A short routine covers most of it:

• Keep WordPress, plugins and themes updated, and delete the ones you do not use.
• Use strong, unique passwords and turn on two-factor for administrators.
• Run malware scans on a schedule (manual scans in Free, scheduled scans in Pro).
• Keep a verified, recent backup you can restore from.
• Turn off the theme and plugin code editors so a stolen administrator login cannot edit files from the dashboard. Stack Guard Free has a switch for it.

A WordPress redirect hack is annoying, not mysterious. Once you know where they hide and why they return, they stop feeling like magic and start feeling like a checklist.