Hacked WordPress: what to do in the first hour and how to protect your site

A customer calls to say that after visiting your website they landed on a casino. You open it on your computer and everything looks normal. Or Japanese text and offers for cheap medications suddenly appear in Google under your company name. These are typical symptoms of a hacked WordPress site, and what you do in the first hour determines whether the attack will happen again and how long Google will warn people about your site.

Below you will find the symptoms of a break-in, a plan for the first hour, a way to get the warning removed in Google Search Console and 10 safeguards that take about 30 minutes. I draw on WordPress.org recommendations and Google documentation.

Symptoms: how to tell that WordPress has been hacked

A break-in is rarely visible on the home page. Malicious code often works only for some visitors, so that the owner notices nothing for as long as possible. The most common signs:

• Redirects only for some visitors. In Search Console Help, Google describes scripts added by hackers that redirect phone users to malicious sites. You type the address on a computer and see the normal site, while a customer arriving from Google results on a smartphone lands on a scam.
• Foreign subpages in Google. Type site:yourdomain.pl into the search engine and go through the results. Japanese titles, medications, casinos or counterfeit designer clothes are usually spam injected by hackers. Google calls the Japanese-character variant the “Japanese keyword hack”: these are automatically generated subpages with links to stores selling counterfeits.
• New administrators. In the WordPress dashboard there is an account nobody at the company created, or Search Console says someone new has verified ownership of your site. According to Google, this is a strong sign of a break-in.
• Google warnings. Next to your site in search results the note “This site may be hacked” appears, and Chrome shows a full-screen warning, for example about malware.
• A block from the host. The provider disables the site or sends an email about malicious files. WordPress.org lists this among the unambiguous signs of a break-in.
• Company emails in spam. A hacked site is sometimes used to send out spam, and then the server’s IP address ends up on blacklists. When your email runs on the same server, your offers suffer too.

Beware of a trap: hacked subpages can show an ordinary visitor a 404 error while showing Google’s crawler spam. To see what Google sees, use the URL Inspection tool in Search Console and the “Test live URL” button.

What not to do in the first minutes

The first instinct is to delete everything or click “restore backup” in the hosting panel. Both moves can be a mistake:

• Don’t delete files blindly. You lose the traces that let you work out how the hackers got in. You will remove the symptom, and the vulnerability will remain.
• Don’t restore a backup without closing the vulnerability. A backup from before the attack usually has the same hole, for example an outdated plugin, so the attack can happen again.
• Don’t change passwords from a computer that may be infected. WordPress.org reminds us that an attack often starts with a trojan on the owner’s computer that steals FTP and dashboard passwords.
• Don’t ask Google for a review right away. Google states outright that a premature request only lengthens the time your site stays marked as dangerous.

A plan for the first hour

This list is worth printing and keeping together with your hosting login details. The times are approximate.

1. Write down the symptoms (5 minutes). What you see, since when and on which device. Take screenshots and note recent changes to the site, such as a new plugin. This is where the WordPress.org guide for hacked sites begins.
2. Call your host (10 minutes). Ask what they detected and in which files. Ask for the server logs before they are deleted, and for a list of backups with dates.
3. Make a copy of the infected site (10 minutes). Download the files and the database to a disk outside the server, into a clearly named folder, for example INFECTED-2026-10-25. Google and WordPress.org recommend this before any removal. This copy is for analysis, never for restoring.
4. Limit the damage (5 minutes). If the site redirects customers to scams or distributes malicious files, ask your host to take the site offline temporarily.
5. Scan your computer (2 minutes to start). Run a full antivirus scan on the computer you use to log in to WordPress. Do the remaining steps from another, clean device.
6. Change passwords (10 minutes). The hosting panel, FTP/SFTP, the database user (enter the new password in wp-config.php as well), all WordPress administrators and the email inbox that receives password reset links. Then replace the security keys in wp-config.php with new ones from the official WordPress.org generator. This logs everyone out, including the intruder.
7. Remove unknown accounts (5 minutes). In WordPress, review users with the Administrator role, and in Search Console go to Settings → Users and permissions. Before deleting, note the account’s login, email and creation date. Also remove the intruder’s verification token from the site (an HTML file or a meta tag), because otherwise, as Google writes, the removed owner can verify ownership again.
8. Update and scan (10 minutes). Update WordPress, plugins and themes. Run the scanner in the dashboard (WordPress.org mentions Wordfence and Sucuri, among others) and an external scanner, for example Sitecheck. An update closes the vulnerability, but it does not remove files added by hackers.

If the site has orders, customer accounts or saved form messages, check whether data may have leaked. Under Art. 33 GDPR, the controller reports a breach to UODO (Urząd Ochrony Danych Osobowych, Poland’s data protection authority) without undue delay and, where feasible, no later than 72 hours after becoming aware of it, unless the breach is unlikely to result in a risk to the rights and freedoms of customers. A notification sent after 72 hours must explain the reasons for the delay, and where the risk is high, Art. 34 GDPR also requires notifying the customers themselves. The form is on the UODO website. This is general information, not legal advice (the law as of 25 October 2026), so have a lawyer or a data protection officer assess a specific leak.

