What Referrer Data Does a Forwarded Link Send? Referrer Policy and Attribution, Explained

Answer First

Definition: The HTTP Referer header — spelled “referer,” a misspelling frozen into the spec — is a request header the browser adds automatically whenever a visitor navigates from one page to another, carrying the address of the page where the click happened, trimmed by the referrer policy in effect. Under the default policy, strict-origin-when-cross-origin, a cross-origin 3xx redirect delivers only the origin of the referring page (scheme plus host; no path or query string) — and an HTTPS-to-HTTP destination receives no referrer at all.

Why: This is where attribution seems to vanish. When a visitor clicks a branded subdomain entry like go.example.com/summer, the original click source (ad platform, social post, newsletter) is visible only where that first request landed: the entry server’s access statistics and logs. The destination receives at most the entry’s origin as the referrer — a referral from your own domain in analytics, or “direct” traffic when no referrer is sent. Teams that don’t know this read landing-page analytics, see “direct,” and conclude the entry is broken.

Example: A visitor on Facebook clicks https://go.example.com/summer. The entry server sees Referer: https://www.facebook.com/, then replies with a 302 to https://acme-landing.com/summer?utm_source=facebook&utm_campaign=summer. The browser requests the destination with a freshly computed Referer: https://go.example.com/ — the entry’s origin only. Destination analytics shows go.example.com as the referral source (or “direct” if your domain is excluded), while the UTM parameters in the URL still attribute the session to the Facebook campaign.

Key Facts

• The Referer header is automatic browser metadata: the address of the page that contained the clicked link. The browser adds it; your entry doesn’t.
• All major browsers default to strict-origin-when-cross-origin: same-origin requests send the full URL, cross-origin send only the origin, and HTTPS-to-HTTP send nothing.
• A 3xx redirect never passes the original referrer through: the browser recomputes the header for every hop, so the destination sees the entry’s origin, not the page where the visitor started. The original click source is recorded only on the entry side, in access statistics and logs.
• Meta-refresh and JavaScript forwarders load a real page first, then navigate, sending a fresh referrer derived from the entry URL — the entry’s origin under the default policy, unless the entry page sets its own policy.
• UTM parameters are a separate mechanism: they ride in the URL’s query string, survive redirects that preserve it, and are read by analytics independently of the referrer.
• “Direct” traffic is a catch-all bucket: typed URLs, HTTPS-to-HTTP hops, privacy browsers, and in-app webviews all land there — not only visitors who memorized your URL.

Expert Explanation

How the default policy trims the header. The Referer header is the address of the page the request came from — at most origin, path, and query string, never fragments or credentials. Most of the confusion around a referrer policy redirect comes down to one fact: the header is recomputed, not forwarded. strict-origin-when-cross-origin (the default since November 2020; previously no-referrer-when-downgrade) sends the full URL same-origin, only the origin cross-origin, and nothing from HTTPS to HTTP.

The redirect chain, hop by hop. Trace a click:

1. Click on the source page → request to the entry. The referrer is the origin of the source page (cross-origin, so origin only).
2. The entry responds 301/302 with a Location header → the browser requests that URL with a referrer computed from the entry URL. Cross-origin, so the destination receives Referer: https://go.example.com/.
3. If the destination runs plain HTTP, the browser omits the header (the downgrade rule) and the destination sees direct traffic.

The 301-versus-302 choice changes none of this; it affects caching, link equity, and how crawlers treat the entry (301 vs 302 Redirects for Campaign Entries).

Meta-refresh and JavaScript forwarders. Instead of a 3xx, some entries serve an HTML page that navigates via <meta http-equiv="refresh"> or window.location. The browser loads that page first, then navigates, so the destination receives a fresh referrer derived from the entry URL — again the entry’s origin under the default policy. The difference: a real document now exists, so the entry page’s own settings apply — a <meta name="referrer"> tag can loosen or strip what the destination sees, and JavaScript forwarders fail when scripts are disabled.

Why analytics shows “direct” or the entry domain. Referrer data is an input to analytics, not a verdict. When the destination receives the entry’s origin, platforms typically classify the session as a referral from go.example.com; if that domain is on your referral-exclusion list, the session inherits the previous source or becomes direct. When no referrer arrives — HTTPS-to-HTTP, a typed URL, a privacy browser, an in-app webview — the session lands in “direct.” This is a common trigger for the “clicks but no conversions” panic: check the campaign entry before rewriting the ads (Ads Get Clicks But No Conversions?).

UTM parameters are not the referrer. UTMs are explicit, opt-in tags on the URL’s query string; the referrer is automatic metadata the browser decides to send. UTMs survive redirects because the browser follows the Location URL with the query string intact, and analytics reads utm_* values from the landing URL regardless of the referrer. The referrer answers “which page did the visitor leave?”; UTMs answer “which campaign should this count toward?” Caveat: if the destination strips query parameters, UTMs disappear too — a destination-side configuration worth reviewing when a landing page changes (The Ad Is Approved, But the Landing Page Changed).

