Unexpected WordPress redirects can send visitors to another site while the administrator sees a normal page. We assess the reported journey, locate the responsible layer and define cleanup when malicious code or access is confirmed. A redirect alone does not establish whether the source is WordPress, a third-party tag, hosting rules or a cached response.
Send the affected public URL and what the visitor saw to request a redirect malware assessment. Initial assessment does not require passwords. The scope and quote are agreed before intervention; see how the cleanup process works.
Which redirect behaviour are you seeing?
- Visitors redirect but the administrator does not: compare the logged-out journey, source of arrival and session conditions.
- Mobile visitors reach gambling or adult pages: record the device, first visit and affected page without asking customers to repeat it.
- Suspicious .htaccess rules redirect search visitors: review conditions against legitimate routing before replacing configuration.
These guides help describe the incident. They do not prove that one named file is the cause.
What the assessment and cleanup cover
The agreed scope follows the evidence: response and script chain, affected pages, source systems, changed files or database content, external tags, server/CDN rules and access that could restore the payload. Where several sites share an account, hosting cooperation may be needed to define the boundary.
- Before changes: preserve relevant evidence and a recovery route.
- Diagnosis: identify the redirect source and confirmed persistence or entry points.
- Intervention: remove confirmed malicious changes and address the evidenced access or component within the approved scope.
- Verification: repeat the triggering journey and agreed control visits.
- Handover: record findings, changes, tests, remaining dependencies and follow-up responsibilities.
For wider compromise, see the WordPress malware cleanup service. Access changes and work on third-party accounts must be explicitly scoped.
What to send before requesting access
Provide the legitimate page URL, approximate time and time zone, device and browser, entry route, first or repeat visit, destination domain as text and recent changes you know about. A screenshot can help. Do not send passwords, session cookies, customer records or suspected files through the public enquiry.
A missing reproduction on the owner’s device does not invalidate a visitor report. We use those conditions to choose controlled tests rather than asking the customer to follow an unsafe destination again.
How the result is verified
The test record should distinguish affected visits from controls: mobile and desktop, search and direct arrival, first and repeated sessions, public page and relevant origin/cache behaviour. Record what changed and any condition that could not be tested.
After the source is corrected, refresh affected cached responses and recheck them. A clean scan or one normal administrator visit is not a complete closure test. Reinfection requires investigation of persistence and access, not repeated deletion of the same visible script.
Search warnings and follow-up
If Google flags deceptive content, check third-party resources as well as the site. A security review follows removal; its outcome and timing are controlled by Google. See Google’s guidance on deceptive content.
Keep a current recovery copy and agreed monitoring responsibilities. The WordPress security handbook treats protection as ongoing risk reduction. No cleanup can promise permanent immunity.
Request a scoped assessment
Ask Jordi to assess the redirect incident with the visible symptom and public URL. The next step is a defined scope, not an automatic full rebuild. Content and references reviewed 14 October 2026.
EVIDENCE-LED WORDPRESS RECOVERY
Trace malicious redirects across every persistence layer
In WordPress malware cleanup and reinfection prevention, the visible symptom may be far from the cause. The objective is to remove malicious persistence, close evidenced entry points and verify the behaviour that triggered the alert. 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.