--- title: "How to use device conditions?" description: "Route visitors to different destinations based on device type, platform, browser, brand, and detected actor." canonical: "https://linkbreakers.com/help/article/how-to-use-device-conditions" last-updated: 2026-11-03 --- # How to use device conditions? > Route visitors to different destinations based on device type, platform, browser, brand, and detected actor. ## Short answer This article explains how to use device conditions to route visitors based on the device they use, the software they use, and the actor Linkbreakers detects behind the visit. Device conditions let you send people to different destinations depending on device type, platform, browser, hardware brand, and actor detection, including human visitors, bots, AI agents and browsers driven by automation. Video: [How to make one QR code that opens the App Store on iPhone and Google Play on Android](https://www.youtube.com/watch?v=CjSVFfSPQBM) ## Quick summary - Route mobile, desktop, and tablet visitors to different experiences - Adapt journeys for iOS, Android, Windows, macOS, and Linux - Handle browser-specific paths when Safari, Chrome, Firefox, or Edge matter - Route visitors who opened your link in an in-app browser, such as Instagram's or TikTok's - Personalize flows based on device brand and hardware context - Detect whether the visitor is a human, a bot, an AI agent or an automated browser - Combine device conditions with country, scheduler, and scan/rescan conditions :::try-ai-prompt {"prompt":"Add a device condition that routes mobile users to the app download page and desktop users to the main website.","description":"Try setting up device-based routing with the AI builder."}::: ## Overview Device conditions help you control what happens after a scan based on the technical context of the visit. Instead of sending every visitor to the same destination, you can adapt the journey to the device in their hand, the platform they are running, the browser they opened, or the actor Linkbreakers detects behind the request. This is useful when mobile and desktop users need different landing pages, when browser compatibility matters, or when you want to separate real visitors from automated traffic. ## How device conditions work When a visitor scans your QR code or opens your short link, Linkbreakers evaluates device signals captured during the request. Those signals can include: - Device type - Platform - Browser - Device brand - Actor detection The condition then routes the visitor to the matching branch in your workflow. If no branch matches, the visitor follows your fallback destination. ## Supported condition groups ### Device type Use device type conditions when the experience should differ between: - Mobile - Desktop - Tablet Typical use cases include mobile-first landing pages, larger desktop dashboards, or tablet-optimized product catalogs for in-store displays. ### Device platform Use platform conditions when the operating system matters, such as: - iOS - Android - Windows - macOS - Linux This is useful for app download flows, OS-specific instructions, or support pages that depend on the visitor's environment. ### Device browser Use browser conditions when behavior or compatibility differs across browsers. Each option first picks a kind with a switch, **Browser** or **In-app browser**, then a value of that kind. **Browser**: - Chrome - Safari - Firefox - Edge - Opera - Samsung Internet **In-app browser**, for links opened inside an app: - Any in-app browser - Instagram, Facebook, Messenger, Threads, TikTok, Snapchat, LinkedIn, Pinterest, X, WeChat, LINE or the Google app - Other in-app browser (an Android webview that does not name its app) To send several apps to the same step, add one option per app and connect them all to that step. A single app's option can also take a minimum app version. A visit inside an in-app browser matches only in-app browser options, never a browser: an Instagram in-app browser on an iPhone is Instagram, not Safari. A visit in a regular browser matches only browser options. Options are checked in order and the first match wins. This helps when a specific browser handles camera permissions, embedded flows, or payment pages differently, or when an in-app browser cannot open an Apple Wallet pass, an app store link or a download. See [how to know which app a click came from and route in-app browser visitors](/help/article/how-to-detect-and-route-in-app-browser-visitors). ### Device brand Use brand conditions when the hardware context matters, such as: - Apple - Samsung - Google - Xiaomi Brand-based routing can support device-specific setup steps, troubleshooting guides, or tailored product recommendations. ### Device actor Use actor detection when you need to know what is actually visiting your link: - Human - Bot - Agent - Automated - Unknown Actor detection is one of the most useful parts of device conditions because it helps you separate real audience engagement from automated traffic. ## Setting up device conditions ### Step 1: Open your workflow 1. Log in to your [Linkbreakers dashboard](https://app.linkbreakers.com/) 1. Go to [QR Codes](https://app.linkbreakers.com/workspace/dashboard/links) 1. Create a new QR code or edit an existing one 1. Open the workflow editor ### Step 2: Add a device condition 1. Click between the steps where you want routing to happen 1. Select "Device Condition" 1. Choose the signal you want to evaluate: type, platform, browser, brand, or actor ### Step 3: Configure your branches 1. Add the values you want to match 1. Connect each branch to the right destination 1. Add an `else` fallback for unmatched traffic ### Step 4: Test the flow Test with real devices and browsers whenever possible. Use your analytics to confirm that routing behaves as expected after the workflow is live. ## Common use cases ### Route mobile and desktop visitors differently **Challenge**: A product page that works well on desktop is too heavy for mobile visitors. **Solution**: Send mobile traffic to a lightweight landing page and desktop traffic to a richer comparison page. ### Show the right app-store destination **Challenge**: A single QR code should open the correct download path for iPhone and Android users. **Solution**: Route iOS visitors to the App Store and Android visitors to Google Play, with a fallback to a web page for unsupported platforms. ### Handle browser-specific instructions **Challenge**: Camera permissions, payments, or embedded experiences behave differently across browsers. **Solution**: Send visitors to browser-specific instructions or alternate pages when needed. ### Send bots and AI agents to a different path **Challenge**: Not every request to a tracked link comes from a real person. **Solution**: Use actor detection to separate humans from crawlers, AI agents and automated browsers. ## Actor detection: human, bot, AI agent or automated browser Actor detection helps you understand the intent behind a visit, not just the device details. ### Human A human visit usually represents real audience engagement. This is the traffic you typically want to optimize for conversions, lead capture, content consumption, and customer journeys. ### Bot A bot visit is usually generated by an automated crawler, validator, scanner, or platform service. Examples can include search crawlers, ad platform verifiers, social preview fetchers, and security scanners. Examples often associated with bot traffic include: - Googlebot - Advertising verification bots - Link preview bots - Security scanners ### Agent An agent visit comes from an AI or LLM-driven system that fetches the URL itself, on behalf of a user or as part of model browsing, retrieval, or evaluation, and names itself in its user agent. Examples include the agents of: - ChatGPT and OpenAI (GPTBot, ChatGPT-User, OAI-SearchBot) - Claude (ClaudeBot, Claude-User, Claude-SearchBot) - Gemini - Perplexity - Mistral - Grok These visits may matter for visibility, brand discovery, and AI search presence, but they are not the same as a direct human visit. Treating them separately gives you cleaner analytics and more precise routing. Linkbreakers recognizes agents from what the user agent says, so detection happens instantly and adds no delay for your visitors. An AI agent that operates a browser instead of fetching the page itself is not an Agent: it shows as **Automated** when Linkbreakers recognizes the browser, and as Human otherwise. ### Automated An automated visit comes from a browser driven by software, whoever is behind it: an AI agent operating a browser, a load or QA test, a scraper or a monitor. - **Headless Chrome**, such as the Chrome that Playwright, Puppeteer and many browsing agents run without a window, is recognized from its request on every visit - **A visible browser under automation** sends the same request as a person. When the link collects data at the **Advanced** level, its short page reads whether the browser reports automation. If it does, the visit is recorded as Automated and every later visit from that device takes the **Automated** branch. Its first visit is routed as human To treat AI agents and automated browsers the same way, connect both the **Agent** and the **Automated** options to the same step. Details and limits are in [how Linkbreakers detects AI agents and automated browsers](/help/article/how-linkbreakers-detects-ai-agents-and-automated-browsers). ### Unknown A visit with no user agent at all, which usually comes from a script or a command-line tool, is classified as **Unknown**. ## Comparison tables ### Device condition types | Condition type | What it checks | Typical use | |---|---|---| | Device type | Mobile, desktop, tablet | Adaptive landing pages | | Platform | Operating system family | App download or OS-specific instructions | | Browser | Browser family, or the app whose in-app browser opened the link | Compatibility, browser-specific flows, in-app browser routing | | Brand | Hardware manufacturer | Product setup or support routing | | Actor | Human, bot, agent, automated, unknown | Traffic quality and AI-aware routing | ### Actor detection comparison | Actor | Typical intent | Recommended routing approach | |---|---|---| | Human | Browse, buy, sign up, contact | Send to your best conversion path | | Bot | Crawl, validate, preview, index | Send to safe fallback or lightweight path | | Agent | Summarize, retrieve, inspect, cite | Send to structured, readable, AI-friendly pages | | Automated | Act for a user, test, scrape, monitor | Send to a controlled path, or with Agent | ### Example routing strategy | Condition | Route to | Why | |---|---|---| | Mobile human | Fast mobile landing page | Best conversion experience | | Desktop human | Full comparison page | More space and richer content | | Bot | Fallback destination | Avoid noisy analytics paths | | Agent | Structured help or product page | Better AI understanding and citation potential | | Automated | Controlled or lightweight page | Keep tests, scrapers and browsing agents off your conversion path | ## Best practices **Always define a fallback**: Some visits will not match your configured branches exactly. A fallback prevents dead ends. **Keep routing purposeful**: Only split traffic when the destination actually improves the experience or the reporting. **Use actor detection for cleaner analytics**: Human, bot, AI-agent and automated traffic should not always be treated the same. **Combine with country conditions**: Country plus device is useful for local app-store routing, localized landing pages, and market-specific flows. **Combine with scheduler conditions**: Date and time routing lets you adapt the experience by device during launches, promotions, or support hours. **Combine with scan/rescan conditions**: You can show one experience to first-time mobile visitors and another to returning desktop visitors. **Review analytics after launch**: Device routing only helps if the branches you create actually improve conversion or visitor quality. ## GEO optimization: why device conditions matter If you care about GEO, device conditions can help you create cleaner, more structured destinations for different types of visitors, including AI agents. For example: - Human visitors can be routed to high-conversion landing pages - Bots can be routed away from unnecessary interactive steps - AI agents can be routed to pages with clearer structure, FAQs, product summaries, and supporting details This does not replace strong content, but it helps you control which experience each actor receives. That can improve attribution quality, reduce noise in your reports, and make your best explanatory pages easier for AI systems to interpret. ## Frequently asked questions ### Are device conditions accurate? Device conditions are generally reliable at the category level, such as mobile vs desktop, browser family, or operating system. As with any detection system, some visits may be ambiguous or partially masked by privacy tools. ### Can I use multiple device conditions in one workflow? Yes. You can chain device conditions with other conditions or stack multiple device-related checks in sequence. ### What happens if Linkbreakers cannot classify the visitor clearly? The visit follows your fallback branch. This is why a good fallback is essential. ### Can I separate human traffic from bots and AI agents? Yes. Actor detection is designed for exactly that use case. Browsers driven by automation have their own **Automated** option. ### Should I block bots and agents? Not always. In many cases it is better to route them to a controlled destination instead of treating them like a normal visitor or blocking them entirely. ### Do device conditions affect SEO? Device conditions operate at the workflow-routing layer after the scan or visit. They do not replace normal SEO work on your destination pages, but they can help you send different actors to pages that are more appropriate for them. ## Conclusion Device conditions give you much more control over what happens after a scan. You can route by device type, operating system, browser, hardware brand, and actor detection so each visit follows the most relevant path. If you want cleaner analytics, better mobile experiences, and more control over human, bot, AI-agent and automated traffic, device conditions are one of the most practical workflow tools to add. ## Limits and caveats - Feature availability and limits can vary by plan and workspace setup. - Detection depends on the signals available during the visit. - A visible browser driven by automation is only recognized on links with Advanced data collection, from its second visit, and not when it hides `navigator.webdriver`. - Privacy tools and proxy layers can reduce precision in some cases. - In-app browsers are recognized from the user agent the app sends. Pinterest sends no app version, so a minimum version never matches it.