Malicious redirects are usually conditional — they fire only on mobile, only from search results, or once per visitor — which is why the owner often cannot reproduce them from their own desktop. Finding the injection means knowing every layer it can hide in.
Step 1 — Reproduce and record the conditions
Note the device, browser, country and referrer that trigger the redirect, and where it sends you. Test as a search visitor and on mobile, not just by typing the URL directly. These conditions both help locate the payload and are the only way to prove later that it is gone.
Step 2 — Search every hiding place
- Database: check
wp_optionsfor tamperedsiteurlandhome, and search the tables for injected<script>or external domains. - Theme files:
header.php,footer.phpandfunctions.phpare common injection points. - Server rules:
.htaccessoften carries conditional redirect rules based on user-agent or referrer. - mu-plugins and uploads: a dropped PHP file in
/wp-content/mu-pluginsloads automatically and hides from the plugin list. - Scheduled tasks: a cron entry that re-injects the code after cleanup.
Is your website affected right now?
Send the URL and the symptom you can see. Jordi Ensenyat reviews the case personally and defines the scope and quote before anything is changed. This form never asks for passwords.
Step 3 — Why one edit is not enough
The visible redirect is often the last stage of the payload. If a backdoor remains or the stolen credential is still valid, the redirect returns. Removal has to be paired with closing the entry point — the vulnerable component or the compromised account — and rotating credentials.
Step 4 — Verify under the original trigger
Re-test using the exact device, referrer and network that reproduced it, with caches and CDN purged. A redirect can persist in a cached response after the source is clean, so clearing every cache layer is part of confirming the fix.
When to escalate
If the redirect keeps returning, spans several sites, or comes with a search-engine warning, treat it as a full compromise rather than a single bad file. Send the conditions that reproduce it and the destination and the case can be assessed without credentials.
EVIDENCE-LED WORDPRESS RECOVERY
Trace malicious redirects across every persistence layer
Redirect malware may appear only for mobile visitors, search traffic or first-time sessions. The payload can live in a plugin, theme, database option, server rule, injected script or scheduled task, so a single clean file scan is not enough.
What we verify
- Redirect behaviour by device, referrer, session and affected URL
- Modified PHP and JavaScript, database injections and rogue plugins
- Web-server rules, scheduled tasks and external script dependencies
- Clean requests after cache purge plus follow-up monitoring signals
What a verified outcome means
Identified redirect code and persistence are removed, compromised access is addressed and the behaviour is retested under the conditions that originally triggered it.
BEFORE THE ASSESSMENT
Common questions about this WordPress incident
Why does the redirect happen only on mobile or from Google?+
Attackers often condition redirects by device, referrer, cookie or visit count to avoid detection by the site owner.
Will replacing .htaccess remove the infection?+
Only if that file is the sole cause. Redirects can also persist in PHP, JavaScript, the database, cron jobs or external resources.
How do you verify that a redirect is gone?+
The original trigger conditions are retested after cleanup and caches are considered. Logs and external warnings are reviewed where available.