How User Agent Strings Shape Redirect Decisions
When a server decides to send a visitor somewhere other than the page they requested, it usually starts by asking who is on the other end of the connection. The most common method is the User-Agent header, a short line of text every browser, crawler, app and script volunteers to identify itself. Travel sites, news portals, retailers and campaign landing pages use that declaration to choose between a mobile layout, a desktop version, an app download, a paywall or a localised page. Get the judgement wrong and a paying customer ends up on a dead end, a crawler ends up in a loop, or a visitor reaches a page offering nothing but a click here link.
The header was written in a simpler era, when each browser had a stable and distinctive signature. Today's strings are longer, crowded with compatibility tokens and increasingly frozen by their vendors. Safari on an iPhone presents itself as mobile Safari even inside apps and embedded webviews, Edge appends its own token, and Chrome on Android leaks the handset model. The User-Agent string remains useful, but it is a claim rather than a proof, and every redirect rule built on it carries that weakness.
What a User-Agent String Contains
A request header usually carries a line like this: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/131.0.0.0 Safari/537.36. The first token claims compatibility with the original Netscape engine, the second names the rendering engine, the third names the browser, and the fourth keeps older sites working. Appended tokens carry the operating system and, on mobile, the device model. Crawlers announce themselves plainly, often with a verification address; scripts may say curl/8.4.0.
Server rules are usually matches: contains Android, send to the mobile page; contains Googlebot, serve the full article; contains a tablet keyword, show the tablet layout. Such matches are cheap to write and cheap to maintain, which is why they persist in the redirect logic of a great many sites, even where the vendor's own documentation points towards other signals.
The weakness is that a string can be set to anything. A script can copy a real Chrome header, and some crawlers do exactly that to reach content that would otherwise be gated. Detection vendors respond with deeper parsing, cross-checks against IP ranges and network behaviour, so a redirect decision based on the header alone may be overturned a layer higher up. Australian owners of such rules should treat the header as one signal among several rather than a verdict.
Redirects That Follow the Device
The most visible use of the header is the mobile redirect. When a Sydney commuter opens a link from an email on the train, many publishers would rather send them to a stripped-down page that loads quickly over a mobile connection than to a desktop layout with wide hero images and embedded video. The same request from a Melbourne office desktop gets the full version, and a server can make that split from the tokens alone.
App-based redirects work the same way. Retailers, banks and streaming services will send an iOS device to the App Store listing or pass a deep link into an installed app. Australian names appear here constantly: the shopping apps of Coles and JB Hi-Fi, the banking apps of the big four, the streaming apps of Binge, Stan and Foxtel. Each decision begins with a look at the string, and each needs a working web fallback behind it, because an install prompt is not a destination.
The traps sit at the edges. Corporate proxies in Australian offices rewrite or strip headers, and older security appliances present unusual strings that no rule matches, so visitors land on a default path nobody tested. Set-top boxes and smart televisions, which in many Australian homes sit beside a phone and a laptop, use web views that identify themselves in ways mobile rules may misread as desktop.
Bots, Crawlers and Deliberate Spoofing
Crawler traffic is where redirect logic becomes risky, because search engines index what they are given. Googlebot, Bingbot and the lesser known market crawlers announce themselves, and a responsible publisher uses that announcement to avoid charging a subscription or serving an app-install page to something that will never subscribe. Applebot, which fetches content for the App Store and Apple News surfaces, and the aggregators that republish Australian reporting matter for the same reason.
The reverse trap is cloaking. If a crawler receives different content from a human presenting the same string, the site is serving two audiences different versions of a page, and that is the behaviour search engines are built to punish. A rule that sends Googlebot to a stripped-down version and a human to an interstitial can read as an attempt to game indexing, particularly when the versions differ in substance rather than layout.
Because the string can be forged, security-minded sites have moved away from trusting it. Bot management now combines the header with JavaScript challenges, cookie behaviour, IP reputation and request pacing, and often avoids hard blocks for anything merely unusual. For a Sydney or Brisbane publisher scraping price comparisons and ticket resale, that layered approach is kinder to genuine visitors than a header-based trap.
Redirects That Carry a Tracking Parameter
Not every redirect moves a visitor to different content; some exist to record that a click happened. Campaign emails, search ads and social posts link to a short path that resolves to the real destination with an identifier appended, and the same technique appears on pages that offer nothing but a single clickable line. Background reading on pages that look like errors but are simply passing the click along is useful for anyone who lands on one.
The decision can still depend on the header. One campaign link may send desktop visitors to a landing page, mobile visitors to an app install and known crawlers to the article itself, all from the same short URL with the same tracking parameter. The parameter survives the hop, the referrer may not, and client hints travel with it. Australian marketers need to keep one further point in mind: the Privacy Act 1988 and the Australian Privacy Principles require clear notice about tracking, and a redirect chain that quietly appends identifiers is exactly the kind of collection regulators ask about.
The other reason such redirects draw attention is the blank page itself. A visitor who lands on a page with one link and no explanation has no way to judge whether the site is broken, whether their connection is at fault, or whether the link is safe to follow, and each of those impressions costs trust.
Australian Traffic Conditions and Regional Behaviour
Australia ranks among the most mobile-heavy markets in the world, and a redirect rule that treats mobile as the default case behaves very differently here than in a desktop-dominated market. Commuters in the Sydney and Melbourne central business districts read news on phones during the morning peak, regional shoppers in Western Australia open pages over slower connections, and people outside fixed-line coverage rely on mobile networks from Telstra, Optus or Vodafone. Those conditions reward lightweight redirected pages and punish heavy ones.
The device mix also includes screens that never appear in Western market data. Australian households often keep a television running as a second screen, with web interfaces on smart TVs and Foxtel hardware beside the browser on the laptop, and the strings those devices send rarely match a phone rule. Retail traffic changes shape at predictable local moments too: Boxing Day sales, end-of-financial-year discounting at JB Hi-Fi or Harvey Norman, and the January calendar reset all bring bursts of bot activity that look like a flood of unusual values to a server doing simple counting.
Regional latency deserves attention as well. A visitor in Perth or Hobart opening a link that hops through two redirects pays for every hop, and a chain that looked fine in a Sydney data centre adds visible delay in the west. One well-chosen redirect beats a chain of three.
Feed Readers and Other Non-Browser Agents
Some of the least predictable clients are the ones that never render a page for a person. RSS readers and aggregators pull articles straight from a feed, identify themselves with their own strings, and often follow or ignore the site's redirect rules depending on how the feed was built. A background read on what RSS is and how feeds are assembled explains why a feed can deliver content the website itself would have redirected elsewhere.
Australian publishers rely on feeds more than many sites realise, whether they are daily digests emailed to subscribers, the topic feeds offered by the ABC, or the syndication feeds that carry reporting from the Guardian Australia or the Australian Financial Review to partner outlets. When a redirect sends those agents to a download prompt instead of the article, subscribers receive an invitation to install an app rather than the story they signed up for, and cancellations follow.
The practical fix is to treat feed clients as a named group in the rules, serve them the content humans receive, and keep the app promotion somewhere a feed reader can ignore.
Building Redirect Rules That Hold Up
Start by looking at what actually arrives. Server logs across a week in an Australian month show the real distribution of strings, including clients nobody planned for: in-app browsers, game consoles, monitoring services, and crawlers with names from outside the search ecosystem. Reading that list before writing rules prevents the commonest mistake, a redirect built around an idealised device rather than a real one.
Prefer capability signals over identity claims where the platform allows it. Client hints give a structured, negotiated view of the browser and device, and CSS media queries can handle layout differences without any server-side hop at all. Where a redirect is genuinely needed, keep it to one hop, choose the destination with a fallback that is always safe, and pick the status code honestly: a permanent move for a permanent change, a temporary one for a campaign that will end. Tracking parameters should be preserved deliberately rather than by accident, because the usual complaint about redirect chains is losing the attribution that paid for the traffic.
Test behaviour rather than intent. Australian traffic deserves its own test pass, with a phone on a mobile connection, a desktop on broadband, and at least one genuinely older device, and the results should be checked against the search console to confirm crawlers still reach what they need. Rules reviewed each quarter, with logs open and the fallback destination watched, survive changes in how browsers describe themselves better than any rule written once and left alone.