Insight · WordPress

WordPress site hacked? What to do, in order

Published
1 October 2026
Read
6 min read
Written by
ROQ-TECH studio

Your website is sending visitors to a pharmacy page, or Google is showing a warning next to your name, or your host has emailed to say the account is suspended for malware. This is what to do, in the order it needs doing: the first hour, the clean-up, the checks before you tell Google it is fixed, and how to stop it happening again.

How to be sure it is a hack

The common signs are a site that redirects to another website on some visits but not others (often only on phones, or only from Google results), pages in the search results you never wrote, with titles about medicines or betting, a “this site may be hacked” line under your name in Google, a red warning page in Chrome, new administrator users you do not recognise, or an email from your host. A site that is simply down, or showing a maintenance message, is usually not hacked; that is covered in a separate guide.

The first hour

  • Change every password that reaches the site. WordPress admin accounts, the hosting control panel, FTP, and the database password in wp-config.php. Do this from a computer you trust. If the attacker got in with a stolen password, cleaning the files without changing it just invites them back.
  • Take a copy of the site as it is. Before you delete anything, download the files and export the database. It feels wrong to keep an infected copy, but you may need it to find out how they got in, and for your insurer or lawyer if customer data was involved.
  • Look at the users list. In WordPress, open Users and sort by role. Delete any administrator you did not create. Do the same in the hosting panel for FTP accounts.
  • Find out when it started. Your host’s access logs and your backup dates will tell you. You need the date to choose a clean backup, and to know how long customers may have been affected.
  • Take the site offline if it is harming visitors. If the site is redirecting people to scams or serving a download, put up a maintenance page through the hosting panel until it is clean. A day offline costs less than a week of customers being sent to a fraud page.

Cleaning it: restore if you can, clean by hand if you must

The fastest reliable fix is to restore a backup taken before the hack and then immediately update everything, because the backup still has the weakness that let the attacker in. This only works if you know when the hack started and you have a backup older than that. Most hosts keep daily backups for a week or two; ask yours what they have before you assume.

If there is no clean backup, the site has to be cleaned in place. The order that works:

  • Replace WordPress itself with a fresh copy. Download the current version from wordpress.org and overwrite the wp-admin and wp-includes folders and the files in the root, except wp-config.php. Attackers hide files among these, and replacing them wholesale is quicker than hunting.
  • Reinstall every plugin and theme from the official source. Delete each one and install it fresh from wordpress.org or the developer. Delete any plugin or theme you are not using rather than leaving it deactivated. Check wp-content/mu-plugins, a folder most owners have never looked in, and delete anything you do not recognise.
  • Search the uploads folder for code. wp-content/uploads should contain images and documents only. Any file ending in .php in there is malicious and can be deleted.
  • Read wp-config.php and .htaccess. Both are favourite hiding places. Compare them with a fresh copy and remove anything you cannot explain, especially long lines of encoded text.
  • Run a scanner afterwards, not instead. A security plugin such as Wordfence, or your host’s own scanner, is good at confirming a clean site and poor at cleaning a dirty one on its own. Run it after the steps above and act on anything it still finds.
  • Check the database. Look in the posts table for content you did not write, and in the options table for a site URL or home URL that has been changed. The redirect hack often lives there rather than in a file.

Before you tell Google it is fixed

Open Google Search Console and look at the Security Issues report. If Google flagged the site, there is a “request review” button, and you should only use it once you are confident the site is clean, because a failed review takes longer to clear. Check the Pages report for addresses you never created and ask for them to be removed. Then search your own business name and look at what Google shows for the next few weeks; spam pages can linger in results after they are gone from the site.

If customer details were on the site, such as order records or form submissions, the Protection of Personal Information Act requires you to notify the Information Regulator and the people affected as soon as reasonably possible. Your lawyer or accountant will know the form it takes. It is not optional, and it is easier to do early.

How to stop it happening again

Hacked WordPress sites almost always let the attacker in through one of three doors: a plugin or theme with a known weakness that was never updated, a weak or reused password on an administrator account, or an old PHP version on the host. They are the first three things our security audits check, and all three are cheap to close.

  • Update everything, monthly at least. WordPress, plugins, themes and PHP. Remove plugins you do not use rather than leaving them installed.
  • Strong passwords and limited logins. No account called “admin”, a long unique password for each administrator, and a plugin that limits login attempts. Two-factor login if your team will use it.
  • Backups you have tested. Daily backups kept for at least a month, and a restore you have tried once. The month matters: a hack found on day twenty needs a backup from day nineteen.
  • Fewer places to get in. Block the xmlrpc.php file, turn off file editing in the admin, and keep the WordPress version out of the page source. These are settings, not products, and they are on our security audit checklist for every site.

There is also a structural answer. On the sites we build, WordPress is not on the public domain at all; it lives at a private address and the public site is made of pre-built pages with no login, no PHP and no database to attack. That is one of the main reasons we build that way, and it is explained in headless WordPress vs traditional WordPress. It does not make WordPress itself immune, but it takes the shopfront out of the firing line.

Questions we get

Will Google penalise the site permanently?

No. Once the site is clean and the review passes, the warning is removed and rankings generally recover over a few weeks. Rankings for the spam pages disappear, which is what you want.

Is it my host’s fault?

Rarely. On shared hosting the host secures the server, and you are responsible for what runs inside your account. An out-of-date plugin is yours, not theirs. A host that still runs an old PHP version is a reason to move, though.

Should I pay a cleaning service?

If you have no clean backup and no developer, yes. Several reputable security companies clean WordPress sites for a fixed fee and it is money well spent compared with a week of trial and error. Whoever does it, the prevention list above still has to happen afterwards, or you will be paying them again.

If you would like us to look at a site that has been hacked, or to check one that has not been yet, send the address through the contact page.

Weighing this up for a real project?

Tell us what the site has to do and we’ll tell you honestly which one it should be, including when that’s traditional WordPress.

Talk to the studio ↗