WordPress Site Hacked and Redirecting? How to Detect It, Clean It and Stop It Coming Back

If your WordPress site sends visitors to spam, scam or “you won a prize” pages, someone has injected code that redirects them. It usually hides in .htaccess, a modified core, theme or plugin file, or the database. Confirm it safely, lock down every login, back up, remove the code and the way the attacker got in, then ask Google to remove any warning.

This guide walks through each step in order, with the checks I’d run, and ends with what stops it from coming back, which is where most clean-ups fail.

Signs your WordPress site has a redirect hack

Redirect hacks are built to hide from the site owner. The malicious code often fires only for some visitors: people arriving from Google, mobile users, first-time visitors, or anyone who isn’t logged in. That’s why “it works fine for me” is so common. Watch for:

• Visitors, clients or colleagues report landing on a different site, especially from Google results or on their phones.
• Google shows “This site may be hacked” or a red browser warning, or Search Console reports a problem in Security issues.
• Search results for your domain show spam titles, foreign-language pages or URLs you never created.
• There are admin users you don’t recognise, or user accounts you created have new roles.
• Your host suspends the site or reports malware, or your emails start landing in spam because the server’s IP was blacklisted.
• Unknown scripts appear in the page source, or there’s a sudden drop in Core Web Vitals with no change on your side.

WordPress.org’s own “My site was hacked” FAQ calls these indicators of compromise. Write down which ones you see and when you first noticed them. You’ll need that later.

Admin users added that you didn’t create

A new administrator account is a strong sign the attacker has kept a way back in. Don’t just delete it straight away: note its username, email and creation date first, because the date helps you work out when the breach happened and which backups are clean.

Confirm the redirect without exposing your own computer

Google recommends not opening suspected malware pages in your normal browser, because malware often spreads through browser vulnerabilities. Its guide to sites hacked with malware uses curl instead, sending a Google referrer and a different user agent to trigger conditional redirects. From a terminal:

# Plain request: look at the status code and any Location header
curl -sI https://example.com/

# Pretend to arrive from Google search
curl -sI --referer "https://www.google.com/" https://example.com/

# Pretend to be a phone arriving from Google
curl -sI --referer "https://www.google.com/" \
  --user-agent "Mozilla/5.0 (Linux; Android 14; Pixel 8) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/129.0 Mobile Safari/537.36" \
  https://example.com/

