Short answer: your site is serving injected code that sends some visitors elsewhere. The redirect is usually conditional — mobile only, search referrers only, or once per visitor — which is why you often cannot reproduce it from your own desktop.
Reproduce and record the trigger first
Before touching anything, note which device, browser, country and referrer reproduce it, and where it sends you. Test as a Google visitor and on mobile. These conditions locate the payload and are the only way to prove afterwards it is gone. Do not repeatedly open the destination from a machine holding important logged-in sessions.
Search every layer — the exact places to look
- Database: check
wp_optionsfor tamperedsiteurlandhome, then search all tables for injected<script>or the attacker’s domain. - Files: over SSH,
grep -RIlE 'eval\s*\(|base64_decode\s*\(|gzinflate\s*\(|str_rot13\s*\(|assert\s*\(|create_function\s*\(' wp-content/surfaces obfuscated code. Checkheader.php,footer.php,functions.phpand any.phpinside/wp-content/uploads. - Server rules:
.htaccessoften carries conditional redirects keyed on user-agent or referrer. - Auto-loaded code: a dropped file in
/wp-content/mu-pluginsloads on every request and hides from the plugin list. - Scheduled tasks: inspect the cron array (
wp cron event list) for a task that re-injects the code.
Why deleting one line is not a cleanup
The visible redirect is usually the last stage. If a backdoor remains, or the credential the attacker used is still valid, it returns within hours. A real cleanup compares files against clean copies (reinstall core and plugins from source), removes persistence, closes the entry point, and rotates every credential — WordPress, database, SFTP and hosting.
Verify under the original trigger
Re-test using the exact device, referrer and network that reproduced it, with every cache and the CDN purged — a redirect can survive in a cached response after the source is clean. Then monitor for several days, because reinfection from a missed backdoor usually returns quietly.
WP REPAIR INCIDENT STANDARD
Reconstruct the incident before fixing it
Conditional spam redirects are an incident, not a single bad line. Reproducing the trigger, preserving evidence and finding persistence are required before cleanup can be verified.
- 1
Record device, referrer, geography, cookies and destination URL that reproduce the redirect.
- 2
Search files, database, server rules, mu-plugins and scheduled tasks.
- 3
Compare installed core, plugin and theme files with clean upstream packages.
- 4
Identify the vulnerable component or credential that allowed the change.
What must be verified
- The original conditional trigger no longer redirects.
- Clean file comparisons and user/cron/database reviews show no persistence.
- Credentials are rotated and the entry point is patched or removed.
Official technical sources
Continue the diagnosis
This guide explains the diagnosis. If the site is affected now, the intervention should preserve a rollback path and verify the real business journey.
See the emergency repair service →