Waarom heeft mijn QR-code zoveel scans? Bots, e-mailscanners en echte cijfers

Je drukt 500 flyers, geeft een klant een QR-code, en aan het eind van week één laat het dashboard 1.200 scans zien. Niemand heeft extra flyers gedrukt. Niemand heeft dubbel geteld. De klant is blij, achterdochtig, of allebei, en in beide gevallen heb je een verklaring nodig die standhoudt.

Een deel van die hits zijn echte mensen. Een ander deel is nooit gebeurd zoals het dashboard suggereert. Zodra de bestemming van een QR-code een gewone URL wordt, is die URL vogelvrij voor alles op internet dat automatisch links ophaalt. E-mailbeveiliging en berichten-apps raken links aan zonder dat er ooit een mens naar een scherm kijkt, en een simpele scanteller kan geen onderscheid maken tussen zo'n geval en iemand die voor je poster staat.

Dat is geen reden om QR-analytics in het algemeen te wantrouwen. Het is wel een reden om te weten welke mechanismen een aantal opblazen, welke niet, en hoe je een cijfer rapporteert dat je kunt verdedigen, want een scanaantal dat niemand kan verklaren is geen aantal waar je ROI op zou moeten berekenen.

Het korte antwoord

Een aanzienlijk deel van de "scans" op een dynamische QR-code zijn geautomatiseerde aanroepen van de bestemmings-URL, geen telefooncamera in iemands hand. De twee grootste boosdoeners zijn zakelijke e-mailbeveiliging die links opent voordat de ontvanger dat doet, en linkvoorbeeld-crawlers in berichten-apps die een URL ophalen zodra die als tekst gedeeld wordt. Algemene bot- en invalid-traffic-percentages op het open web lopen uiteen van ruwweg een vijfde tot ruim de helft van al het verkeer, afhankelijk van het kanaal en de meetmethode, en dat is de eerlijke achtergrond waartegen je elke opblazing in je eigen cijfers moet lezen. Geen enkel QR-platform publiceert een QR-specifiek botpercentage, omdat de mix volledig afhangt van hoe een code is verspreid. Wat je wel kunt doen: de mechanismen herkennen, filteren wat je kunt filteren, en totalen en unieke scans apart rapporteren.

E-mailbeveiliging klikt je link al aan voordat jij dat doet

Dit is de grootste, best gedocumenteerde bron van opgeblazen scanaantallen, en het gebeurt ongeacht of iemand in de inbox van de ontvanger de e-mail ooit opent.

Safe Links van Microsoft Defender for Office 365 scant URL's in inkomende mail twee keer: één keer voordat het bericht wordt afgeleverd, en nogmaals "op het moment van klikken" elke keer dat iemand op de link klikt, waarbij de link opnieuw wordt geverifieerd tegen actuele dreigingsinformatie in plaats van te vertrouwen op een gecachet resultaat. Microsoft breidde dit in 2024 uit met QR-codedetectie: Defender gebruikt beeldverwerking tijdens de mailflow om de URL uit een QR-afbeelding te halen en die door dezelfde scanpijplijn te sturen als getypte links. Een QR-code die als bijlage of ingesloten afbeelding wordt verstuurd, kan al een aanroep van de bestemming triggeren voordat ook maar één ontvanger het bericht opent, en nogmaals als diegene later doorklikt.

Link Protection van Barracuda en URL Protection van Mimecast werken volgens hetzelfde principe aan de ontvangende kant: elke herschreven link wordt opnieuw geverifieerd tegen de live bestemming op het moment van klikken, zonder vervaldatum en zonder een gecachet "veilig"-oordeel dat tussen klikken wordt meegenomen. Niets hiervan is kwaadaardig of ongebruikelijk, het is precies wat deze producten horen te doen: een link in een sandbox openen voordat een mens dat doet. Het neveneffect, voor iedereen die QR-scans meet, is dat een code die binnen een e-mail naar een veiligheidsbewuste organisatie wordt gedeeld meerdere geautomatiseerde hits kan registreren voor één enkele e-mail, of zelfs voor een e-mail die niemand ooit opent.

Berichten-apps en het linkvoorbeeld-probleem

