What to Do If Your WordPress Site Is Hacked

Every claim checked against a real site

If you’re here because you already know something’s wrong, a defaced homepage, a host suspension notice, a Google “This site may be hacked” warning, skip the reassurance and go straight to step one. This is a real, ordered recovery sequence, not a vague panic checklist, and the order matters, doing these out of sequence is one of the most common ways a cleanup goes wrong.

Worth knowing upfront, since it’s genuinely reassuring in the middle of a stressful moment: the overwhelming majority of hacked WordPress sites are fully recoverable. Attackers running automated campaigns are typically exploiting a known, already-patched vulnerability at scale across thousands of sites, not specifically targeting yours with a novel technique, which means the fix is usually well-understood even when it’s tedious.

Step 1: Confirm it’s actually hacked, not just broken

A white screen, a database error, or a broken layout can look alarming but often has nothing to do with a compromise, a bad plugin update or a server issue causes the exact same symptoms. Check your Google Search Console Security Issues report specifically, if Google’s flagged something, it’ll say what and often where. Look for signs that are genuinely hard to explain any other way: unfamiliar admin accounts, content you didn’t write, redirects to spam or gambling sites, or your host explicitly telling you the account was suspended for abuse. If none of that’s present, the honest next step might be ordinary troubleshooting, not a hack response, and it’s worth ruling that out first rather than spending hours on a cleanup process the site doesn’t actually need.

A quick way to check for redirects specifically, since they’re one of the most common symptoms: open your site in an incognito or private browser window and check whether it behaves differently than when you’re logged in as an admin, some malware specifically cloaks itself to show a normal site to logged-in administrators while showing spam or redirects to everyone else, including search engines, precisely so the compromise goes unnoticed for longer.

Step 2: Contain it before you do anything else

Put the site into maintenance mode or take it offline entirely if your host allows it. This stops the malware from continuing to serve spam or malicious content to visitors and search engines while you work, and it stops an active attacker from continuing to operate if they still have access. Tell your host what’s happening, many hosts have their own security team or specific guidance, and some will proactively help with containment on shared infrastructure, particularly since a compromised site on shared hosting can occasionally pose a risk to neighboring accounts too, hosts generally want to know quickly.

If the site is business-critical and taking it fully offline isn’t realistic, a maintenance-mode holding page that at minimum stops search engines and new visitors from encountering malicious content is a reasonable middle ground, but understand it’s a compromise, the underlying compromise is still active until you actually work through the rest of this sequence.

Step 3: Preserve evidence before you change anything

This is the step people skip in a panic, and it’s a real mistake. Take a full backup of the site exactly as it currently is, infected state and all, before deleting or fixing anything. If you end up needing professional help, that snapshot is what lets an investigator actually determine how the attacker got in, without it, the entry point sometimes never gets identified, which means the same vulnerability can get exploited again after cleanup. This isn’t optional caution, it’s the difference between a clean recovery and a repeat infection weeks later.

There’s a real tension here worth naming honestly: the instinct in a crisis is to start deleting suspicious files immediately, and that instinct is understandable but premature. A malicious file you delete before backing it up is evidence you can’t ever recover if it turns out to matter later, whereas a backed-up infected file costs nothing to keep around for a few extra minutes while you work through the rest of this process properly.

Step 4: Reset every credential, not just the obvious one

Change every admin, editor, and FTP/SFTP password, and your hosting account and database passwords too if there’s any chance they were exposed. Regenerate your WordPress security keys and salts in wp-config.php (WordPress.org provides a secret-key generator for exactly this), which invalidates every existing session cookie and forces every logged-in user, including any attacker with an active session, to log back in. Skipping this step is a common reason a “cleaned” site gets reinfected within hours, a session or credential the cleanup missed is all an attacker needs to walk right back in.

Step 5: Scan and identify what you’re actually dealing with

Run a reputable malware scanner (SecondGate’s file integrity scan if you’re already running it, or Wordfence, Jetpack Scan, and MalCare all offer free scanning) to get a concrete picture of what’s infected rather than guessing. A single-file infection is a meaningfully different job than backdoors spread across the database, theme files, and scheduled tasks, and knowing which one you’re facing changes how much of the rest of this process you can realistically do yourself.

Step 6: Replace WordPress core, plugins, and themes with clean copies

Rather than trying to manually inspect and clean every core file, it’s faster and more reliable to overwrite WordPress core entirely with a fresh copy from WordPress.org’s official download page. Do the same for every plugin and theme, reinstalling from the official WordPress.org repository or the original vendor rather than trying to salvage the existing files, and delete anything you don’t actually use while you’re at it rather than reinstalling it. This single step removes the overwhelming majority of file-based infections in one pass.

Step 7: Clean the database

Malware commonly injects itself into the database too, not just files, spam links hidden in post content, malicious scripts added to widget or theme option fields, entirely fake posts or pages created to serve spam content. Search the wp_posts and wp_options tables specifically for unfamiliar <script> tags, base64-encoded strings (a common way malicious code hides itself in plain sight, since a string of random-looking characters is easy to miss scrolling through a database table, and decodes into working malicious code only when actually executed), and any content you don’t recognize creating or publishing. This step is genuinely tedious, and it’s the part most likely to need professional help if the infection is extensive, since it requires knowing what “normal” data looks like well enough to spot what doesn’t belong.

A specific pattern worth searching for directly: malicious code injected into theme or plugin option fields often uses PHP’s eval() or base64_decode() functions wrapped around otherwise unreadable text, a direct database search for either of those two function names across your options table is a fast way to surface a real chunk of database-level infections that a file scan alone would miss entirely, since the malicious code here never touches a file at all.

