Recovering a hacked WordPress site is not simply uploading an old copy or reinstalling the core. A responsible recovery preserves the information you need, closes the access that may have been used and tests the site before returning it to normal operation.

The exact order depends on the symptoms, hosting setup, WordPress version and available evidence. Use these steps as a map so a temporary restoration does not get mistaken for a complete solution.

1. Define what “recovered” means

Before changing files, list what must work again: public pages, forms, payments, email, users, integrations, the dashboard and scheduled tasks. Also record which symptoms must disappear: redirects, pop-ups, unknown users, browser warnings or content changes.

A visible homepage does not prove that the site is clean. The goal is for the business to operate, access to be trustworthy and the incident to have a reasonable explanation.

2. Preserve the compromised state and choose a recovery point

Save a copy of the affected files and database before restoring anything. Then review available backups with the hosting provider and compare their dates with the last moment when you can confirm that the site was working correctly.

Do not automatically choose the newest copy. If the attacker was already present, that backup may contain the same entry point. If you restore an older copy, document which legitimate content needs to be recovered separately.

3. Close the access that may have been exposed

Change passwords for WordPress, hosting, SFTP or SSH, the database, administrative email and connected services. Remove administrator users you do not recognise and review active sessions. Enable two-factor authentication when possible.

Do this from a trusted device. If the computer used to administer the site has malware or stores an exposed password, recovering the server will not be enough.

4. Replace known components and review custom code

The core, plugins and themes should come from legitimate, compatible sources. The official WordPress guidance for compromised sites recommends reviewing modified files, scanning the environment and understanding the entry point before closing the incident.

Custom components need more care. Do not overwrite them without confirming which code and content the business needs to keep. Review recently modified files, server configuration, scheduled tasks and folders that allow file uploads.

5. Review the database and site behaviour

Look for users, options, posts, scripts or redirects that nobody authorised. Check that the site URL has not been changed, that there is no injected content or hidden links and that visitors are not being sent to another domain.

Test in a private window and from more than one device: homepage, internal pages, forms, payments, email, search, login and every critical integration. Recovery must validate the experience the company actually depends on.

6. Update the site and address the cause

Once the site is in a trusted state, update WordPress, plugins, themes and the supported server version. Remove components that are no longer used and review permissions, backups and access.

If you cannot explain what allowed the access, treat the incident as open even if the site looks normal. The WordPress hardening guide is a useful technical reference for strengthening the environment after recovery.

7. Document the outcome

Keep a short report with symptoms, dates, backups reviewed, users removed, files replaced, credentials changed, tests performed and open risks. If Google or the browser displayed a warning, follow the corresponding review process after confirming that the site is clean.

Request professional WordPress malware cleanup if the site handles sensitive data, was blocked by hosting, contains multiple infections or is compromised again. The first 30 minutes guide helps organise the initial response, while the WordPress disinfection guide covers the cleanup review.