WordPress site hacked: how to respond and fix it

Your WordPress site redirects to a casino, shows a hacker’s calling card, or Google flags it as dangerous? The most urgent thing is not to delete files at random. It is to contain the attack, keep a copy of the hacked state, then take back control of your accounts before you repair anything. This guide sets out the order of decisions from the first hours to the following thirty days, the commands worth knowing, and the obligations you must not miss (including the 72-hour GDPR deadline).

Not sure yet that you have been hacked? Start with the checks that tell you whether your WordPress site is hacked. Looking for the technical detail of the cleanup, file by file? It is in our step-by-step procedure for cleaning a hacked WordPress site. This article is your response plan: who does what, in which order, and how to avoid reinfection.

The first ten minutes: contain without erasing

As long as the malicious code is running, it can steal data, send spam or infect your visitors. But wiping everything straight away destroys the traces that will help you find the way in. The right compromise:

1. Take the site offline for visitors: a maintenance page at server level (an .htaccess rule that serves a static page with a 503 status, or your host’s option), not a WordPress plugin that depends on the compromised code.
2. Alert your host with a support ticket: they may already have detected the infection, can block outgoing email and have logs you cannot see.
3. Start an incident log kept off the server: time, finding, action, who. It will be useful for your insurer, a contractor, a police report or the data protection authority.
4. Do not restore a backup yet: you do not know how long the site has been compromised, nor whether the backup is clean.

Assess the severity to set the right pace

Not every hack calls for the same urgency. The table below helps you decide who to involve and what comes first.

What you see	Main risk	Priority	Who to involve
Redirects to shady sites, Google warning	Infected visitors, deindexing	Offline immediately	Host, you or a contractor
Indexed spam pages (pharmacy, casino)	Search rankings, reputation	Same day	You, then Search Console
Defaced home page	Brand image	Offline immediately	Host, contractor
Customer accounts, forms or orders exposed	Personal data breach	Immediate, GDPR clock running	Data protection officer, supervisory authority, contractor
Payment form tampered with (shop)	Card theft	Immediate	Payment provider, bank, contractor
Ransom demand or encrypted files	Data loss	Immediate, do not pay	Host, police, national cyber security centre

Keep a copy of the hacked state

Before any repair, download a full copy: files (over SFTP or as an archive created by your host), the database (SQL export) and, if possible, the server access logs for the last 30 days. Store it off the server, separate from your clean backups, and label it clearly “infected” so you never restore it by mistake. This copy is what lets you date the intrusion, and therefore pick a backup from before it.

To date the intrusion, look in this copy for recently modified PHP files and the creation date of unknown accounts. This is where the 3-2-1 backup rule makes all the difference: without an older off-site copy, cleanup is the only option left.

Regain access, from the widest to the narrowest

Change passwords from a clean computer, starting with whatever grants the most power: an attacker who keeps access to your mailbox or your hosting account can start all over again.

1. The mailbox that receives password resets, then your hosting account and domain registrar (turn on two-factor authentication).
2. SFTP and SSH accounts, the control panel (cPanel, Plesk) and the database user, then update wp-config.php.
3. WordPress keys and salts, which logs out every open session, including the attacker’s.
4. Every administrator account, then application passwords and plugin API keys (payments, email delivery, remote backup).

With WP-CLI, the basic checks take just a few commands:

# New keys and salts: every session is closed
wp config shuffle-salts

# Administrator accounts: spot the ones you do not recognise
wp user list --role=administrator --fields=ID,user_login,user_email,user_registered

# Scheduled tasks: an unknown task can reinfect the site
wp cron event list --fields=hook,next_run_relative,recurrence

# Site addresses: a redirect can hide here
wp option get siteurl
wp option get home

Repair: what to replace, what to inspect

The principle: anything that can be reinstalled from an official source gets replaced, not cleaned line by line. Only what is yours (content, media, settings, custom theme) is inspected by hand.

Item	Action	Command or method
WordPress core	Reinstall as is	wp core verify-checksums then wp core download --force --skip-content
Plugins and themes	Delete, then reinstall from wordpress.org or the vendor	wp plugin verify-checksums --all, never a “nulled” version
Uploads folder	No PHP file should be there	find wp-content/uploads -name "*.php"
mu-plugins and drop-ins	Check every file	wp-content/mu-plugins, object-cache.php, advanced-cache.php
.htaccess and wp-config.php	Compare with a clean version	Redirects, auto_prepend_file, unknown includes
Database	Look for injected scripts	wp_options and wp_posts tables: <script> tags, eval, base64
Users	Delete unknown accounts	Reassign their content, check for changed roles

