How to Clean a Hacked Website (Step by Step)
Cleaning a hacked website means finding how attackers got in, removing every malicious file and database injection, patching the hole, and resetting all credentials. Work from a backup, scan thoroughly, then verify the site is clean. Only after that should you ask security vendors to delist you.
TL;DR: A hacked site needs four things, in order: scan, remove, patch, harden. WordPress runs roughly 43% of all websites (W3Techs, 2026), so most cleanups follow the same plugin-and-theme pattern. Skipping the "patch the entry point" step is why so many sites get reinfected within days.
If your site is already showing a browser warning, you're dealing with two problems at once: the infection and the blocklist flag. This guide covers the cleanup. For the warnings themselves, see our walkthroughs on the "this site may be hacked" Google label and the "deceptive site ahead" warning on WordPress. Cleaning comes first. Delisting comes after.
How do you know your website is actually hacked?
Confirm a hack by looking for unfamiliar files, injected redirects, spam pages, or a browser warning before you start cleaning. A meaningful share of sites Sucuri scanned in a year contained malware (Sucuri, 2023), so the symptoms are common and well-documented. Match what you see to known patterns before touching anything.
The clearest signals are external. Search engines may show "This site may be hacked" under your listing. Browsers can throw a red full-page warning. Your host might suspend the account. Visitors may report pharma spam, casino redirects, or pop-ups they see but you don't.
One pattern trips up owners constantly: cloaking. Malware often shows clean pages to logged-in admins and infected content only to search-engine crawlers or first-time visitors from Google. If your site looks fine to you but Google flags it, that's the likely cause. Test in a private window from a different network.
For a full symptom checklist, read our guide on the signs your website has been hacked. If you're still unsure after that, treat it as compromised and proceed carefully.
What should you do before you start cleaning?
Before removing anything, take a full backup, put the site in maintenance mode, and document what you find. A clean backup is your safety net, since cleanup can break a live site. Sucuri's incident data shows that reinfection is a leading reason owners need repeated cleanups (Sucuri, 2023), and rushed work is usually why.
Back up everything first
Download a complete copy of your files and database, even the infected ones. You'll want a reference if you delete too much. Store it offline, label it "infected — do not restore," and keep it separate from any clean backups.
Take the site offline or into maintenance mode
Put up a maintenance page so visitors and crawlers aren't served malware while you work. This also stops the infection from spreading to forms, newsletters, or connected services during cleanup.
Notify your host
Many hosts run their own scanners and can share exactly which files they flagged. In our experience running unflag, owners reach us after the cleanup is meant to be done — and the host's malware log is often the fastest map back to ground zero. It usually lists modified files with timestamps that point straight at the breach, which matters because we clear residual blocklist flags rather than scan the site ourselves; we rely on the cleanup being real.
How do you find the malware?
Find malware by scanning files and the database, then comparing your site against known-clean copies of its software. Free remote scanners catch what's publicly visible, but server-side scanning finds more. Around 39% of hacked sites in one Sucuri sample had at least one outdated core, plugin, or theme (Sucuri, 2023) — so start where software is stale.
Run a remote scan
Tools like Sucuri SiteCheck, Google Safe Browsing's status page, and VirusTotal check what a visitor or crawler sees. They're quick and free. They miss backdoors that don't render publicly, so treat a clean remote scan as encouraging, not final.
Scan at the server level
A server-side scan reads every file directly. On WordPress, security plugins such as Wordfence or MalCare compare your core files against the official versions and flag anything changed. Patchstack's research found that plugins accounted for the large majority of new WordPress vulnerabilities (Patchstack, 2024), so scan plugins hard.
Check the database
Malware hides in the database too — injected <script> tags, spam links in posts, or rogue admin users. Search your content tables for suspicious domains and unfamiliar URLs. On WordPress, check wp_users and wp_options for accounts and settings you didn't create.
How do you remove the malware? (step by step)
Remove malware by deleting malicious files, replacing core software with fresh copies, cleaning database injections, and removing rogue users. Work methodically and keep your infected backup nearby. Because WordPress powers about 43% of the web (W3Techs, 2026), most of these steps map directly to a typical WP install.
Step 1 — Replace core files
Delete your platform's core files and reinstall them from the official source. On WordPress, that means replacing everything except wp-content and wp-config.php with a fresh download from WordPress.org. This wipes most injected core malware in one move.
Step 2 — Clean themes and plugins
Reinstall plugins and themes from official sources rather than cleaning them by hand. Delete anything you don't recognize or no longer use. Abandoned plugins are a common entry point, and the safest fix for a nulled or pirated plugin is removal, not repair.
Step 3 — Remove database injections
Open your database and remove injected scripts, spam content, and unauthorized admin accounts. Edit carefully — one wrong deletion can break the site, which is exactly why you took that backup. Search for the suspicious domains your scanner flagged.
Step 4 — Hunt for backdoors
Backdoors let attackers return after you've cleaned everything else, so they're the most important thing to find. Look for recently modified files, oddly named PHP files in upload folders, and obfuscated code using functions like eval, base64_decode, or gzinflate. If you find one, assume there are more.
How do you patch the hole so it doesn't happen again?
Patch the entry point by updating all software, removing the vulnerability the attacker used, and resetting every credential. Cleaning without patching guarantees reinfection. Outdated software featured in a large share of compromised WordPress sites (Sucuri, 2023), which makes updates the single highest-value step here.
Update everything
Update your CMS core, every plugin, every theme, and your server software. Don't reactivate a plugin that has no recent updates — abandonment is a risk in itself. If a vulnerable plugin caused the breach, find a maintained alternative.
Reset all credentials
Change every password connected to the site: admin logins, database, hosting control panel, FTP/SFTP, and any API keys. Assume the attacker captured all of them. Owners often reset the WordPress admin password and stop there, but hosting and FTP credentials are the more common re-entry path, since those rarely rotate.
Remove unauthorized access
Delete unfamiliar user accounts, revoke unused API tokens, and check scheduled tasks (cron jobs) for anything you didn't set up. Attackers frequently plant a scheduled task that reinstalls malware after you've cleaned it.
How do you harden the site after cleanup?
Harden a cleaned site by enabling automatic updates, adding two-factor authentication, limiting login attempts, and running ongoing scans. Hardening turns a one-time fix into lasting protection. Google reports it shows warnings on billions of devices through Safe Browsing (Google, 2022), so staying clean keeps you off those lists.
Enable automatic updates for core software and plugins where you can. Add two-factor authentication on all admin accounts. Limit login attempts to slow brute-force attacks. Use a web application firewall to block known exploit patterns before they reach your code.
Set up ongoing monitoring so you learn about problems before Google does. A weekly scan and file-change alerts catch reinfection early. Keep regular, off-site backups going forward — a clean recent backup makes the next incident far less stressful.
When can you request removal from blocklists?
Request blocklist removal only after your site is fully clean and you've verified the malware is gone. Vendors re-scan when you ask, and a still-infected site gets rejected — sometimes with a longer cooldown. Google's own guidance is to fix the site completely before requesting a review in Search Console.
This is the order that matters. Clean and verify first. Then request review from each vendor that flagged you. For Google specifically, the Safe Browsing review is a manual submission inside Search Console — there's no API and no way to automate it. You copy your situation in and Google's systems re-check the site.
Once the site is verified clean, getting delisted across every vendor is its own chore — different forms, different inboxes, different wait times. That's the gap unflagdomain's pay-once blocklist removal service fills. In practice we scan a domain across a maintained catalog of 124 active security vendors, then generate a removal request worded uniquely for each one that flagged you — identical boilerplate reads as spam — and dispatch them over a randomized window with your email as Reply-To, so vendor replies land in your inbox. Vendors that only take web forms or manual review, like Google Safe Browsing, become guided dashboard cards instead. The dashboard shows real sent, bounced, and failed counts per vendor, and we re-dispatch on bounce. To be clear, no service can guarantee delisting — vendors make that call after they re-scan. unflagdomain guarantees the requests go out; it doesn't clean malware, and it can't bypass Google's manual review.
Final takeaways
A successful cleanup follows one sequence: confirm the hack, back up, scan, remove, patch, harden, then verify. The patch step is where most owners fail, and reinfection is the predictable result — Sucuri's data ties outdated software to a large share of compromises (Sucuri, 2023). Skip it and you'll be cleaning the same site next month.
If the work feels beyond your comfort level, hire a professional incident-response service to do the cleanup. The cleanup is the hard, technical part. Requesting blocklist removal afterward is comparatively simple — but only worth doing once the site is genuinely clean. Start with the signs your website has been hacked to confirm scope, work through the steps above, and save the delisting requests for last.
Look for browser warnings, a "this site may be hacked" label in search results, unfamiliar files, spam pages, or strange redirects. Sucuri found roughly 1 in 25 scanned sites carried malware in 2023. Test your site in a private browser window, since some malware hides from logged-in admins.
Replace WordPress core files with a fresh download, reinstall plugins and themes from official sources, clean injected scripts and spam from the database, and delete rogue admin users. Then update everything and reset all passwords. Patchstack reports plugins drive most WordPress vulnerabilities, so scan and patch them carefully.
A straightforward cleanup can take a few hours; a complex compromise with multiple backdoors may take days. Time depends on infection depth, your platform, and whether you find the entry point. Hiring a professional incident-response service speeds it up if you're not comfortable editing files and databases.
Sometimes, but only if you have a backup from before the infection and you patch the vulnerability afterward. Restoring an old backup without patching leaves the same hole open, so attackers return quickly. Restore, then update all software and reset every credential to prevent reinfection.
Only after your site is fully cleaned and verified malware-free. Vendors re-scan when you request review, and a still-infected site gets rejected, sometimes with a longer wait. Google's Safe Browsing review is a manual submission in Search Console with no automation, so fix everything first.