How We Removed Casino Spam From 25 WordPress Law Firm Sites

What Casino Spam Is

Casino spam, sometimes called a gambling or "togel" hack, is a type of SEO spam injection. The attacker does not deface your site. Instead they quietly add hundreds or thousands of hidden pages about online casinos, betting, and gambling, then point search engines at them. The goal is to borrow your domain's trust with Google so those spam pages rank.

Because the pages are hidden from normal visitors, most owners never see them. The first sign is usually indirect: a Google warning, a sudden flood of strange pages in Search Console, or rankings that quietly slide. For a law firm, where trust is everything, having gambling pages tied to your domain is a serious problem. If you suspect this, our guide on the signs your WordPress site is hacked covers the early warning signals.

How We Found It Across 25 Sites

The trigger was a Google Search Console audit on one site. The property was showing thousands of indexed URLs that should not exist, all with casino and betting keywords. That one finding raised an obvious question: if this site is infected, and it shares hosting and a management pattern with two dozen others, how many of the others are infected too?

So we ran the whole network. Rather than trust each site's dashboard, we checked every site from the outside and the inside:

• We crawled each site's public XML sitemaps and looked for gambling URLs that did not belong.
• We searched Google directly for spam pages on each domain.
• We checked each site's database for admin accounts and settings that no one on our team created.

The result was worse than expected. The infection was present, in one form or another, on the large majority of the network. A file-level cleanup had already been done weeks earlier, but the sites were still serving spam. That told us the real problem was not in the files at all.

What the Infection Looked Like

Once we mapped it, the attack had a clear and repeatable fingerprint. The same components showed up site after site, which is typical of an automated campaign that hits a whole hosting environment at once.

Hidden admin accounts in the database

Every infected site had one or two rogue administrator accounts that we did not create. They used throwaway names and were added straight into the database, not through the normal WordPress screens. These are the reason a hack comes back: even after you clean the files, the attacker simply logs back in with their hidden admin and reinfects the site. Finding and deleting these is the single most important step most cleanups skip.

Malicious settings in the options table

Each site also had a handful of injected rows in the WordPress settings table. These stored the attacker's configuration: which spam to serve, where to pull it from, and how to regenerate it. A file scanner never looks here, which is exactly why the earlier file cleanup did nothing to stop the spam.

A hidden loader and a ghost author

On many sites the attacker dropped a small loader file into the must-use plugins folder, a directory WordPress runs automatically on every page load and that most owners never open. It re-injected the malware even after the visible theme files were cleaned. The spam content itself was published under a ghost author, a fake user whose only posts were Spanish-language betting pages. Cleaning required removing the author and every post tied to it, carefully, so we did not touch legitimate content.

The pattern that mattered: file malware, database admins, injected settings, and a must-use-plugin loader all worked together. Remove only the files and the database half quietly rebuilds the infection.

Why a Plugin Scan Missed It

This is the part owners find hardest to believe. The sites had security tools, and an earlier cleanup had run, yet they were still spamming Google. Three reasons:

• Most scanners only read files. This infection lived mostly in the database, in the users table and the settings table, where a typical file scan never looks.
• The spam was cloaked. The pages were served only to search engine crawlers, not to a logged-in owner clicking around, so the site looked fine to a human.
• The admin interface was partly locked down. On this host, the usual programmatic way to list users was blocked, so we had to query the database directly to see the rogue accounts at all.

This is the same reason a cheap, automated clean so often fails. If you want the detail, we wrote a full SEO spam cleanup playbook and a breakdown of what malware removal actually costs.

How We Cleaned All 25

Because the infection had the same fingerprint everywhere, we built one tested cleanup and ran it carefully across the network, verifying each site by hand afterward. The sequence:

1. Map before touching anything. For each site we listed the rogue admins, the injected settings rows, the ghost author, and the loader file, so we knew the full scope first.
2. Remove the database half. We deleted the hidden admin accounts, the injected settings rows, and the ghost author with all its spam posts, while protecting legitimate users and content.
3. Remove the file half. We cleaned the infected theme files, deleted the must-use-plugin loader, and replaced anything tampered with using known-clean copies.
4. Close the entry point. We rotated the hosting and SFTP credentials across the network, since a shared access path was the most likely way the whole environment was hit at once.
5. Verify from the outside. After cleaning, we re-crawled each site, re-checked Google, and confirmed zero spam URLs were still being served before calling it done.

The order matters. We removed the database accounts and the loader before the visible files, because cleaning files first just gives the attacker a window to rebuild while you work. Doing it in the wrong order is why so many "cleaned" sites get reinfected within days. We cover this trap in our guide on spam redirects.

Recovering the Google Rankings

Removing the malware stops the bleeding, but it does not undo the damage already in Google's index. Thousands of casino URLs had been crawled and stored. Cleaning the site does not delete them from search overnight. So the recovery had a second half, done in Search Console for each affected property:

• We removed the polluted sitemaps the attacker had created and resubmitted clean ones, so Google would stop discovering spam URLs.
• We used the removals tool to pull the worst clusters of casino URLs out of search fast.
• We let the now-dead spam pages return "not found" so Google would drop them naturally on the next crawl.
• Where a malware warning had been applied, we requested a review once the site was verified clean.

If your site has already been flagged, our guide on what to do when Google flags your WordPress site walks through the review process step by step.

What We Learned

Five takeaways from cleaning 25 sites at once, in case you are facing the same thing:

• One infected site on shared hosting is a warning about all of them. Automated campaigns hit whole environments. If one site falls, audit the neighbors.
• A file cleanup alone is not a cleanup. If the database admins and settings survive, the spam comes right back.
• Hidden admin accounts are the real reinfection vector. Removing them is non-negotiable.
• Cleaning the site and recovering the rankings are two separate jobs. You have to do both.
• Rotate the keys. If you never close the door the attacker came through, you are just scheduling the next hack.

The whole network is clean today, monitored, and on a maintenance routine that catches this kind of thing early. That is the real lesson: the cleanup is the emergency, but ongoing maintenance and monitoring is what keeps it from happening again.