The classic hiding places for a backdoor are precisely where nobody looks: an innocuous-looking file in uploads, a mu-plugin that does not appear in the plugin list, a cron task that recreates the deleted file. If you cannot find how the attacker got in (vulnerable plugin, reused password, stolen FTP credentials), the site will be hacked again within days: that is the time to call in a professional.

The response plan, step by step

Getting off blocklists and clearing the Google warning

Once the site is clean, and only then, bring it back online and get the warnings lifted:

• Google Search Console: the “Security issues” report lists what Google found. Fix everything, on every page, then click “Request review” and describe the problem, what you did and the result. Google says a review for malware or hacked content takes from a few days to a few weeks: do not send another request while the first one is pending. More detail in our guide to the “dangerous site” warning.
• Indexed spam pages: let them return 404 or 410 and use the temporary removals tool for the most visible ones. The full method is in our article on SEO spam and deindexing.
• Other lists: check the domain with scanning services such as VirusTotal or Sucuri SiteCheck, and the IP address your email is sent from on anti-spam blocklists if your messages land in spam folders. Each list has its own delisting procedure.

WordPress Hacked? Step-By-Step Fix, Cleanup, and 99% Attack Prevention TutorialClicking loads the video from youtube-nocookie.com (YouTube, Google). Nothing loads until you click.

Notify: regulator, affected people, police

If the attacker could access personal data (customer accounts, contact forms, orders, a subscriber list), this is a personal data breach under the GDPR. Article 33 requires you to notify your supervisory authority (the ICO in the UK) within 72 hours of becoming aware of it, unless the breach is unlikely to result in a risk to people. Where the risk is high (passwords, bank details, sensitive data), Article 34 also requires you to inform the people concerned. In every case, record the breach in your internal register. Our article on GDPR, logs and WordPress security explains what to keep.

• Incomplete notification: you can notify within 72 hours with what you know, then add to it. A partial notification on time is better than a perfect one that is late.
• Online shop: alert your payment provider if the checkout may have been tampered with. They will tell you what to do about the cards.
• Help and reporting: your national cyber security centre (the NCSC in the UK) publishes guidance and can point you to the right service, and a police report is often required by your insurer.

The next thirty days: not getting hacked again

A site cleaned without fixing the cause is often reinfected. During the following month:

• Update everything that is left, delete unused plugins and replace abandoned plugins.
• Turn on two-factor authentication for every account that can publish or administer.
• Run integrity checks again every week and watch for new administrators.
• Test a backup restore, for real, on a staging site.
• Write a short post-incident review: cause, duration, cost, what was missing.

What WP Masquerade can do, and what it does not do

Let us be clear: WP Masquerade is not a cleanup tool. It does not scan for malware, does not filter traffic like a firewall and does not back up your site. For the repair, use a scanner (Wordfence, MalCare, Sucuri) or a professional, and the backup tool of your choice.

It comes in afterwards, to reduce the chances of another incident and warn you earlier. The free version moves the login page, blocks XML-RPC and removes the traces that reveal WordPress to bots. WP Masquerade Pro adds mandatory two-factor authentication by role, login limiting, core integrity checks, the administrator activity log and vulnerable plugin alerts, which would often have let you patch the flaw before the attack.

Frequently asked questions

Should I restore a backup or clean the site?

Restore if you have a backup from before the intrusion and you know when the intrusion happened. Otherwise, clean or rebuild. Either way, fix the entry point and change every credential, or the attacker will come back.

How long does Google take to remove the warning?

After a review request in Search Console, Google quotes a few days to a few weeks for malware and hacked content. The delay depends on how thorough the cleanup is: any remaining issue makes the review fail.

Do I need to notify the regulator for simple SEO spam?

Not if no personal data could be viewed or copied. But an attacker who was able to add pages has often had access to the database: check what it contains (accounts, orders, form entries) before concluding, and record your assessment in your breach register.

Is changing the WordPress keys and salts enough?

No. It closes open sessions, but an attacker who knows a password, has a hidden administrator account or a backdoor gets straight back in. Salts are one part of a whole: passwords, accounts, files and scheduled tasks.

When should I call in a professional?

When you cannot find the entry point, when the site gets reinfected after cleanup, when customer or payment data are at stake, or when the site generates your revenue. Ask for a written report: cause, affected files, actions taken.

Sources

• WordPress.org: FAQ My site was hacked (external link, opens in a new tab)
• Google: Security issues report (external link, opens in a new tab)
• GDPR Article 33: notification of a personal data breach to the supervisory authority (external link, opens in a new tab)
• WP-CLI: wp config shuffle-salts (external link, opens in a new tab)