How to Clean Up a Hacked WordPress Site

Cleaning up a hacked WordPress website involves more than deleting the first suspicious file you find.

A compromise can affect WordPress files, plugins, themes, database content, administrator accounts and other access to the hosting environment. If you remove the visible malware but leave a backdoor, vulnerable plugin or stolen account in place, the site can simply become infected again.

This guide is for people who are comfortable working with WordPress files, backups, administrator accounts and hosting tools such as SFTP or SSH.

If the site is business-critical, handles sensitive information, has several affected websites, keeps becoming reinfected, or you cannot confidently distinguish legitimate custom code from malware, professional help may be safer than continuing yourself.

If you are not yet sure whether the site is actually compromised, start with our guide to signs your WordPress website may have been hacked.

If you have confirmed or strongly suspect a compromise, work through the following steps carefully.

1. Confirm the compromise and understand the scope

Before deleting anything, establish what you are dealing with.

Useful evidence can include:

• malware scanner results
• unexpected redirects
• unfamiliar administrator accounts
• browser security warnings
• Google Search Console security issues
• hosting-provider alerts
• spam pages
• recently modified files
• suspicious server activity
• reports from visitors

Do not assume every unusual file or performance problem is malware.

A modified file might be the result of a legitimate update. High CPU usage could come from a badly behaving plugin. A failed login might simply be a forgotten password.

Look for changes that cannot be explained or several suspicious indicators occurring together.

Also consider whether the problem might extend beyond one WordPress installation.

For example:

• Are other sites on the same hosting account behaving strangely?
• Has the hosting account itself been accessed?
• Are multiple administrator accounts affected?
• Is there evidence of server-level changes?
• Is an old staging copy of the website exposed?

Remote scans, server-side scans, vulnerability checks and file-integrity checks can all help with this investigation.

If the website is actively serving phishing pages, malware downloads or dangerous redirects, you may need to restrict access or work with the hosting provider before continuing.

2. Back up the compromised site before changing it

It may sound strange to back up a website you already know is infected, but preserving its current state can be useful.

Back up:

• the WordPress files
• the database
• relevant logs if available
• malware scan reports
• any other useful evidence

This gives you something to compare against and provides a fallback if you accidentally remove legitimate content during the cleanup.

An important distinction is:

A backup of an infected site is evidence and a rollback point. It is not necessarily a clean backup that should be restored later.

Keep it clearly labelled so it is not mistaken for a known-good recovery copy.

If the hosting provider already maintains historical backups, note their dates as well. You may be able to use one of them in the next step.

3. Decide whether a known-clean backup is the safest recovery route

If you have a trustworthy backup from before the compromise, restoring it can sometimes be safer than manually cleaning every modified file.

Before doing that, consider whether the backup genuinely predates the infection.

A backup may already contain the compromise if the malware went unnoticed for several days or weeks.

You also need to consider what would be lost by restoring it, such as:

• recent orders
• customer accounts
• form submissions
• comments
• content changes
• configuration changes

Restoring a clean backup also does not solve the original security weakness by itself.

The restored site may still contain:

• the vulnerable plugin that was exploited
• an abandoned theme
• weak or stolen credentials
• unsafe configuration
• another route back into the site

If you restore a known-clean backup, continue with the security, credential and validation steps below rather than assuming the incident is finished.

If you do not have a trustworthy clean backup, continue with manual cleanup.

4. Check and replace compromised WordPress core files

WordPress core files can be compared against the official files published for the installed version.

If WP-CLI is available, run:

wp core verify-checksums

If the installation matches the official WordPress checksums, WP-CLI should report that the core files verify successfully.

Unexpected checksum failures deserve investigation.

You can also extend the check to files in the WordPress root:

wp core verify-checksums --include-root

This can help expose unexpected root-level files.

A checksum mismatch does not automatically prove that a file is malware, but standard WordPress core files normally should not contain custom modifications.

If standard WordPress core files have been compromised, replacing them with clean official files for the appropriate WordPress version is generally safer than manually editing malicious fragments out of individual core files.

Be careful not to treat everything in the WordPress directory as disposable.

Important site-specific areas such as wp-content and configuration such as wp-config.php require separate investigation.

And remember that clean core checksums do not prove the whole website is clean. Malware may still exist in plugins, themes, uploads, the database or entirely new files.

5. Check plugins and themes

Plugins and themes need to be reviewed separately from WordPress core.

For plugins distributed through WordPress.org, WP-CLI can compare installed files against official checksums:

wp plugin verify-checksums --all --strict

Investigate unexpected mismatches rather than immediately deleting everything the command reports.

A file may have been deliberately customised, partially updated or changed for another legitimate reason.

