The Emergency Guide to Website Malware Removal

What to Do When Your WordPress Site Gets Hacked

WordPress incident response is the specialized process of detecting, containing, and recovering from a security breach on your WordPress website. In the world of cybersecurity, an incident is any event that violates an organization’s security policies or standard operating procedures. For a WordPress site owner, this usually manifests as a malware infection, a database injection, or an unauthorized administrative takeover. If your site has been compromised, the speed and structure of your response will determine whether you lose a few hours of traffic or your entire business reputation. Here are the immediate, non-negotiable steps to take:

Block public access – Put your site in maintenance mode or restrict access via .htaccess to prevent further infection of visitors.
Change all passwords – This includes WordPress admin accounts, hosting panel access, SFTP, SSH, and database credentials.
Preserve evidence – Take screenshots and create a full forensic backup of the infected site before you begin the cleanup process.
Scan for malware – Use an external scanner like Sucuri SiteCheck to assess the visible damage and identify malicious redirects.
Contact your host – Your hosting provider may have server-level logs or off-site backups that are critical for identifying the attack vector.
Clean and restore – Remove malicious code, replace core files with fresh versions, and sanitize your database tables.
Harden and monitor – Patch the original vulnerability and set up ongoing monitoring to prevent the “reinfection loop.”

Finding out your WordPress site has been hacked is a gut-punch moment that triggers immediate panic. Your business may be losing sales every minute the site is down, or worse, serving malware to your loyal visitors. Your search engine rankings could be dropping as Google flags your site with a “This site may be hacked” warning, which can take weeks to clear. And somewhere in the background, an automated botnet is likely still probing your server for the next opening.

As former Cisco Chairman John Chambers once famously said, “There are two types of companies: those that have been hacked, and those who don’t know they have been hacked.” That quote hits differently when it’s your site, your data, and your customers on the line. The reality of modern web security is that WordPress, powering over 40% of the internet, is a massive target for automated scripts. These scripts don’t care about your content; they want your server’s processing power to send spam, host phishing pages, or mine cryptocurrency.

The good news? A fast, structured response limits the damage significantly. Most WordPress hacks are not targeted attacks against you personally. They are automated exploits scanning thousands of sites at once, looking for unpatched plugins, weak passwords, or misconfigured servers. That means the same disciplined response plan works in almost every case. By following a professional WordPress incident response framework, you can move from a state of crisis to a state of recovery in a matter of hours.

This guide walks you through every phase of the response lifecycle – from the first moment you suspect something is wrong, all the way through deep-tissue cleanup, recovery, and long-term hardening. I’m Kevin Gallagher, founder of wpONcall, and over more than a decade managing hundreds of WordPress websites, I’ve handled incident response scenarios ranging from simple malware injections to complex backdoor attacks that took days to fully unravel. Everything in this guide comes from real-world experience cleaning up hacked sites and helping business owners get back online fast.

WordPress incident response terms explained:

The 5 Phases of a WordPress Incident Response Plan

When a breach occurs, panic is your worst enemy. To move from chaos to control, we follow a structured lifecycle modeled after the NIST (National Institute of Standards and Technology) guidelines for computer security incident handling. This isn’t just about deleting a few bad files; it’s about ensuring the attacker doesn’t have a “spare key” to get back in ten minutes later. A common mistake site owners make is deleting the malware but leaving the backdoor, leading to a cycle of reinfection that can destroy a site’s SEO permanently.

An effective WordPress incident response plan consists of five distinct, chronological phases:

Triage: This is the “stop the bleeding” phase. We identify the breach, block the attacker’s access, and preserve evidence. During triage, we determine the scope of the incident: Is it just one site, or is the entire server compromised? We also implement immediate containment measures to prevent the malware from spreading to other users or sites on the same hosting account.
Action: Here, we perform deep scans and manual audits to find every trace of malicious code. This involves looking beyond the obvious. We check the database for rogue admin users, audit the wp-content/uploads directory for executable scripts, and examine the theme’s functions.php for hidden backdoors. This is the most labor-intensive part of the process.
Mitigation: We close the vulnerability that allowed the hack in the first place. If the entry point was an outdated plugin, we update or replace it. If it was a compromised password, we implement a site-wide password reset and enforce Two-Factor Authentication (2FA). Without mitigation, the cleanup is temporary.
Recovery: This involves restoring clean files, verifying site integrity, and requesting removal from search engine blocklists. We move the site from a “quarantine” environment back to production, ensuring that all functionality is restored and that the site is no longer flagged as dangerous by browsers or security software.
Lessons Learned: We document the attack vector and update our WordPress disaster recovery plan to ensure it never happens again. This “post-mortem” analysis is vital for long-term security. We ask: How did they get in? Why wasn’t it detected sooner? What tools do we need to prevent this in the future?

