The Case Files: Every Hacked Website We Cleaned Up in 2026, What Gave It Away and What Fixed It

01 / 06

What do the hacked sites we cleaned up have in common?

Three things. Every one ran self-hosted WordPress. Every attack was designed to stay out of the owner's view. And in three of the four, the owner had noticed nothing; the fourth knew the site had been hacked before, but not what was still hiding. That matches the wider picture: plugins carried 91% of the 11,334 new WordPress vulnerabilities found in 2025 (Patchstack, 2026), and attackers automate their search for them.

We are an SEO and web agency, not an incident response firm, and these sites came to us for search work. The hacks came with them. We are not naming the businesses. They are clients, and the lessons are about the attacks, not about them.

Two more sites appear in the series for a different reason: a health clinic whose calculator page was hammered by bots, and a pool company whose Google Ads were flagged after our own edge challenged Google's traffic. Neither was hacked. Both taught us something about bots.

02 / 06

What was the hidden plugin that ran for months?

A fake caching plugin, with a made-up author, found on a professional services firm's site in July 2026 and on a real estate brokerage's site in October. On both, its files dated to November 29, 2025. It hid from the Plugins screen, skipped logged-in users and handed visitors code fetched live from the attacker's server.

This is the case that best answers "how could I be hacked and not know?". The owner, logged in, saw a normal site. The Plugins screen did not list the plugin. The code it served came from the attacker's server each time, so it could change what it did whenever they chose, without touching the site.

The second find matters as much as the first. After the first cleanup, an integrity check was built to compare the plugins on the server with the plugins WordPress shows. Three months later, on another site, that check flagged the same plugin. One site's incident became the next site's early warning.

Full story, the cleanup measurements and an 8-point self-check: the plugin the owner never saw.

03 / 06

How did gambling pages hide on an art gallery's website?

As plain folders that the server sent before WordPress was ever asked. Nine of the gallery's 39 sitemap pages were replaced by gambling doorways aimed at Indonesia. WordPress search, its API, a Google site: search and the Wayback Machine all said clean. A 639 KB page among 185 KB pages, and one strange day in Search Console, gave it away.

The attack ran on a schedule: two admin accounts four seconds apart, then a hidden file, then nine doorway folders in nine minutes, then a Search Console verification file one minute later to claim the site in Google's tools. A script, not a person.

The symptom in Search Console was a single day, September 3, with 112 clicks and 3,103 impressions against a normal 1.4 and 64.3, then straight back to normal. Gambling and adult searches made up 79.5% of the quarter's clicks (First-party incident records, 2026).

The seven signs that would have caught it, and how to check each: how to tell if your website is hacked.

04 / 06

What did a plumbing company's cleanups miss?

Two things a normal cleanup does not look for. A two-word link on the home page, the same color as the text and placed between commas like a typo, wrapped in 11 invisible off-screen boxes. And the old hacked server, which came back for about 16 hours and 49 minutes when the domain's settings were reset to the registrar's defaults.

The link survived because the first cleanup checked spam pages and brand names, not the links inside the pages it kept. The old server came back because moving the site had not cleaned the server it left, and the domain's nameservers were changed through the registrar account itself, with every registrar lock still on. Who made that change is still unknown.

A 10-point checklist for the steps after the obvious ones: what a hacked website cleanup misses.

05 / 06

What did the bots do once the sites were protected?

They kept coming. In five days behind our edge, the rebuilt plumbing site logged 3,412 trap hits from 1,450 addresses, including 1,588 requests for a WordPress login it no longer had (First-party edge data, 2026). Across the wider web, bots made up 53% of traffic in 2025 and bad bots 40% (Thales, 2026).

The bots wanted logins, configuration files and known plugin weaknesses. Someone checked whether the old spam pages were still up, from 18 addresses with one request each. A toolkit checked a known backdoor path from 9 hosts. None of it found anything, because the new site was static.

Two lessons came from other sites. On a health clinic's site, 108 of 142 blocked visitors used home or mobile connections, so blocking by address alone would have locked out patients. And on a pool company's site, our own edge was challenging Google's traffic until Google Ads flagged the site; the flags cleared after we fixed it.

The numbers, the caveats and our own mistake: what our edge saw in five days.

06 / 06

How do you keep a business site from becoming the next case file?

Shrink what can be attacked, and watch from outside. Two-step login on every account, including the domain. Fewer plugins and updates on. A Cloudflare proxy in front, where your platform allows one. And for most service businesses, a static site on Cloudflare, which removes the server code, plugins and site login these attacks relied on.

Platform choice sets how much of this is your job. Hosted builders patch their own servers; self-hosted WordPress hands you everything. Not every platform lets a Cloudflare edge sit in front of it: Wix does not, and Shopify's help center says it does not. The details are in our website builder security comparison.

Where the platform allows it, put an edge in front. It filtered the bots and recorded the trap hits behind these case files. RankShield, our founder's security company, runs that kind of layer on Cloudflare, which it describes as "a managed filtering layer on Cloudflare's global network that sits in front of your whole site". It is $39 a month, added on top of a RankShield plan; details are on the RankShield edge page. It is an option we offer, never a condition of working with us.

For most service businesses, our answer is a static site on Cloudflare with an edge in front. Every attack in these files needed something a static site does not have. The case for it, and its limits, are in why we build sites as static pages on Cloudflare.

Watching from outside matters as much as hardening. In every case here, the owner was looking from inside: logged in, at the dashboard, at what WordPress reported. Look at what the server sends to a stranger, read Search Console monthly and test your contact form. Our free SEO audit is a good first look.