How to check a website for malware

Something is wrong with your website. Visitors are reporting redirects to strange domains. Google is showing a “This site may be compromised” warning in search results. Your hosting provider sent a notification about suspicious files. Or maybe nothing visible has happened, but you want to verify your site is clean after hearing about a vulnerability in a plugin you use.

Whatever brought you here, the question is the same: how do you check whether a website actually has malware? The answer depends on whether you are checking your own site (where you have server access) or someone else’s site (where you only have a URL). Both scenarios are covered here.

External scanning - checking any website from the outside#

External scanners inspect your site the way a visitor or search engine sees it. They load the page, analyze the HTML, JavaScript, and outbound links, and check the domain against known malware databases. They cannot see your server’s files or database directly, but they can detect the symptoms of infection.

Google Safe Browsing

Google maintains a list of sites that distribute malware, host phishing pages, or serve unwanted software. This is the most widely used malware database – Chrome, Firefox, and Safari all check it before loading pages.

Check your site directly:

https://transparencyreport.google.com/safe-browsing/search?url=yourdomain.com

If your site is flagged, Google shows a warning to every visitor using Chrome (which is roughly 65% of all web traffic). This is the most urgent malware signal because it directly kills your traffic.

Google Search Console

If you own the site, Search Console provides more detail than the public transparency report. Under Security & Manual Actions > Security Issues, Google lists specific pages with detected malware, the type of infection (injected content, redirects, downloads), and instructions for requesting a review after cleanup.

Search Console also sends email alerts when Google detects malware on your site. If you have not verified your site in Search Console yet, do it now – it is the earliest warning system for many types of infection.

Sucuri SiteCheck

Sucuri’s free scanner at sitecheck.sucuri.net loads your site and checks for:

• Known malware signatures in the HTML and JavaScript
• Blacklisting status across multiple databases (Google, Norton, McAfee, PhishTank)
• Injected spam links or hidden iframes
• Suspicious redirects
• Outdated CMS versions

SiteCheck is useful as a quick external check but it only sees what a visitor sees. Server-side malware that only activates under certain conditions (specific user agents, specific countries, logged-in users) may not trigger during an external scan.

VirusTotal

VirusTotal checks a URL against 70+ antivirus engines and blacklist databases simultaneously. Submit your URL at virustotal.com and it returns results from every engine, giving you a comprehensive view of whether your site is flagged anywhere.

This is particularly useful for checking if a specific URL on your site has been flagged – not just the homepage, but the specific pages that visitors reported issues on.

What external scanners miss

External scanners have significant blind spots:

• Conditional malware. Sophisticated infections only trigger for specific visitors – Google bot sees a clean page while real visitors from specific countries see redirects. External scanners may test as one user agent but miss behavior targeted at others.
• Server-side backdoors. A PHP backdoor sitting in your plugins directory does nothing visible on the front end. It waits for the attacker to send a specific request. External scanners cannot detect it because it produces no visible symptoms.
• Database injections. Malware stored in the WordPress database (injected JavaScript in post content, malicious URLs in options) only appears when the specific post or page is loaded. A scanner checking the homepage will miss it.
• Cron-based malware. Some infections schedule actions via WordPress cron or system cron – sending spam emails, running cryptocurrency miners during off-peak hours, or periodically re-infecting cleaned files. These produce no visible symptoms during a scan.

External scans are a starting point. If they find something, you definitely have a problem. If they find nothing, you may still have a problem.

Server-side scanning - checking your own site from the inside#

If you have SSH or SFTP access to the server, you can scan files directly. This catches what external scanners miss – backdoors, hidden files, obfuscated code, and server-side malware that produces no visible front-end symptoms.

WordPress integrity checks with WP-CLI

The fastest way to check if WordPress core files have been modified:

wp core verify-checksums

This compares every core file against the official checksums for your WordPress version. Any modified, added, or missing file is reported. Legitimate WordPress installations should pass with zero warnings. Any file that fails the checksum check has been modified and needs investigation.

Check plugins from the wordpress.org repository the same way:

wp plugin verify-checksums --all

This does not work for premium plugins (which are not in the wordpress.org repository), but it covers most installations. If a plugin file has been modified outside of an update, the checksum check flags it.

ClamAV scanning

