How to Fix a Hacked WordPress Site, Step by Step

A red warning in Chrome, a redirect to an unfamiliar domain, and a dashboard where everything looks as it always does. The emergency sequence for a WordPress site: what not to do in the first hour, where the infection actually hides, and how to get rid of the Google warning.

A client rings on Thursday morning: Chrome is showing a full-screen red warning where your shop should be. You open the site on your phone, and a second and a half later the browser bounces you to a domain you have never heard of, while the office desktop with the dashboard open since Monday looks exactly as always. That is what a hacked WordPress site usually looks like — not a defaced home page signed by the attacker, but a site showing one face to its owner and another to its visitors, which is why the first hours are usually spent arguing about whether there is a problem at all.

How to fix a hacked WordPress site comes down to questions this article answers in the order they are normally asked: what you may and may not do in the first hour, while nobody yet knows how deep the attacker got; where in a WordPress installation the code tends to be hidden, because without that a clean-up is guesswork; and how to get Google to lift the warning without wrecking your second attempt. In between sits the step owners skip most often — rotating credentials at the right moment and in the right order.

Everything that needs doing in the next few hours is here; you will not have to go elsewhere halfway through. We have left out only what matters once the site is running again — backup strategy, system hardening and protection against the next time, the same whatever the platform — and we point to a separate guide on those further down. The subject here is what makes WordPress different: the plugin ecosystem, the wp-content folder, the database tables in which an infection survives a file clean-up, and the commands that promise more than they check. In our experience those four things decide whether a site is clean after one day or after the third attempt.

How to fix a hacked WordPress site in the first hour: delete nothing

The first reaction is almost always one of two — open the hosting file manager, find something unfamiliar in it and delete it, or press the button that restores yesterday's backup. We ask you to do neither, and the reason is practical rather than bureaucratic. The urgency is understandable, because every hour under a red warning costs you visitors, but haste is exactly what produces the two decisions that stretch a recovery from eight hours into a week, and both of them are irreversible.

Delete the infected files and you delete the only material from which the way in is later established: file modification times, the contents of the scripts the attacker uploaded, and the server access log entries that line up with those times. Without the way in, a clean-up removes symptoms and nothing else, and the price of that has been measured — in a study by Google and the University of California, Berkeley covering 760,935 hijacking incidents between July 2014 and June 2015, 12% of sites were compromised again within 30 days, because the symptoms had been dealt with and not the cause (Li et al., WWW 2016).

So the first job is a full copy — every file and the whole database in one pass, before a single byte is touched, because the visible redirect or the defaced home page is rarely everything that is going on: on Sucuri's figures, 49.21% of infected sites in 2023 were found to be carrying at least one backdoor, and over the year their team removed 21,062 of them (Sucuri, "2023 Hacked Website & Malware Threat Report", June 2024). Keep the copy off the server itself, because that server is where the attacker still has access.

The next call goes to your hosting provider, and not out of politeness: they hold the access logs your own account usually shows only a few days back, and on a shared server they have to check whether the same is happening next door. If the site takes payments or collects personal data, take it down now or switch on maintenance mode — every visitor who types card details in over the next hour is a separate problem you do not have yet. Maintenance mode costs a day's turnover; a missed moment costs a letter to your customers.

If wp-admin no longer opens — which does happen on a hacked site — you cannot switch maintenance mode on from the dashboard, and two routes remain: a rule in the root .htaccess that sends everyone except your own IP address to a static page announcing technical work, or a request to the host, in that same call, to suspend the account for a while. The second looks crude, but it works even when you can no longer reach the files.

Yesterday's backup looks like the fastest way back, and occasionally it is, but only when you know which day the attacker came in. In our experience an infection is noticed considerably later than it began — the code stays quiet for a while, then starts serving spam pages or redirects — so the backdoor is most likely already inside yesterday's copy. Restoring it hides the symptoms for a couple of hours and returns the site to the exact state it was hacked in, which is why we normally start hacked website recovery within a few hours and, however urgent it is, begin with a copy rather than a deletion — even when the client is on the phone asking us to just clean it all up, fast.

