I'm tracking incoming traffic from links shared on X (Twitter). Every link gets wrapped by X into a t.co/... short URL. When that link is clicked and redirects to my server, I'm logging $_SERVER['HTTP_REFERER'] and the User-Agent on the receiving end.

For what appears to be the exact same type of request — same browser, same OS, same general click flow — the Referer header is sometimes present and sometimes completely missing.

Example 1 — no referrer: User-Agent: Mozilla/5.0 (Linux; Android 10; K) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/151.0.0.0 Mobile Safari/537.36 HTTP_REFERER: (empty)

Example 2 — referrer present: User-Agent: Mozilla/5.0 (Linux; Android 10; K) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/151.0.0.0 Mobile Safari/537.36 HTTP_REFERER: https://t.co/

The same inconsistency shows up on desktop Chrome as well — one click produces no referrer, another (same browser/OS) produces https://t.co/.

What I've already found: t.co's redirect response reportedly varies depending on the request — sometimes it's a plain HTTP redirect, other times it returns a 200 OK with an HTML page that performs the redirect itself (per this write-up). That would explain the referrer difference in principle — a plain redirect just forwards whatever referrer policy the original page already had, while an HTML-based redirect makes t.co itself the new referring page. However, that write-up frames the variation as bot-vs-browser detection, and all of my test requests came from a genuine browser (not a crawler/bot), so that specific explanation doesn't seem to account for the inconsistency I'm seeing within real-browser requests.

Question: Has anyone else observed this, and is there a known/documented reason why t.co would choose a different redirect method for two requests that otherwise look identical from the client side (same UA, same device, same flow)? Is there any way to detect in advance (or after the fact) which redirect method was used, so this could be accounted for rather than treated as random?