Your site’s been hit with SEO spam, and you’ve checked the usual spots. Here’s a senior engineer’s guide to finding the hidden culprits and the three strategies—from a quick patch to a full rebuild—to reclaim your server.

Beyond the Core Files: My Playbook for Hunting Down SEO Spam

It was 2 AM. A PagerDuty alert shattered the silence. The marketing site for our biggest e-commerce client was suddenly ranking for… well, let’s just say ‘less than reputable’ pharmaceuticals. The CMO was calling my boss, my boss was calling me, and a major sales campaign was set to launch in 72 hours. I SSH’d into web-prod-01, checked the core WordPress files—pristine. The theme files? Looked clean. Yet, there it was, a phantom <div> full of spam links appearing only for the Googlebot user-agent. It’s a feeling I know too well, and if you’re reading this, you probably do too. You’ve done the first pass, and now you’re wondering where on earth the ghosts are hiding in the machine.

First, Understand Why You Can’t Find It

You’re not going crazy. The reason you can’t find the injection in the core files is because that’s amateur hour. Modern attackers are far more subtle. They aren’t trying to deface your site; they’re trying to hijack its SEO authority. They know you’ll check `index.php` and your theme’s `header.php`. They’re counting on you stopping there.

The real infection is almost always in one of these three places:

• The Database: A single malicious entry in your wp_posts or wp_options table can inject content across your entire site. The code is pulled from the database at render time, so your files on disk look completely clean.
• Obfuscated Code in “Innocent” Files: Attackers will often stick a long, ugly string of encoded text inside a seemingly random plugin file or even an image’s metadata. This string is then decoded and executed using functions like eval(), base64_decode(), or gzuncompress().
• Server Configuration Files: A sneaky rule in your .htaccess file can redirect or inject content based on the visitor’s user-agent or referrer. This is how they show spam to Google but show your normal site to you, making it incredibly hard to spot.

The Action Plan: From Triage to Total Annihilation

Alright, enough theory. You’re here because your site is on fire. Here is my personal, battle-tested playbook, broken down into three levels of escalation.

Level 1: The Quick & Dirty Triage

This is the “stop the bleeding” phase. The goal isn’t to be perfect; it’s to get the spam off the public-facing site right now. We’re looking for the most common culprits.

1. Hunt for suspicious functions with grep: SSH into your server and run this from your web root. This command recursively searches for common obfuscation and injection functions.

grep -r -E "eval\(|base64_decode|gzuncompress|str_rot13" /var/www/your-site/

2. Check for recently modified files: Attackers often leave a timestamp. This command will find all files modified in the last 3 days. Pay close attention to files you don’t recognize or core files that shouldn’t have been touched.

find /var/www/your-site/ -mtime -3 -ls

3. Scan the database: Check your posts table for injected <script> tags or spammy links. This SQL query is a good starting point (replace `wp_posts` with your table name).

SELECT * FROM wp_posts WHERE post_content LIKE '%<script>%' OR post_content LIKE '%display:none%';

Warning: This approach is a band-aid. You may have removed the symptom, but the root cause—the vulnerability that let the attacker in—is likely still there. The infection will almost certainly return if this is all you do.

Level 2: The Forensic Deep Dive (The ‘Right Way’)

Okay, the immediate fire is out. Now we do it right. This is about methodically cleaning the site and hardening it to prevent re-infection.

1. Isolate the Patient: Put your site into maintenance mode. You don’t want users or search engines hitting the site while you’re operating on it.
2. Full Backup: Take a complete file and database backup of the infected site. Label it clearly, e.g., `site-backup-INFECTED-2023-10-27.tar.gz`. This is your evidence and your safety net if you accidentally delete something important.
3. Replace the Core: Delete your core application directories (like `wp-admin` and `wp-includes` for WordPress) and replace them with fresh, clean copies downloaded directly from the official source. Do not just copy over them; a malicious file named `wp-includes/class.wp.php-` won’t be overwritten.
4. Audit & Update Everything: Go through every single plugin and theme. If you don’t recognize it or it’s not actively used, delete it. Update everything else to the latest version from a trusted source.
5. Change Every Secret: This is non-negotiable. Change all admin passwords, database user passwords, FTP passwords, and hosting panel passwords. Generate new WordPress salts. If you use SSH keys, audit the `authorized_keys` file. The attacker could have left a backdoor.

Level 3: The Nuclear Option (Nuke and Pave)

Sometimes, the infection is too deep, or it keeps coming back. You can no longer trust the server’s integrity. At this point, you assume the entire operating system is compromised. It’s time to burn it all down and start fresh.

This is my go-to when I’ve cleaned a site twice and it still gets reinfected. My time is more valuable than trying to find a needle in a haystack of compromised system binaries.

1. Backup ONLY the Essentials: Do not do a full server backup. You’ll just back up the infection. Carefully export the database and grab your `uploads` directory. That’s it. Your themes and plugins can be re-downloaded.
2. Provision a New Server: Spin up a brand new, clean instance (e.g., `web-prod-02`). Patch it completely before you put a single file on it.
3. Scrub the Database: Before importing your database backup, open it in a text editor and search for any suspicious content, like spam links, unknown `admin` users, or JavaScript injections. Clean it manually. This is tedious but critical.
4. Rebuild from Scratch: Install a fresh copy of your application (WordPress, etc.). Re-install your themes and plugins one by one from their official repositories. Do NOT copy them from your old, infected server.
5. Migrate Clean Data: Import the scrubbed database and upload your `uploads` directory.
6. Update DNS and Decommission: Point your domain to the new server’s IP address. Once traffic is flowing correctly, take the old server (`web-prod-01`) offline and delete it permanently.

Pro Tip: The Nuclear Option feels drastic, but it’s often faster in the long run than playing whack-a-mole with a persistent attacker. More importantly, it gives you peace of mind that there are no hidden rootkits or backdoors left on the OS. Your reputation depends on it.

Which Path Should You Choose?

Here’s a quick breakdown to help you decide.

Dealing with a hack is a rite of passage. It’s stressful, but it’s also a powerful learning experience. Follow a methodical process, don’t panic, and remember that even senior engineers have been in this exact same spot at 2 AM. Now go get your site back.

Darian Vance

Lead Cloud Architect & DevOps Strategist

With over 12 years in system architecture and automation, Darian specializes in simplifying complex cloud infrastructures. An advocate for open-source solutions, he founded TechResolve to provide engineers with actionable, battle-tested troubleshooting guides and robust software alternatives.

🤖 Frequently Asked Questions