Capture agent traffic server-side when no JavaScript fires

Why nothing fires

Your web container is a JavaScript file. Anything that does not run JavaScript never announces itself to it. As of September 2026 that covers a large share of the traffic hitting real sites: Cloudflare Radar data puts automated requests at 57.5% of HTML traffic, per HUMAN Security's 2026 benchmark report. Not all of that acts on a user's behalf, but the acting slice is the one that buys things: industry analyses estimate roughly 70.6% of AI referrals are invisible to standard GA4 setups, with AI-driven traffic undercounted 3-4x.

Three distinct agent paths hit your site, and only one of them reliably fires tags:

The third row is where the money moves. Since the Agentic Commerce Protocol's Instant Checkout was rolled back in March 2026, most agent shopping journeys end in a discovery-plus-redirect flow, but agent-initiated fetches, availability checks, and API-side order flows still produce requests with no client-side trace. If your only collection point is the browser, that entire path is invisible - and it is not a segment you want to lose: Adobe Analytics measured AI-driven traffic converting 42% better than non-AI traffic in March 2026.

The capture pattern

A standard server-side GTM deployment does not solve this by itself - the server container normally receives events from the web container, which is exactly the component agents skip. If you are new to server containers, read our server-side GTM overview first. The agent capture pattern adds a second input path alongside the browser one:

1. Collect at the layer that always sees the request. Your CDN edge (a Cloudflare Worker or equivalent), your web server middleware, or your commerce backend for order flows. This layer sees every request, agent or human, JavaScript or not.
2. Classify the request. Declared user-agent, secondary headers, cryptographic signatures where present, and IP verification. The full signal stack is its own page: classify agent vs human requests in server-side GTM.
3. Forward classified agent hits to the server container over HTTP. Shape the payload the way your server container's client expects, and stamp it traffic_type=agent (or a custom dimension of your choosing) so downstream tools can segment it.
4. Route in the server container. Forward to GA4 with the traffic-type parameter, to ad platforms only where the event genuinely qualifies as a conversion, and drop or aggregate pure crawler noise.
5. Respect the consent gate. An agent request carries no consent banner interaction. Decide, with whoever owns privacy, what processing basis applies to agent hits and encode that decision in the container, not in ad-hoc filters. The governance side is covered in consent banners and agent tracking.

A minimal edge-side forwarder looks like this (Cloudflare Worker syntax; the same shape works in any middleware):

// After your agent classification returns true:
const evt = {
  client_name: 'server_ingest',
  event_name: 'agent_page_fetch',
  page_location: request.url,
  traffic_type: 'agent',
  agent_signals: { ua: request.headers.get('user-agent') || '',
                   sig: request.headers.get('signature-agent') || '' },
  event_id: crypto.randomUUID(),   // dedup key, see below
  ts: Date.now()
};
// Fire-and-forget so the visitor-facing response is never delayed
ctx.waitUntil(fetch('https://sgtm.your-domain.com/agent-ingest', {
  method: 'POST',
  headers: { 'content-type': 'application/json' },
  body: JSON.stringify(evt)
}));

On the server container side, a small custom client claims the /agent-ingest path, maps the payload into the event data model, and your regular tags take it from there. For purchases specifically - the case where the "request" is an order confirmation inside your commerce backend rather than a page fetch - the same pattern applies one layer deeper, and the conversion-platform half of it (CAPI payloads, match keys) is covered in capturing agent checkout via CAPI.

Dedup before you ship it

The second row of the path table is the trap: an operator-style agent driving a real browser can fire your pixel and be captured by your server-side path. Both copies must carry the same event_id (Meta) or transaction_id (GA4 purchases), or the platform counts the action twice - inflated conversions, wrong optimization signals. The full dedup treatment, including which agent paths need it and which are server-only by nature, is at agent events double-counting: pixel + CAPI dedup.