You open the site while logged in and everything appears normal. A customer coming from Google is sent to an advert, fake update or unrelated shop. Selective redirects are a common way to keep an infection hidden from the person managing the website.
Treat the report as credible until evidence proves otherwise. Do not repeatedly visit the destination on an everyday computer, and do not begin deleting files before preserving the conditions that trigger it.
For active redirects, use our WordPress redirect malware removal service to define assessment, cleanup and closure tests. This guide describes a symptom; it does not identify the cause from the title alone.
Record the visitor’s exact path
Ask for the original page URL, approximate time, device, browser and whether the visitor arrived from search, social media or a direct link. A screenshot is useful; the malicious destination URL is useful only when handled as unsafe evidence.
Do not ask the customer to reproduce the redirect again. One clear report is enough to start controlled testing.
Note whether the redirect affected a first visit and disappeared on refresh. Malware often sets a cookie or browser-storage marker to avoid showing itself twice.
Reproduce from an isolated environment
Use a disposable browser profile or analysis environment with no saved WordPress session. Do not sign in to email, banking or the WordPress dashboard from that profile.
Test a small matrix:
- direct visit and search-result referrer;
- mobile and desktop user agent;
- first visit with clean cookies;
- affected page and homepage;
- CDN enabled and origin path where authorised.
Stop if the destination attempts a download. Preserve the request details without opening the file.
Inspect the redirect chain
Preserve a bounded GET response, including headers and body, before following any redirect. A HEAD-only check does not collect that body:
curl -q --silent --show-error --max-time 15 --max-filesize 1048576 --dump-header headers.txt --output response.txt https://example.com/Run this from a clean analysis environment only for an authorised URL. The first option ignores a local curl configuration; there is no redirect-following flag. Review headers and saved text without opening it as a web page. This records one HTTP response, not later JavaScript navigation. The curl manual documents HEAD and response-output options.
In a browser network log, identify the response or script that changes location. A 301 or 302 points toward server, PHP or CDN behaviour; a page that loads first and then leaves can involve JavaScript, an iframe or a browser notification.
Original local comparison: method and visitor condition
In a benign HTTP exercise on 25 October 2026, we recorded six requests to a server bound only to the local computer. Four illustrate why one apparently normal response is an incomplete control:
Same fixture URL: HEAD → 200; GET → 302
Visitor fixture: direct control GET → 200
Visitor fixture: invented example condition GET → 302
Redirect destinations followed: 0The condition was an invented training header, not a real administrator session, mobile device, search referrer or Google request. The fixture intentionally produced different responses. This demonstrates a comparison method; it does not reproduce an infection or establish why a real website redirects. No JavaScript or downloaded file was executed.
For an actual incident, preserve a control and an affected observation for the same public URL. Record method, collection time, session state, entry route, device class, first response status, response source and whether any later navigation occurred. Change one condition at a time and keep the observations paired. A hash difference alone can come from legitimate dynamic content; compare the relevant redirect or script evidence.
Capture the first response before following the chain. Record a suspect destination as evidence rather than opening it. A clean HTTP response also leaves JavaScript-triggered behaviour untested. Ask the analyst to state which layer was observed and which remains unresolved.
A changed user-agent label does not authenticate a Google crawler. Google’s request-verification documentation describes verification using the requesting IP. Keep a synthetic test distinct from verified access-log evidence. For unexpected URLs in Search, the spam pages without WordPress entries guide separates the current response from indexed history.
Public HTTP observation: four controlled requests
On 24 October 2026 at 22:40 UTC, we collected four GET responses from the English version of this guide: direct desktop-style headers, the same with a synthetic search referrer, mobile-style headers and a repeated mobile-style request without cookies. All four returned HTTP 200, no Location header and identical response bodies at collection time.
This is a dated observation of our editorial URL, not an infected client site. The labels describe request headers, not physical devices or a real search visit. We did not test an administrator session, execute JavaScript or verify a Google crawler. The result covers the initial HTTP response only; it does not prove the absence of a browser-level redirect or infection elsewhere.
Compare public and administrator HTML
Save the initial HTML response from a clean visitor and compare it with the logged-in view. Search for unfamiliar script domains, encoded blocks, injected iframes and scripts placed before the closing body tag.
Do not paste suspected code into an online decoder. It may contain site paths, credentials or an active payload. Work in an offline copy.
If the HTML is clean but the browser still redirects, inspect external JavaScript responses, service workers and cached CDN content.
Check common WordPress and hosting layers
Review recently modified files, active and must-use plugins, the current theme, wp-config.php, root index.php and .htaccess. Inspect the database for injected scripts in posts, widgets and options.
Also check:
- unexpected administrators and application passwords;
- WordPress cron and server cron;
- hosting-panel redirects;
- DNS records and Cloudflare rules;
- neighbouring sites under the same account.
Do not assume the first suspicious file is the only persistence point.
Contain without destroying evidence
If visitors face an active scam or drive-by download, place the site behind a controlled maintenance response or restrict public access while keeping logs and files intact. Preserve a filesystem and database copy with timestamps.
Resetting every timestamp through a bulk file replacement makes later investigation harder. Likewise, restoring an old backup before identifying the entry route can reintroduce vulnerable code or erase evidence.
Coordinate with the host if the account contains several sites or if suspension is likely.
Verify the cleanup against the original trigger
After removing confirmed malicious code and closing the entry route, repeat the same referrer, device and clean-cookie tests. Check public HTML, external requests, users, scheduled tasks and file changes.
Purge infected CDN pages only after the origin is clean. Monitor redirects and file integrity for recurrence.
When to request urgent malware cleanup
Request urgent help when the redirect is selective, downloads a file, crosses several sites or returns after removal. Send public URLs, timestamps and screenshots through the enquiry form—never passwords or malicious attachments.
A responsible cleanup should preserve evidence, identify persistence, remove the payload, close the route and prove the original visitor condition no longer triggers.
Prepare the assessment and closure test
Send the public URL, device/browser, approximate time, entry route and first or repeat visit. Provide the destination as text and a redacted screenshot if available. Request a redirect assessment without passwords or suspected attachments.
Ask the proposal to identify affected layers, recovery copy, intended intervention, repeatable trigger tests and follow-up owner. Compare affected visits with direct and administrator controls. The assessment process separates diagnosis from approved changes.