How to Recover a Hacked WordPress Site Safely

The instinct after discovering a hack is to delete the suspicious files and move on, and that instinct is the reason many sites get compromised twice. Removing the visible symptom destroys evidence about how the attacker got in and what else they left behind. Recovery has a useful order: contain the damage, preserve what can be investigated, find the entry point, remove the access, and only then clean and reopen the site to the public.

Stabilization comes first. Put the site into maintenance mode or take it offline if user data or payments are exposed, notify the hosting provider so their logs are preserved, and snapshot the compromised state before changing anything. Web server access logs, authentication logs, and file timelines are the raw material for understanding the intrusion. Many hosts rotate logs quickly, so capturing them early matters as much as any cleanup step that follows. Note the time the problem was first noticed and how it surfaced; that timeline becomes the backbone of the review later.

Scoping the compromise goes beyond the WordPress installation. New administrator users, unexpected scheduled tasks, modified theme or plugin files, injected scripts in uploads, altered configuration files, and unexpected outbound connections are all signs to check. Attackers often leave multiple footholds, including webshells in less obvious directories and changes in the database such as injected options or posts. The server itself deserves a review for suspicious processes or cron entries, not just the content management layer.

The recovery path depends on how much you trust the backups. Restoring a verified clean backup and then patching the vulnerability is usually the fastest route, provided the backup predates the intrusion and its own integrity has been confirmed. If backups are infected, incomplete, or nonexistent, a clean rebuild — fresh core files from official sources, reinstalled plugins and themes, recreated users, imported content after review — is more work but far more trustworthy. The decision should be made deliberately rather than by default.

Credentials need a full rotation, not a partial one. That includes hosting panel access, FTP and SSH accounts, the database user, every WordPress administrator, and any API keys stored in the configuration. Replacing the authentication salts in the configuration file invalidates existing sessions and forces everyone to log in again. Unknown users should be removed, roles reviewed for least privilege, and any integration credentials that touched the site should be revoked and reissued, since they may have been read during the intrusion.

Cleaning means comparing files against trusted sources. WordPress core ships checksums that make it possible to spot modified or unexpected files, while plugins and themes are safest reinstalled fresh from official repositories. Uploads and configuration directories need manual review for injected code. Server-level artifacts — additional access rules, scheduled tasks, mail forwarding, and unexpected processes — belong on the same list, because a clean WordPress installation on a compromised server is not actually clean.

Know when to bring in help. A compromised site that processes payments, stores customer records, or shares a server with other businesses raises the stakes beyond a solo cleanup, and hosting providers, incident responders, and legal counsel each have a role if data was exposed. A structured recovery includes evidence handling and verification steps that are easy to skip under pressure. The cost of that structure is usually smaller than the cost of a second breach, which is the most common outcome of a rushed cleanup.

Hardening should be treated as part of the recovery, not a later project. Updates for core, plugins, and themes remove known vulnerabilities; two-factor authentication and login limiting raise the cost of credential attacks; disabling the built-in file editor and tightening file permissions narrows the ways an attacker can persist. A web application firewall and a scheduled scanner add detection. Offsite backups with a tested restore path are what convert the next incident from a catastrophe into an inconvenience.

There is an aftermath beyond the code. Search engines may have flagged the site or indexed spam pages, so a security review request and a monitoring period for reinfection are worth planning. If customer data was exposed, notification obligations and legal review may apply, and the sooner those conversations start the better. Communicating honestly with users about what happened and what you changed protects reputation more than silence does.

The final step is a short incident review. Write down the likely entry point, how it was discovered, what the recovery actually cost, and which hardening measure would have stopped it. Most reinfections trace back to a skipped step rather than a novel attack: a forgotten admin account, an unpatched plugin, a backup that was never tested. Treating the review as part of the fix is what keeps the site from repeating the experience. If the site had no maintenance routine before, the review is also the moment to put one in place: recovery ends the incident, and prevention is what keeps it closed.