I’m Writing a Practical WordPress Malware Removal Book Based on Real Cleanup Cases
A WordPress site can look completely normal to the owner while visitors are being redirected somewhere else.
A blank screen can be malware.
It can also be an ordinary PHP error.
A security scanner can find a suspicious file without telling you how it got there, what created it, or whether deleting it actually solved the compromise.
These are some of the reasons I started writing:
WordPress Malware Removal for Developers & Site Owners
The book is now available in Early Access on Leanpub, with Chapter 1 available as a free sample.
Why I’m Writing This Book
I’ve been working with WordPress sites since 2018 through freelance marketplaces, agencies, direct client projects, and my own company, 3Zero Digital.
During that time, I’ve investigated and cleaned more than 4,500 hacked WordPress sites.
The incidents were rarely as simple as:
Run a malware scanner → delete the infected file → change the password → done.
Real cases are usually messier.
I’ve worked on sites where:
- desktop visitors saw a normal website while mobile visitors were redirected
- malware was stored in the WordPress database rather than an obvious PHP file
- administrators existed in the database but were hidden from the WordPress Users screen
- fake plugins were designed to look harmless
- SEO spam appeared in Google without being obvious inside WordPress
- malicious behavior came back after the first cleanup
- checkout pages loaded suspicious remote code
- the WordPress files looked clean while the problem existed at the hosting, DNS, or CDN layer
That experience shaped the main idea behind the book:
Finding malware is not the same as understanding what happened.
Start With the Symptom, Not the Word “Malware”
One of the first lessons in the book is simple:
“Hacked” is a conclusion. The symptom is what you actually observed.
For example:
- the site redirects
- the screen is blank
- Google shows pages you never created
- an administrator is missing
- checkout suddenly behaves differently
- a visitor gets a warning
- a deleted infection keeps returning
Each symptom may have a security explanation.
But many of them can also have ordinary explanations.
A blank page could be caused by malicious code replacing index.php.
Or it could be caused by a PHP/theme mistake.
The symptom alone does not decide which one is true.
Evidence does.
A Site Looking Normal Does Not Prove It Is Clean
One of the real cases used in Chapter 1 involved a website that appeared completely normal from the owner's desktop.
But a request using a mobile browser identity received a redirect to an external domain.
The malicious rule was checking the visitor before deciding what response to send.
That means checking the homepage once from your normal browser is a very weak security test.
A compromised site may behave differently depending on:
- mobile vs desktop
- logged-in vs logged-out users
- first visit vs returning visit
- direct traffic vs Google traffic
- cookies
- referrer
- IP or geographic conditions
This is why WordPress malware investigation often requires looking beyond the WordPress dashboard.
What the Book Covers
The current plan includes 16 chapters:
- Is the WordPress Site Actually Hacked?
- How Does a WordPress Site Get Hacked?
- What to Do Before Cleaning Malware
- Find What Else Is Infected
- Remove Malware from WordPress Files
- Remove Malware from the WordPress Database
- Clean the Hosting Account, Server, and DNS
- Find and Remove WordPress Redirect Malware
- Remove WordPress SEO Spam and Hacked URLs From Google
- Find and Remove Fake WordPress Plugins and Themes
- Remove Unwanted and Hidden WordPress Administrators
- Find and Remove WooCommerce Credit-Card Skimming Malware
- Hosting and Domain Suspension Removal
- Blacklist Removal
- Stop Malware from Coming Back
- Secure and Monitor a Recovered Site
The goal is to follow an incident from the first suspicious symptom through investigation, cleanup, recovery, and verification.
This Is Not Meant to Be a Theory-Only Security Book
I’m trying to keep the book practical.
The examples come from real cleanup and investigation experience.
That includes looking at:
- WordPress files
- plugins and themes
- database records
- users and capabilities
- browser source and Network requests
- logs
- cron jobs
- hosting accounts
- DNS and CDN settings
- Google search results
- WooCommerce checkout behavior
I also try to separate what the evidence proves from what it only suggests.
For example:
A suspicious loader contacting a remote server is evidence of suspicious behavior.
It is not automatically proof that payment information was stolen.
A malicious file proves that malicious code exists.
It does not automatically prove how the attacker originally entered the site.
Those distinctions matter during real incident response.
Early Access
The book is being published progressively on Leanpub.
Chapter 1 is available now as a free sample, and new chapters will be added as they are completed.
Early Access readers receive future chapters and updates to the same edition as they are released.
You can read the free sample or follow the book here:
I’m also interested in feedback from WordPress developers, hosting professionals, security researchers, and site owners who have dealt with compromised WordPress sites.
What part of WordPress malware cleanup do you think causes the most confusion?
