Conditional redirect malware often hides from owners by checking referrer, cookie, device, geography or first visit. Direct navigation and logged-in administrator tests can look normal while search visitors reach scams or unwanted downloads.
Preserve a reproducible redirect chain and contain public harm without repeatedly visiting the destination.
Capture a safe reproduction
Use an isolated browser or controlled HTTP inspection from a clean environment. Record the search result URL, timestamp, user agent, referrer condition, status codes and every redirect location.
Do not log into WordPress in that profile or follow a chain that starts a download. Avoid sharing live malicious links publicly.
Test only enough variations to identify the condition.
Compare first and later visits
Malware may set a cookie after the first redirect so the site owner cannot reproduce it again. Compare a fresh profile with a returning session and record relevant cookie names without publishing their values.
Test direct versus search-referrer requests, mobile versus desktop, and logged-out traffic. One dimension at a time keeps the condition understandable.
Do not clear production visitor cookies or cache globally before preserving evidence.
Identify where the redirect occurs
A 301/302 response can originate at Cloudflare, web server, .htaccess, Nginx/Plesk configuration, PHP or WordPress. A JavaScript/meta refresh appears in page content after a 200 response.
Match response headers, server/CDN logs and page source. Compare the known origin through authorised protected access to distinguish CDN/DNS compromise from WordPress.
Do not assume every redirect is a plugin setting.
Inspect common WordPress persistence points
Review active and must-use plugins, theme bootstrap files, wp-config.php, root index files and executable code in upload/cache directories. Compare maintained components with trusted packages.
Search database options, widgets, posts and injected JavaScript for the redirect domain or obfuscated loader. Work from snapshots and avoid executing decoded payloads on the server.
Modification time alone can be forged or changed by updates.
Review server and account controls
Check .htaccess, Nginx/Apache rules, PHP auto-prepend settings, cron tasks and hosting panel scheduled jobs. Inspect unknown SSH/SFTP users, keys and recent file-manager activity.
Rotate control credentials from a clean device after evidence is preserved. Remove public file-manager or database tools that were not intentionally deployed.
Check sibling sites under the same account.
Examine DNS and CDN changes
Confirm nameservers, A/AAAA/CNAME records, Cloudflare workers/rules, page rules and redirect rules. An attacker with DNS/CDN access can target referrers without touching WordPress.
Review account audit logs and API tokens. Revoke unknown access and require MFA.
Keep origin access restricted so attackers cannot bypass a repaired CDN configuration.
Review Google Search Console users, ownership tokens, manual actions and indexed URLs. Revoke unknown owners only after preserving their identifiers and verification method.
Contain without destroying evidence
Serve a static maintenance response outside WordPress or block the affected route/referrer rule at a trusted layer while copies are taken. Disable checkout or account actions if visitors could expose data.
Do not simply block the malicious destination in JavaScript; the loader and access vector remain.
Notify search/security providers through their official processes only after the site is clean enough for review.
Rebuild and verify conditional paths
Replace WordPress core/plugins/themes from trusted sources, validate custom code and database content, close the entry point and rotate secrets. Restore content only from a date and source that have been assessed.
Test search-referrer, direct, mobile, first-visit and returning paths after cache purge. Monitor redirects and file/account changes.
Request emergency rescue when the redirect is conditional or crosses DNS/CDN and hosting. Share the recorded chain and managed access—never visit logs with personal data, credentials or malware archives publicly.