How to Check If A Website Has Malware: 12 Practical Tests Before Cleanup

Your site loads fine on your laptop. Google Analytics shows a traffic cliff you cannot explain. A customer emails to say they got redirected to a casino page on their phone. Your hosting company sent an abuse notice. You ran a free online scanner and it came back clean — but something still feels wrong.

If any of that sounds familiar, you are not alone. We clean hacked websites for a living, and the most common question we hear is not “how do I fix this?” — it is “how do I know for sure whether my site is actually infected?”

This guide answers that question with 12 practical tests, starting with checks anyone can run in under a minute and progressing to deeper forensic checks across files, database records, user accounts, server logs, and reinfection signals. Google specifically recommends monitoring Search Console, using the site: operator to spot unexpected indexed pages, and checking Security Issues reports for hacked content. We will cover all of those — and nine more tests that online scanners skip.

And we know all this becasue we clean hacked WordPress, Joomla, Magento, and custom websites every day as part of routine job.

First Things First

How do I check if my website has malware? Start with a free remote URL scan to check your site’s public surface for known malware, blacklist status, and visible injections. Remote scanners like Malcure WebScan check what a visitor or Googlebot sees — but they cannot inspect your server-side files, database records, hidden backdoors, or conditional malware that only triggers for specific visitors.

If your site runs WordPress, follow the remote scan with a deep WordPress malware scanner that verifies core, plugin, and theme file checksums against official sources, scans database rows for spam and injected content, inspects uploads and archives for hidden backdoors, and flags unauthorized admin accounts. A proper malware check inspects both files and database content, not just public URLs.

Then work through the 12 tests below. Each test catches something the others miss.

Think your site is hacked right now? Run a free WebScan → or request emergency malware removal →

The 12 Tests at a Glance

#	Test	What It Catches	Works On	Time
1	Browser & blacklist warnings	Public compromise signal	Any website	1 min
2	Google Search Console Security Issues	Google-confirmed compromise	Any website	2 min
3	site: search for unexpected indexed pages	SEO spam / hidden doorway pages	Any website	3 min
4	Test for malicious redirects	Visitor-targeted malware	Any website	5 min
5	View page source for injected scripts	Front-end injection	Any website	10 min
6	Compare site files against known-clean originals	Tampered files	Any site (FTP/SSH)	10–30 min
7	Scan uploads, images, archives & backups	Hidden backdoors	Any site (FTP/SSH)	10–30 min
8	Check the database for spam and injected content	Hidden DB malware	Any database-driven site	10–30 min
9	Audit admin users and roles	Account compromise	Any CMS / app	5 min
10	Review plugins, themes, and extensions for vulnerabilities	Original entry point	Any CMS	15 min
11	Inspect server logs, cron jobs & file changes	Persistence & backdoors	Any website	15–30 min
12	Monitor for reinfection after cleanup	Confirms root cause is fixed	Any website	Ongoing

Before You Start

Keep these five rules in mind before running any test:

1. Take a backup before deleting or modifying anything. A full backup — files and database — gives you a rollback path if a manual fix goes wrong.
2. Do not overwrite the site blindly. Reinstalling core files or restoring a backup without identifying the entry point often leads to reinfection within days.
3. Do not assume a clean homepage means a clean site. Most malware does not touch the homepage. It hides in spam pages, database rows, uploads folders, and conditional redirects that only trigger for specific visitors.
4. Test from incognito, mobile, and non-admin sessions. Malware frequently targets logged-out users, first-time visitors, mobile traffic, or search-engine referrals while leaving the admin experience untouched.
5. Malware may trigger only for Googlebot, specific user agents, or certain countries. If your site looks fine to you but users report problems, conditional malware is the most likely cause.

These precautions come from years of hands-on malware cleanup across WordPress, Joomla, Magento, Drupal, and custom-built sites. If you run WordPress, our guide to 9 common signs of a hacked WordPress site can help you decide whether to investigate further.