A 301 or 302 with a Location: header pointing to a domain you don’t own confirms a server-side redirect. If every response is 200, the redirect may be in JavaScript. Fetch the full HTML (curl -s without -I) and look for unfamiliar <script> tags, eval(, atob( or window.location near the top or bottom of the page.

Also check the Security Issues report in Search Console. Google treats it as the source of truth and lists sample affected URLs. The sample isn’t complete, so don’t assume only those pages are infected.

The first hour: contain it

Before you hunt for the code, stop the attacker from making further changes. This follows the order in WordPress.org’s hacked-site FAQ:

1. Document what you see, when, and anything that changed recently (a new plugin, a theme edit, a new user).
2. Tell your host. On shared hosting, other sites on the server may be affected, and the host may already be acting.
3. Take a snapshot of files and database as they are now, even though they’re infected. You need it for forensics and as a fallback if the clean-up breaks something.
4. Reset all access, not just your WordPress password: every WordPress user (administrators first), SFTP/FTP, the hosting control panel (cPanel or similar) and the database user. Use long, unique passwords and turn on two-factor authentication.
5. Log everyone out by replacing the secret keys (salts) in wp-config.php with a fresh set from the WordPress.org key generator.
6. Scan your own computer. The FAQ points out that some infections start with stolen FTP or admin passwords taken from the site owner’s machine.

Where the redirect usually hides

If you have SSH and WP-CLI, these commands cover most of the table. Run them from the WordPress root:

# Core files that don't match WordPress.org's checksums
wp core verify-checksums

# Plugins from the WordPress.org directory that were modified
wp plugin verify-checksums --all

# Who has admin rights?
wp user list --role=administrator --fields=ID,user_login,user_email,user_registered

# Has the site address been changed?
wp option get siteurl
wp option get home

# Script tags hidden in the database
wp db search "<script" --all-tables

# PHP files in the uploads folder (there should normally be none)
find wp-content/uploads -name "*.php"

Two limits to know: plugin verify-checksums only checks plugins hosted on WordPress.org, so premium plugins and themes need comparing against a fresh download from the vendor. And db search will also find legitimate scripts (tracking codes, embeds), so read each match before deleting anything.

No SSH? Use the file manager in your hosting panel or SFTP for the files, and phpMyAdmin for the database. It’s slower, but the places to look are the same.

Clean it, step by step

1. Replace WordPress core. Download the same version you’re running from WordPress.org and replace /wp-admin and /wp-includes entirely over SFTP. The FAQ advises against the dashboard’s reinstall button, because it overwrites existing files but doesn’t remove new ones the attacker added.
2. Replace plugins and themes with clean copies from WordPress.org or the vendor. Delete any plugin or theme you don’t use instead of cleaning it.
3. Restore a clean .htaccess with only the rules you need, and check subfolders for extra .htaccess files.
4. Clean wp-config.php: compare it line by line with wp-config-sample.php and keep only your real settings.
5. Clean the database: fix siteurl and home, remove injected scripts, and delete unknown admin users (after noting their details).
6. Remove PHP files from uploads and any must-use plugins you didn’t install.
7. Update everything to the latest versions: core, plugins, themes, PHP.
8. Change all passwords and salts again. The first reset may have happened while the attacker still had a backdoor.
9. Re-run the curl checks and a malware scan, then watch the site for a few days.

What about restoring a backup? It’s often the fastest route, but only if the backup predates the infection. That’s where the admin-user creation date and file modification dates help. Even after a clean restore, you still have to close the hole, or the same attack will work again.

Get Google’s warning removed

Warnings don’t disappear on their own once you clean up. Google’s request-a-review guide lists the prerequisites: the site is verified in Search Console, cleaned, the vulnerability is fixed, and the site is back online. Then:

1. Re-check your homepage and the sample URLs with curl. They should all return clean responses.
2. Open Security issues in Search Console and select Request review.
3. Explain what was wrong, what you removed and how you closed the vulnerability (for example: “Removed redirect rules from .htaccess, replaced core and plugin files, deleted an unknown admin account, updated an outdated plugin”).

Only request the review once you’re sure. Google notes that requesting it while the problem is still there only extends the time your site stays flagged.

Why WordPress gets hacked again, and how to stop it

“Hacked again” almost always means the clean-up removed the symptom but not the way in: a backdoor file left behind, a second admin account, a reused password, unchanged salts, or the same outdated plugin. WordPress’s hardening guide covers the fixes that close those gaps:

• Keep everything updated and delete plugins and themes you don’t use.
• Disable the built-in file editor so a stolen admin login can’t be used to edit PHP from the dashboard. Add this to wp-config.php:

define( 'DISALLOW_FILE_EDIT', true );

• Least privilege. Give people and tools only the role they need. Few people should be administrators, and integrations should use scoped application passwords for tools and AI agents rather than an admin’s password.
• Two-factor authentication for every account that can publish or install anything.
• SFTP, not FTP, so passwords aren’t sent in plain text.
• A web application firewall, at the server, as a plugin, or as a proxy service in front of the site.
• Off-site backups you can trust: regular snapshots of files and database, kept long enough that you’ll still have a pre-infection copy if a hack goes unnoticed for weeks.
• Monitoring: file-change alerts and uptime checks, so you hear about a new file or an unexpected redirect within minutes, not when a client complains.

This is the part of my hosting work I care most about. I clean up hacked WordPress sites, then close the hole that let the attacker in, and I manage cPanel and VPS servers with hardening and monitoring built in, keeping 99.9% uptime across managed infrastructure. If you’d like to know where your own setup stands, start with a free site health and speed check as part of my MarTech audit. For the wider picture, here is a security and performance check you can run on the whole stack.

FAQ

How do I check redirects on my WordPress site?

Request your pages with curl -sI, with and without a Google referrer and a mobile user agent, and look for 301/302 responses pointing to other domains. Then check your .htaccess files and any redirect plugin’s rules for entries you didn’t add.

Can you get malware from a redirect?

The redirect itself sends you to another site, and that site may try to install malware or phish for details. That’s why Google advises investigating hacked pages with tools like curl instead of a normal browser.

Will a security plugin remove the hack?

A scanner helps you find infected files, and WordPress.org recommends combining a plugin-based scanner with a remote one. Neither replaces the manual steps: resetting access, replacing core and plugin files, and fixing the vulnerability that let the attacker in.

Why does the redirect only happen on mobile or from Google?

Attackers target visitors arriving from search and avoid the site owner (who is usually logged in, on desktop, typing the URL directly). It keeps the hack running longer before anyone notices.