Client's Wordpress site got blacklisted by Google. Took me a full day to figure out what was actually going on.
Got a frantic call from a client last week. His customers were texting him screenshots of that red "this site is unsafe" page in Safari, and in Chrome the site just wouldn't load at all. Google had put the domain on its Dangerous list. It's a WooCommerce store, so basically nobody could get to it. No homepage, no checkout, nothing.
First thing I did was log in and look around, and honestly that's what made it confusing. Everything looked totally fine. Loaded the site on my desktop, poked around wp-admin, no redirects, no weird pages, nothing obviously wrong. But that's kind of the whole point with this stuff now. It's built so the owner never notices. You see a normal site, your customers and Google see something else.
The client was pretty sure he knew how it happened. He'd had a falling out with a developer he used to work with, a guy overseas, and from the way he described him he wasn't the type to care what he left behind on his way out. I try not to assume motive, but it lined up with what I ended up finding, so I kept it in the back of my head.
I used Claude Code to help me go through the server instead of grepping everything by hand. There were something like seven WordPress installs on the account (leftovers from old migrations), so I had it sweep all of them at once, searching the actual file contents for known bad patterns instead of going off file dates. That last part turned out to matter, I'll get to it.
Three things turned up.
First was a couple of fake plugins dressed up as cache/performance tools. One had its folder renamed with a .off on the end so it looked switched off, but it was still active. And it had code in it that hid it from the Plugins page, so even staring right at the admin you'd never see it was there. There was also an open AJAX endpoint acting as a backdoor.
The second one was sneaky, kind of impressive honestly. The theme's JavaScript files had malware tacked onto the end of them. Normal legit library file, and then way down at the bottom this chunk of obfuscated junk. It built a URL out of base64 pieces and fired a synchronous request at a server that was already offline, and because it was synchronous and nothing ever answered, the whole page would just hang. That was the "site keeps freezing" complaint.
And the reason it was a pain to find: whoever did it had reset the timestamps on the files. So if you go looking for recently modified files, which is the first thing most of us check, you get nothing back. They all looked like they'd been sitting untouched for months. Searching by content was the only thing that caught it.
Third was a rogue admin account. Random username, some email, sitting right there next to the owner's. That was the one that made the whole former-developer thing feel a lot more believable.
Cleanup took a while but wasn't crazy. Backed everything up first so I had a copy and a way to roll back. Then I went through the theme files and cut out the injected part at the point where it started, left the real library alone, and checked the file sizes against clean copies to be sure. Pulled the fake plugins and took them out of the active list. Deleted the rogue admin. Patched the hole they came in through, updated everything from clean sources, and changed all the passwords and the salts.
Site's on Cloudflare, so once the server itself was clean I flushed the Cloudflare cache and the live site started serving clean again.
The part I'd really stress to anyone going through this: getting the files clean is only half of it. To actually get off Google's list you have to go into Search Console, into the Security Issues section, and request a review once you're confident it's clean. And write up what you actually did, what the infection was, where it was, the admin account you pulled, the entry point you closed, all of it. I've seen vague "please re-check my site" requests sit forever or get bounced. Give them a clear rundown and let the site genuinely check out, and they'll re-scan and drop the warning.
By the next day the warning was gone, Chrome opened it fine, and Safari's red screen was cleared. About 24 hours start to finish.
The thing that stays with me is how much of it was set up so the owner would never see any of it. The hidden plugin, the code only Google sees. A compromised site can be quietly injecting spam links, bouncing mobile visitors off to junk sites, spinning up pages under your domain you don't even know exist, grabbing what people type into the checkout, and you'd have no idea from just loading it yourself.
Couple things I took from it. Don't trust file timestamps, if someone resets them your "recently changed" scan is useless, go by content instead. And don't skip the Search Console review, clean files alone don't lift the warning, the documented review request is what does it.
Somewhere in the middle of all this I ended up building a Claude Code agent that runs this whole scan for you. It goes through every install on the account, searches by file content instead of dates, flags the hidden plugins and the theme-JS injections and any rogue admins, and checks what the live site is actually serving to visitors. If anyone wants a copy I'm happy to send it over, no charge, and glad to answer questions about running a scan like this on your own site.
[link] [comments]