Edge middleware
Edge middleware — the only layer where a crawler fetch can be counted
Deploy generated middleware at your own edge to record AI crawler visits, signed with a workspace HMAC secret. Browser analytics cannot see these requests at all.
Karl-Gustav Kallasmaa, Founder & CEOLast updated What you configure
The exact settings, as our documentation publishes them.
Fetch the generated install from the API or MCP:
GET /v1/ai-traffic/install (REST)
tool get_ai_traffic_install (MCP)
It returns the ingest endpoint, the signature header,
your workspace's signing secret, the replay window,
the daily cap and a copy-pasteable edge worker.
Connecting it
In order, with the reason each step exists rather than only the instruction.
- 1
Get the generated instructions for your workspace
Attensira generates the install in Settings, and the same values are available from the API and the MCP tool. Use the generated copy rather than an example found elsewhere — a snippet without your workspace's values sends data nowhere, silently.
- 2
Deploy it in front of the tracked domain
The worker runs in the edge layer of your stack, on every request, including the ones that never become a rendered page. That is the only layer at which a crawler fetch exists to be counted.
- 3
Wait for a crawler to actually arrive
Nothing appears until a crawler fetches a page. On a low-traffic site that can take days, and an empty view in the first hours is the expected outcome rather than a failed install.
- 4
Read it in the bot area
Once data arrives it surfaces in the bot area of analytics, whose rows carry visits, pages reached, a purpose mix and a last-seen timestamp rather than rate fields. That is the cross-check to run before rewriting any page that looks like it underperforms.
What it lets you do
- Records requests that no browser-based analytics can see, because they never execute any JavaScript.
- Gives a coverage signal at the path level — which parts of a site AI systems reach, and which they never do.
- Separates an access problem from a content problem, since a page nothing has fetched cannot be cited whatever is written on it.
What it cannot do
An integration page that lists only capabilities is an advertisement. This is the half you are evaluating.
- It cannot verify who visited. User agents are self-reported and trivially spoofed, and Attensira does not publish a verified-bot claim it cannot stand behind, so this is directional evidence about coverage rather than an audited log of visitors.
- It cannot tell you anything about visibility in answers. Crawlers fetch pages and models answer prompts; they are different pipelines on different schedules, and a rise in one does not predict the other.
- It cannot be replaced by a client-side script. AI crawlers do not execute JavaScript, so by the time a browser beacon runs the only visitors left are humans — an existing analytics tool showing zero AI crawler traffic is describing its own method rather than the crawlers.
This is the one integration on the list that is not a connection to a product. It is code you deploy at your own edge, and it exists because of a constraint that cannot be engineered around.
The constraint
AI crawlers do not execute JavaScript. Any measurement that depends on a script running in a browser has, by construction, never recorded one and never will: by the time the script fires, the only visitors left are humans with browsers.
That single fact disposes of an entire category of approach. If your existing analytics reports no AI crawler traffic, it is telling you about its own method rather than about the crawlers. There is no configuration of a client-side tool that fixes this, because the requests in question never reach the point where a client exists.
Edge middleware runs on every request, including the ones that never become a rendered page. It is the only layer at which a crawler fetch exists to be counted at all.
Use the generated install
The product generates the install for your workspace, and the same values are reachable through the API endpoint and the MCP tool. What comes back is the ingest endpoint, the header the signature goes in, your workspace's signing secret, the project id, the replay window, the daily cap, and a worker you can paste.
Almost all of those are workspace-specific, which is why the install is generated rather than published as a snippet. A worker copied from a blog post or another workspace deploys perfectly and sends data nowhere, and the failure produces no error — you simply see nothing, which is indistinguishable from no crawlers having come.
The signing secret is unusual among Attensira credentials in that it can be shown again. It is derived from the workspace id rather than randomly generated and hashed, so re-fetching it is normal. An API key is the opposite and is displayed exactly once.
What you get, honestly stated
You get the fact that requests arrived, when, and against which paths. Read it as a coverage signal: pages that are never fetched cannot become fresh citations, and a section that crawlers never reach is worth checking for robots rules, auth walls or redirects.
What you do not get is verified attribution. Attensira does not claim to prove that a given request came from a specific named crawler, because user agents are self-reported and trivially spoofed, and publishing a verified-bot claim it could not stand behind would be worse than publishing nothing.
And crawler activity is not visibility. Crawlers fetch; models answer. Two pipelines, two schedules, and no reliable relationship between them — a page can be fetched daily and never cited, or cited from something a model absorbed months ago. Do not reconcile the numbers.
Where the data lands
In the bot area of the analytics endpoint, whose rows carry visits, pages reached, a purpose mix and a last-seen timestamp instead of the rate fields the other areas use.
That area is worth calling before rewriting any page that looks like it underperforms, because it splits one apparent problem into two very different ones. A page fetched constantly and never cited is reachable and not chosen, and the work is in the content. A page nothing has fetched cannot be cited by anything, and the work is in access — and no amount of editing changes that.
Patience on a quiet site
Nothing appears until a crawler actually fetches a page. On a low-traffic site that can take days, and an empty view an hour after deploying is the expected outcome rather than evidence of a broken install.
Questions people ask
- Why can my existing analytics not do this?
- Because it runs in a browser and AI crawlers do not execute JavaScript. A beacon has never recorded one and never will, so a report of zero AI crawler traffic is a fact about the measurement rather than about the traffic.
- Why must I use the generated snippet?
- Because it carries your workspace's ingest endpoint and credentials. A snippet copied from elsewhere deploys cleanly and sends data nowhere, with no error to notice.
- Can I fetch the signing secret again?
- Yes. It is derived from the workspace id, so it is stable and can be shown again — unlike an API key, which is displayed exactly once.
- Does crawler traffic mean I am being cited?
- No. A page can be fetched constantly and never cited, or cited from something learned months ago and never re-fetched. Do not reconcile the two numbers.
- Nothing has appeared. Is it broken?
- Probably not yet. Nothing appears until a crawler actually fetches a page, and on a low-traffic site that can take days.
Sources
Every factual statement above, with the page it came from and the date that page was read.
Attensira's AI traffic documentation states that AI crawlers do not execute JavaScript, that a client-side beacon has never seen one, and that edge middleware is the only layer where a crawler fetch exists to be counted.
docs.attensira.com · retrieved
“AI crawlers do not execute JavaScript. A client-side beacon, no matter how it is written, has never seen one and never will”
Attensira's documentation states that the install instructions are generated for the workspace and carry its own values, and that a snippet without them sends data nowhere.
docs.attensira.com · retrieved
“use the generated copy rather than an example you found elsewhere — a snippet without your workspace's values sends data nowhere”
Attensira's documentation states that it does not claim to prove a request came from a specific named crawler, because user agents are self-reported and trivially spoofed.
docs.attensira.com · retrieved
“Attensira does not claim to prove that a given request came from a specific named crawler.”
Attensira's API reference states that the AI traffic signing secret is derived from the workspace id, so it is stable and can be shown again, unlike an API key.
docs.attensira.com · retrieved
“The signing secret is derived from the workspace id, so it is stable and can be shown again”