WordPress site redirecting to another site: find and remove the redirect

Why the redirect does not happen for you

A redirect planted during a hack picks its targets. It tends to spare the person who runs the site, because that keeps it in place longer. The usual conditions:

• Where the visitor comes from: only visitors arriving from a search engine or a social network are redirected. The code reads the Referer request header.
• The device: only phones are redirected. The code reads the User-Agent header.
• Being logged in: a logged-in WordPress administrator sees the normal site.
• The first visit: a cookie records that the visitor has already been redirected, so the next visit looks normal and the problem seems to come and go.

So when a customer writes "your site sends me somewhere else", take it at face value, even if everything looks right on your screen.

Reproduce the redirect

Put yourself in the shoes of the visitor who gets redirected:

1. Open a private window, search for your business name and click your own result.
2. Do the same from a phone, on mobile data rather than Wi-Fi.
3. Write down the destination address, the time and the device. Your host will ask for them, and so will the review request to Google later on.

If you have a terminal, this command requests your home page while posing as an iPhone coming from Google:

curl -s -i -A "Mozilla/5.0 (iPhone; CPU iPhone OS 17_0 like Mac OS X)" -e "https://www.google.com/" https://www.your-site.com/

Read the first lines of the response. A 301 or 302 status followed by a Location: line pointing somewhere unknown means the server does the redirecting: look in .htaccess or a PHP file. A 200 status while the browser still gets redirected means the redirect runs inside the page, in JavaScript: it usually lives in the database or in a theme file.

Three things to do before you touch the site

1. A full copy, as it is. Files and database, dated, stored away from the server. It is your evidence, your point of comparison and your safety net if the clean-up removes something you needed.
2. New passwords, from a clean device. Your hosting account, FTP or SFTP accounts, the database user (then update DB_PASSWORD in wp-config.php), and every WordPress administrator account.
3. New security keys. Replace the eight lines from AUTH_KEY to NONCE_SALT in wp-config.php with a fresh set from https://api.wordpress.org/secret-key/1.1/salt/. Every open session is logged out, including the intruder’s.

wp config shuffle-salts

Where the redirect hides

1. The .htaccess file

At the site root, and sometimes in a subfolder, .htaccess can carry rewrite rules added by the attacker. The block WordPress writes itself is short and sits between # BEGIN WordPress and # END WordPress:

# BEGIN WordPress
# The directives (lines) between "BEGIN WordPress" and "END WordPress" are
# dynamically generated, and should only be modified via WordPress filters.
# Any changes to the directives between these markers will be overwritten.
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>

# END WordPress

A RewriteCond testing %{HTTP_REFERER} (google, bing, facebook) or %{HTTP_USER_AGENT} (android, iphone, mobile), followed by a RewriteRule to an outside address, is the redirect. Caching and security plugins also write blocks of their own, labelled with their name: match each block against your plugin list before removing it.

2. The PHP files

WP-CLI checks WordPress core and plugin files against the checksums published by WordPress.org and lists every file that was changed or added:

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

The second command covers plugins distributed through the WordPress.org directory. A plugin bought from its vendor is compared against a fresh copy downloaded from your account with that vendor. This is common: among the 540 SMB WordPress sites in our survey of 1 September 2026, 66% run at least one plugin that is not in the public directory.

Without WP-CLI, two searches give you a first shortlist:

find . -name "*.php" -mtime -30
find wp-content/uploads -name "*.php"

The first lists PHP files modified in the last 30 days, the second lists PHP files stored in the media folder, where they are suspicious by default (some plugins place an empty index.php there, which is fine). Modification dates can be faked, so an old file in the wrong place still deserves a look.

Open these first: wp-config.php, the root index.php, the active theme’s functions.php and header.php, and the wp-content/mu-plugins folder, whose plugins load automatically and cannot be switched off from the dashboard. Things to look for: eval(, base64_decode(, gzinflate(, str_rot13(, long unreadable strings, or window.location followed by an address you do not recognise.

3. The database

A JavaScript redirect is often stored in post content or in the settings, where no file will show it. WP-CLI searches every WordPress table for a string:

wp db search "<script"
wp db search "fromCharCode"

Without WP-CLI, run the same searches from phpMyAdmin, in the SQL tab:

SELECT ID, post_title FROM wp_posts WHERE post_content LIKE '%<script%';
SELECT option_name FROM wp_options WHERE option_value LIKE '%<script%';

Some hits are legitimate: an analytics tag, a cookie banner, a widget you added. Anything that matches nothing you installed deserves a closer look, especially a script that builds an address out of character codes.

4. The address settings and the accounts

Under Settings > General, "WordPress Address (URL)" and "Site Address (URL)" must show your own domain. The same values can be forced in wp-config.php with the WP_HOME and WP_SITEURL constants, so check both places.

wp option get home
wp option get siteurl
wp user list --role=administrator

When the constants are defined, the first two commands return their values. The last one lists administrators with their registration date; in the dashboard, the same list comes from Users, filtered on the Administrator role. An account nobody recognises gets deleted, with its content attributed to a legitimate account.

Remove the redirect, then the way in

Deleting the line that redirects stops the symptom. The access the attacker used stays open until you find it, and the redirect comes back within days. The order that holds:

1. Replace core files with a fresh copy: delete the wp-admin and wp-includes folders, then run wp core download --skip-content --force, which rewrites core without touching your plugins, themes and media. The command overwrites existing files but deletes nothing that was added, which is why the two folders go first, and why unknown PHP files at the root are removed by hand.
2. Reinstall the theme and every plugin from their official source, and delete the ones the site no longer uses, deactivated ones included: their files are still on the server.
3. Remove stray PHP files from wp-content/uploads, the rules added to .htaccess and the scripts found in the database.
4. Review scheduled tasks with wp cron event list: a task with an unfamiliar name can put the code back.
5. Update WordPress, the theme and the plugins.
6. Run the tests from the start again, from several devices, over several days.

If the site stores personal data (forms, customer accounts, orders), write down when you discovered the hack. In the European Union, the GDPR requires a personal data breach to be notified to the supervisory authority within 72 hours of becoming aware of it, unless the breach is unlikely to result in a risk to the people concerned.

Google, and what your visitors see

Once Google detects the redirect, Chrome can show a red "Dangerous site" page before opening the site, and Google can write "This site may be hacked" under your search result. The Security issues report in Google Search Console shows what was found and on which URLs. When the site is clean, the Request review button starts the check.