Hacked WordPress Site Recovery: Detect, Clean Up and Lock It Down

Finding out your WordPress site has been hacked is stressful, but the recovery process is well understood. The aim is to stop the damage, remove the attacker's access (not only the visible damage), restore a clean site and close the hole they used. Cleaning only the visible symptom is the most common mistake, because most attackers leave a backdoor and return within days.

Work through the steps in order. If the site is a store or holds personal data, also consider legal reporting obligations in your country and tell your payment provider.

Signs that a site is compromised

Some signs are obvious, others are quiet.

• Defaced pages or a ransom message.
• Redirects to spam, pharmacy, gambling or "your browser is out of date" pages, often only for visitors coming from Google or on mobile, so you may not see them yourself.
• Google warnings: "This site may be hacked" or "Deceptive site ahead" in search or in the browser. Check Google Search Console's Security issues report.
• Spam pages in search results, often in Japanese or on pharmaceutical topics (site:example.com viagra).
• Unknown admin users in Users, or admin accounts you did not create.
• Unfamiliar files: PHP files in wp-content/uploads, files with random names, or recently modified files in places you did not touch.
• Unexpected outbound email, your host suspending the account for spam, or email bouncing back to you. Check the Blacklist Checker for your server's IP address.
• Sudden CPU spikes or traffic from a hidden crypto-miner or spam script.
• Changed .htaccess, index.php or wp-config.php.
• Hosting provider notices about malware.

Visitors may see something different from you, so test with a plain request and a search-engine user agent:

curl -sIL -A "Mozilla/5.0 (Linux; Android 13)" -e "https://www.google.com/" https://example.com/ | grep -iE "^(HTTP|location)"
curl -s -A "Googlebot" https://example.com/ | grep -ioE "<script[^>]*src=[^>]+>" | head

The HTTP Header Checker shows how your server responds from an outside address.

Step 1: Contain it

1. Take a copy of the evidence before changing anything: download the full file tree and a database dump, and the web server access and error logs. You will need these to learn how it happened.
2. Put the site into a safe state. Enable maintenance mode, or serve a simple static "back soon" page with a 503 status, so that visitors are not sent to malware and search engines do not index spam. See website maintenance mode done right. Ask your host to suspend or isolate the account if the attack is spreading to other sites on the same account.
3. Change access first. Before cleaning, change every credential that the attacker may have captured. See Step 3.
4. Tell the people who need to know: the host (they often help with logs and scanning), your clients, and for a shop, your payment processor.

Step 2: Decide: restore a clean backup, or clean in place

A clean restore is the most reliable approach if you have a backup from before the compromise.

To work out when it began, look at file modification times, the oldest suspicious file, and the first odd request in the access log:

# files modified in the last 14 days under the web root
find /var/www/html -type f -mtime -14 -not -path "*/cache/*" -printf '%TY-%Tm-%Td %TH:%TM %p\n' | sort -r | head -50

# PHP files in uploads (there should normally be none)
find /var/www/html/wp-content/uploads -type f -name "*.php"

If you restore, remember the hole is still open. Update everything and rotate credentials before putting the site back online, or it will be reinfected. If you have no usable backup, clean in place as below, or hire a professional cleanup service.

Step 3: Reset every credential

Assume everything on the server was readable by the attacker.

• WordPress admin, editor and author passwords. Force a reset for all: wp user list --field=ID | xargs -n1 -I{} wp user reset-password {} --skip-email works for a small user base; on larger sites reset administrators first and force resets for everyone else.
• Delete unknown administrator accounts: wp user list --role=administrator.
• Hosting control panel, SFTP/SSH and database passwords. Update DB_PASSWORD in wp-config.php afterwards.
• Replace the authentication keys and salts, which invalidates all logged-in sessions:

wp config shuffle-salts

• API keys stored in the site (payment, email, maps) and any SSH keys on the server that you do not recognize.
• Email accounts on the domain, since attackers often read reset emails.

Use a password manager and unique, long passwords, and turn on two-factor authentication; the hardening checklist lists more.

Step 4: Clean the files

1. Replace WordPress core with a fresh copy, without touching wp-content or wp-config.php:

wp core verify-checksums
wp core download --force --skip-content --version=$(wp core version)

verify-checksums lists files that differ from the official release, which includes added files and modified ones. Delete files it flags as unknown, such as extra PHP files in wp-admin or wp-includes.

1. Reinstall every plugin and theme from the official source rather than trusting the existing files. For repository plugins:

wp plugin verify-checksums --all
wp plugin install example-plugin --force

For premium plugins and themes, download fresh copies from the vendor. Delete anything unused or abandoned, and any "nulled" (pirated) copy, which is a frequent infection route.

