How to Detect WordPress Malware Manually

Every week, site owners ask me some version of the same question: “My WordPress site looks normal to me, but traffic is dropping and users are complaining about weird behavior. How do I know if it is hacked?”

That question matters because modern attackers usually do not want you to notice the infection right away. They want the website to look normal to you while it quietly redirects search traffic, injects spam, creates hidden admin users, or leaves a backdoor for later reinfection.

If you need an immediate second opinion before you start editing files, begin with my free WordPress malware scan.

Quick answer

The most reliable way to detect WordPress malware manually is to combine:

• an external frontend scan,
• a blacklist and Search Console check,
• an internal file scan,
• manual inspection of plugins, users, source code, and network requests,
• direct review of high-risk files, the database, and cron jobs.

Automated scanners are useful, but they do not always catch hidden plugins, ghost admin users, cloaked redirects, or database-based spam. That is why manual verification still matters.

When manual malware detection matters most

You should go beyond a basic plugin scan if any of these are happening:

• your site redirects only for some users or devices,
• Google is showing spam pages or hacked snippets,
• the site keeps getting reinfected after “cleanup,”
• you suspect hidden plugins or ghost admin users,
• your host or browser is warning that the site may be dangerous.

In deeper infections, the visible symptom is often only one part of the compromise. I have seen that repeatedly in real-world cases, including this WordPress cloaking malware case study.

Phase 1: Surface checks that catch obvious infections fast

1. Run a frontend scan

Start with a public scanner such as Sucuri SiteCheck. This does not read your server directly. It checks what your website is visibly serving to a visitor, which makes it useful for spotting obvious malicious JavaScript, injected spam, defacements, blacklist signals, and other frontend issues.

A clean result does not prove the site is clean. Conditional malware may still hide from public scanners.

2. Check Google Search Console and blacklist signals

Next, review Google Search Console for security issues, hacked-page warnings, unusual indexed URLs, or sharp drops in impressions and clicks. Then check whether external services such as VirusTotal or browser vendors are already flagging the domain.

If the site is already showing warnings publicly, technical cleanup is only part of the job. You may also need my Google blacklist removal service.

3. Run an internal scan with a reputable security plugin

After the public checks, run an internal scan from inside WordPress or the server. A reputable scanner can help surface modified files, known malware signatures, suspicious code patterns, and integrity issues that public scanners cannot see.

This step is useful, but it should support your audit, not replace it.

Phase 2: Check whether the dashboard is lying to you

4. Compare the plugin list with the actual server folders

One of the most common persistence tricks is the hidden plugin. The malware exists physically on the server but does not appear normally in the dashboard.

1. Count what appears in Plugins → Installed Plugins.
2. Then check wp-content/plugins/ in File Manager or FTP.
3. Also check wp-content/mu-plugins/, because must-use plugins load separately.

If you find an unexpected folder that does not match a legitimate installed plugin, treat it as suspicious and inspect it carefully before deleting anything. An extra folder is a warning sign, not automatic proof on its own.

This guide is especially relevant if the infection keeps recreating fake plugin folders: how to prevent fake hidden plugins from reinstalling on WordPress.

5. Look for hidden or ghost admin users

Attackers often create administrator accounts so they can get back in later. More advanced infections also hide those users from the normal dashboard view.

Do not trust the Users screen alone. Check the database directly in phpMyAdmin:

• inspect wp_users (or your custom-prefix users table),
• review suspicious usernames, emails, and registration dates,
• compare database users with what appears in the dashboard.

If an account exists in the database but not in wp-admin, that is a major red flag. For a deeper walkthrough, read how to find and remove hidden admin users in WordPress.

Phase 3: Use your browser to catch what the malware serves

6. Inspect the raw page source

Open the website in a browser and choose View Page Source. Then check the top and bottom of the HTML for suspicious content such as:

• unexpected external scripts,
• large blocks of obfuscated text,
• hidden links that do not appear visually on the page,
• spam anchors for casinos, pharma, adult terms, or scam pages.

This is especially helpful for hidden SEO spam and injected frontend payloads.

7. Review the Network tab in Developer Tools

Open Developer Tools, go to the Network tab, then reload the page. Watch which domains your site is contacting.