De populaire versie van deze zorg klopt meestal niet in de details. Van geen enkel groot berichtenplatform is bekend dat het een gefotografeerde QR-code server-side decodeert om een voorbeeld te genereren. Het risico ontstaat een stap later, nadat de code al één keer door een echt persoon is gedecodeerd.

Zodra een URL als platte tekst in een WhatsApp-bericht verschijnt, halen de servers van WhatsApp die op om de voorbeeldkaart te bouwen, een echte server-side hit op je redirect-endpoint. De blootstelling is dus niet "iemand heeft mijn QR-code in WhatsApp gescand", maar "iemand heeft hem gescand en de opgeloste link daarna als tekst doorgestuurd", en dat gebeurt voortdurend bij codes die aan menu's, evenementpagina's en aanbiedingen hangen die mensen willen delen. Slack doet hetzelfde (meestal met alleen het eerste stukje van de pagina), en van Telegram wordt breed aangenomen dat het ook zo werkt, al bevestigt geen enkel officieel document het exacte mechanisme.

Niet elke app werkt zo, en dat is relevant als je een afwijking aan een klant moet uitleggen. iMessage bouwt het voorbeeld op het apparaat van de afzender zelf en verstuurt het resultaat als bijlage, dus er vindt helemaal geen serveraanroep plaats. Signal stuurt voorbeeldaanroepen bewust via een proxy, juist zodat de eigen infrastructuur de bestemmings-URL nooit te zien krijgt, een ontwerpkeuze die het bedrijf zelf documenteert als privacyfunctie. Als een klant vraagt of het appen van je QR-link naar een vriend als scan telt, is het eerlijke antwoord: dat hangt helemaal van de app af, en bij de meeste populaire apps is het antwoord ja, één keer.

Dit is niet het werk van je telefooncamera

De decodeerstap, het moment waarop een camera een QR-patroon herkent en een voorbeeldbanner toont voordat je erop tikt, is geen netwerkgebeurtenis. De documentatie van Google's ML Kit stelt expliciet dat barcode- en QR-scanning on-device gebeurt en geen netwerkverbinding vereist, het is patroonherkenning op pixels die de telefoon al heeft. Wat er gebeurt nadat je tikt, het controleren van de reputatie van een URL voordat er daadwerkelijk naartoe wordt genavigeerd, is echt en gedocumenteerd op zowel iOS als Android, maar dat hangt samen met de browser die de pagina opent, niet met de camera die de voorbeeldbanner toont. De opblazing in je cijfers komt niet uit deze stap. Die ontstaat eerder, onderweg, voordat er ook maar een telefooncamera aan te pas komt.

De achtergrond: bot-verkeer

Geen van de bovenstaande mechanismen staat op zichzelf; ze spelen zich af op een internet dat volgens de meeste brede metingen inmiddels meer geautomatiseerd dan menselijk verkeer kent. Het Bad Bot Report 2026 van Imperva, gebaseerd op een vol jaar netwerkverkeer, zet geautomatiseerd verkeer op net iets meer dan de helft van al het webverkeer, een stijging ten opzichte van het jaar ervoor, waarvan een aanzienlijk deel als kwaadaardig is aangemerkt. Los daarvan vonden de invalid-traffic-benchmarks van Pixalate over Q4 2025, gebaseerd op tientallen miljarden programmatic ad-impressies, percentages van ruwweg 23% op web, 36% op mobiele apps en 21% op connected tv, een andere meting, gericht op advertentiefraude in plaats van algemeen verkeer, maar wijzend in dezelfde richting.

Geen van beide cijfers is een QR-statistiek. Gebruik ze als context voor een klant die schrikt van elk geautomatiseerd verkeer: een bepaalde basislaag van niet-menselijke interactie met elke link online is inmiddels normaal, en een QR-code is gewoon een fysieke ingang naar een URL, net als elke andere.

Een bot-hit onderscheiden van een echte scan

Je kunt geautomatiseerde hits niet volledig elimineren, maar je kunt de meeste wel markeren, met dezelfde signalen waar ad-tech- en analyticsplatforms al jaren op vertrouwen.

