What We Learned When Our Own Website Was Hit With Malware

What We Found

We first caught it the way most site owners eventually would, an unusual spike in Google Search Console's Page Indexing report. Instead of the roughly 120 real pages we expected, the report was showing tens of thousands of pages we had never created, most of them sitting in a "crawled, currently not indexed" state, thin spam content designed purely to exploit our domain's existing authority. Once we pulled the actual numbers, the scale of it was hard to miss, and it made containment the immediate priority before anything else.

What We Actually Did

Reacting in the right order mattered here, the same sequence we now walk clients through when we handle this for them:

1. Contained the entry point — traced the compromise back to exactly the kind of gap we now warn clients about constantly: outdated plugins and themes that hadn't been updated in some time, combined with no dedicated security plugin or hardening layer actually watching for this. There was no leaked credential, no clever social engineering, just neglected basics that had quietly become a real opening. We locked it down immediately so nothing new could get injected while we worked through the rest.
2. Removed the injected content — cleaning out the spam pages and checking carefully for any backdoors left behind, not just the visible symptoms sitting in the index.
3. Submitted the affected URLs through Google Search Console's removal tool — so they would stop showing in search results and crawl reports while the index cleaned up naturally over the following weeks.
4. Hardened the actual weakness — patched and locked down the specific gap that let this happen, rather than treating the cleanup itself as the fix.
5. Rebuilt our own monitoring — put ongoing checks in place so something like this gets caught within hours next time, not discovered weeks later through an indexing report.

What This Kind of Attack Actually Costs a Business

Beyond the direct cleanup work, an incident like this carries costs that are easy to underestimate going in. Search rankings can dip while Google reprocesses a domain full of injected spam, since the index has to work through both removing the fake pages and re-establishing trust in the real ones. There is also the quieter cost of attention: the days spent on cleanup and monitoring are days not spent on client work or new business development, which is a real, if less visible, price alongside the technical one.

What a Real Cleanup Timeline Looks Like

Containing the immediate threat, locking down the outdated components and stopping new injections, happened quickly once we identified the problem. Getting the site genuinely clean, and confident it was clean, took considerably longer than we expected going in, realistically the better part of a month from discovery to feeling like we had actually closed every gap, not just the obvious one. Google's own reprocessing of the affected pages continued even after that.

The Uncomfortable Truth About "It Won't Happen to Us"

Before this, we would have said our own stack was reasonably well maintained, and in most respects it was. That is precisely the uncomfortable lesson: "reasonably well maintained" and "actually secure" are not the same standard, and the gap between them is exactly where an incident like this lives. It is a genuinely different feeling to write a client-facing security checklist after living through the thing the checklist is meant to prevent, and that gap is what convinced us this was worth writing about honestly rather than filing away privately.

What We Changed Permanently

Going through a real incident changed our internal standard, not just for our own site, but for how we approach every client's security work now. We now treat the Page Indexing report as a standing weekly check across every site we maintain, not just our own, specifically watching for the kind of sudden, unexplained page-count spike that was our own first warning sign. We also tightened how quickly patches get applied across our own infrastructure, since the gap that let this happen was one we could have closed sooner if we had been checking as rigorously on ourselves as we do for clients.

That timeline is itself part of what changed our standards. A month is a long time to be uncertain whether your own site is genuinely clean, and it is exactly why we do not treat a quick surface cleanup as sufficient for clients either, now we verify thoroughly before calling anything resolved.

Why We Are Telling You This Instead of Staying Quiet About It

Plenty of agencies talk about security in the abstract, best practices, generic checklists, without ever having actually lived through a real incident on their own infrastructure. We would rather be the agency that is honest about this, because it is exactly this experience that shaped the security processes we now run for every client, the wp2shell response, the plugin supply chain monitoring, the ongoing hardening work, all of it sharpened by lessons that started here, on our own site.

If your site has not had an incident like this, that is genuinely good, and this post is not meant to create worry where there was not any before. Where we come in is exactly this: catching this kind of thing early through ongoing monitoring, or cleaning it up properly and closing the real gap if it has already happened, the same process we just walked through on our own infrastructure. That is the work behind our WordPress security service and malware removal practice, $30 an hour, written scope before any billing starts.