Start with Malcure WebScan for any public website. If your site runs WordPress, Malcure Advanced Edition can go deeper by scanning files, database records, uploads, archives, and hidden backdoors — not just public URLs. It is trusted by 10,000+ WordPress sites.

Test 1: Check for Browser and Blacklist Warnings

What this test finds

Public-facing compromise signals: browser warnings, search-engine warnings, hosting suspension notices, and ad-platform disapprovals. These are the most visible indicators that something is wrong — and they often appear before you notice anything yourself.

How to run it

1. Open your website in a regular browser window. Look for a red warning screen that says “Deceptive Site Ahead,” “This site may harm your computer,” or “The site ahead contains malware.”
2. Visit Google Safe Browsing Site Status and enter your domain. This checks Google’s blacklist in real time.
3. Check your hosting account for suspension notices, abuse emails, or resource-usage warnings.
4. If you run Google Ads, check for “Disapproved: Malicious software” notices in your Google Ads dashboard.
5. If you use an email service through your host, check whether outgoing emails are being blocked or marked as spam.

Red flags

• Any browser warning screen when visiting your own site.
• Google Safe Browsing reporting your site as “Dangerous” or “Deceptive.”
• Hosting suspension notice or abuse complaint from your web host.
• Google Ads disapproved for “Malicious software” or “Compromised site.”
• McAfee, Norton, or other security tools flagging your domain.

What to do if it fails

A browser or blacklist warning is a public symptom, not a root-cause diagnosis. It confirms compromise but does not tell you where the malware lives. Continue through all 12 tests to find the infection, then clean it before requesting a review. If the warning is from Google, see our guide to fixing the “This Site May Harm Your Computer” warning for the full review-and-reinstatement process.

Test 2: Check Google Search Console Security Issues

What this test finds

Google-confirmed malware or hacked content. When Google’s automated systems detect malicious behavior on your site — injected pages, redirects, or cloaked content — they report it in the Security Issues section of Search Console. This is the closest thing to an official “your site is hacked” notice you can receive.

How to run it

1. Log in to Google Search Console.
2. Select your website property.
3. Navigate to Security & Manual Actions → Security Issues.
4. Review any listed issues. Google categorizes them by type: “Hacked: URL injection,” “Hacked: Content injection,” “Malware infection,” “Social engineering,” etc.
5. Check your Search Console messages and email notifications — Google may have already sent alerts about detected malware.

Google says the Security Issues report shows hacked pages it has identified, and Search Console notifications can alert owners when malware is detected. If you do not yet have Search Console set up, Google recommends verifying your site now — it is the earliest warning system you will get.

Red flags

• Any entry under “Security Issues” — there are no false positives here worth ignoring.
• “URL injection” issues, which typically indicate spam pages injected into your site.
• “Content injection” issues, which mean Google found hidden or cloaked content on existing pages.
• Notifications about “Hacked content” or “Malware” sent to the property owner email.

What to do if it fails

Do not request a review yet. Google will re-flag your site if the underlying infection remains. Continue through the remaining tests — especially the file-system check (Test 6), database check (Test 8), and server-side scan — then clean the infection before submitting a reconsideration request.

Test 3: Search Google for Unexpected Indexed Pages

What this test finds

SEO spam, hidden doorway pages, and spam-injected content that attackers have placed on your site and Google has indexed. These pages are often invisible when you browse your site normally — they appear only in search results or when Googlebot crawls them. This test works for any website, regardless of platform.

How to run it

Run each of these searches in Google (replace example.com with your domain):

site:example.com
site:example.com viagra
site:example.com casino
site:example.com cialis
site:example.com payday
site:example.com Japanese
site:example.com ブランド
site:example.com inurl:product
site:example.com inurl:category
site:example.com inurl:tag