• User-agent matching. Bekende bots en beveiligingsscanners identificeren zichzelf in de user-agent-string van het verzoek. Open-source lijsten zoals de isbot-library bestaan om tegen deze signaturen te matchen, en de meeste dynamische QR-platforms draaien op elke hit een versie van deze controle.
• Hosting-/datacenter-IP-reeksen. Een telefoon op een mobiel netwerk ziet er op netwerkniveau heel anders uit dan een verzoek dat vanuit AWS, Azure of Google Cloud komt. Diensten zoals MaxMind markeren IP-reeksen expliciet als hostingprovider-infrastructuur in plaats van consumentenverbindingen, een sterk maar niet waterdicht signaal.
• Onmogelijke snelheid. Een code die in Rotterdam wordt gescand en negentig seconden later opnieuw "gescand" wordt vanaf een IP dat geolocaliseert naar Singapore, zijn geen twee personen. Timing en locatie samen vangen op wat geen enkel signaal alleen kan vangen.
• Geen herhaalgedrag. Een echte campagne levert terugkerende bezoeken en sessieactiviteit op. Eén aanroep die nooit uitmondt in verdere activiteit op de bestemmingspagina past bij een geautomatiseerde controle, niet bij een bezoek.
• Ontbrekende JavaScript-uitvoering. Scanners halen doorgaans de ruwe respons van een pagina op zonder ooit de JavaScript uit te voeren, hetzelfde principe achter de bot-managementscore van Cloudflare en het standaard bot-uitsluitingsgedrag van Matomo.

Geen enkel signaal is op zichzelf doorslaggevend, en daarom combineren platforms er meerdere voordat ze besluiten dat een hit niet als echt bezoek meetelt.

Wat dit betekent voor het cijfer dat je rapporteert

De oplossing is geen betere enkele metric, maar het rapporteren van twee cijfers in plaats van één. Totaal aantal scans (elke gelogde hit) en unieke scans (aparte bezoekers, gededupliceerd op apparaat of sessie) vertellen een ander verhaal, en precies in het gat daartussen verstopt zich bot-verkeer. Een code met 1.200 scans totaal en 640 unieke scans verdient een zin in het rapport, geen voetnoot, en dat is precies waarom welke scanstatistieken ertoe doen een andere vraag is dan welke statistieken er bestaan: totaal aantal scans is het ijdelheidscijfer, unieke scans en conversies verderop in de funnel zijn de cijfers die standhouden.

Diezelfde logica moet ook doorwerken in je ROI-berekeningen en elke benchmark waarmee je een scanpercentage beoordeelt: een benchmark gebaseerd op ongefilterde totalen oogt altijd indrukwekkender, en minder betrouwbaar, dan één gebaseerd op een cijfer dat je kunt verdedigen. Als je data naar Google Analytics 4 stuurt, duikt datzelfde e-mailscanner- en linkvoorbeeld-verkeer daar ook op, dus je bot-uitsluitingsinstellingen moeten echt werk verzetten en niet op de standaardwaarden blijven staan. Het speelt ook mee bij het A/B-testen van een campagne: als de ene variant vaker wordt doorgemaild dan de andere, pikt het scanaantal daarvan meer geautomatiseerde ruis op om redenen die niets te maken hebben met welk ontwerp daadwerkelijk beter presteerde.

Alleen dynamische QR-codes hebben dit probleem, en dat mag gezegd worden: een statische code met een URL die in de pixels is gebakken, genereert helemaal geen serverlog en kan achteraf niet gefilterd, gevolgd of verklaard worden. De analytics-hoofdpijn hier is de prijs van de tracking die een campagne meetbaar maakt; het alternatief is geen schonere data, het is geen data. Het is ook een ander vraagstuk dan de kwaadaardige codes uit QR-codebeveiliging voor bureaus: hier zijn de code en de bestemming allebei legitiem, en het "probleem" zit volledig in hoeveel van het verkeer op een echte link geautomatiseerd is in plaats van menselijk. Een nette UTM-structuur lost bot-opblazing ook niet op, een scanner draagt dezelfde parameters mee als een echte bezoeker, maar het betekent wel dat zodra je het bot-verkeer eruit filtert, wat overblijft correct wordt toegeschreven.

