How to Clean a Hacked Website

Save a full copy of the infected site before you change a file. That copy is evidence, and a rollback if a delete breaks a shop. It is not a clean restore point.

Use the host backup tool, or download the site files and a database dump, and store them off the server. Record the date you last saw the site looking normal. File dates are clues, not proof of the intrusion timeline; compare logs, backups and known-good copies.

Keep incident copies in restricted storage, not a publicly downloadable archive. The backup and restore guide helps distinguish application files from the database. For WordPress-specific checks, use the WordPress recovery procedure.

Delete malware only after the infected backup is stored off the server. A scanner catches known signatures. It misses backdoors in the database and in files you edited, so check the places below even when the scan looks quiet.

1. Run the host malware scan, or a security plugin if the admin panel still opens. Write down every path it flags.
2. In WordPress, open wp-content/uploads and review executable files against known-good sources before removing confirmed malicious code. That folder should hold media.
3. Read .htaccess, index.php, wp-config.php, and the active theme header, footer, and functions files. Preserve suspect content and remove only changes confirmed to be malicious.
4. In the database, review and revoke unauthorised administrator access after preserving records, and remove injected links from posts and the options table.
5. Replace wp-admin and wp-includes with a fresh copy of the same WordPress version. Keep your own wp-config.php. Reinstall plugins and themes from the vendor, not from a free copy of a paid zip.
6. On a site that is not WordPress, replace the application core from the vendor and treat recently changed files outside the content folders as suspect.

Test in a private window after each major delete. If the homepage breaks, you know which change did it. A scanner result, name or timestamp needs investigation against trusted files and logs.

Request a security review only after all reported issues have been fixed throughout the website and the fixes have been tested. A clean homepage or a private-window check is not enough to demonstrate that every affected page is safe.

1. In Google Search Console, open the security issue and request a review. Say which files you removed and which passwords you changed.
2. Clear the site cache and any CDN cache before you decide the public URL is clean.
3. Leave the site online and clean while you wait. The review is not instant. If a warning remains or returns, investigate residual infection, reinfection and delayed reputation updates.

Other browsers and security tools keep their own lists. Fix Google first. The same clean homepage is what those other checks need to see.

The Search Console Security Issues documentation says example URLs are only samples. Describe the cause, actions and verified outcome in the review request, and wait for the decision rather than submitting repeated requests.