Statistics show that attackers typically exploit vulnerabilities massively using automated tools. They don’t care if you’re a small local business in Santa Rosa or a global enterprise; they just want your server resources. For mission-critical sites, a 1-hour response time is the industry gold standard, with full remediation ideally occurring within 24 hours to minimize financial and reputational fallout. The longer a site remains infected, the higher the “dwell time,” which increases the likelihood of being blacklisted by Google.

Why Every Site Owner Needs a WordPress Incident Response Strategy

Relying on “luck” is not a security posture. Without a predefined strategy, you risk permanent data loss and severe SEO impact. When Google flags your site, your organic traffic can drop to zero instantly, and regaining that trust can take months. A proactive strategy provides operational certainty. It ensures that when—not if—an automated botnet finds a hole in your defenses, you have a playbook ready to execute. This involves regular site maintenance, off-site backups, and working with security experts who understand the nuances of the WordPress ecosystem. A well-documented plan reduces the “Time to Recovery” (TTR), which is the most critical metric in incident management.

Immediate Triage: Containing the Breach and Preserving Evidence

The moment you realize your site is compromised, your first priority is containment. You need to prevent the malware from spreading to your visitors and stop the attacker from further modifying your data. This is the “Golden Hour” of WordPress incident response. If you act quickly, you can prevent the search engines from indexing the malicious content, which saves you from the dreaded “This site may be hacked” warning.

Step 0: Block Access. If you can still access your dashboard, use a maintenance mode plugin to show a static page to visitors. If you’re locked out, use your hosting panel or edit your .htaccess file to allow only your specific IP address. This “whitelisting” approach effectively freezes the site for everyone else while you work. A sample .htaccess rule for this would be: order deny,allow deny from all allow from [YOUR_IP_ADDRESS]

Step 1: Preserve Forensics. Before you start deleting files, create a forensic snapshot. This is a read-only copy of the entire site as it exists in its infected state. Why? Because you need to understand how they got in. If you delete the evidence, you might miss the backdoor they left behind. Document everything: take screenshots of defaced pages, note the timestamps of when you first noticed issues, and save any weird error messages. This documentation is vital when fixing broken WordPress sites because it helps identify the timeline of the breach. Check your server’s access.log and error.log files; they often contain the IP address of the attacker and the specific file they exploited.

Critical Password Rotation and Access Control

Once the site is isolated, you must change every single password associated with the account. Do this in a specific order to ensure the attacker doesn’t use one compromised credential to reset another. Hackers often leave “sleeper” accounts in the database, so simply changing your own password isn’t enough. You must audit the entire user list.

Hosting Control Panel: If they have this, they own the server, the email, and the backups.
SFTP/SSH: This is how files are moved. Ensure no unauthorized SSH keys have been added to the authorized_keys file.
Database Credentials: Found in your wp-config.php. After changing the password in the hosting panel, you must update the file.
WordPress Admin Users: Check the Users list for any rogue accounts. Delete any account you didn’t create, especially those with Administrator privileges.

Use a password manager like 1Password or LastPass to generate complex, unique strings of at least 16 characters. To truly kick the attacker out, you must also terminate all active sessions. The easiest way to do this is by regenerating your secret keys (salts) using the WordPress key generator and pasting them into your wp-config.php file. This forces everyone—including the hacker—to log in again. This is a key step in preventing future WordPress hacks.

When to Contact Your Hosting Provider

Your host is your partner in this. If your account has been suspended, they likely detected malicious traffic or resource spikes. Reach out and ask for:

Server Logs: These can show exactly which file was accessed and from which IP. Look for POST requests to unusual PHP files.
IP Allowlisting: If they’ve blocked your site, ask them to allow your IP so you can perform the cleanup.
Backup Availability: They might have a clean version of your site from 48 hours ago. Ask for the retention policy of their backups.
Server-Side Scanning: Many hosts offer tools like ClamAV that can find malware signatures that frontend scanners miss. Reviewing WordPress error logs can also reveal the “chatter” of a failing script or a malicious injection. If you are on a shared hosting environment, ask if other sites on the server have been affected, as cross-site contamination is a common issue.