Cleanup: a backup from before the attack or manual cleaning

A backup from before the attack is the fastest route if you have a backup dated before the first symptoms, preferably a few days older, because the code may have reached the server earlier. After restoring, immediately do updates, new passwords and a scan. In an online store, first write down from the infected copy the orders placed after the backup date, because restoring will delete them.

Manual cleaning remains when there is no backup or it is too old. WordPress.org recommends replacing the wp-admin and wp-includes directories via SFTP with fresh ones, in the same version you have. Reinstalling from the dashboard is not enough, because it overwrites files but does not remove those added by hackers. Download plugins and themes again from official sources, and pay particular attention to .htaccess, index.php, and header.php, footer.php and functions.php in the theme.

A technical person with SSH access will check the most important things faster through WP-CLI:

# WordPress files compared with the WordPress.org checksums
wp core verify-checksums
# the same for plugins from the official directory
wp plugin verify-checksums --all
# administrators with the account creation date
wp user list --role=administrator --fields=ID,user_login,user_email,user_registered
# PHP files in the uploads directory, where they should not be
find wp-content/uploads -name "*.php"

Once the site is clean, change the passwords again: WordPress.org recommends this even if they were already changed when the attack was detected. Finally, check the site with my tool Check your website. It doesn’t look for viruses, but in about 30 seconds it shows whether HTTPS works, whether security headers are present and whether the server reveals its software version.

Google Search Console: how to remove the warning

Without Search Console you can’t ask Google for a re-review. I describe how to add your site to it in the guide Your business website doesn’t show up in Google.

1. Open the “Security issues” report. You will see the type of issue, for example “Hacked: Content injection” or “Hacked: Malware infection”, and sample URLs.
2. Also look at the “Manual actions” report. If there is an entry there, after cleanup request a review in it as well.
3. Check the sample URLs with the URL Inspection tool. They must show clean content or a 404 error.
4. Click “Request review” and briefly describe what was done about each type of issue: pages removed, plugin updated, passwords changed.

How long does it take? According to Google, reviewing a phishing site takes about a day, a site with malware a few days, and a site with spam injected by hackers up to several weeks.

10 safeguards in 30 minutes

The list is based on the WordPress.org recommendations on hardening your site.

1. Automatic updates (5 minutes). Since WordPress 5.5 you can turn them on for every plugin and theme, and in bulk on the plugin list.
2. Remove unused plugins and themes (4 minutes). Delete them, don’t just deactivate them: a deactivated plugin still sits on the server.
3. Plugins only from a reliable source (2 minutes). WordPress.org says it outright: don’t install plugins or themes from untrusted sources, only from the official directory or from known companies. “Nulled” versions, that is, pirated copies of paid plugins, often contain hidden backdoors for hackers, according to Wordfence.
4. Two-factor authentication (5 minutes). For every administrator, for example with the Two Factor plugin from the WordPress.org community: a code from an app on your phone, plus backup codes. Turn it on in your hosting panel as well.
5. Fewer administrators (2 minutes). An employee who adds posts needs the Editor or Author role. Don’t use the login “admin”.
6. Passwords from a password manager, and SFTP (3 minutes). A long, unique password for every access point. Instead of plain FTP, which sends the password in clear text, use SFTP.
7. Backups off the server (5 minutes). A backup on the same server can be lost or get infected together with the site. Set up automatic backups of the files and the database to the cloud or to another server, keep several versions, and once a quarter check that a backup actually restores.
8. Current PHP (1 minute). WordPress.org recommends PHP 8.3 or newer, and PHP 8.2 receives security fixes only until 31 December 2026. You change the version in the hosting panel, after making a backup.
9. Search Console notifications (2 minutes). Google sends an email to verified owners when it suspects a break-in. Check that notifications are turned on and that your mail filter doesn’t catch them.
10. Disable the file editor (1 minute). The line below, added to wp-config.php, blocks editing PHP files from the dashboard. It won’t stop every attack, but it closes the simplest route.

define( 'DISALLOW_FILE_EDIT', true );

There is also a route that makes most of this list disappear. A simple business website without a store or customer accounts can run as plain files, with no plugins to patch. That is how I moved more than 200 subpages of the Żukowscy company website from WordPress and Elementor to Next.js as part of a website redesign. The downside: content changes then require a different panel or my help.

Summary

When there is a break-in, the order matters: first notes and a backup, then passwords, accounts and updates, and cleanup and the request to Google last. Rushing to delete files or restore an old backup often ends in a repeat of the attack.

If you would rather not keep up with updates and backups yourself, I do it as part of technical maintenance from PLN 149 net per month. A security audit with a report and fixes costs from PLN 990 net. If your site has already been hacked, write to me: I will reply within 24 hours with an action plan and a quote.