When a WordPress site is hacked, work in this order: document what you see, stop the harm to visitors, keep a copy of the files and database, change every password from a clean computer, clean the site or restore a backup from before the hack, close the hole the attacker used, and only then ask Google to review the site. Skipping a step usually means coming back to it when the site is hacked again.
It starts with a screenshot from a customer: a red browser warning saying your site is dangerous. You open the site and the home page looks normal, yet Google shows pages under your domain in a language you don’t speak. Your hand is already on “Delete” or “Restore”, and this is exactly the moment to stop. Here is what to do, in order.
How do you know your site has actually been hacked?
By symptoms, not by a hunch. WordPress.org lists clear signs: a Google or browser warning, a host that has disabled the site, visitors’ antivirus flagging it, user accounts nobody created, and changes you can see when you open the site.
Some hacks hide from you. If pages you never wrote appear in Google, if visitors arriving from search results get redirected elsewhere, if the emails your site sends start landing in spam, assume something is wrong even when the home page looks fine. Some hacks show spam only to Google so the owner doesn’t notice.
Tip: Search Google for site:yourdomain.com and scan the results, then open the Security Issues report in Google Search Console (Google’s free tool for site owners). Within minutes you’ll know whether Google has detected a problem and what it sees.
What should you do in the first hour?
Document and contain. Don’t delete anything yet. Write down what you saw, when, and what changed recently: a new plugin, an update, a new user. Whoever handles the cleanup, including you, will need this record.
If the site redirects visitors to a malicious site or serves harmful code, ask your host to take it offline temporarily or block public access. WordPress maintenance mode is not enough, because malicious code can sit in files that keep running while the site is “closed”. On the same call, ask whether other sites on your account were affected and request the server access logs.
Tip: Before cleaning anything, download a full copy of the files and the database to somewhere off the server and label it “infected”. It’s not for restoring. It lets whoever investigates see what happened after the site has been cleaned.
Which passwords do you change, and from which computer?
All of them, from a computer you have scanned and found clean. WordPress.org notes that many attacks begin on the site owner’s own machine, with malware that steals FTP or admin logins. Change a password from an infected computer and the attacker gets the new one.
The full list: every WordPress administrator, your hosting account, SFTP or FTP access (how files are uploaded to the server), the database, and the email account that receives password resets. Review the WordPress users and remove any administrator you don’t recognise. Then replace the security keys (salts) in wp-config.php, which logs everyone out at once, including the attacker.
Tip: Turn on two-factor authentication for the admin area and the hosting account the same day. A stolen password on its own will no longer get anyone in.
How do you clean malware from a WordPress site?
Replace what can be replaced and inspect what can’t. Re-upload the same version of WordPress core from the official source. Reinstall themes and plugins from their official sources and delete anything you don’t use. PHP files in the uploads folder, changes to .htaccess and wp-config.php, and unfamiliar code in the theme’s functions.php are common hiding places.
Check the database too: scripts injected into page content, settings pointing to an unknown address, and users that were added. WordPress.org suggests scanning in two ways, because each catches different things: a scanning plugin that runs inside the site, and an external scanner that sees the site the way a visitor or Google does.
Tip: If your site includes custom code, compare it with the original copy from your developer or code repository, not just with a scan. Scanners know common malware. They don’t know what belongs in code written only for you.
Should you clean the site or restore a backup?
Restoring is fastest, but only if the backup predates the hack. Attackers often leave a backdoor (code that lets them get back in) weeks before anything visible happens. Yesterday’s backup may bring back exactly what you’re trying to remove.
Pick the backup by date, not by convenience: work out when the symptoms started, check the server logs for when suspicious files appeared, and restore to a point before that. After restoring, still change passwords and close the hole, or the clean backup returns a site with the same weakness.
Tip: If you run a store or collect leads, list the orders, sign-ups and enquiries received since the backup date before you restore. A restore wipes them, and without a list you’ll find out when a customer asks where their order went.
How do you close the hole so it doesn’t happen again?
Find how the attacker got in and fix it. The usual entry points are a plugin or theme with a known, unpatched vulnerability, a weak or shared password, or an account belonging to someone who no longer works with you. Server logs and scan results usually point the way.
Then update core, the theme and every plugin, delete deactivated plugins (a disabled plugin still sits on the server and can still be a way in), and change all passwords one more time. The second change rules out the attacker having seen the new passwords during the cleanup. For the routine that keeps a site patched afterwards, see our monthly WordPress maintenance checklist.
Tip: For the next few weeks, check the user list and the Search Console report once a week. A returning hack gets caught early, before Google flags the site again.
What do you do about a Google warning?
Request a review only once the site is clean. The Security Issues report in Search Console has a button to request one. Google says a review can take from a few days to a few weeks, and if it fails because code is still on the site, the next request starts over.
Spam pages the attacker created should return an error (404 or 410), not redirect to the home page, so Google understands they’re gone. If the site sent spam email, also check whether the server’s IP address has landed on mail blocklists, and raise it with your host.
Tip: In the review request, say briefly what you found and fixed: which plugin was the entry point, which files were replaced, which passwords were changed. A request that explains the fix helps the reviewer see the problem was dealt with at the root.
Do you need to report the hack to anyone?
Possibly, depending on what the site stores. If you run a store, tell your payment provider, even if card details aren’t stored on your site. If the site holds personal data about customers, such as names, phone numbers, addresses or user accounts, data-protection rules in your country may require you to report the breach to the regulator, often within a short deadline.
We aren’t lawyers, and this article isn’t legal advice. What you can do right now is keep the first-hour record, the infected copy and the server logs, and speak to a lawyer who knows privacy law where you operate.
Tip: If someone demands money to “give back” your site or not publish data, don’t pay and don’t negotiate on your own. Record the demand and pass it to your lawyer and whoever is handling the site.
When should you hand it to professionals?
Four situations call for help: you have no clean backup, the hack returned after a cleanup, the site is a store or your main source of leads, or you aren’t sure what is safe to delete. In those cases a quick “clean-up” can destroy the very evidence that shows how the attacker got in.
Websight’s WordPress maintenance plans include security scans, malware removal and proactive hardening, daily backups stored on a separate server, and uptime monitoring with emergency support when a site goes down.
One last step worth doing today, even if your site is fine: check the date of the oldest backup you have and where it is stored. If the answer is “only yesterday’s” or “on the same server”, fix that first. And if your site has already been hacked and you’d like someone to go through it with you, tell us what happened.
שאלות נפוצות
How long does it take to clean a hacked WordPress site?
It depends on how deep the hack goes and whether you have a clean backup. Restoring a backup from before the hack is faster than manually cleaning every file and the database. If Google flagged the site, add the time for its review, which Google says takes from a few days to a few weeks.
Can I clean a hacked WordPress site myself with a security plugin?
Sometimes, if the hack is simple and you're comfortable replacing files and working with the database. A scanning plugin detects common malware, but it won't always find backdoors and it doesn't close the hole the attacker used. Leave that open and the site can be hacked again the same way.
Won't my hosting company clean the site for me?
Not always. Some hosts only suspend an infected site to protect the rest of the server; others offer cleanup as a separate service. Ask exactly what's included, and request the server access logs either way.
Why was my site hacked again after we cleaned it?
Usually because a backdoor was left behind, the original hole wasn't closed, or passwords were changed from an infected computer. Check all three: scan your computer, look for the entry point in the server logs, and change every password again after the cleanup.
My site dropped out of Google after the hack. Will it come back?
Google removes the warning once the site is clean and the review in Search Console is approved. Nobody can promise when or where the site will rank again, but you can avoid delays: make sure the attacker's spam pages return 404 or 410, and explain your fix in the review request.
