Why is my QR code scan count so high? Bot scans, email scanners, and how to report real numbers

You print 500 flyers, hand a client a QR code, and by the end of week one the dashboard shows 1,200 scans. Nobody printed extra flyers. Nobody double-counted. The client is thrilled, or suspicious, or both, and either way you need an answer that holds up.

Some of those hits are real people. Some of them never happened the way the dashboard implies. The moment a QR code's destination becomes a plain URL, that URL is fair game for anything on the internet that fetches links automatically. Email security tools and messaging apps touch links without a human ever looking at a screen, and a naive scan counter cannot tell the difference between one of those and a person standing in front of your poster.

This isn't a reason to distrust QR analytics wholesale. It's a reason to know which mechanisms inflate a count, which ones don't, and how to report a number you can defend, because a scan count nobody can explain is a scan count nobody should be calculating ROI from.

The short answer

A meaningful share of "scans" on a dynamic QR code are automated fetches of the destination URL, not a phone camera in someone's hand. The two biggest contributors are corporate email security software that opens links before a recipient does, and link-preview crawlers in messaging apps that fetch a URL once it's shared as text. General bot and invalid-traffic rates across the open web run anywhere from roughly a fifth to over half of all traffic depending on the channel and how it's measured, which is the honest backdrop for reading any inflation on your own numbers. No QR platform publishes a QR-specific bot percentage, because the mix depends entirely on how a code was distributed. What you can do is recognise the mechanisms, filter what you can, and report totals and unique scans separately.

Email security scanners click your link before you do

This is the largest, best-documented source of inflated scan counts, and it happens whether or not anyone in the recipient's inbox ever opens the email.

Microsoft Defender for Office 365's Safe Links scans URLs in incoming mail twice: once before the message is delivered, and again "at time of click" every time someone clicks the link, re-verifying it against current threat intelligence rather than trusting a cached result. Microsoft extended this in 2024 with QR code detection: Defender uses image processing during mail flow to extract the URL encoded in a QR image and feed it into the same scanning pipeline used for typed links. A QR code sent as an attachment or embedded image can trigger a fetch of its destination before a single recipient opens the message, and again if they click through later.

Barracuda's Link Protection and Mimecast's URL Protection work on the same principle from the receiving side: every rewritten link is re-verified against the live destination at the moment it's clicked, with no expiry and no cached "safe" verdict carried between clicks. None of this is malicious or unusual, it's exactly what these products are supposed to do: open a link in a sandbox before a human does. The side effect, for anyone measuring QR scans, is that a code shared inside an email to a security-conscious organisation can register several automated hits for a single email, or even for one nobody opens at all.

Messaging apps and the link-preview problem

The popular version of this concern is usually wrong in the details. No major messaging platform is known to decode a photographed QR code server-side to generate a preview. The exposure comes one step later, after the code has already been decoded once by a real person.

When a URL appears as plain text in a WhatsApp message, WhatsApp's servers fetch it to build the preview card, a genuine server-side hit against your redirect endpoint. So the exposure isn't "someone scanned my QR code in WhatsApp", it's "someone scanned it, then forwarded the resolved link as text", which happens constantly with codes tied to menus, event pages, and offers people want to share. Slack behaves the same way (typically requesting only the first slice of the page), and Telegram is widely observed to as well, though no single official document confirms its exact mechanism.

Not every app works this way, which matters when explaining a discrepancy to a client. iMessage builds its preview on the sender's own device and sends the result as an attachment, so no server fetch happens at all. Signal deliberately proxies preview fetches specifically so its own infrastructure never sees the destination URL, a design choice the company has documented as a privacy feature. If a client asks whether texting your QR link to a friend counts as a scan, the honest answer is: it depends entirely on the app, and for most of the popular ones, yes, once.

Your phone's camera doesn't do this part

The decode step, the moment a camera recognises a QR pattern and shows a preview banner before you tap, is not a network event. Google's ML Kit documentation states plainly that barcode and QR scanning happens on-device and doesn't require a network connection, it's pattern recognition against pixels the phone already has. What happens after you tap, checking a URL's reputation before actually navigating, is real and documented on both iOS and Android, but it's tied to the browser opening the page, not to the camera showing the preview banner. The inflation in your numbers doesn't come from this step. It happens earlier, in transit, before a phone camera is involved at all.

The bot-traffic backdrop

