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.
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
Browser developer tools or a command-line header check can reveal server-side redirects:
curl -sS -I -L --max-redirs 5 https://example.com/Use this only on a site you own or are authorised to examine. A normal curl request may not trigger malware that checks referrer, cookies or JavaScript capability.
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.
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.