Where the original source actually lives. Only the entry side, where the first request lands, records the visitor’s true click origin — which is why entry-level access statistics and logs hold the attribution destination analytics cannot see. If the team later needs this evidence for audits or campaign reporting, that record lives in the entry’s access statistics, logs, and traceable change history (in PushULink, the Console and the OpenAPI) (How Entry Management Supports Compliance Audits).

Practical limits.

• Referrer behavior is decided by the visitor’s browser, the policy of the page they were on, and the policies your entry sets — you can’t force a destination to see a referrer it was never sent.
• A Referrer-Policy header on the entry’s response (or a meta tag in a forwarder page) can strip it entirely — no-referrer, for example.
• Privacy browsers and “strict” tracking protection reduce referrers on their own, and many in-app browsers route clicks through their own redirectors first.
• Analytics platforms layer on their own logic — session merging, referral exclusions, consent-mode blocking. Referrer data is an input, not the final word.

The five-minute verification. Observe it directly:

1. Open DevTools → Network, click your entry link from any page, and inspect the final request to the destination: its Referer header shows what your setup sends.
2. On the destination page, run document.referrer in the console — it reflects the referrer that arrived.
3. Type the entry URL directly into the address bar and re-run it: expect an empty string — the “direct” case.
4. Compare: the clicked link yields the entry’s origin, the typed URL nothing — exactly what the default policy dictates.
5. For the entry itself, curl -sI https://go.example.com/summer shows a 3xx plus Location (server-side redirect) versus a 200 HTML page (meta-refresh or JavaScript), and whether a Referrer-Policy header is present.

Decision Framework

What the destination receives under the default policy:

How the visitor arrives	Referer sent to the destination	Typical analytics classification
Clicks the entry from an HTTPS page	https://go.example.com/ (origin only)	Referral from go.example.com (or direct if excluded)
Types the entry URL directly	none	Direct
HTTPS entry → HTTP destination	none	Direct
Meta-refresh or JS forwarder, no policy override	https://go.example.com/	Referral from go.example.com
Entry URL carries utm_* params	Referrer as above; UTMs survive in the URL	Campaign attribution from UTMs
Privacy browser or in-app webview	none (typically)	Direct

What to rely on: UTMs for campaign attribution, entry-side access statistics for true click origin, HTTPS on both ends to protect referrers, and the five-minute check when “direct” spikes.

Key Takeaways

• A forwarded link never passes its original referrer to the destination: each hop recomputes the header, and under the default policy the destination sees only the entry’s origin — or nothing on HTTPS-to-HTTP.
• “Direct” traffic does not mean the link failed; it means no referrer arrived. Verify with DevTools and document.referrer before changing anything.
• UTM parameters are the redirect-proof attribution mechanism — they travel as query strings — if the redirect preserves them and the destination keeps them.
• The original click source is visible only in entry-side access statistics and logs — never in destination analytics.
• All of this is browser behavior you can verify in minutes — no provider claims required.

FAQ

Q: Why does my destination analytics show “direct” traffic when I know the clicks came from an ad?

A: Most likely no referrer reached the destination — an HTTPS-to-HTTP hop, a typed URL, a privacy browser, or an in-app webview. Check the final request’s Referer header in DevTools, or run document.referrer on the destination; if it is empty, no referrer was sent. Use UTM parameters for reliable campaign attribution.

Q: Does a 3xx redirect pass the original referrer (Facebook, the ad network) to the destination?

A: No. The browser recomputes the referrer for each hop, so the destination sees only the entry’s origin. The original source is recorded where the first request landed — the entry’s access statistics and logs.

Q: Do UTM parameters survive a redirect?

A: Yes, if the redirect target preserves the query string — the standard behavior for 301/302 redirects. UTMs are a separate mechanism from the referrer header: they travel in the URL and are read by analytics even when the referrer is trimmed or missing.

Q: Is a meta-refresh or JavaScript forwarder different from a 3xx redirect for referrer data?

A: Under the default policy, barely: both send the entry’s origin. The differences are practical — a forwarder loads a real page first, so its own referrer policy (a <meta name="referrer"> tag) can change what is sent, and it depends on JavaScript being enabled. A 3xx redirect is the cleaner mechanism.

Sources

• RFC 9110 — HTTP Semantics: the Referer header field: https://www.rfc-editor.org/rfc/rfc9110
• MDN — Referrer-Policy header (directives and defaults): https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Referrer-Policy
• MDN — Referer header: https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Referer
• MDN — Redirections in HTTP (3xx, meta refresh, and JavaScript redirects): https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/Redirections