WordPress Malware Removal Step by Step

By Kokil Thapa | Last reviewed: September 2026

A hacked WordPress site rarely announces itself with a polite error page. You notice odd redirects, new admin users, spam pages in Search Console, or a hosting suspension email. WordPress malware removal step by step is not a single plugin click — it is a disciplined sequence of isolation, backup, scan, clean, patch, and verify. I've walked through this on production WordPress sites for Nepal clients and international eCommerce stores. This guide follows the same order I use when a site must go back online without reinfection.

How do you know if a WordPress site is infected with malware?

Symptoms overlap, so treat any combination as suspicious until you prove otherwise. Google Safe Browsing warnings and Search Console "Security Issues" reports are high-confidence signals. Browsers may flag the domain before you notice anything in wp-admin.

Common on-site signs include unexpected admin accounts, unknown plugins in /wp-content/plugins/, base64 blobs inside index.php or wp-config.php, and Japanese keyword spam URLs indexed overnight. I've also seen checkout redirects on WooCommerce florist stores where only mobile Safari users were sent to a phishing page — a pattern that standard visual checks miss.

Quick checks you can run in five minutes

1. Log into wp-admin and open Users → All Users. Remove any administrator you did not create.
2. Compare your plugin list against what you actually installed. Delete anything unfamiliar.
3. View page source on the homepage. Search for eval(, base64_decode, or hidden iframes.
4. Run wp core verify-checksums if WP-CLI is available on the server.
5. Check Google Search Console under Security & Manual Actions.

False positives happen. A poorly coded ad script can look like an injection. Always capture evidence — file paths, line numbers, timestamps — before you delete anything. That log helps if you need ongoing WordPress maintenance or a post-mortem with your host.

What should you do first before removing WordPress malware?

Panicked edits on a live infected site often spread the problem. The first hour sets the recovery trajectory. Isolate, document, and back up — even a compromised backup beats no backup when a cleanup step goes wrong.

Step 0: Isolate the site

Put the site in maintenance mode or block public HTTP at the web server. On Apache, a temporary .htaccess rule denying all except your IP works. On Nginx, restrict the server block. If the host suspended the account, treat that as free isolation — do not rush to restore until files are clean.

Disable WP-Cron temporarily by adding this to wp-config.php:

define( 'DISABLE_WP_CRON', true );

Malware sometimes re-injects itself through scheduled tasks. Stopping cron during cleanup prevents that loop.

Step 0b: Take full backups

Back up the entire document root and a MySQL dump. Use WP-CLI when available:

wp db export /backups/pre-cleanup-$(date +%F).sql
tar -czf /backups/files-pre-cleanup-$(date +%F).tar.gz /var/www/example.com/

Store backups off the production server. I've seen attackers leave backdoors inside /backups/ on shared hosting. If you lack shell access, use your host's snapshot tool plus a plugin export — but verify the plugin itself is not part of the infection.

Step 0c: Record the baseline

• WordPress version, PHP version, active theme, active plugin list
• Recent changes: new plugins, theme edits, FTP users, SSH keys
• Access logs around the first suspicious date (cPanel or server log analysis)
• DNS and domain registrar login activity

This baseline tells you whether the entry point was a nulled plugin, weak FTP password, or outdated WordPress security configuration.

How do you remove WordPress malware step by step?

This is the core workflow. Work on a staging copy when possible. Never run destructive commands on production until you have a rollback path.

Step 1: Replace WordPress core files

Core files are safe to overwrite because they do not hold your content. Download a fresh copy matching your installed version from wordpress.org. WordPress 7.1 is the current line as of 2026; match the exact version running on the site.

With WP-CLI:

wp core download --force --skip-content
wp core verify-checksums

If verify-checksums fails, note every modified core file. Either restore from the fresh download or inspect manually. Do not assume one bad file means the whole core is corrupt — sometimes only wp-includes/load.php was touched.

Step 2: Audit and clean wp-content

Themes and plugins are the usual hiding spots. Delete inactive plugins entirely — not just deactivate. For active plugins, compare against clean copies from the official repository or your licensed vendor.

Search for common malware patterns across wp-content:

grep -rl "eval(base64_decode" wp-content/
grep -rl "gzinflate" wp-content/
grep -rl "str_rot13" wp-content/
find wp-content/uploads -name "*.php" -type f

PHP files inside uploads/ are almost never legitimate. Delete them unless you explicitly uploaded a PHP snippet for debugging — and you shouldn't.

For themes, child themes are safer to inspect than parent themes. If the parent theme was modified directly, reinstall the parent from the source. Keep the child theme's functions.php but read every line — I've found obfuscated loaders appended after a closing PHP tag.

Step 3: Clean the database

Malware persists in wp_options, post content, and user meta. Search the database for suspicious strings:

wp db search "base64_decode" --all-tables
wp db search "eval(" --all-tables
wp db search "<script" --all-tables

Check wp_options rows named siteurl, home, and any cron entries pointing to unknown domains. Spam posts may live as draft or private post types — export a post list and scan titles.

Remove rogue admin users through WP-CLI:

wp user list --role=administrator
wp user delete SUSPICIOUS_ID --reassign=1

Replace ID 1 with your legitimate admin user ID. Never delete the only admin without reassignment.

Step 4: Reset secrets and salts

Assume every credential on the server is burned. Generate new WordPress salts from the official salt generator and paste them into wp-config.php. That forces logout of all sessions.

Rotate in this order:

1. WordPress admin passwords for every user
2. Database password — update MySQL and wp-config.php together
3. FTP/SFTP and SSH keys
4. Hosting control panel and domain registrar passwords
5. API keys for payment gateways, SMTP, and third-party services

Use a generated password from a password generator — sixteen characters minimum, stored in a password manager.

Step 5: Update everything

Outdated software is the most common reinfection vector. After cleaning, update core, all plugins, and the active theme. Test on staging first if the site is complex — WooCommerce 11.1 stores need checkout verification after any plugin change.

wp core update
wp plugin update --all
wp theme update --all

Remove plugins you no longer use. Every installed plugin is an attack surface, active or not.

Step 6: Verify with a second scan

Run at least two independent checks before removing maintenance mode. WP-CLI checksum verification plus a server-side scanner catches most stragglers. Request a Google review through Search Console once you confirm the front-end is clean.

On a legal-tech portal I maintain, reinfection returned within 48 hours because a mu-plugin loader in wp-content/mu-plugins/ was missed on the first pass. Always list that directory — it is easy to forget.

Which WordPress malware removal tools actually work in 2026?

No single tool catches everything. Combine automated scanning with manual grep on critical paths. The table below reflects what I reach for on client sites.

For ongoing monitoring after cleanup, a Web Application Firewall helps. Cloudflare integration blocks many exploit probes before they hit PHP. Pair that with file integrity monitoring — even a daily cron comparing checksums of wp-config.php and root index.php sends early warnings.

If the infection is deeply embedded — rootkit-style loaders, multiple backdoors, or encrypted callbacks — a clean rebuild may cost less than days of forensics. Export posts and media, deploy fresh WordPress 7.1, reinstall vetted plugins, and import content. I've used this approach during website migration projects when the old install was beyond trustworthy repair.

How do you prevent WordPress malware from coming back?

Cleaning without fixing the entry point guarantees a repeat incident. After every recovery, close the hole that let attackers in and add monitoring they cannot easily disable.

Harden wp-config.php

Add these constants if they are not already set:

define( 'DISALLOW_FILE_EDIT', true );
define( 'DISALLOW_FILE_MODS', true );
define( 'FORCE_SSL_ADMIN', true );
define( 'WP_AUTO_UPDATE_CORE', 'minor' );

DISALLOW_FILE_MODS blocks plugin installs from wp-admin — acceptable on managed sites where deployments go through Git. For active development sites, skip that line and rely on role restrictions instead.

Lock down file permissions

On Ubuntu with Apache and PHP-FPM, directories at 755 and files at 644 are the baseline. wp-config.php should be 440 or 400. The web user must not own files it does not need to write — uploads and cache directories only.

find /var/www/example.com -type d -exec chmod 755 {} \;
find /var/www/example.com -type f -exec chmod 644 {} \;
chmod 440 /var/www/example.com/wp-config.php

Automate backups and test restores

Schedule nightly database dumps and weekly full file archives. A backup you have never restored is a guess. Follow a tested restore procedure — the same discipline described in guides on WordPress automated backups with WP-CLI.

Monitor and limit login exposure

• Enable two-factor authentication for every administrator
• Rate-limit wp-login.php at the web server or WAF level
• Rename or restrict login URL only as a minor obscurity layer — it is not real security
• Review Query Monitor and error logs weekly for odd queries

SEO damage outlasts the malware itself. After cleanup, audit indexed URLs in Search Console. Remove spam URLs with 410 responses or disavow only as a last resort. Technical SEO work — covered in our search engine optimization service — often runs parallel to security recovery for business sites that lost rankings.

For Nepal businesses on budget hosting (Rs 3,000–8,000/year, ~USD 22–60), shared IP reputation can cause email and search issues after a neighbour site gets hacked. Moving to an isolated VPS or managed WordPress host after a serious incident is sometimes cheaper than repeated emergency cleanups. See WordPress migration from managed to VPS hosting for the migration path.

Reference the WordPress hardening guide on developer.wordpress.org when documenting your post-incident checklist. OWASP's WordPress security guidance is another solid external baseline for team handoffs.

Key Takeaways

• Isolate and back up before you edit a single file — a compromised backup still beats no rollback path.
• Replace core from a clean source, then manually audit wp-content and the database; scanners alone miss custom obfuscation.
• Rotate every password, salt, and API key; assume all credentials on the server are compromised.
• Run two independent verification scans before restoring public traffic and requesting Google review.
• Fix the entry point — outdated plugins, weak FTP, or nulled themes — or the malware will return within days.
• Automate nightly backups and test restores; pair with WAF rules and file integrity monitoring for long-term protection.

People Also Ask

Can I remove WordPress malware with a plugin alone?

Security plugins help detect known signatures and quarantine suspicious files. They rarely catch custom backdoors, database injections, or mu-plugin loaders without manual follow-up. Treat plugins as one layer in WordPress malware removal step by step — not the entire process.

How long does WordPress malware cleanup take?

A straightforward infection on a small brochure site may take two to four hours with shell access. Large WooCommerce stores with custom code, multiple backdoors, or no staging environment can take one to three days. Rebuild-from-scratch is faster when trust in the existing file tree is gone.

Will Google remove the "This site may be hacked" warning automatically?

Not immediately. After you clean the site, request a review in Google Search Console under Security Issues. Google re-crawls and validates the fix — usually within a few days, sometimes longer if spam URLs remain indexed. Remove or 410 spam paths before requesting review.

Should I pay a ransom or "hack repair" service?

Never pay ransomware demands for WordPress sites — backups and clean rebuilds are the answer. Paid cleanup services can help if you lack technical capacity, but verify they provide a written report of entry point and changes. Cheap "guaranteed clean in one hour" offers often reinstall without fixing root cause.

Recover clean, then stay clean

WordPress malware removal step by step rewards patience over speed. Isolate, back up, replace core, scrub wp-content and the database, rotate every secret, verify twice, then harden. Skip any step and you will likely fight the same infection again next week. On production sites I maintain — from legal portals to WooCommerce stores — that sequence is non-negotiable.

If your site is down now and you need hands-on recovery, WordPress support and maintenance covers emergency cleanup, hardening, and monitoring. For a full rebuild on cleaner infrastructure, explore hosting setup or speed and security optimization. Contact us with your site URL, symptoms, and hosting type — the faster we start at isolation and backup, the faster you get back online.