A hacked WordPress site triggers exactly the wrong instinct: delete everything suspicious, immediately. In reality the first hour decides whether you recover cleanly or fight reinfection for weeks. The winning moves are about preserving evidence and cutting off access, not deleting files. This checklist covers the first hour on a hacked WordPress site, in order.
How you found out changes what you do first
The discovery route tells you how much time you have, so start there.
- A browser interstitial such as “Deceptive site ahead” or “The site ahead contains malware”. Google Safe Browsing has flagged you. Traffic is already gone, and you will need a review request later.
- A Search Console message under Security Issues, naming hacked content, spam, or cloaking. Read the sample URLs it lists. They tell you what the attacker was actually doing.
- Your host suspended the account or emailed about outbound spam or CPU abuse. The site may already be offline. Ask them for the log lines that triggered it, because that is a shortcut to the entry point.
- Odd redirects or injected content reported by a visitor. Frequently only visitors from search engines or on mobile see it, so check with a phone and a search-referred visit, not just your own browser.
- A security plugin alert about changed core files. Verify it yourself before acting, because these produce false positives on legitimate customisations.
In every case the site is now untrusted. So treat everything on a hacked WordPress site, the dashboard included, as potentially controlled by someone else.
1. Cut off access without destroying evidence
On a hacked WordPress site the hosting account comes before the dashboard. So change the passwords that grant entry in this order: hosting-panel and SFTP logins, then WordPress administrator accounts, then the database user. Doing the host first matters. If the attacker still holds file access, a new WordPress password buys you nothing.
Next, rotate the security keys in wp-config.php. Replacing the eight AUTH_KEY, SECURE_AUTH_KEY, LOGGED_IN_KEY and NONCE_KEY values, plus their matching salts, invalidates every existing login cookie at once. WordPress publishes a generator for fresh values. Without this step an attacker who is signed in stays signed in, however many passwords you change.
Then, if your host offers it, put the site behind maintenance mode or a server-level password. That stops visitors seeing spam and stops the attacker’s payload being served while you work.
However, do not delete any files yet, and do not run a “clean up” plugin blindly. The timestamps, rogue files and injected code are the map of how the attacker got in, and you will need that map.
2. Take a forensic copy before you change anything
Copy the whole site, files and database together, to somewhere offline before the cleanup begins. This is the step people skip and regret.
The copy is what lets you answer questions later: which customer records were exposed, when the first modified file appeared, whether the payment page was touched. It is also your undo button if a cleanup goes wrong. Label it clearly as infected so nobody restores it by accident.
Store it outside the web root. A zip of a compromised site sitting at a guessable URL is a second incident waiting to happen.
3. Establish when the hacked WordPress site was entered
Sort wp-content and the site root by modification time over SFTP or in the host’s File Manager. Files changed at odd hours, or in tight groups, mark the timeline. A .php file anywhere inside wp-content/uploads is almost never legitimate.
Also check your host’s access logs around those timestamps. The requests just before the first modified file usually reveal the entry point. In practice it is one of four things: an outdated plugin with a public exploit, a stolen or reused password, an exposed backup or database dump, or a vulnerable theme left installed but inactive.
These patterns inside PHP files are worth searching for, because they show up in most injected code: eval(, base64_decode(, gzinflate(, str_rot13(, and long unbroken strings of random-looking characters. Finding them confirms a file is malicious. Not finding them does not prove a file is clean, since good attackers write readable code too.
Write the timeline down as you go. On a hacked WordPress site the single most valuable artefact is a dated list of what changed and when.
4. Decide: restore or clean
This is the decision that shapes the rest of the work, and it turns on two questions.
Do you have a backup that predates the earliest compromised timestamp? If yes, restoring it is almost always faster and more trustworthy than cleaning in place. You get a known-good state instead of a hopefully-good one.
What would that restore cost you? Orders, form submissions, comments and posts created since the backup are lost unless you extract them first. On a store, that cost is usually the deciding factor, and exporting recent orders before restoring is worth the extra twenty minutes.
Afterwards, you still must close the entry point. A restored site with the original hole open gets taken again, often within days, because automated scanners revisit known-vulnerable targets.
In contrast, cleaning in place is the right call when the backup is too old to lose. It means comparing every core file against a fresh WordPress download of the same version, replacing each plugin and theme with an official copy rather than editing files, and checking the database for injected content.
5. Check what the attacker left behind
Persistence is the part most cleanups miss. A hacked WordPress site that looks clean and reinfects itself on Tuesday still has one of these.
- Extra administrator accounts. Check Users and sort by role. Also check for accounts with a plausible name and an unfamiliar email.
- Scheduled tasks. A cron event that rewrites files puts the malware back after every cleanup. Anything scheduled that you do not recognise deserves scrutiny.
- Modified
wp-config.phpor.htaccess. Redirect rules and PHP includes hide well at the bottom of these files, often after many blank lines. - PHP files in
wp-content/uploads. Uploads should hold media, nothing executable. - Must-use plugins you did not install. Files in
wp-content/mu-pluginsload automatically and never appear in the normal Plugins list, which is exactly why attackers like them. - Injected rows in the options table. Scripts hidden in site-wide settings survive a file cleanup completely.
Meanwhile, verify your sitemap and robots.txt were not modified. SEO spam campaigns often edit those first, and that is frequently how owners discover a hacked WordPress site in the first place: through a search console warning rather than anything visible on the page.
6. After it is clean
Rotate every credential a second time once the hacked WordPress site is verified clean. Passwords changed during the incident may have been captured by code that was still active at the time.
Then update everything, and delete plugins and themes you do not use rather than merely deactivating them. An inactive plugin still has files on disk, and its files can still be reached directly. If one of those updates fails partway, our guide to recovering from a failed WordPress update covers the repair.
Next, deal with the reputation damage. In Search Console, open Security Issues, confirm the problem is fixed, and request a review. Reviews of hacked-content flags typically take a few days, and a site that still contains injected pages fails them, so verify first. If your host suspended the account, send them the same evidence.
Finally, watch the logs for a week. A failed reinfection attempt against a closed door is the confirmation that you found the real entry point. Continued success means you did not.
What it costs to skip the entry point
Cleaning the files without closing the hole is the single most common way a hacked WordPress site goes wrong twice. The site comes back, ranks recover, and three weeks later the same injection reappears. By then the backups also contain the malware, the search-engine warning is a repeat offence, and the cleanup starts again from a worse position.
So the order in this guide is not decoration. Evidence first, containment second, cleaning third, and the entry point closed before the site goes back to the public.
Quick checklist
In short: rotate credentials starting with the host, replace the security keys, freeze the site, take an offline forensic copy, then build the timeline from modification times and access logs. Only then restore or clean, and close the entry point before going live.
A hacked WordPress site handled in this order stays fixed. Handled in panic order, it usually comes back within the month.
When to hand it over
If the site takes payments, holds customer data, or you cannot establish a clean timeline, this is the point where a specialist earns their fee. Our hacked WordPress repair service runs exactly this process: preserve evidence, establish the timeline, close the entry point, verify the cleanup, and record everything so you know what happened.
Tell us what you are seeing and include your host name and when you first noticed. If the site is actively serving spam or redirecting customers right now, urgent WordPress help starts with containment instead of repair.
For hardening after recovery, see our WordPress security services and the official WordPress hardening guide. The WordPress.org FAQ on hacked sites covers the manual cleanup steps in more detail than fits here.