Forensic Analysis and Malware Eradication Strategies

Now we go hunting. Malware in WordPress often hides in plain sight, using names that look like core files (e.g., wp-log-php instead of wp-login.php). Common “Indicators of Compromise” (IoC) include site defacement (the obvious “Hacked by…” message), sneaky redirects to suspicious domains, pharma hacks (where your site suddenly sells discount medications in search results), and SEO spam that injects thousands of junk links into your footers or hidden div tags.

Start with a frontend scan using Sucuri SiteCheck. It’s a great way to see what the public (and Google) sees. Next, check your URL against VirusTotal to see which blocklist authorities have already flagged you. For the backend, if your host allows it, run a ClamAV Server-Side Scanner to check the actual file contents against known malware signatures. You can see more about what a hacked WordPress site looks like to help identify these symptoms. Remember that some malware is “environment-aware” and will only show itself to mobile users or search engine bots, making it invisible to you in a standard desktop browser.

Manual File Auditing and Integrity Monitoring

Automated scanners are good, but they aren’t perfect. Skilled hackers write code specifically designed to bypass them using obfuscation techniques like Base64 encoding or string reversal. You must manually audit critical files for suspicious functions like eval(), base64_decode(), gzinflate(), or str_rot13(). While these functions have legitimate uses, they are the hallmarks of obfuscated malware when found in core files.

wp-config.php: Look for extra code at the very top, before the <?php tag. This is a common place for hackers to include a global backdoor.
index.php: This is a favorite spot for redirects. Check both the root index.php and the one in your theme folder.
functions.php: Hackers often hide backdoors here because it loads on every page. Look for code that creates new users or sends emails.
.htaccess: Check for rules that redirect mobile users or search engine bots. Hackers use this to steal your traffic without you noticing.

A pro tip is to use the WP-CLI verify-checksums command. This compares your core WordPress files against the official versions in the repository. If a file has even one extra character, this tool will flag it. This is an essential part of debugging in WordPress. If the checksums don’t match, you know exactly which files have been tampered with.

Auditing Plugins and Themes for Backdoors

Most hacks enter through a vulnerable plugin or theme. If you’ve used “nulled” (pirated) plugins, there is a 99% chance they contain a backdoor. Even legitimate plugins can be exploited if they aren’t updated. During your audit, delete any plugin or theme you aren’t actively using. For the ones you keep, don’t just “update” them—delete the folder entirely via SFTP and reinstall a fresh copy from the official WordPress.org repository or the developer’s site.

Check your /wp-content/uploads/ directory; there should never be a .php file in there. This directory is meant for media files like JPEGs and PNGs. If you find a PHP file here, it’s almost certainly a web shell that allows the attacker to execute commands on your server. A thorough WordPress security audit is the only way to be sure you’ve cleared the path and identified the original entry point.

Database Sanitization and Core File Restoration

The database is often overlooked during a cleanup, but it’s where “Pharma hacks” and rogue admin users live. If you clean the files but leave the database infected, the site will remain compromised. Hackers often use the wp_options table to store malicious scripts that execute every time a page loads, or they use the wp_posts table to inject thousands of spam links that are hidden from regular users but visible to search engine crawlers.

Use a tool like Adminer or phpMyAdmin to run SQL queries. You are looking for:

Rogue Admins: Run SELECT * FROM wp_users; to see if there are any accounts you don’t recognize. Pay close attention to the user_registered date.
Spam Content: Search the wp_posts table for keywords related to the hack (e.g., “viagra”, “casino”, “luxury watches”).
Malicious Options: Check wp_options for large, serialized strings that don’t belong to your known plugins. Look for options like default_role being changed to administrator.

Feature	Manual Cleaning	Full Restoration
Precision	High – keeps all recent data	Low – loses data since last backup
Speed	Slow – requires deep auditing	Fast – overwrites everything
Risk	High – might miss a hidden backdoor	Low – if the backup is truly clean
Best For	Sites with high-frequency content	Sites that haven’t changed recently

Cleaning the database is a core part of our WordPress malware removal process. If you find malicious code in the database, you must be careful when deleting it, as serialized data can break your site if edited incorrectly.

Safe Core File Replacement and Verification

The safest way to ensure your core files are clean is to replace them entirely. This is a standard procedure in WordPress incident response because it removes any doubt about file integrity.

