How to Safely Trace a Referrer-Based WordPress Redirect

The homepage looks normal, and typing a URL directly opens the expected page. But after someone clicks a Google result or a social link, the browser jumps to a pharmacy, casino, download, or phishing site. That difference is not proof that the browser is wrong: the request conditions may be activating a redirect that a direct visit never triggers.

Short answer: do not reproduce the problem by exposing visitors to the dangerous destination. Preserve evidence, create a private staging copy that cannot receive public traffic, and compare the same URL with a controlled Referer header and without one. Record the HTTP status and Location header without automatically opening the destination. Then trace the rule through the CDN, web server, WordPress, database, and JavaScript until you identify both the source and any persistence mechanism.

Why would a redirect depend on a referrer?

The Referer header tells a server which page initiated a request. A legitimate campaign or membership flow may use that context, but malicious code can also branch on referrer, user agent, device, cookies, or a combination of conditions to hide a redirect from the site owner. Google notes that redirects on hacked sites may be shown only to selected visitors—for example, based on referrer, user agent, or device—so an owner who types the URL directly may not see the same behavior (Google Search spam policies).

A single test in an administrator’s browser is therefore not enough to declare a site clean. Cache, login state, geolocation, plugins, the CDN, and JavaScript can change the result. At the same time, an unusual redirect is not automatically evidence of a hack: an approved marketing plugin, short link, or business rule may be responsible. Establish who owns the behavior and why it exists instead of guessing from the visible destination.

Make the test safe before reproducing the symptom

1. Do not use your primary work computer or a logged-in administrator session. Record the starting URL, time, network, browser, and the visitor’s report. Never submit credentials or payment details to the destination.
2. Do not click the search result again in public. Save the URL as text. Disable automatic redirect following in your first request; do not add -L to curl.
3. Contact the host or security team if the site handles transactions or sensitive information. Ask for a snapshot and logs before cleanup, an isolation rule, and approval for testing. If the destination is dangerous, have the provider help contain traffic without destroying evidence.
4. Use a private staging site or isolated local copy. It must not send email, accept payments, or contact production integrations. Restrict access and make sure the DNS or host configuration cannot route ordinary visitors to the copy.
5. Preserve evidence securely. Record file hashes, paths, modification times, response codes, Location, CDN request IDs, and relevant log excerpts. Do not post logs containing tokens, cookies, customer data, or full IP addresses in a public forum.

If the final destination is an unfamiliar domain, you do not need to open it to prove a redirect exists. A 3xx status and its Location value from the first response are useful evidence. For safety, use a destination you control in staging—not the suspected attacker’s address.

Build a controlled request matrix

Choose one page and one test window, then change one variable at a time. On staging, compare a request with no referrer, one with a referrer from a domain you control, and one other safe organizational referrer. Use a pattern like this with your own staging host:

curl --max-redirs 0 -sS -D - -o /dev/null \
  -H 'Referer: https://staging.example.test/source/' \
  'https://staging.example.test/landing-page/'

This inspects response headers without following a redirect. Run the same request without -H as a control. Do not replace the example with a visitor’s URL or send the test to the suspected destination. If a browser is necessary, use a temporary profile with no logged-in session, keep only essential extensions enabled, open DevTools Network with “Preserve log”, and stop navigation if the destination is unknown.

Keep a table with the URL tested, whether a Referer was present, device/browser class, status, a safely redacted Location, and the related log source. Change only one condition in each comparison: for example, trailing slash, query string, anonymous cookie, desktop versus mobile, or a cache hit versus a cache bypass that your team approved. Do not impersonate Google’s crawler or test someone else’s domain. If the behavior appears search-specific, use Search Console’s report and samples and coordinate safe testing with the host.

Keep requests close enough in time that a deployment or cache change does not distort the comparison. Repeat each pair at least twice on the same copy. If results differ without an obvious variable, preserve the logs and check the CDN/cache layer before adding more test cases.

Find the layer that is producing the response

1. Separate an HTTP redirect from a browser-side change

Inspect the first response for 301, 302, 303, 307, or 308 and a Location header. If it is absent but the browser still navigates, inspect HTML, JavaScript, service workers, tag managers, and third-party scripts. Do not immediately rewrite .htaccess: the cause may be a CDN, Nginx rule, plugin, theme, database value, or frontend code.

Compare edge/CDN logs with origin access logs for the same request ID and time. If the edge sends the redirect, inspect its Worker, page rule, cache, or transformation configuration. If the origin returns it, identify the route and WordPress component that handled the request. Save copies of .htaccess, virtual-host configuration, and PHP configuration before editing them.

2. Inspect WordPress code without mass deletion

