Malicious redirects can be 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.
For a store, agree how current activity and recent order records will be preserved before changes or restoration. Separate expected provider handoffs from unexpected destinations, then define the affected journeys and follow-up. Our WooCommerce redirecting to another website guide explains that merchant-specific assessment and the conditions a repair should re-test.
Step 1 — Reproduce and record the conditions
Record the public starting route, visible destination, device, browser, arrival source and approximate time. These conditions help investigate the behaviour and define a known case to re-test. Passing that case documents the observed result; it does not establish that every possible trigger or persistence mechanism has been removed.
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. - Must-use components: review directly loaded PHP files and any loaders they use. Subdirectory files are not automatically loaded merely by being present; legitimate components appear in the separate Must-Use listing.
- 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 can return. 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 the known affected journey and compare the appropriate origin and delivered responses. If an affected response remains cached, invalidate the identified entries at the relevant layer after the source correction. Keep customer sessions and transaction data outside a routine cache-clear action. Record which conditions passed and which remain unexamined.
When to escalate
Recurring redirects, effects across several sites or a search-engine warning warrant a wider investigation. Send the public starting route, destination domain and observed conditions with sensitive values removed. The scope can then distinguish configuration, the redirect source and any evidence requiring broader compromise handling.
EVIDENCE-LED WORDPRESS RECOVERY
Trace malicious redirects across every persistence layer
In WooCommerce and ecommerce incident recovery, the visible symptom may be far from the cause. The objective is to restore revenue-critical journeys while preserving orders, customer data and payment evidence. 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
- The complete journey, not only the screen where the error appears
- External dependencies, logs and evidence before configuration changes
- 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
Close-out documents the cause found, the change applied and the tests performed. The result must be observable and repeatable—not a feeling that it “seems to work”.
BEFORE THE ASSESSMENT
Common questions about this WordPress incident
How do you verify that the problem is genuinely resolved?+
The affected journey is reproduced, its dependencies are checked and post-change evidence is recorded.
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.