The signs that give away a hacked WordPress site

A redirect that fires for a visitor arriving from a Google result but not when the address is typed into the browser bar is no glitch but the attacker's deliberate choice. Google's spam policies list redirects as a category of hacked content in which attackers inject code that "redirects some users to harmful or spammy pages" (Google Search Central, checked August 2026), and it is the word "some" that misleads the owner. Checking takes a minute: open the site in an incognito window, then find it in Google's results and open it from there, and repeat both on a phone.

The second group of signs sits on the administration side and is far more concrete: wp-admin suddenly returns a 404, the login form simply reloads after a correct password, the user list holds an administrator account nobody on your team created, or the site address under Settings → General is no longer yours. In the database that last sign is only two rows in the wp_options table — siteurl and home — which is exactly why the address in your settings and the address a visitor ends up at can differ.

The third group comes from outside and is the most painful, because somebody else is telling you the state of your own site: the hosting company suspends the account without warning after spam has gone out of it, a security issue appears in Search Console, or a "This site may be hacked" label turns up beside your link in the results, which Google shows when it believes an attacker has changed existing pages or added spam pages (Google Search Help, checked August 2026). Google attaches that label on its own initiative, not on a complaint, and it appears even when the site looks flawless to you.

The names are not academic here: they are what you will search on and what you will judge a contractor by. Google's own documentation names three — the gibberish hack, the Japanese keyword hack and the cloaked keywords and links hack, where the attacker's pages show one thing to the search engine and something else to the visitor. The industry favourite "pharma hack" comes from the security company Sucuri (2020) and appears nowhere in Google's documentation. The check is the same for all three: run a site: query on your own domain, and the pages nobody in your company wrote are there in front of you. In the Japanese variant they are auto-generated pages with Japanese headings, in randomly named folders on your domain.

And now the unpleasant part: a clean scan does not prove the site is clean. A scanner sees only what the server chooses to show it, the attacker's code often recognises scanners and search engine crawlers, and Google's guide to the cloaked keywords and links hack warns that the hack tends to be hidden so that the owner believes the problem has passed. If the scan is clean but your host is complaining about outgoing mail, believe the host. That is where a website security audit with a manual review of files and logs earns its place: a scanner answers whether the site holds anything from a list of known patterns, not whether somebody is still inside.

Where the WordPress risk actually sits

In our experience, when the cause is finally found it is almost never the WordPress core itself. Patchstack's "State of WordPress Security in 2026" report counts 11,334 new vulnerabilities disclosed across the WordPress ecosystem during 2025 — 42% more than the year before — and the way that number breaks down is what matters to you right now: 91% of them were in plugins and 9% in themes, while in the WordPress core only six were reported in the whole year, all of them low priority. Almost every newly discovered vulnerability, in other words, is not in the WordPress you once installed but in what has been bolted onto it over the years.

Every plugin is a separate codebase written by a separate author with separate — and fairly often already abandoned — update discipline, so a site with forty plugins is not a site with one security problem but forty independent ones. In our experience a typical company site gets by perfectly well on ten to fifteen, and the rest are left over from tasks everyone has long since forgotten: a gallery that is no longer displayed, a form replaced by a different one, a slider the current design does not use. When we take over WordPress development and maintenance, cutting the plugin count is the first job rather than the last.

And here is the mistake that recurs more than any other: the unnecessary plugin gets deactivated rather than deleted. Deactivating tells WordPress not to load it any more, but the files stay where they were on the server, some still reachable directly over HTTP, and an attacker's script only needs the path. In June 2021 Wordfence documented an actively exploited zero-day in the Fancy Product Designer plugin, a flaw "exploitable in some configurations even if the plugin has been deactivated", and advised uninstalling it rather than switching it off. If you no longer need a plugin, its place is not greyed out in the plugin list but off the server.