Review active plugins, must-use plugins, the active theme, drop-ins such as advanced-cache.php, and recent changes. Search for redirect calls and request conditions involving template_redirect, wp_redirect, wp_safe_redirect, HTTP_REFERER, HTTP_USER_AGENT, $_SERVER, or the destination domain. A text search is not proof by itself: strings may be encoded, assembled from the database, or generated by another file.

Run wp core verify-checksums to compare core files for the installed version with official checksums. This does not verify every plugin, theme, upload, or database record. For plugins distributed through WordPress.org, wp plugin verify-checksums --all can identify changed plugin files; premium and custom plugins may not have public checksums. Save the output and confirm the version before replacing files. See the WP-CLI core checksum command and plugin checksum command.

For a local WordPress destination, developers should generally use wp_safe_redirect() and then stop execution with exit; WordPress validates the destination host against allowed hosts (wp_safe_redirect() reference and wp_validate_redirect()). This is repair guidance, not permission to paste unfamiliar code into production. If the business must redirect to an external host, use a reviewed allowlist and validated input; never trust a request’s Referer or redirect parameter.

3. Review data, scheduled tasks, accounts, and access

On an isolated copy, inspect options, widgets, custom HTML, page content, scheduled cron events, administrator accounts, application passwords, sessions, and integration settings. Look for unfamiliar domains, newly changed redirects, and tasks that invoke unapproved code. Record who can access the host, CDN, DNS, registrar, and Search Console. Removing one plugin or file without finding the entry point can let an account, scheduled task, or other persistence mechanism recreate the rule.

Do not run destructive database searches against serialized production data. Take a database backup, use trusted read-only tools first, and ask for help if you are not comfortable examining serialized options. Any production database change should have a reversible change plan and a test.

Fix the cause, then verify from more than one angle

After preserving evidence, close the entry point and persistence. Revoke unfamiliar accounts, tokens, application passwords, sessions, and third-party access only after confirming that a legitimate owner can still sign in. Update WordPress, plugins, themes, the server runtime, and integrations from official sources; replace unsupported components. Restore files and database records from a known-clean backup or remove changes through a complete review. Do not merely delete the Location line while the code that injects it is still running.

After fixing staging, repeat the same matrix. Confirm that the response no longer changes just because of the referrer, that no header points to an unfamiliar host, and that approved traffic flows still work. Purge cache only after removing the malicious rule; clearing cache first may hide the symptom without removing the cause.

On production, test a safe internal link in a private browser with the team’s approval. Monitor edge and origin logs for recurrence, review sample URLs in Search Console, and look for hidden spam pages. Google recommends monitoring logs; unfamiliar URL parameters or traffic spikes around redirect URLs can be clues (malware-prevention guidance for site owners). If a security notification exists, request a review only after the underlying issues have been fixed. For the broader incident, see our guide to a hacked WordPress site and malware warning signs.

Testing mistakes that create risk or hide the real cause

• Testing only from a logged-in administrator browser and declaring the issue resolved because the page looks normal.
• Letting curl -L or a browser open an unfamiliar destination; the first response is enough to record the redirect.
• Deleting .htaccess, a plugin, or a suspicious file before saving evidence and verifying ownership.
• Treating Google or social media as the only possible referrer. An attacker may choose another condition, while a cache or proxy can alter the request.
• Installing a scanner and trusting a “clean” result; scanners may not see database code, accounts, edge rules, or persistence.
• Asking Search Console to review the site before the cause is fixed, or submitting repeated requests as a debugging method.
• Pasting Apache directives onto Nginx or another server without confirming how the host runs PHP.

Incident closure checklist

Before restoring full traffic, assign an owner and evidence to each item: the initial snapshot is saved; the CDN, host, DNS, and plugins reviewed are recorded; the redirect trigger is understood; malicious rules are removed or components replaced; the original weakness is fixed; at-risk credentials and sessions are revoked; cache is refreshed safely; sample URLs and related pages pass controlled tests; log monitoring and escalation ownership are documented. If any condition remains unclear, involve the host or a security professional before reopening a risky page.

Do I need to send a Google referrer to prove the redirect? No, not on the production site. Google documents referrer-dependent redirects, but opening an unfamiliar destination is risky. Use an isolated copy, official report samples, and coordination with the provider.

Does a Referer header alone prove malware? No. It is only one test variable. Correlate it with logs, code, data, and an unapproved configuration change.

Can I remove every WordPress redirect? No. Business and login redirects may be legitimate. Identify their owner and purpose, preserve the original configuration, and change only a rule proven unsafe or unauthorized.

When should I escalate? Escalate immediately if visitors encounter phishing, redirects affect login or payments, owner access is lost, data theft is suspected, or you cannot keep the test environment isolated.

If a suspicious redirect affects visitors or transactions, do not guess at server rules. Request WordPress emergency recovery help to contain risk, preserve evidence, and map the source before production changes.