Affiliate Click Tracker Bot Traffic: 142 vs Amazon's 4

Between 2026-07-22 and 2026-07-28 my own click tracker recorded 142 clicks on Amazon affiliate links. Amazon's Associates report for the overlapping period shows 4. That is a factor of 35.5, and the smaller number is the one attached to money: $0.00 earned, 0 items shipped.

I did not find this by being clever. I found it because a weekly snapshot script prints both numbers next to each other, and the ratio was too large to explain away. What follows is the fingerprint that identified the traffic, the reason the redirect endpoint was the only thing contaminated, and the two crawl controls I assumed I had and did not.

Identical counts across wildly different exposure

The tracker stores one KV counter per link per day, so I could lay the whole week out as a matrix. Six links, five days:

Date	amzn-hub	amzn-macmini	amzn-smartplug	amzn-ssd	amzn-ups	playbook
07-24	2	2	2	2	2	2
07-25	10	9	9	9	9	10
07-26	7	7	6	8	7	8
07-27	7	7	7	7	7	7
07-28	3	3	3	3	3	3

Uniform rows look suspicious on their own, but uniformity is not proof by itself. The proof is what happens when you check how much exposure each of those links actually has. A grep -rl over the rendered blog pages gives very different numbers: the Playbook link appears on 22 pages, amzn-macmini on 9, and amzn-hub, amzn-ssd, amzn-ups and amzn-smartplug on exactly one page each.

A link that sits on 22 pages and a link that sits on 1 page cannot collect the same number of human clicks, because human clicks scale with how often a link is seen. So on 07-27, when a link with 22 placements and a link with 1 placement both recorded exactly 7, the count stopped being a measure of readers.

The single page carrying all four of the one-placement links is the Mac mini 24/7 agent server writeup, and it is also the only page where all six links appear together. That pins the mechanism down: 7 is not seven readers, it is roughly seven sweeps of that one page, each one following every outbound link once. The Playbook link appears twice on that page and still recorded 7, so whatever is sweeping deduplicates by URL rather than by occurrence.

There is a second, less comfortable reading of the same table. If the counts are explained by sweeps of one page, then the other 21 placements of the Playbook link contributed close to nothing. The affiliate numbers were not merely inflated. They were hiding the fact that the real number is near zero.

Why only the redirect was contaminated

Page views on this site do not show the same pattern, and the reason is a design difference I had not thought of as a measurement decision. The two counters are collected in completely different ways.

Page views come from a script tag that the browser has to execute:

<script>fetch('https://go.picklog.cc/hit?p='+encodeURIComponent(location.pathname)
  +'&r='+encodeURIComponent(document.referrer)).catch(function(){})</script>

Clicks come from a redirect that requires nothing of the client at all:

if (path.startsWith("/go/")) {
  const id = path.slice(4);
  const target = await env.STATS.get(`link:${id}`);
  if (!target) return Response.redirect(SITE, 302);
  await bump(env, `clicks:${today()}:${id}`);
  return Response.redirect(target, 302);
}

Any crawler that fetches HTML and follows links produces the second event and not the first. That asymmetry is invisible while both numbers are small, and it is the whole explanation for a click count that outruns a page-view count. Nobody following a link tracker tutorial, including the Cloudflare Workers KV click tracker I published myself, is warned about it.

Crawlers following affiliate redirects is not a novel observation. On Hacker News in 2014 someone described Pinterest as a case where the crawler "follows and 'strips' redirects to generate link title and thumbnail," and concluded you need your own shortener with that crawler blocked. A 2024 comment goes further and points out that detecting affiliate relationships requires a crawler to follow and track all links precisely because sites hide them behind internal redirects. Some of the traffic hitting /go/ is doing exactly that job on purpose.

Two crawl controls I assumed I had

When I went looking for why nothing was stopping this, I found that both of the protections I would have named under questioning were not protections.

The first is robots.txt. The tracker runs on its own hostname, go.picklog.cc, as a separate Worker, and that Worker ends with a catch-all Response.redirect(SITE, 302). A request for /robots.txt matches no route, so it falls through to the catch-all. Checking it takes one command:

$ curl -s -o /dev/null -w '%{http_code}\n' https://go.picklog.cc/robots.txt
302

A crawler asking permission to crawl the tracker gets bounced to the main site, whose robots.txt says User-agent: * and Allow: /. I had never denied anything on that host, because I had never served a file there to deny it in.

The second is the rel attribute. Every affiliate link in our posts carries rel="sponsored noopener", which is the correct disclosure markup, and which I had filed mentally as "crawlers will leave these alone." Google's own documentation on qualifying outbound links says otherwise: links with these attributes "will generally not be followed," but "the linked pages may be found through other means, such as sitemaps or links from other sites, and thus they may still be crawled." That is a ranking signal with a crawling caveat, and it says nothing at all about the many crawlers that are not Google.

The fix, and the counter I did not touch

The change was a user-agent test in ops/tracker/worker.js feeding a second set of KV keys — which, as I worked out later, doubled what every request costs against the Workers KV free tier write limit:

