You open your browser, type in your URL, and see a defacement page in Arabic. Or Google Search Console sends you a "Security Issues Detected" email at 2 AM. Or your hosting provider suspends the account with a note about "malware distribution." The first instinct — delete everything and start fresh — is almost always wrong. Deleting everything without understanding how the attacker got in means you'll be hacked again within days. The second bad instinct is restoring from the most recent backup, which may have been taken after the infection.
This guide documents the structured recovery sequence I use for client sites. Done methodically, you can have a compromised WordPress installation cleaned, hardened, and back online within four hours — and with documentation sufficient to get Google's manual review passed.
Step 1 — Take the Site Offline Immediately
Your first priority is stopping the damage from spreading. Every minute the infected site is accessible, it is potentially serving malware to visitors, sending spam from your server, or being crawled by Googlebot — which will expand the list of infected URLs in Search Console and deepen the ranking penalty.
If you can still access wp-admin, activate a maintenance mode plugin and put up a blank holding page. If wp-admin is inaccessible, connect via FTP or your host's file manager and rename index.php to index.php.bak. This breaks the site for all visitors but also stops the malware payload from loading. A cleaner option if you know your own IP address: add a temporary .htaccess rule at the top of the file that denies all traffic except your IP:
Order deny,allow
Deny from all
Allow from YOUR.IP.ADDRESS.HEREThis lets you work on the site while blocking public access and Googlebot. Once you have the site contained, you can work without time pressure.
Step 2 — Identify What Was Compromised
Do not start cleaning before you know what you're cleaning. Skipping this step is how sites get re-infected within 48 hours — because the attacker's entry point is still open.
Start with Google Search Console. Navigate to Security & Manual Actions → Security Issues. The report tells you the malware type (cloaking, harmful downloads, social engineering, unwanted software), and which URLs Google has flagged. This also sets your baseline for the review request later.
Run a Sucuri SiteCheck scan (free at sitecheck.sucuri.net). It identifies the malware family, lists infected files, and checks whether your domain is on any blocklists. This scan works from the outside, so it catches what real visitors actually see.
Then dig into your server logs. Your hosting control panel's error log often shows the PHP errors that indicate which file was exploited. The access log shows the exact request that triggered the initial compromise — look for POST requests to wp-content/uploads/, suspicious requests to rarely-accessed PHP files, or a surge of login attempts followed by admin-area activity from an unfamiliar IP.
Common attack vectors you'll find: a nulled plugin or theme that shipped with a pre-installed backdoor, brute-forced admin credentials (especially if login attempts weren't rate-limited), an outdated plugin with a known CVE (check wpscan.com for the plugin name and version), or a PHP file upload vulnerability in a contact form or gallery plugin.
Step 3 — Change All Credentials Before Touching Files
If the attacker has active access to an admin account or FTP credentials, cleaning files while they watch is pointless. Lock them out first.
Change the WordPress admin password from wp-admin → Users → Profile, or directly in the database if wp-admin is inaccessible. Rotate the database password in wp-config.php and update the same password in your hosting control panel's database manager — both must match. Change your hosting account password, FTP/SFTP credentials, and every email account password associated with the domain.
Then check whether the server has been sending spam. In your hosting control panel, look at mail queue or outgoing mail logs. If there are thousands of queued messages, the server is being used as a spam relay. Contact your host immediately with specifics — most providers (Hostinger, GoDaddy India, BigRock) have a dedicated abuse/security team that will help you halt the spam campaign and document it for their records.
Step 4 — Clean the Infected Files
Download a fresh copy of WordPress core from wordpress.org matching your installed version. Extract it and upload wp-admin/ and wp-includes/ entirely, overwriting existing files. Do not merge selectively — replace the entire directory trees. These two directories should contain only core files; if an attacker planted a backdoor in wp-includes/ms-settings.php or a fake plugin in wp-admin/includes/, the clean overwrite removes it.
Replace every plugin directory with a fresh download from the WordPress plugin repository, or from the premium plugin vendor's official site. Never reinstall a nulled plugin — if a nulled plugin caused this compromise, every nulled plugin in your installation is suspect.
Scan wp-content/uploads/ for PHP files. There should be none — this directory holds images, PDFs, and media, not executable code. Any .php file here is a web shell:
find wp-content/uploads -name "*.php" -type fDelete every result. Then use Wordfence's CLI scanner or Sucuri's scanner to compare your remaining files against known-good checksums. Manually open functions.php in your active theme and look for eval(base64_decode(...)), preg_replace with the /e modifier, or long strings of obfuscated characters — these are injected backdoors.
Step 5 — Clean the Database
File-level cleaning is not enough. Many attacks inject malicious JavaScript directly into post content or store configuration in wp_options that reinstalls the malware on the next page load.
Export the database as a backup before making any changes. Then run this query in phpMyAdmin or via WP-CLI:
SELECT ID, post_title, post_content
FROM wp_posts
WHERE post_content LIKE '%<script%'
ORDER BY ID;Review each result. Legitimate posts may contain embedded scripts (YouTube iframes, analytics snippets), but look for obfuscated base64-encoded scripts, unfamiliar external domains loading JS, or redirects targeting mobile user agents.
Check wp_options for suspicious values: verify that siteurl and home point to your actual domain, not a redirect domain. Check active_plugins for plugins you didn't install. Inspect the wp_users table for admin-level accounts you didn't create — attackers routinely create hidden admin accounts as persistence mechanisms. Delete any unfamiliar accounts.
Run a full-text search across all tables using WP-CLI:
wp db search '<script' --all-tablesThis catches injections in custom tables, WooCommerce order data, and plugin-specific tables that a manual query would miss.
Step 6 — Remove Backdoors
Backdoors are the part of an attack that most amateur cleanups miss. A backdoor is a hidden file or code snippet that lets the attacker return even after you've removed the visible malware. Your site can appear clean for weeks while a backdoor sits dormant, waiting.
Common hiding spots: PHP files in wp-content/uploads/ named to look like image files (e.g., image4892.php), code buried inside inactive theme directories (attackers know most developers never look there), modified files within wp-includes/, and .htaccess redirect rules that serve a different page to Googlebot or mobile visitors than to desktop browsers.
Run Wordfence's scanner with "Scan files outside WordPress installation" enabled. Run MalCare's free scan for a second opinion. After you believe the site is clean, install a fresh WordPress in a subdirectory, then use a diff tool to compare your cleaned site's file tree against the fresh install. Any file that exists in your site but not in the fresh install that isn't a plugin, theme, or upload deserves scrutiny.
Step 7 — Harden the Site Against Recurrence
Update WordPress core, every plugin, and every theme to current versions before bringing the site back online. Then delete every inactive plugin and theme — deactivated code still runs if it contains vulnerabilities that are exploited directly via URL, bypassing WordPress's activation check.
Install Wordfence Free or Solid Security (formerly iThemes Security). Disable XML-RPC unless you specifically need it — it's a brute-force amplification vector. Add this to functions.php:
add_filter( 'xmlrpc_enabled', '__return_false' );Enable login attempt limiting. Add two-factor authentication on every administrator account — Wordfence and Solid Security both include TOTP-based 2FA. Move wp-config.php one directory above your webroot so it's not accessible via HTTP even if directory traversal is somehow achieved.
Set correct file permissions across the installation: directories at 755, files at 644, and wp-config.php at 600. You can set these recursively via SSH:
find . -type d -exec chmod 755 {} \;
find . -type f -exec chmod 644 {} \;
chmod 600 wp-config.phpStep 8 — Request Google Review
Once the site is fully cleaned and hardened, log into Google Search Console, navigate to Security & Manual Actions → Security Issues, and click "Request Review." Write an accurate, specific description: what type of malware was present, which files were infected, what actions you took (file replacement, database cleaning, credential rotation, hardening measures). Vague descriptions like "I cleaned the site" delay the review.
Turnaround varies by malware type. Phishing warnings typically lift within one to three days. Malware warnings take three to seven days. Do not submit the review request until you are certain the site is clean — a failed review because residual malware was detected extends the penalty period and signals to Google's systems that the site owner is not taking the issue seriously.
While waiting for the review, monitor Search Console daily. Watch for new Security Issues entries, which would indicate a re-infection. Set up Sucuri's free website monitoring or Google Search Console's email alerts so you're notified immediately if another issue appears rather than discovering it days later.
Frequently Asked Questions
My host suspended my account because of malware. What do I do?
Most Indian hosting providers — Hostinger, GoDaddy India, BigRock — will restore temporary access if you contact their support team and explain that you are actively remediating the issue. Ask specifically for read-only SFTP access so you can download files for forensic review without risk of the malware executing further. Do not ask them to restore a backup without first verifying when the infection began — if the backup was taken after the site was compromised, restoring it reintroduces the exact problem. Once you have cleaned and hardened the site, submit a detailed support ticket describing what you removed, what vulnerabilities were patched, and what security measures you have added. With specific documentation, most hosts re-enable accounts within 24 to 48 hours.
Should I restore from backup or clean the infected site?
Restore from backup only when two conditions are both true: you have a backup confirmed to predate the infection, and you know the infection's start date with confidence. If either condition is uncertain, cleaning is the safer path. For WooCommerce sites handling orders from Kerala customers, restoring from a week-old backup means losing every order placed since then — a business cost that often makes cleaning unavoidable regardless of backup availability. The restore-versus-clean decision is almost always determined by whether the database contains irreplaceable data, not by which option is easier.
How much does professional WordPress malware removal cost in India?
Freelance WordPress developers in Kerala typically charge ₹3,000 to ₹8,000 for one-time malware removal, with the higher end applying to WooCommerce sites or complex multisite installations. Sucuri's professional cleanup service starts at $199 (approximately ₹16,500) and includes 12 months of their website application firewall — a worthwhile investment for any site generating meaningful revenue. Wordfence Response pricing starts significantly higher, around ₹25,000 per incident. For a small business site in Kerala that isn't processing payments, a qualified local developer's ₹3,000 to ₹5,000 service is appropriate — provided they follow a documented remediation process rather than simply removing flagged files and closing the ticket.