Premium and custom plugins may not have WordPress.org checksums available at all.

For these, obtain a known-clean copy from the original developer where possible and compare it carefully with the installed version.

The same principle applies to themes.

Look for:

• unfamiliar files
• unexpected modifications
• recently changed code with no explanation
• abandoned software
• plugins or themes nobody remembers installing
• unexpected executable code

Where a standard plugin or theme has clearly been compromised, replacing it with a clean copy from a trusted source is usually safer than trying to remove fragments of malicious code manually.

Be especially careful with custom themes and plugins.

If you cannot confidently determine which changes are legitimate custom development and which are malicious, this is a sensible point to stop and get professional help.

6. Inspect wp-content, uploads and unexpected files

The wp-content directory deserves particular attention because it contains site-specific plugins, themes, uploads and other data that core checksum verification does not clean for you.

Review areas including:

• wp-content/plugins
• wp-content/themes
• wp-content/uploads
• wp-content/mu-plugins
• cache or temporary directories
• custom directories
• unfamiliar files in the WordPress root

Look for things that do not belong.

Possible warning signs include:

• unfamiliar PHP files
• files with misleading names similar to legitimate WordPress files
• recently modified files that do not correspond with an update
• heavily obfuscated code with no known legitimate purpose
• unexpected scripts inside media directories
• backdoors identified by your malware scanner

Executable PHP inside an uploads directory deserves investigation because ordinary image, document and media uploads generally do not need PHP code.

That does not mean every PHP file in every uploads directory is automatically malicious. Some legitimate systems create unusual file structures.

Context matters.

Do not delete something simply because you do not recognise it.

7. Check the WordPress database

A hacked WordPress site can remain compromised even after its files have been replaced.

Malicious or unwanted content may also be stored in the database.

Depending on the attack, this might include:

• spam pages or posts
• injected JavaScript
• malicious links
• unexpected options
• altered widget content
• compromised plugin settings
• unfamiliar users
• malicious redirects
• other injected data

Export or back up the database before editing it.

Then investigate the entries associated with the symptoms you have found.

For example, if the compromise created hundreds of spam pages, identify how those pages are represented before deleting them.

If a scanner identifies malicious code in an option or post, inspect that specific data rather than performing broad database replacements based on guesswork.

Be particularly careful with serialized WordPress data.

A careless search-and-replace operation can corrupt stored settings even when the text you are trying to remove is genuinely malicious.

If you do not understand the structure of the database content you need to modify, stop before making destructive changes.

8. Review WordPress users and other privileged access

Check all WordPress administrator accounts.

For each administrator, ask:

• Do you recognise the person?
• Do they still require access?
• Is the email address correct?
• Is their role appropriate?
• Was the account created or modified unexpectedly?

Remove or disable accounts that are genuinely unauthorised.

Do not stop with WordPress if the compromise may involve wider access.

Depending on the hosting setup, also review:

• hosting or control-panel users
• SFTP accounts
• SSH access
• deployment users
• database users
• other privileged services connected to the site

An attacker who still has valid server or hosting credentials does not need a malicious WordPress administrator account to regain access.

9. Find and close the route back in

This is one of the most important stages.

Ask how the compromise may have happened and what could allow it to happen again.

Investigate possibilities such as:

• vulnerable plugins
• vulnerable themes
• outdated WordPress core
• abandoned software
• reused or stolen passwords
• old administrator accounts
• compromised hosting credentials
• untrusted or nulled plugins and themes
• exposed staging sites
• other infected sites on the same account
• hidden backdoors

You may not always be able to prove the exact original entry point.

That does not mean you should ignore known weaknesses.

If the site contains an actively vulnerable plugin, an unexplained administrator account and a backdoor, all three need attention even if you cannot prove which one came first.

If you remove the malware but leave the vulnerability or stolen access in place, the site can simply become infected again.

10. Update and patch the site

Once you understand the state of the website and have dealt with malicious modifications, update the legitimate software.

This normally includes:

• WordPress core
• active plugins
• the active theme
• other software the site genuinely requires

Remove unused plugins and themes rather than leaving unnecessary code installed.

Replace abandoned software where there is no safe maintained version available.

If a particular vulnerability contributed to the incident, make sure the relevant update, patch or replacement has actually closed that weakness.

If you manage the underlying server yourself, also consider whether PHP, the web server, database software or operating system require security updates.

11. Reset credentials and WordPress security keys

If an attacker may have obtained legitimate access, cleaning the files is not enough.

Depending on the compromise, change affected credentials such as:

• WordPress administrator passwords
• hosting or control-panel passwords
• SFTP or SSH credentials
• database credentials
• domain or DNS access
• other privileged services connected to the site

