What to do when your WordPress site is hacked

A hacked WordPress site rarely makes the problem obvious. Google shows “This site may be hacked” under your listing, or a customer says your homepage sent them to a casino. Or there is an admin user you never created. The obvious move is to restore last night’s backup and get back to work. That is also how many sites end up hacked twice.

Restoring a backup, deleting the strange script or running one clean scan all fix the symptom. If the attacker still has a way in, they come back. The steps below are in order, and the order is the point.

Is the site actually hacked, or just broken?

Check this before anything else, because the two problems need opposite responses. WordPress.org’s hacked-site FAQ lists these as stronger signs of a hack:

• Google or a browser flags the site.
• A scanner reports malware.
• Your host suspends the account.
• Users appear that nobody created.
• Pages are visibly defaced.

Add redirects you didn’t set up and scripts in the page source that you don’t recognise.

Some messages look alarming but usually have ordinary causes: “500 Internal Server Error”, “There has been a critical error on this website”, “Error establishing a database connection” and the white screen. Most come from a plugin conflict, a PHP fatal error or a database login problem. Our guides to fixing a 500 server error and fixing a WordPress fatal error cover those. If what you have is a fault rather than an intruder, SiteSelf can find and fix the broken part when you ask in chat. A confirmed hack is work for your host or a security specialist.

A clean-looking homepage doesn’t prove much either. Injected redirects often target only mobile visitors, logged-out visitors or people arriving from Google, so administrators see a normal site. Open a private window, stay logged out, and check on a phone too.

What to do in the first hour, before you delete anything

Your first job is to stop harm to visitors and keep evidence. Cleaning comes later. Kinsta’s malware documentation warns that wiping or resetting the site straight away can destroy forensic evidence without closing the hole the attacker used.

1. Write down what you see. Note the symptom, when you first noticed it, the URLs involved and anything that changed recently. WordPress.org’s FAQ recommends doing this before you contact your host.
2. Contact your host. Ask them to look at the whole hosting account and whether they can restrict public access while you work. A maintenance page served by compromised WordPress code may not block direct requests to malicious files.
3. Save a copy of everything, infected or not. That means files, the database, and the access and error logs. Label the copy as compromised and store it away from your normal backups so nobody restores it later by mistake.
4. If you run a store and the checkout may have been changed, pause it. Contact your payment provider through its normal support channel.

Don’t install three security plugins, bulk-delete unfamiliar files or restore the newest backup during this hour. Each one changes the evidence you need to find the way in.

How attackers usually get into WordPress

The entry point decides whether the cleanup holds, so find it before you rebuild. Here are the routes, from most to least common.

Vulnerable or outdated plugins and themes

Patchstack’s 2026 report counted 11,334 new WordPress vulnerabilities in 2025, 42% more than the year before. 91% were in plugins and only six were in core. 46% had no fix from the developer when they were made public. Patchstack also reports a weighted median of five hours from disclosure to the first observed attack. That figure is weighted toward the most heavily attacked bugs, so it doesn’t mean every flaw is hit in five hours. It does mean a monthly update routine is slow compared with an attack. All of these counts are found flaws, not hacked sites.

Stolen credentials

Firewalls and login-lockout plugins don’t see logins to your hosting control panel, SFTP or database. WordPress.org’s FAQ also names malware on the administrator’s own computer as a way FTP and wp-admin passwords get stolen. If you change your passwords on an infected laptop, the attacker gets the new ones too.

Pirated (“nulled”) plugins and themes, and neighbours on shared hosting

Pirated premium plugins often ship with a backdoor already in place. On shared hosting, one compromised site can reach the other sites in the same account. That is why moving hosts on its own often brings the infection along.

Expect some uncertainty here. A disabled security plugin, a strange file and a new admin are all clues, but they rarely show which came first. Host logs are usually the best evidence you have.

Why deleting the malicious code is not the fix

The code you can see was put there by something you can’t see yet. WordPress.org’s FAQ points out that the dashboard’s reinstall only overwrites existing files. Files the attacker added stay where they are. Attackers commonly leave a way back in these places:

• Administrator accounts that exist in the database but don’t appear in the Users screen.
• Changed rows in wp_options, or injected content in posts.
• Redirect rules in .htaccess, and edits to wp-config.php.
• PHP files in wp-content/mu-plugins, drop-ins, or wp-content/uploads.
• WordPress cron events and server cron jobs.
• Files outside public_html, or a second WordPress install in a subfolder.

On the WordPress.org forums, one agency reported several client sites hacked the same way: the same rogue user, a plugin called “hellos”, and file-manager plugins installed. Cleaning didn’t stop it, and the sites kept getting reinfected. That pattern points to access outside WordPress, not a missed file.

If you have SSH and WP-CLI, these commands give you a fast first look. They change nothing.

wp core verify-checksums
wp plugin verify-checksums --all
wp user list --role=administrator
wp cron event list

The plugin checksum check only covers plugins from WordPress.org. To find admins that the dashboard hides, query the database directly. Change the wp_ prefix if yours is different:

SELECT u.ID, u.user_login, u.user_email, u.user_registered
FROM wp_users u
JOIN wp_usermeta m ON m.user_id = u.ID
WHERE m.meta_key = 'wp_capabilities'
  AND m.meta_value LIKE '%administrator%';

How to clean the site without restoring the hack

Rebuild from copies you trust instead of patching what is there. Keep the site restricted until you finish.

1. Replace core with the same version. Delete wp-admin and wp-includes, then upload fresh copies from the matching official release. WordPress.org says this is appropriate only with the same version. Uploading on top of the old folders leaves the attacker’s extra files in place.
2. Delete plugin and theme folders and reinstall them from the original source. Remove anything unused or pirated. Keep custom code aside and review it before you put it back.
3. Check uploads, configuration and scheduled tasks by hand. Look for PHP in uploads, files with double extensions, unknown cron events and edits to .htaccess or wp-config.php. Ask the host to check server-level cron jobs and anything above the web root.
4. Clean the database. Remove unknown admins, then search posts and options for injected scripts and links. Kinsta notes that database infections can take more than one round.
5. Use a backup only if you know it is clean, and only after the entry point is closed. A backup made before you noticed the hack may still contain it. Our guide to restoring a WordPress site from backup covers how to do the restore once you have a trustworthy copy.

Scanners help here, but they don’t diagnose the problem for you. One site owner on the WordPress.org forums reported six months of returning malware despite running Wordfence every day. Treat scan results as leads, and back up any file before you change it. Our guide to malware removal that doesn’t come back covers the file and database checks in more detail.

Which credentials to change, and why you change them twice

Change every credential, not just your WordPress password. Do it from a device you trust.

• Every WordPress administrator and editor account.
• The hosting control panel, and the email address it sends password resets to.
• SFTP and FTP accounts. Remove the ones nobody uses, and remove SSH keys you don’t recognise.
• The database user. Update wp-config.php to match.
• API keys and SMTP passwords stored on the site.
• The WordPress secret keys (salts). Changing them logs everyone out. WP-CLI does it with wp config shuffle-salts.

WordPress.org’s FAQ says to change passwords again once the cleanup is done. Anything you changed while malicious code was still running may have been captured.

How to confirm the site is clean and get Google’s warning removed

Check the site the way the attacker wanted visitors to see it. Use a logged-out browser and a phone, open the exact URLs that redirected before, and try a link from Google search results, not just the homepage. Clear the page cache, the host’s cache and any CDN cache first.

Google’s Search Console help says the sample URLs in the Security issues report may not be a complete list. It also advises against opening infected pages directly in your browser; use URL Inspection to see what Google gets. Request a review only after every issue is fixed across the whole site, and explain what you fixed. Google says reviews often take days or weeks. Don’t submit another request while one is pending.

After you reopen, watch the site for a few days. Check for files coming back, new admins, spam going out from the site’s email, and forms that suddenly behave differently.

If the hacked site is a WooCommerce store

WooCommerce’s security FAQ says a store is only as secure as its WordPress installation, and that one badly written plugin or code snippet can put the site and its data at risk. Customer contact details and orders are stored in your site’s database. Card numbers and security codes generally go straight to the payment processor, but payment tokens may be stored on the site. After a store hack, ask your payment gateway and your host what they can see, not just WordPress. Get qualified advice on whether you have to notify customers. The rules depend on where you and your customers are.

When to stop and get help

Hand the job to your host or a security specialist if any of these is true:

• Files come back after you delete them.
• An admin account keeps reappearing.
• You have no logs.
• The host reports that the hosting account itself was compromised.
• You can’t tell which files are clean.

Give them the copy you saved, the timeline and a list of what you changed. Some hosts help for free. Paid cleanups range widely, so ask whether reinfection is covered.

Once the site is stable, preventing a repeat is mostly routine work: update plugins promptly, delete what you don’t use and limit who has admin access. Our list of common WordPress security issues and our guide to what a care plan should include cover the routine.

Frequently asked questions

Can I just restore yesterday’s backup?

Only if you know the backup is clean, and only after you have closed the entry point. A backup made before you noticed the hack may already contain it. A restore also brings back the vulnerable plugin, so the attacker can come straight back in.

I had a security plugin installed. Why was I still hacked?

Login lockouts mostly stop repeated failed password guesses. A stolen valid password, a vulnerable plugin, or access through hosting, SFTP or the database gets around them. A security plugin reduces risk, but it can’t stop every attack.

I can’t log in to wp-admin after the hack. What now?

Attackers sometimes change the admin email or redirect wp-admin. Get control through your hosting account first. Use SFTP, phpMyAdmin or WP-CLI to check the admin users, then change passwords and the secret keys. If you can’t get into the hosting account either, contact your host before doing anything else.

Should I take the site offline?

If visitors could be harmed, for example by redirects, malware downloads or a changed checkout, yes. Ask your host to restrict access at the server level. A short outage costs less than sending customers to malware.

Can one hacked site infect my other sites?

Yes, if they share a hosting account or server user. Ask your host to check every site in the account. Cleaning one site while a neighbouring site still has a backdoor usually leads to reinfection.