Guide · Clean scan, live warning
Wordfence says clean. Sucuri says clean. Your host ran ImunifyAV and says clean. And Google still shows a security issue, or the browser still warns, or the blacklist entry is still there, or customers still report being redirected. This is one of the most common positions to be stuck in, and the instinct — scan again, with something else — almost never resolves it. There are four distinct reasons a clean scan sits next to a live flag, they need completely different responses, and the first job is working out which one you have.
Published Last reviewed
The four explanations
A clean scan is a statement with a precise and fairly narrow meaning: the files this tool read, at the moment it read them, did not match the patterns it knows. Every word in that sentence is doing work. It is not a statement that the site is clean, and it is certainly not a statement that whoever flagged you was wrong.
When a clean result and a live flag coexist, one of four things is true. They are not equally likely, they are not equally serious, and the response to each is different — so resolve which one you are in before doing anything else.
The site really was compromised, you really did clean it, and nothing has told the flagging party to look again. Blacklists and browser warnings do not clear themselves on a schedule you can rely on. This is the best case, it is genuinely common, and the fix is a review request — not more cleaning.
Cloaked payloads decide what to serve based on who is asking. Serve clean content to logged-in administrators, to requests from the site's own server, and to anything that looks like a scanner — while serving the payload to search-engine crawlers or to mobile visitors arriving from search. You see a clean site. The scanner sees a clean site. Google sees the hack.
A WordPress plugin reads the WordPress installation. Content in the database, a PHP startup directive that runs before WordPress, a file in the account home directory above the web root, a cron entry, or a compromised neighbouring account are all outside that boundary. Clean is accurate; it is just answering a narrower question than the one you asked.
A broken or expired certificate, mixed content, an aggressive ad or affiliate script, a third-party widget that was itself compromised, or a flag that actually applies to a subdomain or a parked domain rather than the site you keep scanning. Worth ruling out early, because it is cheap to check and embarrassing to miss.
Start here
You cannot resolve a contradiction without the other side of it. Every source that flags a site will tell you something about what it found and when — and that detail usually decides which of the four you are in within minutes.
| Who flagged you | Where the detail lives | What it tells you |
|---|---|---|
| Search Console → Security & Manual Actions → Security Issues, plus the Safe Browsing site status page. | The category of issue and often sample URLs. Sample URLs are the single most useful artifact you can get — they tell you exactly where to look. | |
| Your host | The suspension or abuse notice itself, and the scan log behind it. | Specific file paths and detection names. Ask for the log if the notice only summarises it. |
| A blacklist or reputation service | The service's own lookup page for your domain or IP. | The listing date and reason. An old listing date with no recent recheck is the signature of a stale flag. |
| A browser warning | The warning itself names the mechanism, usually Safe Browsing. | Routes you back to Search Console. A certificate error is a different problem wearing similar clothes. |
| A customer or visitor | Ask what they saw, on what device, from where, and how they arrived. | Arrival path and device are exactly the conditions a cloaked payload keys on. This is often the most valuable report you will get. |
| A payment processor or ad platform | The rejection notice and the review contact. | Usually cites a specific URL and behaviour. Deadlines here are commercial, not technical. |
Reproducing it
If the flag is current, the next job is reproducing the behaviour under the conditions it actually occurs in. Cloaked malware is built specifically to fail this test, so approximate the victim rather than the owner.
Cloaking very commonly excludes logged-in administrators, and a plugin or a cached admin session will hide the behaviour from you indefinitely. Use a private window at minimum, a browser profile with no extensions ideally.
Many payloads trigger only on a search-engine referrer. Reach the page from a search result rather than by typing the address, or set the referrer deliberately in developer tools. A direct visit is the one condition that is usually safe.
Device class and network are routine cloaking conditions. A phone on mobile data is a genuinely different visitor from your desktop on the office connection, and sometimes that is the entire difference.
The URL Inspection tool in Search Console fetches as Googlebot and shows the rendered result. When the payload is keyed to crawlers, this is the fastest way to see what Google saw — and it is authoritative in a way a third-party scanner is not.
Open the network panel and read the actual HTML the server returned, plus every script it pulls in. An injected script that writes itself in after load will not appear in 'view source' but will appear in the network log and the live DOM.
If Search Console or your host named specific URLs, test those, not the homepage. Spam pages generated under a site frequently do not appear in any menu, are not linked from anywhere a visitor would find, and render perfectly normally to the owner who goes looking for them.
Where to look
If you have reproduced live malicious behaviour and the scanners still disagree, you are in explanation two or three. These are the places that sit outside a WordPress file scan, roughly in the order they pay off.
Injected content in the options table — particularly autoloaded values — survives replacing every file on the site, because it is not a file. A filesystem scanner is not looking there.
An auto_prepend_file directive in .user.ini, .htaccess, or php.ini loads a file before WordPress exists, so it has already run before any plugin could observe it. Check the site directory and every parent directory.
Above the document root: hidden dot-directories, unexpected executables, SSH keys, and the account's crontab. A WordPress plugin cannot read any of it.
Must-use plugins load automatically and never appear in the normal plugin list. object-cache.php, advanced-cache.php, and db.php load early and are routinely overlooked in a cleanup.
An ad network, a chat widget, an affiliate script, or a compromised CDN asset produces genuinely malicious behaviour with nothing malicious in your own files. Your scanner is correct and the flag is correct.
On shared hosting, one account can hold several sites. A flag against the domain may be about a neighbouring installation, an old staging copy, or a subdomain nobody has looked at in two years.
Getting the flag lifted
A review request is the right move in explanation one and a serious mistake in explanations two and three. A failed review is not free: it costs days, and repeated failed requests on the same site get slower rather than faster.
If you have reproduced live malicious behaviour under any condition, you are not in the stale-flag case. Requesting a review while the payload is live wastes the request and the time it takes to fail.
The URLs the flagging party gave you are examples, not an inventory. Cleaning exactly those and requesting a review is how sites end up re-flagged within days.
A cleanup that does not address how the site was reached leaves the same door open. Rotate every credential the site and account hold, and address the vulnerable component or exposed access path.
Re-run the reproduction steps above — logged out, from search, on mobile, and as Googlebot. Your own logged-in view of the homepage is the weakest possible evidence that a cloaked payload is gone.
For Google, that is the Security Issues report in Search Console. Say what was found and what was done. For a host, reply to the abuse ticket with the same account. For a blacklist, use its own delisting form.
Different services recheck on different schedules, so the browser warning, the search result label, and the blacklist entry rarely clear at the same moment. Give it time before concluding the cleanup failed.
Common questions
Usually not. Two scanners that read the same files answer the same question twice, and a second clean result tells you very little you did not already know. The useful next step is not another scanner but a different vantage point: fetch the page as Googlebot, view it logged out from a search referrer, and look at the database and the PHP configuration — the places no WordPress file scan covers.
Most likely because nothing has told Google to look again. A Safe Browsing flag does not expire on a fixed schedule; it clears after a successful review, which you request in Search Console. If you cleaned the site and never requested a review, that is the whole explanation.
The cleanup is removing the symptom and leaving the mechanism. Something is restoring the payload — a database-resident loader, a PHP startup directive, a cron entry, a compromised neighbouring account, or credentials that were never rotated. Repeated re-flagging is a persistence problem, not a review problem.
They are rarely wrong about what they examined; they are frequently misread about what that covered. The honest framing is that a clean result is accurate and narrow at the same time. When a clean result and a reproducible symptom genuinely coexist, the symptom is the stronger evidence — work from it.
Get sample URLs from whoever flagged you and test exactly those, logged out, from a search referrer, on mobile, and through the URL Inspection tool. If it still will not reproduce, check whether the flag concerns a subdomain, a staging copy, or another site in the same hosting account — that is the usual answer when everything else comes back clean.
A successful Google review is typically a matter of days rather than weeks, though nobody can promise a figure. Blacklists and reputation services run on their own schedules and often lag behind, so partial clearing is normal and is not a sign the cleanup failed.