Step 8: Hunt down backdoors specifically

This is the step that separates a cleanup from a lasting fix. A backdoor is deliberately built to survive a surface-level cleaning, check scheduled cron jobs for anything you didn’t create (WP-Cron → Tools → Site Health → Info → WP Cron Events on most setups, or a server-level crontab if the site’s on a VPS), check the wp-content/uploads/ folder for any .php file at all (that folder should never contain executable PHP, its presence there is close to definitive evidence of a backdoor), and check wp-content/mu-plugins/ carefully, must-use plugins load automatically before anything else in WordPress, including before normal plugins, which makes that folder a genuinely favored hiding spot for a backdoor specifically because it’s rarely checked and runs with real priority.

Attackers also commonly plant a backdoor disguised as a legitimate-looking file, a name close to a real WordPress core file, or a plugin file with an extra character or two that’s easy to miss on a quick glance. If step 6 (replacing core, plugins, and themes wholesale) was done properly, most of this category is already gone, this step is specifically about catching what survives outside those standard locations, in the uploads folder, the database, or a genuinely custom or heavily modified theme where a full clean reinstall wasn’t an option.

Step 9: Remove unauthorized admin accounts

Go through Users → All Users methodically and remove anything you don’t recognize or can’t account for. Attackers frequently create a new, innocuous-looking administrator account as their own backdoor, one that survives a password reset on the original accounts entirely, since it’s a separate account altogether, not a compromised version of an existing one.

Step 10: Harden before you go back online, not after

Bringing a cleaned site back online without closing whatever let the attacker in the first place just invites a repeat, and it often happens fast, sometimes within hours of going back live. Update everything, since an outdated plugin is the entry point in the large majority of real cases. Enable 2FA on every admin account. Limit login attempts. Disable the built-in file editor by adding define('DISALLOW_FILE_EDIT', true); to wp-config.php. For the full version of this, how to secure a WordPress site covers the complete hardening checklist in depth, worth working through properly here rather than treating it as optional now that you’ve already had one incident.

Step 11: Request a Google review if you were flagged

Google doesn’t automatically clear a security warning once you’ve cleaned the site, you have to actively request a review through Google Search Console → Security Issues, and it’s typically processed within around 72 hours. If the warning comes back after review, that’s a strong signal something was missed in the cleanup, not a false alarm, go back through steps 6 through 9 rather than just requesting another review.

A note on what caused this, since it matters for what happens next

Understanding roughly how the attacker got in isn’t just curiosity, it changes what “hardened” actually needs to mean for your specific site. If the entry point was an outdated plugin with a known, public vulnerability, that’s the most common cause by a wide margin, and the fix is straightforward, that specific plugin is now updated or removed as part of step 6, and staying current going forward closes that door. If it was a weak or reused admin password, the fix is equally clear, unique credentials and 2FA on every account. If you genuinely can’t determine how they got in even after working through this whole process, that’s itself a signal to bring in professional help rather than bring the site back online on a guess, since hardening against the wrong assumption leaves the real door still open.

Realistic timelines, so you know what to expect

A simple infection with a recent clean backup and straightforward file-based malware can genuinely be resolved in 2 to 4 hours. A complex infection, backdoors spread across multiple systems, extensive database injection, can take 1 to 2 days done properly, rushing this specific category of infection is how reinfections happen. Thorough scanning and testing before going back online matters more than speed here, a fast but incomplete cleanup costs more time overall than a slower, complete one, since a repeat infection means starting this entire process again from step one.

Worth budgeting time for the parts that aren’t in your control too. If Google flagged the site, the review request in step 11 typically takes around 72 hours to process regardless of how fast your own cleanup went, and a search engine’s crawl and reindex of a cleaned site can take longer still before rankings and any lost visibility fully recover, that part is genuinely outside your hands once the technical cleanup itself is done.

When to call in professional help instead

If the infection keeps returning after cleanup, if you can’t confidently identify every backdoor, or if this is a business-critical site where downtime has a real cost, professional recovery is usually the better call rather than continuing to DIY it. For real numbers on what that costs, how much it costs to secure a WordPress website covers the realistic range for cleanup services by severity, and in most cases that cost is genuinely smaller than the value of your own time spent on a cleanup that isn’t fully succeeding.

There’s a specific tell worth watching for: if you’ve worked through steps 6 through 9 once, thought the site was clean, and it’s showing signs of reinfection again within days, that’s a strong signal a backdoor genuinely survived the process, not that the attacker found a brand new way in. At that point, continuing to repeat the same manual process is unlikely to produce a different result, and professional help with deeper forensic tools becomes the more time-efficient choice, not just the safer one.

Restoring from a backup instead

If you have a backup that predates the hack, restoring it can be faster than manual cleanup, with one critical catch: always scan the backup itself before restoring it, if the backup was taken after the initial compromise but before you noticed it, restoring it brings the malware right back with it. Once restored, immediately update everything before doing anything else, the vulnerability that let the attacker in the first time is still there in an old backup until it’s patched.

After it’s over

Once the site’s clean, hardened, and back online, this is the moment to actually put real ongoing protection in place rather than going back to exactly how things were before. SecondGate‘s free tier covers 2FA with passkey support and brute-force protection. Its Pro tier (£39.99/year) adds file integrity monitoring, so a future backdoor attempt gets caught the moment a file changes rather than discovered weeks later the hard way. Worth being honest that no plugin does the cleanup itself, that’s genuinely the job of the steps above or a professional service, but the right protection in place afterward is what stops this from happening a second time.

Get SecondGate free

Scroll to top