Scale explains why all of this happens automatically and with no personal motive behind it: according to W3Techs, as of 5 August 2026 WordPress powers 41.2% of all websites. In an ecosystem that size, every published plugin vulnerability is immediately usable against a very large number of identically built sites, which makes it more profitable to automate attacks than to aim them — the script reads version numbers, not company names. Nobody picked your site in particular, and that is precisely why a small brochure site with no customer data and no payments is hacked just as readily as a large online store.

Where an attacker hides code in a WordPress installation

The first place we open is wp-content/uploads — a folder that holds nothing but images, PDFs and video, and in which no PHP file should ever execute. If a .php file is lying there among the 2019 product photographs, it did not arrive by accident: it is almost always either an uploader the attacker uses to push the next batch of files onto the server, or a shell that runs commands with your server's privileges. You can tell the problem is real rather than theoretical from the fact that both Sucuri and Wordfence ship a hardening setting that uses an .htaccess rule to switch the PHP engine off in this very folder.

The second place is wp-content/mu-plugins. Plugins there are activated automatically, cannot be deactivated from the dashboard and — the part that matters most — do not appear in the plugin list the dashboard shows by default, so an owner can spend months looking at an apparently clean panel; in July 2025 Sucuri described exactly such a case, with a backdoor in that folder. Alongside it we always check .htaccess, in the root and in the subfolders, because a redirect that fires only for visitors from a search engine or only on mobile devices is most often written there — which is the reason your own site looks entirely normal to you.

Code is also written into the first lines of existing, wholly legitimate files, most often at the top of wp-config.php and in the theme's functions.php, and it hardly ever looks like malicious code: it is one long line with a base64_decode, gzinflate or eval call, followed by hundreds of blank lines so that in the editor the file looks finished. That is why comparing files against a clean original is worth more than reading them: nobody finds that line by eye, because nobody scrolls a file down to line nine hundred.

Then there is the database, where a file scanner does not look and where three places need checking: the wp_options rows siteurl and home, which the attacker rewrites so your pages load their resources from someone else's server; the wp_users table, where an administrator account with a plausible name tends to appear; and the wp_posts entries, where hidden links and iframes are built into old articles nobody opens any more. If the files are cleaned but the injection stays in the database, the infection is back the same day. The row itself does not execute: a small loader in the theme's functions.php or in mu-plugins reads it and runs it on every page load, and between them the two restore the deleted files faster than you can check the result. That is why, in hacked website recovery, files and database are one job for us, not two.

Comparing files against verified originals

The first tool we reach for once the full file and database copy is safe is wp core verify-checksums: it compares every file's hash against the checksums WordPress.org publishes and shows at once which files have been modified and which have no business being there. The trouble starts where its reach ends — the command checks only wp-admin/, wp-includes/ and the root wp-* files, while the source code deliberately skips the whole of wp-content — plugins, themes and uploads alike (WP-CLI checksum-command source, viewed 5 August 2026). That same source excludes one root file separately, wp-config.php, so the file whose opening lines most often carry injected code is invisible to the check. A clean result from the command does not mean a clean site.

There is a separate wp plugin verify-checksums for plugins, but it too compares files only against the WordPress.org repository checksums, so a commercial plugin bought from its developer is passed over; for themes there is no equivalent command in the WP-CLI documentation at all (WP-CLI documentation, viewed 5 August 2026). Themes are therefore closed to automated verification altogether, and so are plugins bought outside the repository, while wp core verify-checksums leaves out wp-content entirely — the part of the code where all but six of the 11,334 vulnerabilities Patchstack counted for 2025 arose. On the sites we take over, the theme tends to be the one thing nobody has ever checked.

Checksums are therefore a starting point, not a method. We do not disinfect the core and the plugins; we replace them with the same versions from the original source, overwriting folders in full rather than file by file. From the old installation we keep wp-content/uploads, and even that only after checking there are no PHP files among the images — for the same reason the PHP engine is worth switching off there at all. Where there is version control we restore the theme from it; where there is not, we take the developer's own copy and reapply the customisations one at a time, deliberately, because only then can we say later which line on the site is ours.