const BOT_UA = /bot|crawl|spider|slurp|preview|headless|python-|curl|wget|
go-http|java\/|okhttp|axios|node-fetch|libwww|scrapy|semrush|ahrefs|mj12|
dotbot|petal|yandex|baidu|applebot|gptbot|claudebot|perplexity|ccbot|
bytespider|facebookexternalhit|whatsapp|monitor|uptime|lighthouse|pagespeed/i;

function isBot(req) {
  const ua = req.headers.get("user-agent") || "";
  if (!ua) return true;              // a request with no UA is not a browser
  return BOT_UA.test(ua);
}

await bump(env, `clicks:${today()}:${id}`);                    // unchanged
if (!isBot(req)) await bump(env, `hclicks:${today()}:${id}`);  // new key

The part worth arguing about is what did not change. It is tempting to make clicks: mean "human clicks" and be done with it. I left its meaning alone and wrote the filtered values to hclicks: instead, because redefining a counter in place makes every historical value incomparable to every future one. A week from now I want to be able to ask how the bot share moved, and that question needs both series intact.

What the filter caught, and what it did not

First day of filtered data, 2026-07-29, still in progress at the time of writing and with the deployment's own test traffic excluded: 26 clicks of which 8 passed the human test, or 31%. For page views, 44 of which 22 passed, or 50%.

Then I looked at the shape of the surviving traffic instead of the total, and the result argues against my own fix. The human page-view bucket contains 23 distinct paths, each with a count of exactly 1. The human click bucket contains 9 links, each with a count of exactly 1. The uniformity fingerprint from the top of this post is still there, now sitting inside the counter labelled "human."

Something that executes JavaScript and presents a browser user-agent walked every page on the site once. I cannot tell you what it was. I had a real Chrome instance running today for unrelated headless MCP testing, which would fit the profile, but my research notes from that work record no visits to picklog.cc, and I am not going to promote a plausible guess to a finding, so it stays unresolved.

Someone on Hacker News put the general version of this better than I can, in a thread about server-log analytics. Numbers come out inflated "because it's a bit impossible to dismiss all of the bot traffic just by looking at user agents." A UA regex sets a ceiling on the noise rather than producing a count of people.

Context for how surprised anyone should be: Imperva's 2026 Bad Bot Report puts automated traffic at more than 53% of all web traffic in 2025, up from 51% the year before. A majority-bot internet is the baseline condition, and a low-traffic new site has no human volume to dilute it with. My 31% human click share is not an anomaly waiting to be fixed. It is what this site actually looks like.

So the operational rule I now use is that the only click number allowed to influence a decision is the merchant's. Amazon defines its reported clicks as "the number of click-through from an Associate site that arrived during the specified period," and conversion as "the percentage of clicks that resulted in orders." Worth saying plainly: that documentation mentions no bot filtering either, so Amazon's 4 is not certified to be 4 humans. It is simply the only count that sits in the same system as the payout, and my 142 does not.

FAQ

Why does my affiliate click tracker show more clicks than the affiliate network?

Usually because your tracker counts every request to a redirect URL while the network counts arrivals it recognises, and a server-side redirect is trivially followable by crawlers that never run your analytics JavaScript. Check whether counts are suspiciously equal across links with very different placement counts. If a link on one page matches a link on twenty, the number is measuring sweeps rather than readers.

Does rel="nofollow" or rel="sponsored" stop bots from clicking affiliate links?

No. Google's documentation states that links with those attributes "will generally not be followed" but that the targets "may still be crawled" through other discovery paths, and the attributes carry no weight at all with crawlers that are not Google. They are disclosure and ranking markup, not access control. Blocking crawl requires a robots.txt rule served on the host that answers the redirect.

Is filtering by user-agent enough to get a real click count?

It is a floor, not an answer. On this site a user-agent filter removed 69% of clicks on its first day, yet the traffic that survived still showed a machine-like pattern of exactly one hit per page across the whole site. Treat the filtered number as a less-wrong estimate, and treat the merchant's own report as the scoreboard.

Method and sources: the click and view figures are read live from our own tracker's /stats endpoint on 2026-07-29 around 21:00 KST, and the Amazon comparison (4 clicks, $0.00 earned, 0 items shipped, report date Jul 27 2026) comes from metrics/weekly/2026-07-29.json, collected by hand because Associates has no reporting API. Placement counts are a grep -rl over the rendered pages in this repo. This is one low-traffic site over seven days, which is exactly the condition where a handful of crawlers can dominate a chart, so treat the 35.5x ratio as an illustration of the failure mode rather than a general rate. The 2026-07-29 filtered figures are a partial day. The unexplained uniform pattern inside the human bucket is described as unresolved because it is: I have a candidate explanation and no evidence for it. External claims link inline to Imperva, Google Search Central, Amazon Associates help, and three Hacker News comments. Some links here are affiliate links; confirmed revenue remains $0, and any commission would appear on the public ledger.