Most website owners first realise something is wrong when Google flags their site in search results, or when their hosting provider suspends the account citing malicious activity. Sometimes a customer notices suspicious popups. Sometimes a web developer finds unexpected files in the uploads folder during a routine check. In each case, the compromise has usually been present for days or weeks before anyone noticed.

The signs are rarely subtle once you know where to look. Search Console will show a manual action under Security Issues. Your hosting provider may send a warning email citing malware detected in specific files. Your analytics may show a sudden drop in traffic because search engines have deindexed your pages. Or visitors may start reporting that antivirus software is blocking your site entirely.

What many site owners do not realise is that a hacked site is rarely an isolated incident. Once an attacker has code execution on your server, they typically install multiple backdoors, create satellite files across multiple directories, and may have already extracted database contents including user data. The cleanup process is not just about deleting the obvious malicious file. It is about finding every trace of the intrusion and closing the door they used to get in.

What a Compromised Website Actually Looks Like

Website malware takes several forms. Understanding what you are dealing with determines how you approach the cleanup and how quickly you can restore normal operation.

Drive-by downloads are malicious scripts injected into pages that attempt to download malware to visitor browsers. They are typically found in theme or plugin PHP files, or in the database in posts and comments that appear clean to normal visitors but deliver malware when loaded by a search engine bot. This is why checking only what you see in the browser is insufficient. You need to examine what a bot sees, which often differs significantly from what a human visitor sees.

Backdoor files are PHP scripts placed by the attacker to give themselves renewed access even after the original entry point is closed. They are often disguised with innocuous names like wp-user.php, image.php, or footer.php and placed in uploads directories, theme folders, or the wp-admin folder. Some backdoors are highly sophisticated, buried several levels deep in the directory structure or hidden inside legitimate files. A thorough cleanup requires finding and removing every backdoor, not just the entry point file.

SEO spam takes the form of hidden links, hidden content, or doorway pages added to the site to redirect search engine traffic to attacker-controlled sites. It is often invisible to normal visitors but readable by search engines, which is why the first sign of SEO spam is frequently a drop in search rankings rather than anything visible on the site itself. You may also notice new pages appearing in your sitemap that you did not create, or your site's content may have been modified to include links to external sites you do not recognise.

Cryptomining scripts inject JavaScript that runs in visitor browsers, using their CPU resources to mine cryptocurrency. These are increasingly common and can significantly slow down your site for legitimate visitors. They are usually injected into the site footer, header files, or JavaScript files loaded across the site.

Step One: Isolate the Site Before You Touch Anything

The instinct when a site is hacked is to immediately start deleting suspicious files and changing passwords. This is understandable but counterproductive. Jumping straight to cleanup without understanding the scope spreads contamination, leaves hidden backdoors in place, and can break the site in ways that make forensic analysis harder.

Before doing anything else, take the site offline or put it behind a coming-soon page so visitors are not exposed to whatever the attacker planted. Most hosting control panels offer a quick way to do this without terminating the hosting contract. If your host does not offer this, you can add a temporary hold page by renaming the web root's index file and placing a static HTML page in its place.

# Quick method to take a site offline
# Rename the current index file
mv public_html/index.php public_html/index.php.offline

# Create a simple hold page
cat > public_html/index.html << 'EOF'
<!DOCTYPE html>
<html><head><title>Site Under Maintenance</title></head>
<body><h1>This site is currently under maintenance.</h1></body>
</html>
EOF

Make a full backup of the current compromised state before you touch anything. This includes all files, the database, and any log files available from your hosting control panel. Copy this backup somewhere offline, because you may need to refer back to it if something goes wrong during cleanup or if the investigation requires understanding what the attacker changed.

If you have a staging environment or a separate dev URL, clone the site there so you can work without pressure. Every action you take on the live site while it is still serving malicious content to visitors is a liability. Working on a staging copy also gives you the freedom to experiment with cleanup approaches without risking the live site.

If your hosting provider offers a one-click staging feature, now is the time to use it. If not, manually cloning the site to a subdirectory or separate hosting account takes 15 to 30 minutes and is worth the effort before you begin forensic work.

Step Two: Identify the Type and Scope of the Infection

Run a malware scan using a tool like Wordfence, Sucuri, or MalCare to identify infected files. These tools maintain databases of known malware signatures and can often detect patterns that would be difficult to find manually. For WordPress sites specifically, Wordfence and Sucuri offer both free scanning and premium cleanup services.

