Has your WordPress site been hacked? The first steps.

One morning a customer writes to tell you that your site sent them to a casino page. Or you search for your business on Google and see dozens of pages with Japanese characters and drug names that you never created. A hacked WordPress site is stressful, but it’s rarely a disaster, as long as the first steps are taken in the right order.

Below is the order we follow ourselves on the sites we maintain: how to confirm the problem, what to do straight away, what to avoid, how the cleanup works, what applies to Google and the GDPR, and what changes afterwards.

01How to tell your site has been hacked

The word “hacked” doesn’t say much. The WordPress.org documentation first asks you to describe the symptoms precisely, because they determine what you’ll look for. The most common:

• Redirects to spam, casino or fake store pages. They often happen only on mobile or only for visitors coming from Google, so the owner doesn’t see them.
• Spam pages on Google. In the search box, type site: and your domain. Pages in Japanese or with drug names mean someone is creating content on your site.
• Unknown administrators among your WordPress users, or plugins you didn’t install.
• Warnings. Google shows the label “This site may be hacked” in search results when it believes someone has changed pages or added unwanted ones (Google Search Help). A warning may also appear in the browser, or visitors’ antivirus may block the site.
• Suspension by your hosting provider or bounced emails, because the server has ended up on a spam blocklist.

02The first hour: six steps, in order

1. Write down what you saw and when. The time, the symptoms, and what changed in the last few days: a new plugin, an update, a new user. You’ll need it, and so will your developer and, if it comes to that, the Data Protection Authority.
2. Keep a copy of the infected state. Files and database, as they are. It sounds strange, but WordPress.org explicitly recommends it before the cleanup: if something goes wrong, you have a reference point and evidence of how the attack happened.
3. Tell your hosting provider. On shared hosting, the infection may affect other sites in the same account, and your host has logs you can’t see.
4. Change all passwords, from a clean computer. Not just WordPress, but also the hosting panel, SFTP/FTP, the database and the administrator’s email. WordPress.org notes that the starting point is often an infected computer that steals passwords, so scan yours too.
5. Check the users. Under Users, filtered by “Administrator”, every account should belong to someone you know. Record the unknown ones (name, email, date) and then remove them.
6. Protect your visitors. If the site is sending people to malicious pages, put it in maintenance mode or take it offline temporarily from the hosting panel until it’s cleaned up.

03What not to do

• Don’t delete files blindly. You lose evidence of how the attack happened, and the backdoor is usually somewhere else.
• Don’t restore a backup and forget about it. If the hole they exploited, such as an outdated plugin, is still there, the infection will come back.
• Don’t rely on reinstalling from wp-admin. WordPress.org explains that it replaces the existing files but doesn’t delete the new ones the attacker added.
• Don’t install “cleaners” from unknown sources and never nulled, that is “cracked”, versions of premium plugins and themes. They often come with malicious code built in.
• Don’t ask Google for a review before you’re done. Google warns that premature or repeated requests can delay later ones.

04How to clean up a hacked WordPress site

There are two routes, and they’re often combined.

In a manual cleanup, the order is roughly this:

• Core. Replace the wp-admin and wp-includes folders with clean files of the same version, over SFTP. With WP-CLI, the command wp core verify-checksums compares the files with WordPress.org’s official checksums, and with the –include-root option it warns about anything in the root folder that doesn’t belong to WordPress.
• Plugins and themes. Download them again from wordpress.org or from your account with the vendor, never from “free” copies. Delete anything you don’t use.
• Uploads and “favorite” files. PHP files inside wp-content/uploads have no business being there. Pay particular attention to .htaccess, index.php and to header.php, footer.php and functions.php in the theme, which WordPress.org lists as common targets.
• Database. Scripts hidden in posts, widgets and settings, and administrators created directly in the database.
• New security keys (salts). Change them in wp-config.php, so that anyone still logged in is logged out, and then change all passwords again.

Finally, update WordPress, plugins and the theme, and find out how the attacker got in. Without this step, the cleanup is only temporary.