Download a fresh copy of WordPress from WordPress.org.
Delete your /wp-admin/ and /wp-includes/ directories entirely. Do not just overwrite them.
Upload the fresh versions from your download.
Replace all files in the root directory except wp-config.php and .htaccess (which you should have already audited).

This ensures that any “zombie” code hidden in the core files is wiped out. Always perform this in a staging environment first to ensure nothing breaks before you restore your website from backup to production. Once the core is clean, repeat the process for your plugins and themes.

SEO Recovery and Blocklist Removal

Once the site is clean, you have to tell the world. If you were blacklisted, your search traffic won’t return until you request a review. Log into Google Search Console and Bing Webmaster Tools. Check the “Security Issues” tab. Once you’ve verified the site is clean, click the “Request Review” button. Be honest: tell them what happened, the vulnerability you found, and the specific steps you took to fix it. This is the final step in a complete WordPress site recovery. If you were dealing with a WordPress redirect hack, ensure those redirects are completely gone by testing your site from different IP addresses and devices before requesting the review.

When to Hire Professional WordPress Incident Response Services

There are times when DIY isn’t enough. If you find yourself in a “reinfection loop”—where you clean the site and it’s hacked again 24 hours later—you have a hidden backdoor or a server-level vulnerability that requires professional tools. Professional WordPress malware removal services are essential when:

The site handles sensitive customer data, PII, or credit cards.
The hack is complex (e.g., cross-site contamination on a shared server).
You simply don’t have the 10-20 hours required for a deep forensic audit.
You need a guaranteed 1-hour response and 24-hour resolution to keep your business running. Experts have access to proprietary databases of malware signatures that aren’t available to the public.

Conclusion

Recovering from a hack is a marathon, not a sprint. Once the immediate fire is out, you need a 30/60/90-day hardening plan to ensure it never happens again. Security is a process, not a product. The goal of WordPress incident response is not just to fix the current problem, but to build a more resilient infrastructure for the future. This includes:

Immediate: Enable Two-Factor Authentication (2FA) for all users and implement a Web Application Firewall (WAF).
30 Days: Disable XML-RPC if you don’t use the mobile app, and implement login protection to throttle brute-force attacks. Audit all user permissions.
60 Days: Set up file integrity monitoring and verify your WordPress backup services are running daily and stored offsite in a secure cloud environment.
90 Days: Conduct a full security review of all third-party integrations, API keys, and connected services. Ensure your hosting environment is running the latest version of PHP.

At wpOncall, we specialize in this exact type of proactive maintenance and emergency response. We don’t just clean the mess; we tighten the ship so the “hacker-pirates” move on to an easier target. Based right here in Santa Rosa, CA, we understand that for a local business, your website is your digital storefront. Don’t leave it unlocked. A single breach can cost thousands in lost revenue and recovery fees, making proactive security the most cost-effective investment you can make.

Frequently Asked Questions about WordPress Incident Response

How do I know if my WordPress site has been hacked?

Common signs include unexpected redirects to other sites, new administrator users you didn’t create, strange pop-ups or “pharma” ads, and warnings from Google or your hosting provider. Sometimes, the only sign is a sudden, unexplained drop in site performance or search rankings. You might also notice your server’s CPU usage spiking as it’s used for malicious tasks.

Can I clean a hacked WordPress site myself?

Yes, if you have technical experience with SFTP, SQL, and the WordPress file structure. However, hackers are experts at hiding backdoors in obscure locations. If you miss just one line of code, the attacker can regain access instantly. For business-critical sites, professional help is usually the safer and faster route.

How long does it take to recover from a WordPress hack?

A basic cleanup can take 2 to 4 hours, but a full forensic recovery—including database sanitization, file integrity verification, and blocklist removal—typically takes 24 to 48 hours. The speed of recovery depends heavily on whether you have a recent, clean backup available and how quickly you detected the breach.

Will my SEO recover after a hack?

Yes, but it takes time. Once you’ve cleaned the site and Google has processed your “Request Review,” the warnings will be removed. However, if the hack resulted in thousands of spam pages being indexed, it may take several weeks for those to drop out of the search results. Consistent, clean content and a secure site will eventually restore your rankings.

What is the most common way WordPress sites get hacked?

Over 90% of WordPress hacks are due to vulnerabilities in plugins and themes, followed by weak passwords and insecure hosting environments. Using outdated software is the equivalent of leaving your front door wide open. Regular updates and a strong firewall are your best lines of defense.

Learn more about WordPress site security and how to stay protected.