For non-WordPress sites or for a second opinion, you can also use grep to search for common attack patterns across your file structure. The following command searches recursively through all PHP files for suspicious function calls:

grep -rn "eval\|base64_decode\|system(\|shell_exec(\|passthru(" /var/www/html/*.php 2>/dev/null

Search for PHP functions commonly used in backdoors: eval(base64_decode(, system(, shell_exec(, passthru(, and preg_replace with the /e modifier. Files containing these patterns in unexpected locations, particularly in the uploads directory or in plugin folders you do not remember installing, are strong indicators of compromise.

Check your database for spam content. Attackers frequently insert content into the wp_posts or similar tables, hidden pages, spammy comments with links, or injected script tags. Look for posts with status publish that you did not create, or comments containing <script> tags. The following SQL query can help identify suspicious content in WordPress posts:

SELECT ID, post_title, post_type FROM wp_posts
WHERE post_content LIKE '%<script%'
OR post_content LIKE '%eval%'
OR post_content LIKE '%base64%';

For database management tasks like this, tools like phpMyAdmin can simplify the process of examining and cleaning database content. A secure installation of phpMyAdmin on your server can help you navigate tables and run queries safely when reviewing compromised data. If you prefer command-line access, the MySQL CLI offers more direct control over database operations.

Review your access logs for the period before the compromise was detected. Look for requests to URLs that do not exist in your normal site structure. These are often probe requests from automated attack tools scanning for vulnerable plugins or configurations. Also look for POST requests to admin URLs from IP addresses you do not recognise.

# Find requests to non-existent pages (potential scanning)
grep "404" /var/log/apache2/access.log | head -50

# Find POST requests to admin URLs from unknown IPs
grep "POST /wp-login.php\|POST /admin" /var/log/apache2/access.log

Step Three: Remove the Malware and Close the Entry Point

Delete backdoor files as you find them. Do not just rename them or move them to a zip file. Delete them. Backdoors are designed to survive cleanup attempts and are often planted in multiple locations, so work through the scan results systematically rather than stopping at the first file you find.

Identify and close the entry point. Common entry points are outdated plugins with known vulnerabilities, weak FTP or SSH passwords, insecure file permissions on the uploads directory, or SQL injection in custom PHP code. Checking your PHP site for SQL injection vulnerabilities is a necessary step in any malware cleanup because SQL injection is one of the most common ways sites are initially compromised.

When examining how the attacker gained access, pay particular attention to plugins that have known vulnerabilities listed in the WordPress plugin repository or documented in CVE databases. If you are using shared hosting, the entry point may have been a different site on the same server, which means you should also review your hosting account for any other sites that may be vulnerable.

Update everything. Every plugin, theme, and the core CMS should be updated to the latest version. If a plugin or theme is no longer maintained, remove it entirely and replace it with a maintained alternative. Abandoned plugins are a significant ongoing risk because security vulnerabilities in them are never patched. The same applies to your PHP version. Using an outdated PHP version is itself a vulnerability that attackers actively exploit.

Change all passwords. FTP credentials, database passwords, admin accounts, and any API keys that were stored in configuration files should be changed. If the attacker had filesystem access, they may have read credentials from configuration files. For WordPress sites, this means changing passwords in wp-config.php and updating the corresponding values in the database. For other CMS platforms, locate the equivalent configuration files and rotate any secrets found there.

When changing database passwords, remember to update the configuration file that connects your application to the database. Failing to do this will break your site connectivity immediately after the password change.

Step Four: Restore and Harden

If you have a clean backup from before the compromise date, restoring from it is faster than cleaning. However, restore is not sufficient on its own. The restored site will have the same vulnerabilities that led to the compromise. Apply all hardening steps before bringing the restored site back online.

File permissions are a common root cause of successful attacks. Directories should be 755 and files should be 644. Configuration files like wp-config.php should be 440 or 400. The uploads directory should never be executable. PHP files inside the uploads directory should not be processed by the web server.

# Set correct permissions for directories and files
find /var/www/html -type d -exec chmod 755 {} \;
find /var/www/html -type f -exec chmod 644 {} \;

# Secure configuration files
chmod 440 /var/www/html/wp-config.php

In Apache, you can disable PHP execution in the uploads directory by adding this to an .htaccess file inside the uploads directory:

# Disable PHP execution in uploads directory
<FilesMatch \.php$>
 Order Deny,Allow
 Deny from all
</FilesMatch>

This does not affect legitimate image or document uploads. It prevents an attacker from uploading a PHP file and then executing it, which is one of the most common attack patterns on compromised sites.

PHP security for business websites covers the specific hardening steps that prevent the vulnerabilities attackers most commonly exploit. Worth reading alongside this guide if you manage the server yourself. Beyond file permissions, consider implementing a Web Application Firewall (WAF) to add a layer of protection that blocks common attack patterns before they reach your application. Cloud-based WAFs like Cloudflare or Sucuri can be implemented without modifying server configuration, making them accessible for sites on shared hosting.

Hardening your hosting environment matters as much as hardening the application. If you are on shared hosting, understand that other sites on the same server can potentially affect yours. Consider whether your hosting choice is appropriate for the security requirements of your business. Why WordPress sites on cheap hosting can be a security risk is worth reviewing if you are evaluating whether your current hosting setup provides adequate protection for your business needs.

Step Five: Verify and Monitor

After cleanup, verify the site is clean using the same scanning tools you used during identification. Run multiple scanners if possible, as different tools detect different threat patterns. Submit the site for re-review in Google Search Console. If Google has deindexed pages due to the compromise, requesting a review after you have confirmed the site is clean is required before your search rankings will recover.

Set up monitoring before you consider the job done. File integrity monitoring alerts you when core files are modified. Uptime monitoring tells you when the site goes down. Search Console monitoring tells you when Google detects security issues again. Each of these gives you a chance to catch a reinfection before it becomes a major problem.

  • File integrity monitoring: Tools like Wordfence offer this for WordPress sites. For custom applications, consider tools like AIDE or OSSEC that monitor filesystem changes.
  • Uptime monitoring: Services like UptimeRobot or Pingdom check your site at regular intervals and alert you when it becomes unavailable.
  • Search Console alerts: Enable email notifications in Google Search Console so you receive immediate notice of any new security issues.

Review your backup strategy. Backups taken after a compromise and stored on the same server are themselves compromised. Ensure your backup solution stores backups on a separate system, tests restores regularly, and retains at least one clean backup from before the compromise window. If your current backup system stores backups on the same server as your site, treat this as an urgent security gap and implement off-server backups as part of your recovery plan.

For databases specifically, a proper backup and recovery strategy can mean the difference between a quick restoration and extended downtime. Point-in-time recovery capability allows you to restore to a specific moment before the compromise occurred, rather than accepting the last available backup which may include malware.

Step Six: Ongoing Maintenance to Prevent Recurrence

Cleaning a compromised site once is manageable. Dealing with repeated compromises is costly and damaging to your reputation. Ongoing maintenance is not optional for business websites. It is the difference between a one-time incident and a recurring problem.

Schedule regular updates. Do not wait for security advisories before updating plugins and themes. Set a weekly or bi-weekly reminder to check for and apply updates. For high-risk plugins, consider enabling automatic updates if the plugin supports them safely.

Audit your plugin and theme selection quarterly. Remove anything you are not actively using. Each additional piece of code on your site is a potential attack surface. The fewer plugins you have, the smaller your attack surface. For each remaining plugin, verify that it is actively maintained and has a good security track record.

Monitor your access logs weekly, even when there are no reported issues. Unusual patterns that you catch early are easier to address than successful attacks that you discover later. Look for repeated failed login attempts, requests to admin URLs from unfamiliar IP addresses, and requests to URLs that do not exist on your site.

What Matters Most

Website malware cleanup is not a single action. It is a process that starts with isolation, proceeds through identification and removal, and only ends when the entry point is closed and monitoring is in place. Sites that skip the final monitoring step are frequently reinfected within weeks, and the second compromise is always harder to clean because the attacker has had time to deepen their access and install more sophisticated backdoors.

The most important practical steps are isolating the site before making changes, documenting the compromised state for forensic reference, identifying and closing the entry point (not just removing visible malware), and implementing monitoring that will catch future problems early. Each of these steps has a specific purpose in the overall process and skipping any of them increases the risk of an incomplete cleanup.

If you manage multiple client sites, treat every compromise as a training opportunity. Document what happened, how it was discovered, what the entry point was, and what steps were taken to prevent recurrence. Build those lessons into your standard hardening checklist so the next site under your care is better protected from the start.

If you need help reviewing your current setup or managing the cleanup of a compromised site, prepare a short note with your website URL, hosting details, the current issue as you understand it, and any steps you have already taken. This helps focus the initial discussion on the practical work ahead rather than basic information gathering.