1. Inspect wp-content manually. Look in uploads, mu-plugins, languages and cache for PHP files, and check for unexpected folders. Search for common malicious patterns:

grep -rEl "eval\(base64_decode|gzinflate\(base64_decode|str_rot13|preg_replace\(.*/e['\"]" /var/www/html --include=*.php
grep -rEl "FilesMan|c99shell|wso " /var/www/html --include=*.php

Matches are leads, not proof: some legitimate software uses base64_decode. Open each file and judge. The real danger is files you do not recognize.

1. Check .htaccess, index.php and wp-config.php for injected lines. Look for rules that redirect based on user agent or referrer. Also check .htaccess files in subfolders and hidden files at the top level.
2. Check scheduled tasks and the server itself: wp cron event list for strange events, and on a VPS crontab -l for each user, /etc/cron.*, systemd timers and ~/.ssh/authorized_keys. Malware often re-creates itself from a cron job.

Step 5: Clean the database

Malware can live in the database, not just the files.

• Users: unknown admins in wp_users, and unfamiliar wp_capabilities in wp_usermeta.
• Injected content: spam or <script> or <iframe> tags in posts, widgets and options. Search with WP-CLI:

wp db query "SELECT ID, post_title FROM $(wp db prefix)posts WHERE post_content LIKE '%<script%' OR post_content LIKE '%<iframe%' LIMIT 50;"
wp db query "SELECT option_name FROM $(wp db prefix)options WHERE option_value LIKE '%eval(%' OR option_value LIKE '%base64_decode%';"

• Options such as siteurl, home, active_plugins, and widget_text. Check each for strange values.
• Spam posts and comments: wp post list --post_status=publish --orderby=date --order=DESC | head.

Restore only the clean parts, or restore a clean database backup and re-enter recent legitimate content.

Step 6: Update and close the hole

• Update WordPress core, all plugins and themes: wp core update && wp plugin update --all && wp theme update --all.
• Use your logs to find the entry point. Search the access log around the first suspicious file date for POST requests to plugin files or xmlrpc.php and for repeated failed logins ending in a success. Cross-check against vulnerability databases for the plugins you ran. Without the entry point, you are likely to be hit again.
• Apply the file permission, upload and wp-config.php hardening in the hardening checklist.
• Disable PHP execution in wp-content/uploads.
• Check that your SSL certificate and headers are correct with the SSL Checker and Security Headers Checker.

Step 7: Remove warnings and relaunch

1. Test thoroughly using the user-agent and referrer methods above, from a different network.
2. Remove maintenance mode and purge all caches (plugin, server and CDN).
3. In Google Search Console, open Security issues and request a review once clean. Reviews generally take a few days. Spam URLs that remain in the index can be removed from search with the Removals tool, and by serving 404 or 410 for them.
4. If the site or its IP was blocklisted, check the Blacklist Checker and follow the email blacklist removal guide for sending reputation.
5. If emails were sent, check SPF, DKIM and DMARC so spoofing and abuse are visible in reports.

Step 8: Monitor and keep backups

For at least a month afterward, watch closely:

• Run wp core verify-checksums and wp plugin verify-checksums --all from a daily cron, and alert on changes.
• Set up an uptime monitor with a keyword check on your page, which can catch defacement or injected content, and with SSL and domain alerts.
• Keep daily off-site backups and test a restore. If you do not already have a safe process, write down what happened in a short report; the incident postmortem template is a good format.

Next steps

• Check reputation with the Blacklist Checker.
• Review your response headers with the Security Headers Checker.
• Run the Website Health Check after cleanup.
• Add monitoring with the uptime monitor.
• Follow the WordPress security hardening checklist.

FAQ

Can I just restore a backup and be done?

Only if the backup predates the compromise and you also close the vulnerability and reset all credentials. Otherwise the attacker walks back in through the same hole with the same access.

How do I know the malware is really gone?

You cannot prove it with certainty, but a fresh core and fresh plugins from official sources, verified checksums, no unknown files or users, a clean database and no reinfection for several weeks is a strong sign. Keep monitoring.

Will Google penalize me for a hack?

Google may flag the site with a security warning and drop spam pages, which hurts traffic until you clean up and request a review in Search Console. Quick cleanup limits the damage; see website downtime SEO impact.

Should I hire a professional?

If you handle payments or personal data, cannot find the entry point, or the site is reinfected after a cleanup, yes. A host or security specialist can analyze server logs and check other sites on the account.

Why did the hack come back after I cleaned it?

A backdoor file, a rogue admin user, a scheduled task, a vulnerable plugin that is still installed or stolen credentials that you did not rotate. Repeat the checks for each of those.

This page is general information written by our editorial team and updated when documentation changes. Servers and providers differ, so test changes safely first. See our editorial policy and disclaimer.