WordPress site hacked: what to do now, step by step

Signs that your site was hacked

• Google or Bing warn visitors about your site, or Search Console lists a security issue.
• Your host has suspended the site or reports malware.
• Visitors are redirected to other websites.
• Google shows pages you never created, often advertising pills, casinos or fake shops.
• There are admin accounts nobody on your team created.
• Visitors' antivirus software flags your site.

These are the signs listed by the WordPress.org FAQ on hacked sites and Google's guidance. If you are not sure your site runs WordPress at all, here is how to check if a website is WordPress.

Step by step: what to do now

1. Stay calm and write everything down

Note what you noticed, when (with the time), and what changed recently, such as a new plugin or a theme edit. Take screenshots. You will need this for the clean-up, for the conversation with your host and for a possible GDPR report.

2. Take the site offline and tell your host

While the site is live, it can infect visitors or leak data. Google recommends taking it offline, ideally by showing a simple maintenance page (status 503) served from outside the hacked server. See Google's guide to quarantining a site. Tell your host straight away. Many have their own process for hacked sites.

3. Check your own computers

Run a virus scan on every computer you use to log in to WordPress or your hosting. Malware on a laptop can read passwords as you type them, and then new passwords don't help much.

4. Change every login

• WordPress: delete admin accounts you don't recognise and reset every user's password.
• Hosting: the customer account, FTP or SFTP, and the database password (then update it in wp-config.php).
• Security keys: generate new keys and salts with the official WordPress.org generator and replace the old ones in wp-config.php. This logs everyone out, including the attacker.
• Email: the mailbox that receives password reset links.

5. Save a copy of the hacked state

Before you delete anything, copy the files and the database as they are now. You need that copy to work out how the attacker got in. Label it clearly as infected and never restore it.

6. Rebuild from clean sources

There are two ways. Restore a backup from before the hack, if you are sure it is clean. Or rebuild: upload the same WordPress version from wordpress.org by SFTP, and reinstall plugins and the theme from their official sources. Don't rely on the reinstall button in the dashboard. Then check the places where malicious code likes to hide:

• PHP files in wp-content/uploads. Only images and documents belong there.
• wp-config.php and .htaccess, including copies in subfolders.
• The wp-content/mu-plugins folder. These plugins load automatically and do not show up in the normal plugin list (Sucuri on mu-plugin malware).
• Scheduled tasks (cron jobs) at your host that quietly put the malware back.
• Admin users in the database.

This is not a theoretical list. In Sucuri's report on almost 40,000 cleaned sites, 49% had at least one backdoor, and 55% of infected databases contained malicious WordPress admin users (Sucuri 2023 report).

7. Update everything, then change the passwords again

Once the site is clean, update WordPress, plugins and theme, and delete the plugins you don't need. Our guide on checking your plugins for vulnerabilities shows how. Check the PHP version on your server too, see how to check and update your PHP version. Then change all passwords a second time, because the attacker may have read the first new ones.

8. Find the way in

If you skip this step, the same hole stays open. The most common ways in are a vulnerable plugin or theme, outdated software and weak or reused passwords. Of the 11,334 new WordPress vulnerabilities reported in 2025, 91% were in plugins (Patchstack 2026 report). The infected copy and your server logs often show which file changed first. If you can't do this yourself, bring in a professional.

9. Ask Google for a review

If Google flagged your site, you will find it in Search Console under the Security Issues report. Fix every issue, test the site, then click "Request Review" and describe what you did (Google's help page). According to Google, malware reviews take a few days and reviews for spam hacks can take several weeks.

GDPR: do you have to report the hack?

If your site holds personal data (form submissions, customer accounts, a newsletter list) and the attacker had access, it is usually a personal data breach.

• Article 33: report it to your data protection authority without undue delay and, where feasible, within 72 hours of becoming aware of it, unless it is unlikely to result in a risk to people. If you report later, you must explain why (Art. 33 GDPR).
• Article 34: if the breach is likely to result in a high risk to people, you must also inform them directly (Art. 34 GDPR).
• Document it either way. Every breach has to be recorded, even one you don't report.
• If your agency or host noticed the breach, they have to tell you without undue delay.

This is not legal advice. If you are unsure, ask your data protection officer or a lawyer.

Do it yourself or get help?

Steps 1 to 5 you can do yourself. Get help with steps 6 and 8 if you can't read code with confidence, if customer data was affected, or if the site has been hacked before. Your host, your agency or a specialist clean-up service are the usual first calls.

How to stop it happening again

• Install updates promptly: plugins, theme, WordPress and PHP. Our overview of WordPress security flaws explains why speed matters: the typical time from a public vulnerability to the first attack is hours, not weeks.
• Delete plugins you don't use.
• Use strong, unique passwords and two-factor login, and keep the number of admin accounts small.
• Keep regular backups away from the server, and test a restore once.

Or shrink what can be attacked in the first place. A website that only delivers finished files has no plugins, no database and no login on your domain. That is how sites on ShiftPress work: every page is built ahead of time as HTML and served through Cloudflare. No website is immune, but there is far less to break into. If you want to go that way, clean up first and move afterwards, so nothing the attacker added comes along. More in static websites: benefits and weaknesses.

More on WordPress security

• WordPress security flaws: why outdated sites get hacked (the overview)
• How to check your WordPress plugins for vulnerabilities (free tools)
• How to check and update your PHP version (safely, with a test first)
• PHP2Shell: the critical PHP vulnerability of October 2026 (news)

Frequently asked questions

The bottom line

A hacked site feels like an emergency, and the order of the steps matters most: secure, change every login, rebuild from clean sources, find the way in, then ask Google for a review. Rushing straight to deleting files is the most common mistake.

Sources: WordPress.org, Google web.dev, Google Search Console Help, GDPR Art. 33, Patchstack, Sucuri.