How to fix a hacked
WordPress website

1. Record the symptoms and speak to your host

Write down the redirects, warnings, unfamiliar pages or account changes you have noticed, along with when they started. Keep relevant screenshots and messages from your host.

Ask your host about the affected account, available backups and safe access for recovery. If visitors are being exposed to malicious content, discuss restricting public access while you investigate.

• Note whether redirects affect everyone or only visitors arriving from Google.
• Ask your host to retain malware reports and access logs before they are rotated or deleted.

What to ask your host

2. Back up the database before making changes

Export the database before making changes and keep it outside the public website directory. A file download alone does not include the database. Label this export as the current affected copy, rather than a clean recovery point.

If the site takes orders, memberships or bookings, note when the export was taken and how you will retain later transactions. Restoring an older database can remove changes made after its backup date; do a test restoration in isolation before changing the live store.

Find the database name in your protected copy of wp-config.php, then open that database in your host’s database tool. In phpMyAdmin, use Export, choose SQL and include all the site’s tables. Save the export privately and check that it contains data. Do not use Import or replace live tables as part of making this backup. Follow the WordPress backup guidance if your host’s controls differ.

3. Preserve configuration details

Save a protected copy of wp-config.php and record the database connection details, table prefix and hosting configuration you will need during recovery. Treat this file as sensitive because it contains credentials.

Review the file for unfamiliar additions. Copying the compromised configuration straight into a rebuilt site can carry the problem across.

Record the current WordPress version and the active theme and plugins too. These details help you obtain matching trusted packages and understand compatibility problems during recovery.

4. Keep a secure copy of the website files

Back up the affected files before replacing or deleting anything. Include hidden configuration files where available, and ask your host to preserve useful logs.

Store the infected copy outside the public web root with restricted access. Do not leave a downloadable archive on the live website or use an archive to bypass your host’s security controls.

Keep the current infected snapshot separate from any backup you believe is clean. Label each copy with its date and purpose so it cannot be mistaken for a recovery point.

5. Choose a recovery approach

There are three common routes. Choose the one that fits your backups and hosting access before you start replacing files.

A backup from before the compromise: restore it to an isolated environment, inspect it and close the weakness that allowed the hack before it replaces the live site. The date alone does not establish that the backup is clean.

No trustworthy clean backup: rebuild with trusted WordPress, theme and plugin packages, then review the database, configuration and uploads you need to keep. Hosting account also affected: work with the host on the account and other installations before putting the repaired site back there.

6. Prepare a protected recovery environment

Use a separate recovery folder or staging environment with public access restricted. Confirm both its document root and database name before making changes. Ask the host to help set this up if you are uncertain which installation a control-panel action will affect.

Avoid renaming the live public_html directory without understanding the hosting setup. A separate environment lets you check the recovery before switching visitors to it.

Stop the recovery copy from sending customer emails or taking live payments. Before switching back, decide how orders, form entries or other changes received during the work will be reconciled.

7. Replace WordPress files from a trusted source

Download a fresh package from WordPress.org. Record the existing version first and plan compatibility with the theme, plugins and PHP version. Work on the recovery copy, then update and test before reopening.

Replace the WordPress core directories and files from the trusted package rather than assuming an overwrite removes everything. Keep the backed-up wp-content and configuration separate for review; they contain site-specific data and may also contain the infection. Check unexpected root files as well.

If you have WP-CLI access, the read-only command wp core verify-checksums compares core files with WordPress.org’s checksums. A successful result checks core integrity; it does not establish that the database, plugins, uploads or hosting are clean. See the official checksum command reference.

8. Review the configuration and database

Check configuration, administrator accounts and database content for unauthorised changes. The database can retain injected scripts, spam content or unwanted settings even after files are replaced.

Preserve legitimate site settings and content. If you cannot distinguish the infection from required data, get help before making bulk database changes.

Review unfamiliar administrators, injected content, unexpected site settings and redirect rules such as those in .htaccess. Compare suspicious files with a trusted copy where possible. A search for one term such as base64_decode is an investigation aid, not proof of malware: legitimate code can use the same functions.

9. Reinstall the theme from its original supplier

Install a trusted copy of the theme from WordPress.org or the original developer. Review child themes and custom changes separately so that legitimate customisations are retained without copying infected code.

If the theme is unsupported or cannot be updated safely, plan a replacement rather than relying on an old vulnerable copy.

Keep a record of legitimate customisations before replacing theme files. Custom templates and child-theme functions may need a careful manual review instead of a straight copy.

10. Review uploads before restoring media

Inspect uploads before transferring media to the recovery environment. Do not assume everything in the uploads directory is a safe image.

Investigate unexpected executable files and unfamiliar folders, while checking whether legitimate plugins require particular assets. Scan and review the files you retain.

For example, an unexpected PHP script among uploaded photographs deserves investigation. A filename or extension alone is not enough to decide whether a file is safe or required.

11. Reinstall and review plugins

Download replacement plugins from WordPress.org or their original suppliers. Avoid copying the old plugin directories into the rebuilt installation.

Review what is still needed, remove unused software and address known vulnerabilities. Test updates and confirm that forms, checkout and other essential features still work.

If you use WP-CLI in a trusted recovery environment, wp plugin verify-checksums --all compares supported plugins with WordPress.org packages. A warning about missing checksums is not proof of infection; premium, custom or unavailable versions may need comparison with the supplier’s package. Read the command’s scope and options.

Using a scanner during the review

12. Secure access and address the cause

Review WordPress administrators and remove access that is not authorised. Reset affected WordPress, hosting, SFTP and database credentials from a trusted device, updating the application configuration when a database password changes. Renew WordPress authentication keys to invalidate existing login cookies.

Address the route the attacker used: vulnerable software, stolen access or an affected hosting account. Check old or abandoned WordPress installations in the same account too. Keep an explanation of what was found and fixed; a firewall alone does not close every route. See the WordPress hardening guidance.

After cleanup, change exposed passwords again if they could have been captured during the work. Confirm that backups can be restored, updates have an owner and someone will review new security alerts.

13. Test recovery and watch for recurrence

Reopen only after you have reviewed the affected files and database, addressed the likely entry point, secured access and tested the recovery copy. Record any remaining uncertainties so they are not mistaken for completed checks.

Test with a logged-out browser and a mobile device, including the URLs that originally redirected or showed warnings. Compare the result after clearing the relevant caches; a cached page can otherwise hide a change.

Keep the original affected backup and a separate post-cleanup backup, with restricted access. Save the scan results, changes made and follow-up checks. If suspicious files or redirects return, investigate the cause rather than repeating the same deletion.

• Affected URLs, important landing pages and a visit from a search result behave as expected.
• A fresh scan and file review show no unresolved findings that you cannot explain.
• Contact forms, login and any checkout or booking flow pass an appropriate test.
• Access is secured, the likely entry point is addressed and a post-cleanup backup is available.