Finding the bad line and deleting it sounds cheaper, which is why it is the most repeated mistake of all: an attacker rarely leaves a single way in, and one unnoticed backdoor makes all the rest of the work pointless. The code may be split across several files, hidden behind a base64 or gzinflate call, written into the database options table, or dropped into that mu-plugins folder the dashboard does not show. Searching for a pattern finds what you already recognise; wholesale replacement gets rid of what you do not.

There is also work we do not do at this stage. We do not rely on a plugin that offers to "repair" infected files at a click: it works from the same list of known patterns, in the same environment the attacker still has access to. Nor do we compare files by hand when the site is an ordinary brochure page or a blog, because a fresh installation with the content carried across takes fewer hours than comparing two directories line by line, and the result can be verified. Careful manual comparison earns its place where the theme or a plugin is unique and there is no version control; the general recovery guide sets out how to handle backups so that the choice exists at all.

Keys, sessions and passwords: what each of them actually does

The authentication keys and salts in wp-config.php encrypt nothing, whatever nearly every guide claims: WordPress uses them as the basis for the key with which wp_generate_auth_cookie() signs the authentication cookie using HMAC-SHA256, while the cookie itself is plain text carrying the username, an expiry time and a session token (WordPress Developer Resources, viewed 5 August 2026). Rotating those values therefore makes every signature issued earlier unverifiable, and the server rejects every cookie handed out until then, even where the session itself has not formally expired.

The practical consequence is exactly the one a hack calls for: WordPress's official documentation describes rotating the keys as the way to log out anyone who might still be signed in (WordPress.org, "FAQ My site was hacked", updated 26 July 2026), so if the attacker holds a valid session, it ends in that instant. Every nonce issued so far becomes invalid along with the sessions, so forms in progress and half-finished checkout steps break at that point — which is why we pick the moment deliberately rather than at random in the middle of a working day.

Rotating the keys and salts changes no password. WordPress builds password hashes with bcrypt and a separate random salt for each one, unconnected to the constants in wp-config.php (the wp_hash_password() function; bcrypt by default since WordPress 6.8), so an attacker who knows the administrator's password, or has created an account of their own, simply logs in again once the keys have changed. Passwords are changed separately and all of them, including the ones nobody is supposed to know, and at the same time you walk the user list looking for accounts nobody on your team created.

The list of credentials does not end with WordPress: in the same pass you change the hosting control panel password, the FTP and SFTP credentials, the database user's password and the matching entry in wp-config.php, and the SSH keys, which are not changed but generated afresh, the old public key deleted from the server's authorized_keys file. Last come the API keys stored on the site — the payment gateway, the email sending service, the shipping and accounting integrations — because they survive untouched the longest: nobody sees them on a screen from one day to the next.

Assume the attacker holds a full copy of the database, because it is the cheapest step in the whole attack: everything in it — customer email addresses, order history, password hashes, the keys written into plugin settings — has to be treated as being in someone else's hands. If any of those passwords has been used anywhere else, that place is compromised too, and this is usually where the conversation moves off the website to email accounts, the accounting system and the shop's payment account.

The order matters as much as the list does: keys and passwords are changed after the backdoors have been taken out, because otherwise the attacker reads the new values straight out of wp-config.php or simply intercepts the next login. This sequence — full copy first, then the cause, then the clean-up, and only then the credentials — is where an in-house recovery most often stalls or comes apart, which is why we take this stage on ourselves and hand over a written report at the end of what was changed, when and why.

How to get the Google warning lifted, and what to do afterwards

