Self-referral and internal referrers
A self-referral happens when your own domain shows up as the referrer for a visit, which usually means a session broke and restarted mid-journey. Common causes include cross-subdomain navigation, redirect chains, and third-party payment or auth hops that return to your site. The fix is to exclude your own domains so internal navigation is not counted as a new source.
What a self-referral is
A self-referral is a visit whose recorded referrer is your own domain. That should not normally happen for a continuous session: navigation within your site is internal, not a new entry. When it does appear, a session has effectively been split, and the second half is logged as if it came from outside.
Left unaddressed, self-referrals pollute your source reports and can credit your own domain instead of the true original source.
- Your own domain appears as the referrer
- Indicates a split or restarted session
- Distorts which source gets credit
Common causes and fixes
Typical causes include navigating between subdomains (for example www and a shop subdomain) when they are not treated as one property, redirect chains that pass through your own URLs, and round-trips to third-party payment, login, or checkout providers that send the user back to your site.
The fix is to configure your own domains and subdomains as internal so they are excluded from the referral report, and to make sure cross-subdomain journeys are handled as one session. MDN's Referer documentation explains the header values involved.
- Cross-subdomain navigation treated as external
- Redirect chains through your own URLs
- Returns from payment, auth, or checkout providers
How it appears in analytics and logs
Seeing your own domain as the referrer means analytics treated an internal navigation as an external entry, usually because a session was interrupted by a subdomain change, redirect, or third-party hop. It is a configuration symptom, not a real traffic source.
Diagnostic use case
Diagnose why your own domain appears as a referrer, identify the misconfiguration behind it, and exclude internal referrers correctly.
What WebmasterID can help detect
WebmasterID treats configured internal domains as internal, so navigation within your own site is not misfiled as a fresh external referral that inflates your source list.
Common mistakes
- Leaving your own domains out of the internal-referrer exclusion list.
- Treating www and apex (or subdomains) as separate properties.
- Crediting a self-referral instead of the true original source.
Privacy and accuracy notes
Self-referrals are a configuration artefact, not visitor data. WebmasterID identifies internal referrers structurally and never re-identifies a visitor to reconstruct a broken session.
Related pages
- Referrer spam and ghost referrals
Referrer spam injects fake referrer domains to lure operators into visiting a promoted site, while ghost referrals never touch your server at all — they are fabricated hits sent straight into measurement endpoints. Both pollute source reports with traffic that is not real. Recognising the pattern and filtering it keeps your data trustworthy without ever visiting the spam domains.
- Direct traffic: what it really means
Direct traffic is the bucket analytics uses when no referrer is available. It includes genuine type-ins and bookmarks, but also a large share of visits whose referrer was stripped — app opens, HTTPS-to-HTTP transitions, shorteners, and privacy settings. Treating 'direct' as a single intent is the classic analytics mistake.
- Website observability
Spot self-referrals and session breaks in raw referral data.
Sources and verification notes
- MDN — Referer headerReferer header semantics relevant to internal navigation.
- MDN — Referrer-Policy
Last reviewed 2026-06-24. Facts are checked against primary/official sources where available; uncertain specifics are marked “Data not yet verified” rather than guessed.