Google recommends using the site: operator to see what Google has found on your site and to spot unknown pages or content you did not create. Pay special attention to URLs with query parameters (?s=, ?p=, ?product_id=), unusual subdirectories, or content in languages you never published.

Red flags

• Search results showing pages you did not create.
• Pages with Japanese, Chinese, or other non-English text you never published.
• URLs containing pharmaceutical brand names, casino terms, or adult content.
• Hundreds or thousands of indexed pages when your site should only have a few dozen.
• Search-result titles and descriptions in a different language from your site.

What to do if it fails

Spam pages in Google search results nearly always indicate either a database injection or file-based malware generating doorway pages. If you run WordPress, our guides to the Japanese keyword hack and WordPress pharma hack cover the specific removal process. For non-WordPress sites, the same principles apply — the spam content is being generated somewhere on your server, and Tests 6 through 8 will help you find it.

Seeing spam pages in Google? Run a deep malware scan before those URLs cause more SEO damage and trigger a Google blacklist. A surface-level URL scanner cannot find the database rows or backdoor files generating those spam pages.

Test 4: Test for Malicious Redirects

What this test finds

Visitor-targeted malware that sends your traffic to scam sites, phishing pages, fake browser-update prompts, adult sites, or competitor URLs. Redirect malware is the most common infection type we see in cleanup cases — and it is also the easiest to miss because it often targets only specific visitors.

How to run it

1. Incognito/private window: Open your site in a browser you rarely use, in incognito mode. Malware often spares logged-in administrators and returning visitors.
2. Mobile device: Test from a phone or tablet. Mobile-only redirects are common because mobile users are less likely to inspect the URL bar.
3. Different network: Test from mobile data (not your office Wi-Fi) or through a VPN set to a different country. Some malware targets specific geographies.
4. Search-referral test: Search for your site on Google and click the result. Some redirects only trigger for search-engine traffic.
5. Different browsers: Test in Chrome, Firefox, and Safari. Some injected scripts target specific browsers.
6. Direct type-in: Type your URL directly into the address bar and compare behavior with the search-referral test.

Red flags

• Your site loads, then immediately sends visitors to a different domain.
• Redirects to fake CAPTCHA pages, “Your browser is out of date” prompts, or “You’ve won” scams.
• Redirects that happen only on the first visit (cookie-based conditional malware).
• Mobile-only redirects that do not appear on desktop.
• Redirects to domains ending in unusual TLDs (.xyz, .top, .club, .online).

What to do if it fails

Redirect malware can live in JavaScript files, .htaccess rewrite rules, PHP header injections, or infected database rows. For WordPress sites, our JavaScript redirect malware guide walks through each location. For any platform, Tests 6, 8, and 10 in this checklist will help you find the source.

Test 5: View Page Source for Injected Scripts, Iframes, or Encoded Code

What this test finds

Front-end malware injections: malicious JavaScript, hidden iframes, encoded payloads, spam links, and unauthorized external domain references. This test catches what is visible in the rendered HTML — but it will miss server-side or conditional malware. It works for any website, regardless of platform or CMS.

How to run it