The "Security Issues" section of Google Search Console is the only place to see what exactly Google has found on your site: it names the type of threat and samples the pages affected, and what your visitor sees right now follows from that. The type of threat does not change what the visitor sees: Chrome no longer sorts the warning heading by whether phishing, malware or unwanted software has been found, but shows the same full-screen warning in every case — headed "Dangerous site" — which simply does not let anyone onto the site, whereas the "This site may be hacked" label mentioned earlier is only a line of text beside the link in the results, and can be clicked through (Google's Chrome help page on dangerous sites, checked August 2026). Chrome no longer uses the older headings that differed by threat type — "Deceptive site ahead", for example — although they survive in parts of Google's documentation. The first blocks and the second warns, and that changes how much time you actually have.

Before pressing "Request Review", be certain the site really is clean and not merely clean-looking in your browser. Google's guide to the cloaked keywords and links hack warns explicitly that attackers try to create the impression that a page has already been deleted or fixed, so every former spam page has to be checked with the URL Inspection tool, which shows Googlebot's view rather than yours. The second step people skip most often is the owner list: in the Japanese keyword hack the attacker adds themselves as a verified Search Console owner (Google's documentation on web.dev), and until they are taken off it they know as much about the state of your site as you do.

The button to look for is "Request Review" in the security issues report, not the "reconsideration request" Google applies to manual actions, and three things are worth writing into the request: what was found, how the attacker got in, and what specifically has been done about it. We promise no deadline, because Google promises none either: its documentation page on social engineering says a review "can take several days to complete", while the Search Console help page on security issues says "from a few days to a few weeks" (both checked August 2026). If somebody quotes you a firm 24 or 72 hours, they are repeating a figure that appears in no Google source.

Haste at this step costs more than waiting does. In the same Google and Berkeley study, 80% of site owners had their site declared clean at the first attempt; the other 20% needed several, and the median time they spent combing out the code the attacker had left behind was a full week. The data is from 2014–2015 and should be read as such, but the arithmetic has not changed: a rejected request means the warning stays for another cycle, and the second time round you are no longer a first-time applicant.

Once the warning has gone the work is not finished: the attacker's pages stay in the index, and they must not be redirected to the home page — they have to return a 404 or a 410 so Google drops them altogether; the removals tool in Search Console only hides them for a while. Rankings do not come back at the flick of a switch: the pages have to be reindexed, at Google's pace rather than yours. A separate guide to hacked website recovery sets out how to use log files and backups so that next time you start from a better place.

When to stop doing it yourself, and what it costs

An experienced site owner does part of this themselves, and we say so without hedging, even to people who ring us with Search Console open and the offending plugin already identified. If the infection is one defaced home page, if the log files show which plugin let it in, if there are no unfamiliar administrators in the user list, and if yesterday's backup is one somebody has genuinely restored in a test environment, then eight paid hours buy you a better night's sleep, not a faster result.

There are four situations in which we advise stopping. The first is reinfection after a clean-up: if the site is hacked a second time, that is not bad luck but proof the way in is still open, and a third clean-up in the same environment costs exactly what the first two did. The second is any shadow of a suspicion about customer or payment data, because alongside the technical work come duties towards the supervisory authority and deadlines no goodwill will extend. The third is a site the business earns from every day, and the fourth is a plain lack of time: cleaning up is not intellectually difficult, but it is long, monotonous and forgives no skipped file.

Our hacked website recovery costs €90 per hour excluding VAT, with a minimum of eight working hours, paid in advance. We normally start work within a few hours of the request, and the whole process from start to handover usually takes 8–72 hours; the difference between eight and seventy-two is almost always how deeply the attacker settled in and how old the last clean copy is. The minimum is not a marketing figure: a full copy, the hunt for the cause in the log files, the clean-up and the verification rarely fit into less.

The order is the one set out above, only without your weekend in it. Before we touch anything we take a full copy of the files and the database, so that the incident can be investigated later at all, and only then is the site isolated; from there it is cleaned of malware and backdoors, the database checked, credentials and keys rotated, the way in found and closed, the review request filed with Google and monitoring set up, and at the end you get a written report on what happened and what changed. If the site is down right now, or you are unsure what you are looking at, book an urgent site check and we will tell you whether there is anything here worth paying for.

In many cases the real answer is not recovery at all but what comes after it: if a site has accumulated twenty plugins and nobody remembers why half of them are there, the problem is maintenance, and what solves it is WordPress development and maintenance, not another clean-up cycle six months from now. The cheapest hour in this whole story is the one spent beforehand: deleting an unused plugin from wp-content/plugins instead of deactivating it, and keeping a backup somebody has actually restored in a test environment once, together cost less than a single day of our work.