The giveaway in this hack is almost always the gap between what Google sees and what a human sees in a browser. Swap in your own Search Console export and the same cloaking logic and hiding spots apply.
Security
Diagnose a spam or SEO content injection hack on category pages
Google Search Console showing pharma-spam titles indexed under category pages that don't exist anywhere in wp-admin, traced through cloaking-by-user-agent to the likely injection point and cleaned up without tipping off whoever planted it.
Works with Claude / GPT275 uses★ 4
The prompt
security-spam-seo-injection-hack-diagnosis
Search Console coverage report shows this: [- 340 indexed URLs under /category/health/ with titles like "Cheap Viagra Online No Prescription" and "Buy Generic Meds Fast" - None of these pages appear anywhere in the WordPress admin post list, page list, or category list - Viewing the URLs directly in a normal browser returns a 404 or redirects to the real homepage - The client noticed because organic traffic to legitimate health-category content dropped and a partner flagged the spam URLs showing up in search results] Diagnose this the way a responder would, not just "run a malware scanner": 1. Explain what the mismatch between what's indexed and what's visible in a normal browser almost always means: user-agent cloaking, where injected code serves spam content only when the request looks like Googlebot (specific user-agent string, sometimes IP-range checks) and serves normal content or a 404 to everyone else. State why this is designed specifically to stay invisible to the site owner during a routine check. 2. Give the concrete places this code usually hides so it survives a shallow look: a modified .htaccess with conditional rewrite rules, an injected function in the active theme's functions.php gated on user-agent, or a standalone PHP file dropped somewhere in wp-content that intercepts requests before WordPress even loads. 3. Lay out how to find it without alerting whoever's monitoring the exploit: compare .htaccess and core files against known-clean copies or recent backups, grep the codebase for user-agent conditionals combined with base64_decode, eval, or gzinflate, and check for unexpected files by modification date rather than by name alone. 4. Once located, sequence containment and cleanup: remove or quarantine the injected code, then close the entry point (likely a vulnerable plugin or stolen credentials) before assuming it's over, since removing the symptom without finding the door it came through means it comes back. 5. Cover the SEO recovery side specifically, since that's the part a pure malware cleanup skips: requesting removal of the spam URLs in Search Console, monitoring for re-indexing, and roughly how long recovery of rankings for the legitimate pages typically takes after cleanup.