1. Right-click your homepage and select “View Page Source” (not “Inspect Element” — you need the raw server response).
2. Search (Ctrl+F / Cmd+F) for suspicious patterns:
   • <script — Look for scripts loading from unknown domains, long encoded strings, or obfuscated JavaScript.
   • <iframe — Look for hidden iframes (often with width="0" height="0" or display:none).
   • eval( — The eval() function in inline scripts is a strong malware indicator.
   • base64 — Encoded payloads frequently use base64 encoding.
   • String.fromCharCode — Common JavaScript obfuscation technique.
3. Scroll to the very bottom of the source code. Malware is often appended after the closing </html> tag.
4. Check the <head> section for unexpected script includes or base-64 encoded style blocks.
5. Repeat this check on a few inner pages — not just the homepage.

Red flags

• Scripts loading from domains you do not recognize, especially .ru, .cn, .xyz, .top, or numeric IP addresses.
• Large blocks of encoded or obfuscated JavaScript.
• Hidden iframes pointing to external sites.
• Spam links injected into the footer, sidebar, or body content.
• Content that appears in the page source but not when you view the page normally (cloaking).

What to do if it fails

A source-code check only catches client-side injections. Server-side malware — PHP backdoors, database injections, .htaccess rewrites — will not appear in the page source. Continue through Tests 6–8 to find those. And remember: if the source is clean but users still report redirects, the infection is likely conditional (Test 4).

Test 6: Compare Site Files Against Known-Clean Originals

What this test finds

Tampered files inside your website installation. Malware often modifies existing site files — adding malicious code to legitimate files makes detection harder because the file still looks like it belongs. This test compares your files against their known-clean originals.

How to run it

If you use WordPress, WP-CLI makes this straightforward:

1. Use a malware scanner that performs checksum verification against the official WordPress.org repository. Malcure Advanced Edition compares your core, theme, and plugin files against their official checksums and flags any modifications.
2. Alternatively, use WP-CLI to verify core file integrity:

wp core verify-checksums

This command compares every WordPress core file against the official checksums for your installed version.

For WordPress plugins and themes:

1. Check the /wp-content/plugins/ and /wp-content/themes/ directories for files that should not be there.
2. Look specifically for PHP files that are not part of the original package, files with suspicious names like wp-tmp.php or config.bak.php, and recently modified files sorted by modification date.
3. Reinstall any plugin or theme that shows unexpected modifications from a fresh download.

For other platforms: Compare your current files against a clean backup or a fresh installation copy. Look for modified timestamps that do not match your own update activity. Any PHP, JavaScript, or template file modified outside of known deployments is worth inspecting.

Red flags

• wp core verify-checksums reports any modified, missing, or unknown files in WordPress core.
• PHP files inside uploads or media directories that should only contain images or documents.
• Core files with modification dates newer than your last platform update.
• Files containing eval(, base64_decode(, gzinflate(, str_rot13(, or shell_exec( in their contents.

What to do if it fails

If core files are modified, reinstall them from a trusted source rather than manually editing — a manual fix can miss secondary infections. For WordPress, reinstall WordPress core using WP-CLI. For other platforms, restore from a clean installation package. Then continue through Tests 7–12 to check for backdoors, database infections, and the entry point that allowed the modification.

Test 7: Scan Uploads, Images, Archives, and Backups

What this test finds

Hidden backdoors and malicious payloads stored in locations that many scanners skip. Attackers frequently hide PHP shells inside image files, ZIP archives, backup folders, and cache directories — places where a site owner rarely looks and where basic security tools often do not scan. This test applies to any website, though the specific directory paths will vary by platform.

How to run it

Inspect these common hiding places for unexpected executable files, files with double extensions, or files that should not be present:

/wp-content/uploads/
/wp-content/cache/
/wp-content/upgrade/
/wp-content/backups/
/images/
/assets/
/media/
/downloads/

Pay particular attention to:

• Executable files inside media directories. Upload and image directories should contain media files — not PHP, ASP, or other executable files. Any script file in a media directory is suspicious.
• Files with double extensions: image.jpg.php, favicon.ico.php, logo.png.php. These look like media files in a directory listing but execute as code.
• Hidden files: Files starting with a dot (.hidden-file.php) or placed inside hidden directories.
• Archive files in unexpected locations: .zip, .tar.gz, or .sql files outside a backup directory may contain malicious payloads or database dumps stolen by an attacker.

Malcure Advanced Edition scans raw images, archives, hidden files, backups, and uploads in addition to standard PHP, JavaScript, and theme files — because a backdoor hidden inside a fake JPEG inside an uploads folder is one of the most common reinfection vectors we see.

Red flags

• Any executable file inside a media or uploads directory.
• Files with double extensions.
• Hidden files or directories (names starting with .) in uploads or cache folders.
• Archive files containing code or database exports in non-backup locations.
• Recently created or modified files in directories that should be static.

What to do if it fails

Quarantine suspicious files — move them outside the web root, do not delete them immediately (you may need them for forensic analysis). Then search the rest of your installation for similarly named files — backdoors are rarely deployed alone. Continue to Test 11 to check how the file got there.

Test 8: Check the Database for Spam and Injected Content

What this test finds

Database-level malware that lives entirely outside the file system. Many site owners assume that if their files are clean, their site is clean. That assumption is wrong. Malware can survive exclusively in database rows — spam links in content, hidden admin users, injected JavaScript in configuration tables, or malicious redirect rules stored as serialized data. This test is critical for any database-driven website.

How to run it

If you use WordPress, check these database tables for suspicious content:

• wp_posts and wp_postmeta: Look for posts you did not create, spam links in post content, hidden divs containing casino/pharma/Japanese text, or encoded scripts stored as post content.
• wp_options: Check the siteurl and home values — attackers sometimes change these to redirect traffic. Look for options with suspicious names, encoded values, or injected JavaScript stored as option values.
• wp_users and wp_usermeta: Look for admin users you did not create (see Test 9).
• wp_comments: Check for spam comments containing links, script tags, or encoded content.

Use WP-CLI to search the database for common malware patterns:

wp db search "eval(" --all-tables
wp db search "base64_decode" --all-tables
wp db search "<script" wp_posts

For other platforms, inspect your database tables directly using phpMyAdmin, Adminer, or command-line database tools. Look for: unexpected content in page/post tables, modified site URL or configuration values, new administrator accounts, and encoded or suspicious text in any content column.

Malcure Advanced Edition scans database records alongside files, identifying infected rows — including SEO spam like Japanese keyword hack and pharma spam — so you can inspect and clean them directly rather than guessing which rows contain malware.

Red flags

• Spam links, pharmaceutical keywords, casino terms, or non-native-language text in content or configuration tables.
• Encoded or serialized data containing JavaScript, PHP code, or external URLs.
• Site URL or home URL values pointing to a domain you do not control.
• Unknown entries in configuration tables with autoload enabled — attackers use these to inject code on every page load.
• Database search results matching eval(, base64_decode, or gzinflate in any table.

What to do if it fails

Database infections require surgical removal — do not blindly search-and-replace. Identify the infected rows, verify they are malicious, and remove them manually or with a database-safe cleanup tool. Expert malware removal includes database inspection and row-level cleanup for cases where the infection is widespread or deeply embedded.

A surface-level URL scanner cannot see infected database rows. Malcure scans both files and database records to find malware that remote scanners miss. Install Malcure Advanced Edition for a complete file + database scan, or start with a free WebScan →

Test 9: Audit Admin Users and Roles

What this test finds

Account compromise: attackers who have created, escalated, or hijacked user accounts to maintain persistent access to your site. This is one of the most overlooked infection vectors — a legitimate-looking admin account with a strong password can survive every other cleanup step. This test applies to any CMS or application with user accounts.

How to run it

If you use WordPress:

1. Go to Users → All Users in your WordPress admin panel.
2. Look for:
   • Users you do not recognize, especially those with the Administrator role.
   • Admin accounts with email addresses from free email providers you do not use.
   • Multiple admin accounts when you know there should only be one or two.
   • Users with suspicious usernames (random strings, brand names, “support,” “admin,” “test”).
   • Subscriber-level accounts that seem out of place — attackers sometimes create low-privilege accounts first, then escalate.
3. Check the wp_users and wp_usermeta tables directly if you have database access — some backdoors hide users from the admin UI.
4. Review the user_registered date — sort by newest to spot recently created accounts.

For a complete WordPress user audit via WP-CLI:

wp user list --role=administrator --fields=ID,user_login,user_email,user_registered
wp user list --fields=ID,user_login,user_email,user_registered --orderby=registered --order=desc

For other platforms: Check your user administration panel or database directly for: unknown administrator accounts, recently created users, accounts with suspicious email addresses, and users with elevated privileges that should not have them.

Red flags

• Any administrator account you did not personally create.
• Admin accounts with generic or suspicious email addresses.
• Recently registered users with administrator privileges.
• Users that cannot be deleted from the admin panel.
• Hidden users that appear in the database but not in the user interface.

What to do if it fails

Delete unauthorized admin accounts immediately — directly from the database if the admin UI will not let you. Then change all passwords for legitimate accounts, reset any application security keys or salts (see Test 11), and check for backdoors that may have been used to create the rogue accounts. For WordPress, a full security audit can identify how the accounts were created and what else the attacker may have accessed.

Test 10: Review Plugins, Themes, and Extensions for Vulnerabilities

What this test finds

The original entry point. Malware cleanup is incomplete if the vulnerable plugin, theme, extension, or module that let the attacker in remains active on your site. Removing the malware payload without closing the entry point guarantees reinfection — often within hours or days.

How to run it

1. Update everything. Install all pending updates for your CMS, plugins, themes, extensions, and any server-side software.
2. Remove unused extensions. Delete any plugin, theme, or module that is:
   • Abandoned (not updated in 12+ months).
   • Installed but inactive — delete it unless you have a specific reason to keep it.
   • Not from an official repository or a trusted developer.
   • A “nulled” or pirated premium extension — these are a leading vector for backdoored code.
3. Keep a fallback. If you use WordPress, keep one default theme (Twenty Twenty-Five or similar) as a troubleshooting fallback. Delete all other inactive themes.
4. Verify integrity. Compare each active extension’s files against the version available from the official source. Any differences indicate tampering.
5. Check for known vulnerabilities. For WordPress, Malcure Advanced Edition checks core, plugins, and themes for known security flaws using real-time threat intelligence and checksum verification.

Red flags

• Plugins, themes, or extensions with known, unpatched vulnerabilities.
• Premium extensions obtained from unofficial sources.
• Recently installed extensions you did not install yourself.
• Deactivated extensions that were previously exploited — the vulnerability still exists even if the extension is off.
• Files with modification dates that do not match the official release.

What to do if it fails

Delete vulnerable or compromised extensions. If you need the functionality, replace them with a maintained alternative from a trusted source. For premium extensions, download a fresh copy from the official developer and reinstall. Then continue to Test 11 to check for backdoors that may have been planted through the vulnerable extension.

Test 11: Inspect Server Logs, Cron Jobs, and Recent File Changes

What this test finds

Persistence mechanisms and backdoors: how the attacker maintains access, what they are doing with it, and whether the infection is still active. This is the most technical test in the checklist — it requires server access — but it is also the test that most often reveals the true scope of an infection. It applies to any website, regardless of platform.

How to run it

Server access logs:

• Check access_log or access.log (location varies by host — typically in cPanel under “Raw Access Logs” or via SSH at /var/log/apache2/ or /usr/local/apache/logs/).
• Look for: repeated POST requests to login or API endpoints, requests to executable files in media directories, login attempts from unfamiliar IP addresses, and requests for files that do not exist (probing).

Error logs:

• Check error_log or error.log for errors that reveal injected code execution, file-inclusion attempts, or failed function calls from unknown files.

If you use WordPress — cron jobs:

wp cron event list --fields=hook,next_run_relative

Look for cron hooks with suspicious names, hooks that execute PHP files in uploads or cache directories, or hooks that run at unusually high frequencies. For non-WordPress sites, check your system crontab (crontab -l) for unexpected entries.

Recently modified files:

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

This lists all PHP files modified in the last 7 days — a strong signal of active infection or recent tampering.

Red flags

• Repeated failed login attempts from unfamiliar IPs (brute-force attack).
• POST requests to executable files in media or upload directories — these are almost certainly backdoors being accessed.
• Cron jobs or scheduled tasks executing files in unexpected locations.
• Files modified outside of known update or development activity.
• Outbound connections from your server to unknown external IPs (data exfiltration).

What to do if it fails

Log anomalies help identify the entry point and whether the infection is still active. Block malicious IPs at the server or firewall level. Remove suspicious cron jobs. Investigate any file that was modified outside of normal update activity. If you find evidence of ongoing access, request expert malware removal — active infections require careful handling to avoid alerting the attacker.

Test 12: Monitor for Reinfection After Cleanup

What this test finds

Whether the root cause is actually fixed. Passing one scan after cleanup does not prove your site is permanently clean. Malware that returns within days or weeks means something was missed: a backdoor, a vulnerable extension, a rogue user account, a database injection, a cron job, or a compromised hosting environment.

How to run it

1. Schedule recurring scans. Run a full files + database scan at least weekly after cleanup. Malcure Advanced Edition supports scheduled scans with email alerts so you know immediately if new malware appears.
2. Monitor file changes. Track when files are added, modified, or deleted. Unexpected changes after cleanup are the earliest reinfection signal.
3. Check Google Search Console regularly. New Security Issues appearing after cleanup confirm the infection was not fully resolved.
4. Review new user registrations. If new admin accounts appear after you have cleaned and secured the site, a backdoor is still active.
5. Set up event logging. Log and review admin logins, extension installations, file modifications, and settings changes.

If malware comes back after cleanup, you probably removed the visible payload but missed the backdoor, vulnerable extension, rogue user, cron job, or database injection that restored it. The 12 tests in this checklist cover every persistence mechanism — if malware returns, re-run Tests 6 through 11 with fresh scans.

Red flags

• Any malware detected by a scheduled scan after you believed the site was clean.
• New or modified files appearing without your action.
• Google Search Console reporting new Security Issues.
• Unknown admin users reappearing.
• Redirects or spam pages returning.

What to do if it fails

Reinfection means the root cause was not addressed. Work back through Tests 6–11 with fresh scans. If the infection returns a second time after your own cleanup, the persistence mechanism is likely beyond what surface-level tools can find. Expert malware removal includes root-cause analysis, backdoor hunting, and verified cleanup — with monitoring to confirm the infection is gone.

What to Do Next: Decision Table

What you found	What it likely means	Next step
Google warning or blacklist	Confirmed or suspected compromise	Scan files + database, clean infection, then request review
Spam pages indexed in Google	SEO spam / database injection	Inspect content, configuration, and database rows; run a deep scan
Redirects only on mobile or from search	Conditional redirect malware	Test as logged-out, mobile, and search-referral traffic; check server config and JavaScript files
Unknown executable files in media or cache	Backdoor or web shell	Quarantine suspicious files; inspect server logs for access patterns
Modified core or platform files	File tampering	Verify checksums; restore clean files from trusted source
Suspicious admin users	Account compromise / persistence	Delete rogue users; reset all passwords and security keys; check for backdoors
All 12 tests pass but symptoms persist	Undetected infection or non-malware cause	Request expert manual review; conditional malware may require server-level inspection
Malware returns after cleanup	Persistence mechanism still active	Check users, cron jobs, vulnerable extensions, database injections, and hosting environment

Run a complete malware scan now. Malcure Advanced Edition scans files, database records, uploads, archives, and hidden files — then flags infected rows so you can inspect and clean them. Start with a free WebScan → or request expert malware removal →

Frequently Asked Questions

Can my site have malware even if the homepage looks normal?

Yes — and this is one of the most common misconceptions we encounter. Most malware does not touch the homepage. It hides in spam pages that only appear in Google search results, conditional redirects that trigger for mobile or search-referral traffic, database rows that inject content into specific pages, or backdoors that sit dormant until accessed directly. A clean-looking homepage proves nothing. Run the full 12-test checklist, not just a visual check.

Can malware hide in the database?

Yes. Malware stored in the database is invisible to file-level scanners and URL-based remote scanners. Common patterns include: spam links injected into content tables, encoded JavaScript stored in configuration rows, rogue admin accounts, and redirected site URL values. Database malware can survive a complete file reinstall — the infection reactivates as soon as the site reconnects to the database. Test 8 covers database inspection in detail.

Why does my site redirect only on mobile or from Google?

Conditional redirect malware. Attackers configure redirects to trigger only for specific conditions — mobile user agents, search-engine referrers, first-time visitors (no cookie), logged-out users, or traffic from specific countries. This makes the infection harder to detect: the site owner browsing from a desktop on their regular browser sees a normal site, while mobile visitors or Google search users get redirected to scam pages. Test 4 covers how to test for conditional redirects. For WordPress sites, our JavaScript redirect malware guide explains the specific injection techniques attackers use.

Can a security plugin or scanner say my site is clean but malware still be present?

Yes. Different security tools scan different things, and no single tool catches everything. A file-only scanner will miss database infections. A URL-based remote scanner will miss server-side malware that does not render in the public HTML. A signature-based scanner will miss zero-day malware or custom obfuscation. A tool that does not scan uploads, archives, or hidden files will miss backdoors in those locations. This is why the 12-test framework exists — each test catches something the others miss.

Should I restore a backup or clean the current site?

It depends on whether the backup is clean. If you have a verified-clean backup from before the infection, restoring it is often faster than manual cleanup — but you must also close the entry point (vulnerable extension, weak password, compromised account) or the site will be reinfected. If you are unsure when the infection started, assume all recent backups are compromised. In that case, clean the current site, identify the entry point, and create a new clean backup afterward. For WordPress, our 10-step malware removal guide covers the full cleanup and verification process.

How do I know the malware will not come back?

You do not — unless you have verified all of the following: (1) every infected file has been removed or restored from a clean source, (2) every infected database row has been cleaned, (3) unauthorized admin users have been deleted, (4) all passwords and security keys have been changed, (5) vulnerable extensions have been updated or removed, (6) backdoors in uploads, cache, and hidden directories have been found and removed, (7) malicious scheduled tasks have been cleared, and (8) scheduled scans with reinfection alerts are active. Test 12 covers ongoing monitoring to confirm the root cause is fixed.

What should I do before requesting a Google review?

Complete the full 12-test checklist — especially Tests 1–8. Google’s review process checks your site for the same malware signals that triggered the warning. If any infection remains, Google will re-flag your site, and repeated failed reviews can make future approvals harder. Before submitting a review: verify all files are clean, the database has no injected content, no unauthorized users exist, and a follow-up scan 24–48 hours after cleanup confirms the infection has not returned. Our Google warning removal guide covers the full review-request process.

Malware Detection Is a Layered Process

No single test — and no single tool — can guarantee your website is clean. Malware detection is a layered process: public reputation checks, search-index audits, redirect testing, front-end inspection, file integrity verification, database scanning, user-account review, vulnerability assessment, server-log analysis, and ongoing reinfection monitoring.

Most “scan your website” articles stop after the first two layers. They tell you to paste your URL into a free scanner and call it done. But a surface-level URL scan cannot see infected database rows, hidden admin accounts, backdoors disguised as images, conditional redirects, or malware that only activates under specific conditions.

The 12 tests in this guide cover what remote scanners miss. Work through them methodically. If any test fails, follow the recommended next step in the decision table above. And if you find malware you cannot fully clean — or if it keeps coming back — get expert malware removal that includes root-cause analysis, verified cleanup, and reinfection monitoring.

Next: 9 tell-tale signs your site is hacked → | 10-step guide to removing malware → | Run a free WebScan →