ClamAV is the most widely used open-source antivirus scanner on Linux servers. It maintains a database of known malware signatures and scans files against them.

If ClamAV is installed on your server:

clamscan -ri /path/to/wordpress/

The -r flag scans recursively through all subdirectories. The -i flag only shows infected files (suppresses the “OK” lines for clean files). A typical WordPress installation takes 1-5 minutes to scan depending on size.

ClamAV detects known malware signatures but may miss custom or heavily obfuscated infections. It is a good baseline check but should not be the only scan you run.

Manual file inspection

Some infections are not in any signature database. Manual inspection catches what automated tools miss.

Recently modified files. Malware modifies existing files or creates new ones. Check for files changed recently:

find /path/to/wordpress -type f -name "*.php" -mtime -7

This lists all PHP files modified in the last 7 days. Compare this against your actual activity – if you did not update plugins or edit files in the last week, any modified PHP file is suspicious.

Files in unexpected locations. Legitimate WordPress files follow predictable directory structures. PHP files in the uploads directory are almost always malware:

find wp-content/uploads -name "*.php"

The uploads directory should contain images, PDFs, and other media files. PHP files here are a strong indicator of infection, since WordPress does not create PHP files in uploads during normal operation.

Suspicious file names. Malware often uses names designed to blend in or look legitimate:

# Files with random-looking names
find . -name "*.php" | grep -E '[a-z0-9]{8,}\.php$'

# Common malware filenames
find . -name "wp-tmp.php" -o -name "class-wp-*.php" -path "*/uploads/*" -o -name ".*.php"

Files named things like wp-tmp.php , class.api.php , or random strings like a8f3d2e1.php in unexpected directories deserve investigation.

Obfuscated code. Open any suspicious file and look for:

• base64_decode()  wrapping large blocks of encoded text
• eval()  executing variable content
• str_rot13()  or  gzinflate()  used for deobfuscation chains
• Very long single lines of seemingly random characters
• Variables assembled character by character:  $a = 'e'.'v'.'a'.'l';

Not every use of base64_decode is malware – some plugins use it legitimately. But eval(base64_decode(...)) wrapping a large encoded string is malware in virtually every case.

Database scanning

Malware can live in the WordPress database, not just in files. Check for injected JavaScript or suspicious content:

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

Also check the wp_options table specifically. Malware often adds entries here to persist between file cleanups:

wp db query "SELECT option_name, LEFT(option_value, 100) FROM wp_options WHERE option_value LIKE '%<script%' OR option_value LIKE '%eval(%';"

The siteurl and home options are common targets for redirect malware. If these point to a domain that is not yours, your site has been compromised:

wp option get siteurl
wp option get home

WordPress cron jobs

Persistent malware often registers WordPress cron events that re-infect the site on a schedule:

wp cron event list

Look for events with unfamiliar hook names, especially ones that run frequently. Legitimate WordPress cron events have recognizable names like wp_update_plugins , wp_scheduled_auto_draft_delete , or plugin-specific prefixes. Events with random or suspicious names should be investigated.

Using security plugins for ongoing monitoring#

Security plugins provide continuous monitoring rather than point-in-time scans.

Wordfence

Wordfence includes a file scanner that compares your WordPress core, plugin, and theme files against their known-good versions. It also scans for malware signatures, backdoors, and suspicious code patterns. The free version includes all scanning features – the premium version adds a real-time signature database rather than a 30-day-delayed one.

After installation, run a full scan from the Wordfence menu. The results categorize findings by severity: critical (known malware), warning (suspicious patterns), and informational (changes that may or may not be intentional). For context on how Wordfence interacts with server-level security, see Wordfence and server-level security: why you need both.

Sucuri Security plugin

The Sucuri plugin monitors file integrity by taking a snapshot of your files and alerting you when anything changes. It also checks your site against external blacklists and provides post-hack hardening recommendations. The scanning functionality is free.

What security plugins cannot do

Security plugins run inside WordPress. If WordPress itself is compromised at a level that prevents plugins from loading correctly, the security plugin may not function. This is why server-level scanning (ClamAV, file integrity monitoring) is important as a layer above what WordPress plugins can provide.

Signs to look for without any tools#

Even without running scans, certain symptoms strongly indicate malware:

• Unexpected redirects. Visitors (or you) are sent to a different domain, especially pharmacy spam, gambling sites, or fake tech support pages.
• Google search warnings. Search results for your site show “This site may be hacked” or “This site may harm your computer.”
• Strange admin users. New administrator accounts you did not create appear in Users > All Users.
• Modified files you did not touch. Your theme’s  functions.php  or  header.php  was modified at a time when no one was working on the site.
• Hosting provider notification. Your host detected outbound spam, high CPU from cryptocurrency mining, or suspicious network connections from your account.
• SEO spam in search results. Searching  site:yourdomain.com  in Google shows pages about pharmaceuticals, gambling, or other spam topics that you did not create.
• Slow site with no explanation. Cryptominers and spam scripts consume CPU and memory, slowing your site noticeably.
• Email delivery problems. Your domain gets blacklisted because malware on your site is sending spam email through your server.

If you notice any of these, scan immediately. For a detailed walkthrough of infection vectors, detection, and cleanup, see WordPress malware: how it gets in and how to remove it.

After scanning: what to do with the results#

If the scan finds malware

1. Do not panic, but act quickly. Malware that has been on your site for a day has already done its damage. Taking an hour to plan your response is better than rushing and missing something.
2. Take a backup of the infected state. Before cleaning anything, back up the current infected files and database. If the cleanup goes wrong or you need to analyze the infection later, you have the evidence.
3. Identify the entry point. How did the malware get in? An unpatched plugin vulnerability, stolen credentials, a compromised theme. If you clean the malware but do not close the entry point, the site will be re-infected within days. Check your server access logs for the initial compromise.
4. Clean or restore. Either manually remove the malware, restore from a known-good backup, or use a combination approach. For a step-by-step cleanup process, see WordPress malware: how it gets in and how to remove it.
5. Harden the site. Update everything, remove unused plugins and themes, rotate all credentials, and set up ongoing monitoring so you catch the next attempt early.

If the scan is clean

A clean scan does not guarantee the site is uninfected – it means the tools you used did not find anything. If you are scanning because of specific symptoms (redirects, spam, Google warnings), and the scans come back clean, the malware may be:

• In the database rather than in files
• Conditional (only triggering for certain visitors)
• Using obfuscation that the scanner does not recognize
• In a location the scanner did not check (server-level cron jobs, non-WordPress files)

If symptoms persist after clean scan results, escalate to manual investigation or professional malware removal.

How Hostney handles malware detection#

On Hostney, malware detection is not something you need to set up or run manually. The platform monitors file system changes in real time across all hosting accounts.

Real-time file monitoring. When a file is created or modified in your hosting account, the system scans it automatically against a malware signature database. This happens within seconds of the file change, not on a scheduled scan that runs once a day. If the file matches a known malware signature, it is quarantined immediately and the incident is reported to your control panel dashboard.

Automatic quarantine. Detected malware is moved to a quarantine directory that is not accessible from the web and not writable by your hosting account. The original directory structure is preserved so you can see exactly which file was infected and where it was. The site continues running with the malicious file removed.

Incident reporting. Every detection creates an incident record visible in the control panel. The record includes the file path, threat name, detection time, and current status. You also receive an email notification so you know about the detection even if you are not logged in to the control panel.

Complementary layers. File scanning works alongside ModSecurity WAF (blocking exploit attempts before they succeed), bot detection (blocking automated vulnerability scanners), and container isolation (preventing cross-account infections). The goal is to stop the malware from getting in, but the file monitoring catches it if the other layers miss something.

Summary#

Checking a website for malware involves two layers: external scanning (Google Safe Browsing, Sucuri SiteCheck, VirusTotal) catches visible symptoms like injected content and blacklisting, while server-side scanning (WP-CLI checksums, ClamAV, manual file inspection) catches hidden backdoors and obfuscated code.

External scans are fast and require no server access, but miss conditional malware, server-side backdoors, and database injections. Server-side scans catch more but require SSH access and take longer. The most thorough approach uses both: external scans for a quick check, then server-side scans for confirmation.

For ongoing protection, combine a WordPress security plugin (for application-level monitoring) with server-level file integrity monitoring (for catching what WordPress plugins cannot see). If your scan finds malware, back up the infected state, identify the entry point, clean or restore, and harden the site before considering it resolved. For the complete cleanup process, see WordPress malware: how it gets in and how to remove it.