Cleaning a Hacked WordPress Site: The Order I Follow Before Calling It Safe

A site that “suddenly redirects to ads” or triggers a Google warning is already past the point where one security plugin will fix it. WordPress malware hides in fake admin users, theme files, and the uploads folder. Cleaning it needs a sequence, not a guess.

This is the order I follow before I tell a client the site is safe to open again.

1. Isolate first, then hunt files

• turn on maintenance mode, or keep visitors out of the index, if people are being sent to a foreign domain;
• take a copy of files and the database as evidence, and do not restore from that copy;
• write down the symptoms: redirects, spam URLs in Search Console, strange email, or a hosting CPU spike.

The infected copy is for comparison. It is not a clean backup.

2. Rotate every credential from a clean device

Change passwords from a computer that is not using the compromised site:

• WordPress users, especially administrators;
• hosting panel, FTP/SFTP, and the database;
• the email account that receives password resets;
• API keys stored in plugins (SMTP, backup, CDN).

If the old password still works, clean files get reinfected within hours.

3. Audit users and entry points

• delete administrators you do not recognize;
• drop users who do not need the admin role;
• disable plugins and themes that are not in use;
• confirm whether public registration was intentional.

Nulled plugins and pirated themes are the entry path I see most often on school and organization sites.

4. Replace the core from official sources

Do not edit infected files one by one and hope you are done.

• overwrite WordPress core with an official copy of the same version, or a patched release;
• reinstall the theme and plugins from wordpress.org or the licensed vendor;
• compare wp-config.php and .htaccess with a version you understand, and remove lines you did not add;
• inspect wp-content/mu-plugins, uploads, and child themes for PHP files that do not belong there.

Uploads are for media. PHP in that folder is almost always in the wrong place.

5. Restore search trust

After the site is clean and HTTPS is normal:

• request a review in Google Search Console if a security warning is present;
• remove spam URLs from the index when Google has already crawled fake pages;
• update every component, then take a clean backup stored apart from the infected copy;
• turn on file-change monitoring, or at least record file dates after the cleanup.

A security plugin helps after the door is closed. It does not replace replacing core files and credentials.

What I send the client

The site has been cleaned of unknown files and users, credentials were rotated, core and plugins were reinstalled from official sources, and a clean backup is stored separately. Please do not reuse the old hosting or email password.

That sentence is more honest than “I scanned it and it is safe.”