Your site sends visitors somewhere else. Google shows a warning. Your host has emailed about malware. Or there’s an administrator account you’ve never seen before.

You need to act, but deleting things at random can make the recovery harder. I work with WordPress security, and this is the order I use to approach an incident: preserve what happened, limit the damage, then investigate and clean up.

This guide is for the first response. If you’re ready for the technical work, I’ve written a separate step-by-step WordPress malware removal guide.

Don’t wipe the site yet

Don’t delete the whole account, restore the first backup you find or install several security plugins at once.

An old backup can contain the same infection. Even a clean backup won’t help for long if the vulnerable plugin or stolen account is still there. Deleting the current files also removes clues about how someone got in.

If your computer might be compromised, don’t use it to change passwords. Start from a device you trust.

1. Write down what you’ve noticed

Before changing the site, collect:

The affected URLs and screenshots of warnings or redirects.
When you first noticed the problem, including your time zone.
Recent changes, such as a new plugin, a theme update or someone being given access.
Emails from your host and anything reported in Google Search Console.

Don’t keep opening a phishing page or downloading a suspicious file to investigate it. A screenshot and the URL are enough to start.

If customer information or payment pages may be involved, involve your host and whoever handles your privacy obligations. Removing malware isn’t the same as determining whether data was accessed.

2. Protect visitors while you preserve the site

If the site is serving scams, unwanted downloads or payment redirects, ask your host to restrict public access immediately. A host-level block is often more dependable than a maintenance plugin inside a compromised WordPress installation.

If you use cPanel or Plesk, look for the provider’s support and backup tools. Ask the host to preserve a snapshot of the files, database and available access logs before making destructive changes. If visitors are at risk, don’t leave the site exposed just to finish collecting screenshots.

The infected copy is evidence, not a recovery backup. Keep it outside the public web directory, with restricted access. It may contain personal data, passwords and malicious files. Don’t open its PHP files through a browser.

No SSH access? Your host can help with an account snapshot, an SFTP download and a database export. Make sure the backup includes the database, not just the WordPress files.

3. Secure the accounts that control the site

From a trusted device, secure the email account used for password resets and the hosting account first. Enable two-factor authentication where it’s available.

Then review:

SFTP, SSH and any remaining FTP accounts or keys.
WordPress administrators, application passwords and active sessions.
Database access and credentials.
DNS, domain registrar and CDN accounts if there’s any sign they were accessed.

Record unfamiliar accounts before removing access, and confirm they’re not used by your developer or agency. If you change the database password, update the matching value in wp-config.php as part of the same change. Otherwise WordPress will lose its database connection.

Changing WordPress security keys invalidates cookie-based login sessions:

wp config shuffle-salts

That doesn’t revoke application passwords, remove a backdoor or secure a stolen hosting account. Those need separate attention. Rotate credentials again after cleanup if the attacker could have read them while the site was still infected.

A note about commands: only work on a site you own or are authorized to manage. WP-CLI isn’t a safe sandbox for malicious code. Some commands load WordPress or its configuration. If you’re not comfortable assessing that risk, let your host or a specialist handle the command-line work in an isolated environment.

4. Ask your host for specific information

A useful support request asks for:

The exact file paths their scanner flagged, with detection times.
Whether the account is suspended or only under warning.
Available web access, error and authentication logs for the suspected period.
Any outgoing spam, unexpected processes or changes to scheduled tasks.
Whether other sites under the same hosting account show signs of compromise.

Don’t assume a scanner report covers the whole incident. It’s a starting point. Ask what the host has already changed or quarantined so you don’t lose track of the evidence.

5. Check the scope without chasing every symptom

In Google Search Console, open Security issues and Manual actions. They’re separate reports. A clean report doesn’t prove that the site is clean.

A Google search for site:example.com can reveal pages you didn’t create, but it isn’t a complete list of indexed URLs. If you see unfamiliar product pages or Japanese search snippets, read my guide to Japanese keyword spam.

Check WordPress users, plugins and themes against what you expect. If you’re handling the technical investigation in a controlled environment, this command compares core files with WordPress.org checksums:

wp core verify-checksums --include-root

A mismatch needs investigation. A successful result covers core files, not the database, all of wp-content or the rest of the hosting account. External scanners have limits too: they may miss malware that only appears to certain visitors.

6. Clean the infection and close the entry point

A proper cleanup may involve replacing core files, reinstalling legitimate plugins and themes, examining the database and checking scheduled tasks, configuration files and hidden access paths.

The part I wouldn’t skip is finding how the attacker got in. Was it a vulnerable plugin, an exposed password, an unauthorized account or another site on the same hosting account? Separate what the evidence shows from what you only suspect.

If you restore a known-good backup, do it in a controlled environment first. Patch the entry point before reopening the site, and account for orders, uploads or edits made since that backup.

When I’d stop and ask for help

I’d avoid trial-and-error cleanup when:

The site processes orders or holds customer information.
Several sites share the same hosting account.
Malware keeps returning after files are removed.
You don’t have a complete backup or access to useful logs.
You can’t tell which changes are legitimate.

You can still preserve evidence and contact your host. You don’t need to solve every technical detail before asking for help.

Before you call it finished

Test the site as a logged-out visitor, including mobile pages, forms and checkout where relevant. Check that unexpected redirects have stopped and that legitimate pages still work.

Turn on two-factor authentication for privileged accounts, set up off-server backups and test a restoration. Monitor new users, changed files and scheduled tasks after the site reopens.

If Google flagged the site, request the appropriate review after the underlying issue is fixed. Removing the infection doesn’t instantly clear search results or browser warnings.

My short version: protect visitors, preserve the evidence, remove unauthorized access, clean the site and fix the entry point. Don’t let the rush to get back online skip the reason the site was hacked.

Want me to take a look?

I offer a free diagnosis based on what I can see from outside your site. Send me the domain and what you’re seeing. Don’t send passwords over WhatsApp. Cleanup is a separate service, with the scope agreed before work starts.

Ask me for a free diagnosis on WhatsApp or see my WordPress security services.

My WordPress site was hacked: what to do right now