To fix a hacked WordPress site, the first hour is for containment and evidence, not cleaning. Take the site offline behind a maintenance page, take a full copy of the files and database as they are now, change every password and key that touches the site, and write down what you saw and when. Do not run a scanner and delete what it flags. That destroys the evidence of how the attacker got in, and a site cleaned without finding the entry point is reinfected within days. A WordPress malware removal service that quotes a price before asking how the attacker got in is selling the scan-and-delete approach with a nicer invoice.
The first hour, in order
- Put the site behind a maintenance page or password at the web server level. Not a WordPress maintenance plugin, because the attacker's code runs inside WordPress. A rule in nginx or Apache, or the host's "site offline" switch, stops visitors being served spam or malware and stops search engines indexing it. If the site is a store, this costs you an hour of orders. Serving malware to customers costs you far more.
- Take a full copy of everything, untouched. All files, including uploads, and a database dump. Do this before changing anything. This copy is the evidence. The timestamps on the files and the rows in the database are how the entry point is found later.
- Rotate every credential. WordPress admin passwords for every user, the database password, FTP and SFTP accounts, the hosting control panel, the salts in wp-config.php, and any API keys stored in plugin settings such as payment gateway keys and mail service keys. Assume all of them are known to the attacker, because if they had file access, they read wp-config.php.
- Check your own machine. A surprising number of WordPress compromises start with a stolen password from an infected laptop. If the site admin's computer has malware, cleaning the site achieves nothing.
- Write down the timeline. When did you first notice. What did you see: redirects, spam pages in search results, a defaced home page, a warning from the host or a browser. What changed on the site in the weeks before: new plugins, a new user, a theme update. Whoever does the repair will ask all of this, and answers from memory a week later are worse than notes from the first hour.
Why scanner-and-delete fails
Every security plugin has a scanner, and the scanner will find files. It will find obfuscated PHP in the uploads folder, a fake plugin with a plausible name, and injected code at the top of index.php. Deleting these feels like progress. It is not, for three reasons.
First, scanners match known patterns. An attacker who has been on a site for months has usually left several ways back in, and at least one of them is a small, clean-looking file the scanner has no signature for. Second, the malware is the symptom. The cause is a vulnerable plugin, a weak password, a stale PHP version or a compromised neighbor on shared hosting, and none of those are fixed by deleting files. Third, the deleted files were the evidence. Their creation dates, their location and the access logs around them are what point to the entry. Delete them and the investigation starts from nothing.
The pattern we see most often in site rescue work is a site that has been "cleaned" two or three times by a scanner, reinfected each time, and only then brought to a developer. Each cleaning made the eventual diagnosis harder.
To fix a hacked WordPress site, find out how they got in
A repair is finished when the entry point is known and closed, not when the scanner is green. Finding it means reading the evidence copy from step two alongside the server access logs. In practice the entry is one of a short list.
- A plugin or theme with a known vulnerability that was not updated. This is the most common by a wide margin. Plugins update weekly and a site with no maintenance plan falls behind within a month.
- A weak or reused admin password, found by brute force or taken from another breach. Look for logins from unfamiliar addresses and for new administrator accounts you did not create.
- An abandoned plugin still active on the site but no longer maintained by its author, so its vulnerability will never be patched.
- Old software on the server: a PHP version past end of life, or an outdated control panel.
- Another site on the same hosting account that was compromised and used to write into this one. If several sites share one account with no isolation, they share every infection.
Once the entry is found, the repair is straightforward: restore from a clean backup taken before the compromise if one exists, or rebuild WordPress core, themes and plugins from fresh copies and carry only the database and uploads across after inspecting them. Then close the entry: update or remove the plugin, enforce strong passwords and two-factor authentication, move the PHP version forward, separate the hosting accounts.
What not to do
- Do not restore a backup without checking when the compromise started. If the attacker has been in for two months and the backup is three weeks old, you have restored the infection.
- Do not reinstall WordPress over the top of the existing files and call it done. Uploads, wp-config.php and the database are untouched by that, and those are where persistent backdoors live.
- Do not pay for a "guaranteed" clean from a service that has not asked to see the logs. They will run a scanner.
- Do not go back online because the site looks normal. Many infections show nothing to the site owner and serve spam only to search engine crawlers or visitors from specific countries.
- Do not delete the evidence copy, even after the repair. If the problem recurs, it is the baseline.
When to call a WordPress malware removal service, and what it costs
Call a developer when any of these are true: the site takes payments or holds customer data, the site has been cleaned before and came back, you cannot find the entry point within a day, or the host has suspended the account. A store that stays offline for three days while the owner experiments with scanners loses more than the repair costs.
Our WordPress site rescue service starts with a $300 diagnosis. A senior developer takes the evidence copy and the logs, finds the entry point, lists every file and database row that was touched, and writes up what the repair involves. That comes back as a fixed price for the repair, so you decide with the facts in hand rather than paying by the hour into an unknown. The diagnosis is worth having even if you then do the repair in-house, because the entry point is the part most people never find. The full price list, including the senior developer hourly rate, is on the pricing page.
Staying clean afterwards
A hacked site is almost always an unmaintained site. WordPress ships several core releases a year, plugins update weekly, and PHP versions reach end of life on a published schedule. Nobody with a business to run keeps up with that by hand. Our maintenance plans start at $59 per month for the Care plan, which covers tested updates, daily off-site backups, and uptime and security monitoring, and that last item is what turns "we noticed the hack three weeks in" into "we noticed it the same morning". The daily off-site backup is what makes a clean restore possible at all. If the repair costs several times a year of maintenance, which it usually does, the arithmetic is not complicated.
Common questions
How do I know if my WordPress site is hacked?
Search for your site name in Google and look for pages in languages you do not publish, or products you do not sell. Visit the site from a phone on mobile data rather than your office connection. Check the users list for administrators you did not create and the plugins list for names you do not recognize. A browser warning, a host suspension email, or customers reporting redirects are later signs.
Can I fix a hacked WordPress site myself?
If you can read server logs and are comfortable rebuilding core, themes and plugins from fresh copies, yes, and the steps above are the process. If the site handles payments, or you cannot identify the entry point, the $300 diagnosis is cheaper than a second infection.
Will Google penalize a hacked site?
Google flags sites it detects serving malware or spam, and that flag suppresses rankings and shows a warning to visitors. It lifts once the site is clean and you request a review in Search Console. Taking the site offline quickly reduces how much gets indexed in the meantime.
Should I move to a new host after a hack?
Only if the host was the cause: shared accounts with no isolation, PHP versions they refuse to update, or no server-level access to logs. If the entry was a plugin or a password, the host was not the problem and moving adds risk during a repair.
Next step
If the site is down or serving something it should not, start a project and mark it as a rescue. Include when you noticed and what you saw, and keep the evidence copy.
Want a senior developer to look at your site?
Tell us what you need. You get a written scope and a fixed price, usually within one business day.
