WordPress Redirecting to Another Website? A Diagnosis Guide

Security guidance · Checked 31 October 2026

In this guide

1. First, distinguish normal routing from a suspicious redirect
2. Build a small reproduction record
3. Trace the layer that makes the decision
4. Preserve the original before cleanup
5. Remove the cause and review the access path
6. Retest the original scenario
7. When to request specialist help
8. Frequently asked questions

Your website opens normally for you, but a customer says it sends them elsewhere. That inconsistency can make a redirect problem frustrating to investigate. It does not mean the customer imagined it, and it does not identify the cause by itself.

Redirects can come from legitimate configuration, a browser extension, a third-party script or a website compromise. A careful diagnosis records when the behaviour occurs and traces the responsible layer before changing production settings.

First, distinguish normal routing from a suspicious redirect

A move from HTTP to HTTPS, a deliberate old-page redirect or a normal payment-provider handoff may be expected. An unexplained jump to an unrelated shop, a fake update page or a suspicious download is different.

Record the starting URL and the destination without following harmful prompts. Note whether you arrived through search, typed the address directly or clicked a particular button. Do not enter credentials or download a file at the unexpected destination.

If the problem is visible only on one device, include that fact. It is a clue to investigate, not a reason to declare either the device or the website clean.

Build a small reproduction record

Ask an authorised maintainer to compare a few controlled conditions: logged in versus logged out, a fresh browser profile, mobile versus desktop and a direct visit versus the reported referral path. Keep timestamps so hosting or CDN logs can be correlated.

Avoid repeatedly sending employees or customers into a potentially harmful page. The maintainer can use controlled tools and appropriate isolation where necessary.

Google’s Security Issues documentation notes that harmful behaviour can depend on browsing context. A failure to reproduce one visitor’s warning does not resolve the underlying report.

Trace the layer that makes the decision

The following is an investigation map, not a claim that every redirect comes from malware:

Start with evidence from the reported request. Editing every layer at once makes it harder to identify what fixed the issue and what might still be present.

Preserve the original before cleanup

Capture the relevant file, setting or database entry before removing it, where safe and authorised. Keep that material private; it may contain sensitive information or active code.

Do not run a global search-and-replace for an unfamiliar domain across the database without checking how it is stored and used. Serialized data, legitimate integration settings and historical content can all be damaged by an indiscriminate replacement.

Likewise, deleting the entire .htaccess file can break legitimate routing. Preserve the original and compare the suspicious rule with the hosting configuration.

Remove the cause and review the access path

Once an unauthorised change is confirmed, cleanup should address the affected component and the way it could be altered again. That may mean restoring a trusted file, correcting a setting, updating a vulnerable component or securing an account.

If the entry point remains uncertain, state that in the handover. A redirect that stops appearing is a useful result, but it is not proof that every persistence mechanism was found. See the recurring-infection guide when the same problem returns.

Avoid installing several overlapping cleanup plugins as a substitute for understanding the affected scope. More software can add noise without resolving the responsible code or access issue.

Retest the original scenario

Repeat the conditions recorded at the start, including the affected page and referral path where appropriate. Check important navigation, forms and any checkout flows within the agreed scope.

Review caching only after the underlying cause has been addressed. Clearing a cache can change what you observe; it should not be mistaken for removing a malicious source that can generate the redirect again.

Keep the before-and-after observations factual: the request tested, the expected destination and the result. Avoid promising permanent protection or a specific search-engine review time.

When to request specialist help

Escalate if visitors reach harmful pages, you cannot locate the responsible layer, the host has suspended access or the redirect returns after cleanup. Send the public URL, symptoms and non-sensitive warning text.

NithuDev provides malicious redirect investigation within WordPress recovery services. Scope and pricing are agreed before work; broader domain or server issues may require cooperation with the host or another administrator.

Frequently asked questions

Why does it work normally when I am logged in?

Some behaviour can depend on session or request context. Record the difference and have the maintainer investigate; it does not establish one particular malware type.

Is every unexpected redirect a hacked website?

No. Misconfiguration and device-level issues can produce confusing behaviour too. Confirm the source before making a security conclusion.

Will Google remove its warning as soon as the redirect stops?

Google controls its own assessment and review process. Verify the site is repaired, then follow the relevant Security Issues workflow if a review is required.

Published by NithuDev. Contact Nithu / Suthakaran Nithursan, website developer and security recovery specialist. About Nithu. Featured artwork is an AI-generated illustration for this guide, not a photograph of a client incident or security evidence.