• 1. E-mailbeveiligingsscanner die de link automatisch opent, los van of voorafgaand aan het klikken door een persoon.
• 2. Linkvoorbeeld van een berichten-app die de link ophaalt zodra die als tekst wordt gedeeld.
• 3. Een echt persoon die de code met zijn camera scant.

Hoe platforms dit filteren

Een dynamisch QR-platform zit in de beste positie om het meeste hiervan op te vangen, omdat elke scan via hetzelfde redirect-endpoint loopt en gecontroleerd kan worden voordat die als bezoek wordt gelogd. De basis is een bijgehouden lijst met botsignaturen die tegen de user-agent wordt gecontroleerd, gecombineerd met een blocklist van hostingprovider-IP's, zodat verzoeken vanuit cloudinfrastructuur worden gemarkeerd in plaats van klakkeloos meegeteld. Geavanceerdere opzetten voegen rate limiting toe en een controle op redirect-gedrag, omdat de meeste geautomatiseerde scanners een URL één keer ophalen en nooit een client-side redirect volgen zoals een echte browser dat wel doet. Niets hiervan maakt het cijfer perfect, maar het brengt "1.200 scans" dichter bij "1.200 hits, waarvan er ongeveer 640 op echte bezoeken lijken", een verdeling die je daadwerkelijk kunt verdedigen.

Veelgestelde vragen

Waarom heeft mijn QR-code meer scans dan flyers die ik heb gedrukt?

Omdat "scans" zoals de meeste platforms die loggen elke geautomatiseerde hit op de bestemmings-URL meetellen, niet alleen camera-en-tik-interacties. E-mailbeveiliging die de link opent voor aflevering en nogmaals bij het klikken, en berichten-apps die een voorbeeld genereren zodra de opgeloste link als tekst wordt gedeeld, registreren allemaal als hits op hetzelfde endpoint als een menselijke scan. De oplage van je print heeft geen enkel verband met hoeveel geautomatiseerde systemen een link aanraken zodra die bestaat.

Wat is het verschil tussen een "scan" en een "klik" bij een dynamische QR-code?

In de terminologie van de meeste platforms beschrijven deze twee dezelfde gebeurtenis: een hit op het redirect-endpoint, of die nu van een cameradecodering komt of van een andere client die de URL ophaalt. Het nuttigere onderscheid is totaal aantal scans (elke hit) versus unieke scans (gededupliceerd op apparaat of sessie), en daar zie je het verschil tussen mens en automaat pas echt terug.

Opent e-mailbeveiliging zoals Microsoft Defender Safe Links mijn link echt voordat ik dat doe?

Ja. De documentatie van Microsoft beschrijft zowel scannen op het moment van aflevering als verificatie op het moment van klikken voor elke link die Safe Links beschermt, inclusief, sinds een update in 2024, URL's die uit QR-codeafbeeldingen in e-mails worden gehaald. Barracuda en Mimecast voeren vergelijkbare click-time herverificatie uit op hun eigen producten.

Telt het mee als scan als iemand mijn QR-link doorstuurt via WhatsApp of iMessage?

Dat hangt af van de app en van hoe de link gedeeld wordt. De servers van WhatsApp halen een URL op om een linkvoorbeeld te bouwen zodra die als platte tekst verschijnt, een echte hit op je redirect. iMessage bouwt zijn voorbeeld op het apparaat van de afzender zelf, dus daar vindt geen serveraanroep plaats. Van geen van beide apps is bekend dat ze automatisch een gefotografeerde QR-code decoderen; het risico ontstaat pas zodra iemand de code al heeft gescand en de resulterende link als tekst deelt.

Hoeveel procent van het internetverkeer bestaat uit bots?

Het Bad Bot Report 2026 van Imperva zet geautomatiseerd verkeer op net iets meer dan de helft van al het webverkeer op de sites die het monitort, een voortzetting van de stijging ten opzichte van het jaar ervoor, waarvan een aanzienlijk deel als kwaadaardig is aangemerkt. Dit is een algemeen cijfer over webverkeer, geen QR-specifiek cijfer: geen enkel QR-platform publiceert een vergelijkbaar getal voor scandata.

Hoe herken ik een bot-scan tussen mijn echte scans in het dashboard?

