WordPress Hacked Recovery
A hacked site is an incident, not a scramble. Recovery follows a standard sequence, isolate, backup, clean, patch, harden, rescan, monitor, with timelines scoped for realism, not false promises.
Priority queueA hacked WordPress site is rarely a single entry point, it is a chain: an infected plugin, a stale password, an unpatched vulnerability, backdoor files left for persistence, and malware aimed at your visitors or your reputation. Recovery is not a cleanup; it is a structured incident-response that removes the intrusion, closes the holes that let it in, and verifies it stays gone.
The sequence is standard and boring on purpose: isolate the site so damage does not spread, take and preserve a clean backup, clean the infection, patch what was vulnerable, harden what was open, rescan to confirm, then monitor for a return. Timelines are framed as a typical shape, scoped honestly after seeing the actual site, because a clean one-theme site and a forty-plugin estate recover differently, and anyone who quotes before looking is guessing.
This is one senior developer, async-first, in the IST timezone. Recovery is urgent-priority work slotted ahead of the queue with a first response inside one business day, and it is delivered with honest expectations about what a one-person practice can promise, which is a careful, methodical recovery rather than a magic overnight reset of a badly compromised estate.
While the investigation runs, the security checklist is useful preparation, and the ongoing answer is prevention: the security page and maintenance cover the hardening and monitoring that make a repeat less likely. Contact the recovery track from the contact page, and expect to be asked for a lot of access, that is how the work gets done properly.
While you wait, the first 15 minutes
- Isolate: take the site offline or to a maintenance page so the infection stops spreading and stops serving visitors malware
- Do not keep poking at the site, every touch risks overwriting evidence of the entry point
- Write down everything you noticed: when it started, what changed, any unfamiliar admin users, files, or emails
- Collect and preserve any backup from before the compromise, do not overwrite it with a clean-and-keep working
- Change the hosting panel password and revoke unknown admin users immediately
- Gather access: hosting, FTP/SFTP, database, and a list of what anyone else has touched
- Then bring the evidence and access to the recovery engagement, reconstruction works from what you preserved
These steps make every later fix cheaper. Do them in order, note what you changed, and include the notes in the brief.
What the engagement covers
Scope, stated plainly.
- Investigation: identify the entry point and the full extent of the compromise
- Isolation and a preserved, dated backup of the compromised state
- Cleaning: removal of malware, backdoors, injected files and unknown users
- Patching: closing the vulnerability that let the attacker in
- Hardening: fixing permissions, credentials, and exposed surfaces
- Rescan: verified clean across the codebase, database and file system
- Monitor: a defined watch window for signs of return before handing back
Honest limits
What to do instead.
A one-person senior practice is the right tool for a lot of emergencies and the wrong one for a few. The wrong ones, honestly:
- A guaranteed completion calendar before the site is seen, timelines are scoped after investigation, never invented upfront
- A 24/7 on-call promise, one senior, async-first, first response inside one business day
- Undoing data loss that predates the last good backup, that is a data-recovery problem, not a re-hack problem
- Litigation, law-enforcement reporting or forensic testimony, those need specialists, and the honest answer points you to them
- Host or server-level reinfections that originate at the provider, those run through host support alongside site-level cleanup
After the emergency: stop the next one.
Every rescue ends with the same question, why was this able to happen? The maintenance retainer exists to make the answer boring: updates applied, backups tested, monitoring in place.
Questions
Asked in emergencies.
The honest shape: from first response, a simple single-site infection can be cleaned and hardened within a few days of urgent-priority work; a heavily compromised estate, many plugins, custom code, deeper access, takes longer. Timelines are scoped after investigation, not quoted before, because anyone who promises speed before looking is guessing about the extent.
No, and distrust anyone who promises that. What recovery can do is clean the current compromise, patch the known entry point, harden the surfaces that were open, and set up monitoring to catch the next attempt early. Ongoing prevention is a maintenance and security posture, covered separately and honestly.
Usually during the investigation and cleaning, yes, a compromised site still serving traffic is both a liability to your visitors and contamination while you work. The maintenance page keeps a face up while the real site is treated. As soon as it is clean and verified, it goes back live; the offline window is part of the method, not a failure of it.
A backup from before the suspected compromise, dated before the first sign of trouble, that you preserve untouched. That becomes the reference point for what a clean state looks like and sometimes the fastest route back. Backups from during the infection are not clean; keep those separate and labeled so nobody restores the problem back onto itself.
Other rescue work
WordPress Emergency Support
Your WordPress site is down, broken, or erroring and it cannot wait for the normal queue. Urgent work is slotted ahead of it, with an honest first response and realistic expectations.
Website Takeover, When Your Developer Disappears
Your developer vanished, or the relationship ended badly, and you are locked out of your own website. This rescue recovers access, audits what you actually own, and takes the site back, properly.
WordPress White Screen of Death, Diagnosis and Rescue
The page is blank, the admin may be gone with it, and nothing tells you why. The white screen is almost never mysterious, it is a PHP fatal error hiding in plain sight, and it has a specific, findable cause.
"Error Establishing a Database Connection", Rescue
That single error line means WordPress reached your server but could not open its database, a dead end with roughly four known doors. Finding which door is the whole job, and each has a different fix.
WordPress Emails Not Sending or Landing in Spam
Contact forms that never arrive, order confirmations in the spam folder, password resets that vanish. WordPress mail failure is an infrastructure problem wearing a plugin costume, and the fix lives at the email layer, not in the form.
Locked Out of wp-admin, Every Route Back In
The reset email never comes. The username is not recognized. Or the developer who held the keys has gone quiet. Lockout is the most common access emergency, and nearly every route back in is documented, legitimate, and ends with the keys in your name.