You are looking for requests to unexpected domains, especially when they load JavaScript, redirects, tracking payloads, or strange assets that you do not recognize. This is one of the fastest ways to catch cloaked redirect malware and external script loaders.

Phase 4: Audit the server and database for hidden persistence

8. Review the highest-risk files first

Start with the files attackers commonly target:

• .htaccess: suspicious rewrite rules, redirect conditions, or traffic manipulation.
• wp-config.php: strange include, require, eval, or remote-loading logic.
• core entry files: such as index.php, wp-load.php, and wp-blog-header.php.

Unexpected modifications are most suspicious when they do not match a known update, deployment, or maintenance window. Do not assume every recent modified date is malicious—but do verify it.

9. Search the uploads folder for unexpected PHP files

Most WordPress sites should not be executing custom PHP from wp-content/uploads/. That directory is usually for media, not server-side code.

If you find unknown PHP files inside uploads, treat them as high priority. Some environments do include harmless protective files such as index.php, so inspect the file before deleting it—but do not ignore it.

10. Search the database for injected payloads

Malware often hides in the database, especially in wp_options, wp_posts, widget content, or custom tables. In phpMyAdmin, search for indicators such as:

• <script
• suspicious external domains
• base64 strings
• hidden-link CSS tricks like off-screen positioning
• spam keywords that do not belong on the site

Not every result is malicious, so validate the context before removing anything. For the cleanup side of this problem, see how to scan and clean your WordPress database for hidden malware.

11. Check WP-Cron and server cron jobs

If the malware keeps coming back after you remove it, check scheduled tasks. Attackers often use cron jobs to reinstall backdoors, recreate rogue users, or pull malicious code from elsewhere.

Review both:

• WordPress cron events,
• server-level cron jobs in your hosting panel.

Look for unfamiliar task names, suspicious PHP execution, or commands using tools like curl or wget to fetch remote files.

If reinfection is your main problem, read why WordPress malware keeps coming back.

You found malware. What should you do next?

Finding malware is only the first half of the job. The real goal is to remove it without leaving the backdoor behind.

A proper cleanup usually means:

• backing up the current state for forensic reference,
• removing malicious files and injected database content,
• replacing untrusted core, plugin, or theme files,
• removing hidden users, plugins, cron jobs, and loaders,
• patching the original entry point,
• rotating credentials after cleanup.

If you remove the symptom but leave the persistence mechanism, the site often gets reinfected. That is why I recommend a full manual cleanup path rather than isolated edits.

If you already confirmed the site is hacked, see my WordPress malware removal service.

When to stop DIY and get expert help

You should escalate the cleanup if:

• the site is a business-critical asset,
• the infection comes back after cleanup,
• Google is showing hacked pages or warnings,
• you found hidden plugins, ghost admins, or cron-based reinfection,
• you are not confident editing files or database rows safely.

That is the point where a wrong deletion can make recovery harder than the original hack.

Final thoughts

Learning how to detect WordPress malware manually is not about paranoia. It is about verification. Modern infections are designed to stay out of sight, which means relying on one scan result or one dashboard screen is not enough.

Start with fast surface checks, verify what is really on the server, inspect the database and scheduled tasks, and treat reinfection as a sign that some persistence mechanism is still alive.

Need help now? Start with my free scan or request professional WordPress malware removal.

FAQ

Can a WordPress security plugin detect all malware?

No. Security plugins are useful, but hidden plugins, cloaked redirects, database payloads, and custom persistence tricks can still be missed.

Is an extra plugin folder always malware?

No. It is a red flag that deserves inspection, but not automatic deletion. Compare it against legitimate plugins, must-use plugins, and known site customizations first.

Are PHP files in uploads always malicious?

Unexpected PHP in uploads is highly suspicious, especially if it looks like a web shell or loader. But inspect carefully before deletion because some setups may include harmless protective files.

Why does malware keep coming back after cleanup?

Usually because something was missed: a hidden admin, fake plugin, scheduled task, database payload, or the original vulnerability that let the attacker in.

What is the safest first step if I suspect a hack?

Run an external scan, check Search Console and blacklists, then verify the server manually before making destructive changes.