Let op een combinatie van signalen: een user-agent die zichzelf identificeert als bekende scanner, een IP-adres in een bekende cloud-hostingreeks in plaats van een consumentennetwerk, fysiek onmogelijke timing tussen twee scans van dezelfde code, en één enkele aanroep die nooit uitmondt in verdere activiteit op de bestemmingspagina.

Moet ik totaal aantal scans of unieke scans rapporteren aan een klant?

Rapporteer allebei, en laat het gat zijn eigen verhaal vertellen. Totaal aantal scans is de ruwe hit-count en bevat geautomatiseerd verkeer; unieke scans dedupliceert op apparaat of sessie en ligt dichter bij het aantal mensen dat daadwerkelijk betrokken was. Een groot verschil tussen die twee verdient een zin in het rapport, geen gladstrijken.

Kan antivirus- of endpointbeveiliging een scan triggeren voordat een gebruiker de link opent?

Ja: zakelijke e-mailbeveiligingsproducten halen standaard de bestemming van een link op, los van en voorafgaand aan het klikken door een menselijke ontvanger. Endpoint- en netwerkbeveiligingstools inspecteren URL's in bredere zin ook tegen dreigingsinformatie, al gebeurt het grootste deel van die inspectie op het moment dat er daadwerkelijk op een link wordt geklikt, niet preventief voor links die nog ongeopend liggen.

Stuurt mijn telefooncamera al een netwerkverzoek bij het herkennen van een QR-code, voordat ik erop tik?

Het decoderen zelf niet, de documentatie van Google voor on-device barcodescanning stelt expliciet dat het zonder netwerkverbinding werkt. Wat er in het moment vlak voor je tikt gebeurt, is niet volledig gedocumenteerd door Apple of Google, dus behandel "de voorbeeldbanner is netwerkstil" als een redelijke aanname en niet als een gegarandeerd feit. Hoe dan ook, daar komen de opgeblazen cijfers in je dashboard niet vandaan, dat gebeurt eerder, onderweg.

Waarom zie ik scans uit steden of landen waar de QR-code nooit is verspreid?

Meestal een zakelijke e-mailscanner of beveiligingsappliance die vanuit een datacenter elders draait, of een linkvoorbeeld-crawler die draait op de infrastructuur van het berichtenplatform, geen van beide fysiek op de locatie van de ontvanger. Geografische afwijkingen zijn ook een van de betrouwbaardere signalen om geautomatiseerd verkeer te markeren, omdat een echt persoon geen code kan scannen in twee ver uit elkaar liggende steden binnen dezelfde minuut.

Verstoort bot- en prefetch-verkeer de ROI-berekening van een QR-campagne?

Dat kan, als de ruwe totale scans de berekening voeden. ROI-rekensommen gebaseerd op een opgeblazen teller overschatten verbeteringen in kosten per engagement en kunnen een werkelijk zwakke campagne er redelijk laten uitzien. Door unieke, gefilterde scans als basis te gebruiken bescherm je de berekening tegen dit soort opblazing.

Hoe filteren dynamische QR-platforms bot-verkeer uit hun analytics?

Meestal door bekende bot-/crawlersignaturen te matchen tegen de user-agent, hostingprovider-IP-reeksen op een blocklist te zetten, herhaalde hits vanaf één bron te rate-limiten, en te controleren of een verzoek zich gedraagt als een echte browser in plaats van een eenmalige geautomatiseerde aanroep.

Kort samengevat

QR-scanaantallen bevatten echte mensen, maar ook e-mailbeveiliging die je link opent voordat iemand het bericht leest, berichten-apps die een opgeloste link ophalen zodra die als tekst gedeeld wordt, en een algemeen achtergrondniveau van geautomatiseerd webverkeer dat inmiddels een aanzienlijk deel van elke link online raakt. Niets hiervan is een gebrek van QR-codes specifiek, het is wat er met elke traceerbare URL gebeurt zodra die bestaat. Rapporteer totaal aantal scans en unieke scans als twee aparte cijfers, pas basale bot-filtering toe (user-agent, hosting-IP en snelheidscontroles) voordat een van beide cijfers een klant bereikt, en gebruik overal waar de data een beslissing voedt het gefilterde cijfer, niet het ruwe: bij ROI, benchmarking, of een test tussen twee campagnevarianten.