Use strong, unique passwords and enable MFA where available.

WordPress authentication keys and salts should also be regenerated where appropriate.

Replacing these values invalidates existing WordPress authentication cookies, forcing active sessions to authenticate again.

If you suspect that the computer or browser used to administer the website may itself be compromised, do not simply set new passwords from the same untrusted device.

Secure the device or use a trusted one first.

The timing of credential changes also matters. An obviously compromised account may need to be disabled immediately, while broader credential rotation can be coordinated as the cleanup progresses.

12. Scan and validate the site again

Do not stop because the obvious malicious file is gone.

If a browser or security service is actively warning that a page is dangerous, do not keep bypassing the warning to test the site manually. Use safer inspection methods or the relevant security tools instead.

Repeat the checks that helped identify the compromise in the first place.

Depending on the site, validation may include:

• another remote malware scan
• another server-side scan
• WordPress core checksum verification
• plugin checksum verification
• reviewing administrator users again
• checking previously infected directories
• checking suspicious database content
• testing redirects
• viewing the site while logged out when it is safe to do so
• testing the site in a private browser session when no active security warning is present
• checking important forms, ecommerce or membership functionality
• reviewing hosting or security alerts

Our guide to scanning WordPress for malware and security vulnerabilities explains the limitations of each type of check in more detail.

A clean result from one scanner is not proof that the entire website is clean.

You are looking for several pieces of evidence that now agree:

• the known malware is gone
• the suspicious behaviour has stopped
• unauthorised access has been removed
• identified vulnerabilities have been addressed
• the site functions normally
• follow-up scans no longer identify the original problem

13. Resolve remaining browser or search warnings

If Google, a browser or another security service flagged the site, the warning may remain for a period after you clean the website.

Do not request a review until you have completed the cleanup and validation.

For Google Search Console security issues, the sensible order is:

1. fix the compromise throughout the site
2. close the security weakness that allowed it where possible
3. test and validate the cleanup
4. request a review through the Security Issues report

When requesting a review, explain what was found and what you changed to resolve it.

Do not repeatedly submit review requests while unresolved security issues remain.

Other security or hosting providers may have their own review or delisting processes.

14. Monitor for reinfection

A website that looks clean immediately after recovery can still become infected again.

For the following days, watch for:

• new malware alerts
• unexpected file changes
• unfamiliar administrator accounts
• redirects returning
• suspicious login activity
• unusual server behaviour
• renewed browser or search warnings

If the same malicious file or behaviour returns, do not simply delete it again and assume the problem is solved.

Reinfection usually means something is still wrong.

Possible causes include:

• a hidden backdoor
• compromised credentials
• another infected site
• a vulnerability that was not patched
• a malicious scheduled task
• another infected file or database entry that was missed

At that point, return to the investigation rather than repeatedly treating the symptom.

When should you stop doing this yourself?

DIY recovery is not suitable for every WordPress compromise.

Consider stopping and getting professional help when:

• you cannot identify which files are malicious
• you cannot distinguish custom code from suspicious changes
• malware keeps returning after cleanup
• several websites are affected
• the hosting account or server itself may be compromised
• you have lost important administrator access
• the host has suspended the website
• the site processes payments or sensitive customer information
• you suspect several important credentials have been stolen
• database cleanup requires changes you do not understand
• evidence may need to be preserved for legal or compliance reasons
• the consequences of accidentally deleting legitimate data are high

Our guide to what professional WordPress malware removal involves explains how a professional investigation and cleanup differs from simply removing the visible malware.

Knowing when to stop is part of doing DIY recovery responsibly.

How do you secure WordPress after a hack?

A successful cleanup gets you out of the immediate incident.

It does not remove the need for ongoing security.

After recovery, make sure the website returns to sensible security practices including:

• regular updates
• strong, unique credentials
• MFA where appropriate
• least-privilege access
• dependable backups
• malware and security monitoring
• secure hosting
• additional protective layers such as a WAF where appropriate

Our guide to WordPress security best practices covers those measures in more detail.

The important thing is to treat the incident as useful evidence.

If the compromise exposed a weakness in how the site was maintained or accessed, fix that process rather than returning to exactly the same setup.

Need help cleaning up a hacked WordPress site?

If the cleanup is more complex than you are comfortable handling, our WordPress Malware Removal service provides a one-off route to getting the site investigated and cleaned up.

We can assess the compromise, remove malicious content, address relevant security issues and validate the website afterwards.

The goal is not simply to remove the first suspicious file. It is to clean up the incident properly and reduce the chance of the same compromise immediately returning.