05Google: warnings and review requests

If Google has detected the problem, you’ll see it in the Search Console “Security issues” report. There are three categories: hacked content, malware and unwanted software, and social engineering, such as fake login pages. The report also gives example URLs, which are useful for the cleanup.

When the site is clean on every page, not just the ones listed, click “Request Review” and describe the problem, what you did and what the result was. According to Google, the review takes from a few days to a few weeks. Don’t send a new request while the previous one is pending. If the site wasn’t verified in Search Console, do it now: that’s where the warning gets removed.

After the cleanup, the spam pages that were created should return a 404 or 410 error, so that they gradually drop out of the results.

06GDPR: when to notify the Data Protection Authority

If the site holds personal data, such as customer accounts, orders, form messages or a newsletter list, and the attacker may have had access to it, this is a personal data breach. Under Article 33 of the GDPR, your business, as the controller, must notify the Hellenic Data Protection Authority within 72 hours of becoming aware of it, unless it is unlikely to result in a risk to the people concerned (European Data Protection Board guide).

• If you don’t have all the details within the 72 hours, make an initial notification and add the rest as you go.
• Every breach is recorded in an internal register, even if it doesn’t need to be notified.
• If the risk is high, you also inform the people themselves (Article 34), preferably individually rather than with a general announcement.

The Authority’s breach notification page also has a self-assessment tool, which it recommends you use before notifying. In an e-shop where payment happens on the bank’s page, card details as a rule don’t pass through your site. Customers’ names, addresses and phone numbers, however, are in the database. Assessing the risk is a legal decision, so bring in your data protection officer or lawyer from day one. Your developer provides the facts: what changed, when, and whether there are signs the database was accessed.

07How to stop it happening again

The data shows clearly where the risk comes from. According to Patchstack’s report on WordPress security, 11,334 new vulnerabilities were found in the WordPress ecosystem in 2025: 91% in plugins, 9% in themes and just 6, all low priority, in core. For 46% there was no fix from the developer at the time of disclosure, and the weighted median time to first exploitation was 5 hours. The pace isn’t slowing: in the week of 28 September – 4 October 2026 alone, Wordfence recorded 510 vulnerabilities in 370 plugins and 10 themes.

• Updates without delay, ideally tested on staging first. When attacks on a new vulnerability start within hours, updating “once a month” isn’t enough for critical ones.
• Fewer plugins. Delete anything you don’t use, don’t just deactivate it. Replace any that their developer has abandoned.
• Two-factor authentication (2FA) for every administrator, with unique, long passwords.
• Least privilege. Whoever writes posts is an Editor, whoever manages orders a Shop Manager. Administrator accounts only for those who really need them.
• A firewall that “understands” WordPress. In Patchstack’s tests with hosting providers, standard server defenses blocked just 12% to 26% of attacks on vulnerabilities, depending on the experiment. An application-level WAF helps, but it doesn’t replace updates.
• Off-server backups, tested. A backup you’ve never restored is an assumption, not a plan. Keep several days’ worth, because an infection may only be detected weeks later.

If your site is already showing any of the signs that it needs maintenance, don’t wait for the hack. In our maintenance plans, Grow includes staging and daily off-server backups, and Scale includes unlimited hack cleanup and a response within 4 hours, 24/7, for critical issues. You can choose the plan that suits you or, if you’d like an overview first, request a technical audit with a security and malware check.

08FAQ

Will I lose my Google rankings?

While there are warnings and spam pages, traffic usually drops, because users avoid the site. After the cleanup and the review, things gradually recover. How quickly depends mainly on how long the problem lasted.

Is a security plugin enough?

It helps detect and block known attacks, but it doesn’t update a vulnerable plugin or change a leaked password. It’s one layer of protection, not the solution.

Can I clean it up myself?

If the infection is simple and you have a clean backup, yes, with the steps above. But if you have an e-shop, customer data or a warning from Google, it’s worth having someone experienced look at it. One missed backdoor means a new infection within days. For immediate help, contact us.