None of the mechanisms above happen in isolation; they sit on top of an internet that is now more automated traffic than human traffic by most broad measurements. Imperva's 2026 Bad Bot Report, drawing on a full year of network traffic, puts automated traffic at just over half of all web traffic, continuing a year-over-year climb, with a substantial share of that flagged as malicious. Separately, Pixalate's Q4 2025 invalid-traffic benchmarks, based on tens of billions of programmatic ad impressions, found rates of roughly 23% on web, 36% on mobile apps, and 21% on connected TV, a different measurement, ad-fraud-focused rather than general traffic, but pointing the same direction.

Neither figure is a QR statistic. Treat them as context for a client alarmed by any automated traffic at all: some baseline of non-human interaction with any link online is now normal, and a QR code is just a physical on-ramp to a URL like any other.

Telling a bot hit from a real scan

You can't eliminate automated hits, but you can flag most of them, using the same signals ad-tech and analytics platforms have relied on for years.

• User-agent matching. Known bots and security scanners identify themselves in the request's user-agent string. Open-source lists like the isbot library exist to match against these signatures, and most dynamic QR platforms run some version of this check on every hit.
• Hosting/datacenter IP ranges. A phone on a mobile network looks very different, at the network level, from a request originating inside AWS, Azure, or Google Cloud. Services like MaxMind explicitly flag IP ranges as hosting-provider infrastructure rather than consumer connections, a strong, if imperfect, signal.
• Impossible velocity. A code scanned in Rotterdam and, ninety seconds later, "scanned" again from an IP that geolocates to Singapore, isn't two people. Timing and location together catch what no single signal does alone.
• No repeat behaviour. A real campaign generates return visits and session activity. A single fetch that never resolves into any further activity on the destination page is consistent with an automated check, not a visit.
• Missing JavaScript execution. Scanners commonly fetch a page's raw response without ever running its JavaScript, the same principle behind Cloudflare's bot-management scoring and Matomo's default bot-exclusion behaviour.

No single signal is conclusive alone, which is why platforms combine several before deciding a hit doesn't count as a real visit.

What this means for the number you report

The fix isn't a better single metric, it's reporting two numbers instead of one. Total scans (every hit logged) and unique scans (distinct visitors, deduplicated by device or session) tell different stories, and the gap between them is exactly where bot traffic hides. A code showing 1,200 total scans and 640 unique ones deserves a sentence in the report, not a footnote, and it's exactly why which scan metrics matter is a different question from which metrics exist: total scans is the vanity number, unique scans and downstream conversions are the ones that hold up.

The same logic should reach your ROI calculations and any benchmark you use to judge a scan rate: a benchmark built on unfiltered totals will always look more impressive, and less trustworthy, than one built on a number you can defend. If you're pushing data into Google Analytics 4, the same email-scanner and link-preview traffic shows up there too, so your bot-exclusion settings need to be doing real work, not sitting on defaults. It also matters for A/B testing a campaign: if one variant gets emailed around more than the other, its scan count picks up more automated noise for reasons that have nothing to do with which design actually performed better.

Only dynamic QR codes have this problem, worth saying plainly: a static code with a URL baked into the pixels doesn't generate a server log at all, and can't be filtered, tracked, or explained after the fact. The analytics headache here is the cost of the tracking that makes a campaign measurable in the first place; the alternative isn't cleaner data, it's no data. It's also a different concern from the malicious codes covered in QR code security for agencies: here the code and destination are both legitimate, and the "problem" is entirely how much of the traffic hitting a real link is automated rather than human. A clean UTM structure doesn't fix bot inflation either, a scanner carries the same parameters through as a real visitor, but it does mean that once you filter the bot traffic out, what's left is attributed correctly.

• 1. Email security scanner that opens the link automatically, before or separately from a person clicking it.
• 2. Messaging app link preview that fetches the link when it's shared as text.
• 3. A real person scanning the code with their camera.

How platforms filter this out

A dynamic QR platform sits in the best position to catch most of this, because every scan passes through the same redirect endpoint and can be checked before it's logged as a visit. The baseline is a maintained bot-signature list checked against the user-agent, combined with a hosting-provider IP blocklist so requests from cloud infrastructure get flagged rather than counted at face value. More advanced setups add rate limiting and a redirect-behaviour check, since most automated scanners fetch a URL once and never follow a client-side redirect the way a real browser does. None of this makes the number perfect, but it moves "1,200 scans" closer to "1,200 hits, of which roughly 640 look like real visits", a split you can actually defend.

Frequently asked questions

Why does my QR code have more scans than the number of flyers or posters I printed?

