Find it · Clean it · Verify it
Website malware removal is the work of finding every malicious file, script and database entry on an infected site, cleaning it out and closing the hole the attacker used. ScanTitan finds the infection and rescans afterwards to show it is gone, while you, your host or a security professional do the cleaning. This guide covers the signs of infection, a five step cleanup for WordPress, Joomla and Drupal, and how to clear Google Safe Browsing and other blocklist warnings.
Free 45-second quick check, no account. See pricing
Illustrative animation with reserved example.test names. Not a real scan.
Reviewed by Obaida Al-Sulaiman, Information Security Manager. OSCP, CISSP, 12 years in web application security.
Website malware removal has four jobs: find every infected place, remove the malicious code, close the entry point and prove the site is clean. Deleting the one file a scanner flags rarely finishes the job. An attacker who gets in through a vulnerable plugin usually leaves a second way back, such as a PHP web shell in wp-content/uploads, a rogue administrator account or a scheduled task that downloads the malware again. ScanTitan covers the finding and the proving. You, your host or a security professional cover the removing. The cards below show who does what, so you can line up help before you start.
Who does what in a malware cleanup
Scan the site and list what looks malicious
Report the URL, script or file path when known
Run PHP malware and webshell and backdoor detection
Same scan, different CMS
Confirm that what you fixed is gone
Repeat scans and alerts on Free, Professional and Business
From a clean backup or fresh copies of core, plugins and themes
Remove injected users, options and spam content
Admin, hosting, SFTP and database
Plugins, themes, CMS and PHP version
Search Console, Security issues, Request review
Most owners learn about an infection from a customer, not a dashboard. Google Search Console may show a Security issues warning, Chrome may show Deceptive site ahead, or your host may suspend the account for sending spam. Quieter infections show nothing at all: a web shell sleeping in wp-content/uploads, or a redirect that fires only on a first mobile visit from Google. Tick the signs you have seen. One sign is enough reason to scan before you change anything, because the infected copy is your evidence of what the attacker touched. Note the date each sign first appeared, because that date tells you which backup is safe to restore. Read the full list of signs.
Each type of infection hides in a different place, so each one needs a different check during website malware removal. A web shell hides in a file, SEO spam hides in the database and in cloaked pages, and a redirect hides in .htaccess or in one injected script. Knowing the type tells you where to look first and how to tell that the cleanup worked. Filter by where the infection lives. For the full catalogue, read our guide to 15 types of malware, Write down which type you found first, because it decides the order of the cleanup. For the tell tale code patterns see obfuscated PHP malware.
A hidden PHP file such as c99, WSO or b374k gives the attacker remote control and survives password changes. This is the type that makes malware come back. How to find a backdoor.
Injected pages sell pills or fake brands, often cloaked so only Google sees them. Pharma hack, Japanese keyword hack and cloaking.
Rules in .htaccess or injected JavaScript send some visitors to another site, often only on a first visit, on mobile or from a search result. Redirect malware and .htaccess malware.
Obfuscated code such as eval(atob()) loads a script or a hidden frame from another domain, the usual drive by download route. Obfuscated code.
A fake login or payment page sits in a subfolder of a legitimate site, which gets the domain flagged. Flagged as phishing.
A script prompts visitors to download a file that looks like an update or an invoice.
Magecart style scripts copy payment data on checkout pages. ScanTitan does not offer dedicated skimmer detection, so stores that take cards should also ask their payment provider about script monitoring. Magecart attacks.
Follow the five steps in order. Skipping the backup risks your content, skipping the entry point invites reinfection, and skipping the rescan leaves you guessing. Each step says who does the work. The commands assume SSH access and WP-CLI on a WordPress site; on shared hosting without SSH, use the cPanel file manager and phpMyAdmin instead. Work in maintenance mode or on a staging copy, and write down every file you change so you can undo it. Stop and ask for help at any step where you are unsure, because a wrong deletion is harder to undo than a wrong guess. Our guide on what to do when your website is hacked covers the first hour in more detail.
Take a full backup of the infected site, files and database, and keep it offline and untouched. It is your evidence. Then limit the damage: put the site in maintenance mode if it redirects visitors or serves spam, and change the hosting, SFTP and database passwords from a computer you trust. Do not delete anything yet, and do not reinstall WordPress over the top, because that erases the traces that show how the attacker got in. If the site holds personal data, write down when you found the infection: GDPR Article 33 gives you 72 hours to notify the supervisory authority of a personal data breach.
Run a ScanTitan malware scan and save the report. It lists what looks malicious and, when known, the URL, script or file path. Then check what a scan cannot tell you. List PHP files changed in the last 30 days, search for obfuscation, and look for PHP files in wp-content/uploads, where none should exist. Compare WordPress core and plugins with the official copies using WP-CLI. Open the Users screen and look for administrators you did not create. A scan finding is an indicator to investigate, not proof, so check each one before you delete it, because a legitimate ad or analytics script can look suspicious and produce a false positive. Write down every path you find, with the date, in one note, and treat any file you cannot explain as suspect until a clean copy replaces it.
find . -type f -name "*.php" -mtime -30 grep -rE "eval\(base64_decode|gzinflate\(|str_rot13" wp-content find wp-content/uploads -name "*.php" wp core verify-checksums wp plugin verify-checksums --all wp user list --role=administrator
A backup from before the infection is faster and safer than hand editing, but only if you know the date it started and you still close the entry point afterwards. Otherwise replace instead of repair: reinstall WordPress core, and every plugin and theme, from the official source, because a file you replace cannot hide a leftover payload. Delete files you do not recognise, especially PHP in wp-content/uploads and unknown files in wp-content/mu-plugins. Reset .htaccess to the default rules, then clean the database: rogue administrators, injected script or iframe tags in wp_posts, and changed siteurl and home values in wp_options.
Run the ScanTitan scan again on the same address. A clean result means the checks that ran found nothing, not that the site is guaranteed safe, so test like a visitor too: open the site on a phone, from a Google result and in a private window, because many infections only fire on a first visit or a search referral. Check the server access logs for requests to files you removed; repeated hits mean the attacker still expects a backdoor to answer. Keep the first report next to the new one. A repeat finding means something still writes the malware back.
Find how the attacker got in, or they will use it again. The usual routes are a vulnerable or nulled plugin, a stolen password and a compromised hosting account. Update WordPress core, plugins and themes, remove what you do not use, replace the WordPress secret keys and salts so old login cookies stop working, and turn on two factor sign in. Run a PHP vulnerability scan or a WordPress vulnerability scan to find the weakness behind the infection. If Chrome or Search Console showed a warning, request the Google review only after the rescan is clean.
WordPress powers most of the infected sites that reach a cleanup, because its plugin and theme ecosystem is large and slow to update. The same six places hold the malware in most cases. Work through them in this order and write down what you find in each, so the rescan has something to compare against. Replace files with official copies wherever you can instead of editing them by hand, since an edited file can still hide a second line you missed. Keep the backup from step one beside you while you work. If your site runs Joomla or Drupal, the last block covers the equivalent files. For a database focused walkthrough, see database malware in WordPress.
Attackers edit wp-config.php, index.php, wp-load.php and files inside wp-includes, and they rely on you not comparing them with the original. Run wp core verify-checksums and treat every mismatch as suspect. The safe fix is to download the same WordPress version from wordpress.org and replace the core folders, keeping only wp-config.php and wp-content. Then open wp-config.php by hand and remove anything after the closing database lines that you did not write, such as an include of a strange file or a long encoded string. Never copy core files from a nulled or third party source.
A vulnerable plugin is the most common way in, and an abandoned one is worse because nobody patches it. Reinstall every plugin and theme you keep from its official source, and delete every inactive one. Check wp-content/mu-plugins too: must use plugins load on every request without appearing in the normal Plugins list, so attackers like it. Pirated copies of paid plugins often ship with a backdoor on day one, so replace them with licensed versions. Keep a short list of what you deleted, so you can reinstall a legitimate copy later. Read mu-plugin malware and nulled plugins for examples.
No PHP file belongs in wp-content/uploads, because it should only hold images, documents and media. Run find wp-content/uploads -name "*.php" and delete what you find after you saved a copy for evidence. Then stop it happening again by blocking PHP execution in that folder with a server rule from your host. Watch for files with double extensions such as image.php.jpg and for folders with random names, since attackers use both to hide web shells and phishing pages from a casual look. A clean uploads folder lists only media and cache folders you recognise.
The .htaccess file in the web root and in subfolders is a favourite place for redirects that fire only on mobile or only from Google. Replace it with the default WordPress rules, then check for .user.ini and php.ini files that set auto_prepend_file, which makes the server run an attacker script before every page. Also look for extra .htaccess files in wp-content and wp-includes. Compare against the default WordPress rules from the WordPress documentation, and delete any rule you cannot explain. Check file modification dates, because a changed date on a file nobody edited is a strong hint. See .htaccess malware for the patterns.
Malware often lives where file scans never look. In phpMyAdmin or with WP-CLI, sort wp_users by registration date and delete administrators you did not create, then check wp_usermeta for unexpected capabilities. Search wp_posts for script and iframe tags, and check wp_options for changed siteurl, home and active_plugins values. List scheduled tasks with wp cron event list: a cron event that fetches a remote file is how malware reinstalls itself. Export the tables before you delete a row, so you can restore a wrongly removed entry, and change the database password when you finish. See hidden admin users.
The logic is the same with different files. On Joomla, check configuration.php, the template index.php files, the administrator accounts and every extension against its official download. On Drupal, check settings.php, the sites/default/files folder for PHP files, user accounts with the administrator role and every contributed module against the Drupal security advisories. Replace modified files from the official release, and delete user accounts you cannot match to a person, then change the administrator passwords. ScanTitan scans Joomla and Drupal sites the same way as WordPress, and the website malware scan page explains what each report shows.
A clean site does not clear a browser warning by itself, because Google and the other blocklist authorities have to re-check it. Request the review only after your rescan is clean. A review sent while the malware is still there is rejected and slows the next attempt. ScanTitan does not send these requests for you, so the steps below are yours to follow. Google may ask for a short description of the fix, so keep your notes from the cleanup and the dates of each step. Our guide on how to check if your website is blacklisted shows how to check all three kinds of listing.
Google shows the problem in two places. Chrome shows a red Deceptive site ahead or The site ahead contains malware page, which comes from Safe Browsing. Search Console lists the cause under Security issues, for example malware, hacked content injection or URL injection. To clear it, confirm the rescan is clean, open Search Console for the property, go to Security issues, check that every listed problem is fixed, choose Request review and describe what you removed and how you closed the entry point. Google answers in Search Console. A manual action is different: a human reviewer flagged spam, and you clear it from the Manual actions report. Do not request again until it answers, since repeated requests do not speed it up.
Every security vendor keeps its own database, so a site can be clean on Google and still flagged elsewhere. Look the domain up on Norton Safe Web, McAfee and Yandex, then use each vendor's own re-evaluation form to ask for a new check. Do this after the Google review, because the other vendors often copy Google's verdict. Check again a few days later, and keep a list of which authorities flagged you, since each one clears on its own schedule. Keep screenshots of each lookup before and after, in case a vendor asks for proof.
If the infection was SEO spam, the spam pages stay in Google's index after you delete the files. Make the removed URLs return 404 or 410, search Google for site:yourdomain.com with words such as pharma or casino to find what is indexed, and submit the URLs through the Removals tool in Search Console. Check the Pages report in Search Console for sudden spikes of new URLs, the usual sign of spam pages. Then submit a clean sitemap. Rankings return as Google recrawls, which takes time, so keep scanning while it does. See the SEO spam hack.
Pick the person by the size of the risk, not by the price. A small brochure site with a clean backup is a reasonable do it yourself job. A store that takes payments, a site that was already cleaned once or a site with no backup should go to someone who does this every week. Either way, run the ScanTitan scan first, because a report with file paths and findings saves a professional hours and gives you something to check their work against. The cheapest cleanup is the one that stays clean, so ask about backdoors and reinfection before you ask about price.
Fits a small site, a recent clean backup and someone comfortable with files and the database. Use the five steps above and rescan when you finish.
Many hosts restore a backup or clean accounts they suspended. Ask what they will check, whether they cover the database and whether they rescan afterwards.
Best for a store, a reinfected site or a site you cannot afford to break, and the right call when you need an incident response team. ScanTitan is not that service, but our report gives them a starting list.
Providers price cleanups per incident or per year, and the figures vary widely, so compare scope before price. Ask whether the quote covers the database as well as files, whether it includes finding and removing backdoors, how fast they respond, whether they rescan afterwards and whether they clean again for free if the infection returns. Get the scope in writing. A cheap one time cleanup that skips backdoors is the most expensive option, because the infection comes back and you pay twice. Ask who does the work, an analyst or a script.
Hardening is what separates a cleanup from a repair. Reinfection is the usual failure of a cleanup, and it has two causes: a backdoor the cleanup missed, or an entry point that stayed open. The list below closes both. Most owners stop after the cleanup and meet the same infection a month later. Treat it as the last stage of the job, not an optional extra, and do it before you ask Google to review the site, because a second infection during the review resets the clock. Our guide on why WordPress malware keeps coming back covers the cases where the infection returns within days, and how a website gets hacked lists the entry points.
ScanTitan does not remove malware. It does the parts that make removal faster and safer: it finds the infection, it tells you where, and it checks your work. You enter the site address, with no plugin to install, the scan reports and does not change your site, and the scan works on WordPress, Joomla and Drupal sites. Save the first report, clean the site, then scan again and compare. If you want to read how the checks work, see the website malware scan, the behavioral malware detection page for redirects that only some visitors see, and the malware code analyzer for a suspicious snippet.
The scan looks for malicious PHP code and for webshell and backdoor indicators, the hidden ways back in that cause most reinfections.
Scan again after the cleanup and compare. A clean result is evidence that the checks that ran found nothing, and the report lists what it could not check.
Free, Professional and Business plans include weekly malware monitoring and send an alert when something is found. Consultant does not include monitoring. See pricing
Follow five steps: back up the infected site and change passwords, find every infected file and database entry, clean or replace them, rescan and test as a visitor, then close the entry point and request a Google review if there was a warning. ScanTitan finds the infection and rescans. You or your host do the cleaning.
No. ScanTitan finds the infection, shows where it is and rescans afterwards so you can confirm the site is clean. The cleanup is done by you, your hosting provider or a security professional you choose.
It depends on how many files and database entries changed, whether you have a clean backup and whether the entry point is still open. A site restored from a clean backup can be back quickly. A site with hidden backdoors in several places takes longer. Any promise of a fixed number of hours is a guess.
Prices vary by provider and by scope. Some charge per incident, others per year with monitoring. Compare what is covered, files only or database too, backdoor removal, rescan and a free re-clean if the infection returns, and get the scope in writing. Doing it yourself is free but costs time and carries risk if you miss a backdoor.
Yes, if you can restore a backup, edit files over SFTP or SSH and query the database. The risk is missing a backdoor, so scan again afterwards. Use a professional for stores that take payments, for sites that were reinfected and for sites with no backup.
It can if files are deleted without a backup. Take a full backup first, replace core, plugin and theme files from official sources, and keep wp-content and your database. Test the site in maintenance mode before reopening it.
Because a backdoor survived, or because the entry point is still open: a vulnerable plugin, a stolen password or a compromised hosting account. Replace instead of repairing files, remove rogue admins and scheduled tasks, update everything and reset every credential and key.
Clean the site, rescan, then open Google Search Console, go to Security issues, confirm each problem is fixed and choose Request review. ScanTitan does not submit the request for you. Other vendors such as Norton, McAfee and Yandex have their own re-evaluation forms.
If personal data was exposed, GDPR Article 33 requires you to notify the supervisory authority within 72 hours of becoming aware of the breach. If you take card payments, tell your payment provider. If you handle card data, PCI DSS also expects you to tell your payment provider, and health data brings HIPAA duties in the United States. Ask a lawyer or your data protection officer if you are unsure.
Free scanners such as the ScanTitan quick check, which looks for a website virus or other malware, detect infections but do not remove them. Removal means changing files and the database, which needs a person or a plugin with access. Use the free check to see whether something is wrong before you pay anyone.
A scan finds and reports malicious code. Removal changes your site to take it out and close the entry point. You need both, in that order, and a rescan at the end.
Rescan the same address, test the site on a phone and from a Google result, check the access logs for requests to the removed files and keep monitoring for a few weeks. A clean scan is evidence, not a guarantee.
Run a free malware check, keep the report for the cleanup, and scan again when you finish.
Run malware scan See pricing