Because "scans" as logged by most platforms count every automated hit against the destination URL, not just camera-and-tap interactions. Email security software opening the link before delivery and again at click time, and messaging apps generating a preview when the resolved link is shared as text, all register as hits on the same endpoint a human scan would hit. Print run size has no relationship to how many automated systems touch a link once it exists.

What's the difference between a "scan" and a "click" on a dynamic QR code?

In most platforms' terminology these describe the same event, a hit against the redirect endpoint, whether from a camera decode or any other client fetching the URL. The more useful distinction is total scans (every hit) versus unique scans (deduplicated by device or session), which is where the human-versus-automated gap actually shows up.

Do email security scanners like Microsoft Defender Safe Links actually open the link before I do?

Yes. Microsoft's documentation describes both delivery-time scanning and time-of-click verification for every link Safe Links protects, including, since a 2024 update, URLs extracted from QR code images inside emails. Barracuda and Mimecast run comparable click-time re-verification on their own products.

Does WhatsApp or iMessage generate a scan when someone shares my QR link?

It depends on the app and how the link is shared. WhatsApp's servers fetch a URL to build a link preview whenever it appears as plain text, a real hit against your redirect. iMessage builds its preview on the sender's own device, so no server fetch happens. Neither app is known to decode a photographed QR code automatically; the exposure only appears once someone has already scanned it and shares the resulting link as text.

What percentage of internet traffic is bots?

Imperva's 2026 Bad Bot Report puts automated traffic at just over half of all web traffic across the sites it monitors, continuing a rise from the prior year, with a significant portion flagged as malicious. This is a general web-traffic figure, not a QR-specific one, no QR platform publishes an equivalent number for scan data.

How can I tell a bot scan from a human scan in my dashboard?

Look for a combination of signals: a user-agent that self-identifies as a known scanner, an IP address in a known cloud-hosting range rather than a consumer network, physically impossible timing between two scans of the same code, and a single fetch that never resolves into any further activity on the destination page.

Should I report total scans or unique scans to a client?

Report both, and let the gap explain itself. Total scans is the raw hit count and includes automated traffic; unique scans deduplicates by device or session and sits closer to the number of actual people who engaged. A large gap between the two is worth a sentence in the report, not something to smooth over.

Can antivirus or endpoint security software trigger a scan before a user opens a link?

Yes: corporate email security products routinely fetch a link's destination before, and separately from, any human recipient clicking it. Endpoint and network security tools more broadly inspect URLs against threat intelligence too, though most of that inspection happens at the point a link is actually clicked, not pre-emptively for links sitting unopened.

Does my phone's camera send a network request just from previewing a QR code, before I tap it?

The decode itself doesn't, Google's documentation for on-device barcode scanning states plainly that it works without a network connection. What happens in the instant before you tap isn't fully documented by Apple or Google, so treat "the preview banner is network-silent" as a reasonable assumption rather than a guaranteed fact. Either way, it's not where the inflated numbers in your dashboard come from, that happens earlier, in transit.

Why do I see scans from cities or countries where the QR code was never distributed?

Usually a corporate email scanner or security appliance running from a data centre elsewhere, or a link-preview crawler running from whatever infrastructure the messaging platform uses, neither physically located where the recipient is. Geographic anomalies are also one of the more reliable signals for flagging automated traffic, since a real person can't scan a code in two distant cities within the same minute.

Does bot and prefetch traffic distort QR campaign ROI calculations?

It can, if raw total scans feed the calculation. ROI math built on an inflated numerator overstates cost-per-engagement improvements and can make a genuinely weak campaign look adequate. Using unique, filtered scans as the base protects the calculation from this kind of inflation.

How do dynamic QR platforms filter bot traffic from analytics?

Typically through known bot/crawler signature matching against the user-agent, blocklisting hosting-provider IP ranges, rate-limiting repeated hits from a single source, and checking whether a request behaves like a real browser rather than a one-shot automated fetch.

The short version

QR scan counts include real people, but they also include email security software opening your link before anyone reads the message, messaging apps fetching a resolved link once it's shared as text, and a general background rate of automated web traffic that now touches a meaningful share of every link online. None of this is a flaw in QR codes specifically, it's what happens to any trackable URL once it exists. Report total scans and unique scans as separate numbers, apply basic bot filtering (user-agent, hosting-IP, and velocity checks) before either number reaches a client, and use the filtered figure, not the raw one, anywhere the data feeds a decision: ROI, benchmarking, or a test between two campaign variants.