Where AI Visitors Leave: Exit Pages and Outbound Clicks

Most analytics is built around the way in: which source, which campaign, which landing page. For visitors sent by an AI assistant, the way out is often more telling. An assistant sends someone to check one specific thing, a price, a limit, an install step. Where they stop reading, and whether they then leave for your GitHub, your checkout or a competitor, tells you whether the page answered the question the assistant sent them with.

That is two questions, not one. The exit page is the last page someone viewed on your site. The destination is the site they went to next. They come from different data, they fail in different ways, and a tool that blends them will tell you things that did not happen. Here is how each one is measured, where the traps are, and how to read both for AI traffic.

Picture three AI visitors who all ended on /pricing.

The first closed the tab. The exit page is /pricing and there is no destination at all. The second clicked through to your payment provider's hosted checkout and paid. The third clicked a link in a comparison table and left for a competitor's site.

An exit-page report shows three identical rows. A destination report shows two different departures and says nothing about the first visitor. Only the pair tells the story: the pricing page is where these visits end, and what happens next splits between a sale and a loss. In Traceten, each visitor's timeline puts the two side by side, as "Exited from /pricing" and, when there was one, "left for" a hostname.

A browser does not reliably tell a page that the visitor is leaving. The unload events are skipped when a phone closes a tab or the browser app is swiped away. Both MDN and Chrome's Page Lifecycle guidance say the same thing: the transition to the hidden state is the last moment a page can reliably observe, so treat it as the likely end of the session and send analytics then.

Traceten's script follows that advice. It sends an exit event when the page is hidden or unloads, using the beacon API so the request survives the page going away, and it guards against sending twice when both events fire together. Nothing is sent while consent is pending or denied.

The exit page is then the URL of the last page view in the session. One trap is worth knowing because it catches every hand-built version of this query. When a visitor grants consent after the page has loaded, that first page load is recorded as the start of the session rather than as an ordinary page view. A rule that looks only at page views then leaves every one-page, late-consent session with a known entry page and a blank exit page. Traceten counts both kinds of record, so a one-page session always exits where it entered.

The destination is harder, because the only evidence is a click. A click on a link is not proof that anyone went anywhere. The link might open in a new tab while the visitor keeps reading. The page's own code might cancel the navigation. The visitor might have held a modifier key.

So Traceten records a destination only when the click looks like a real departure, and throws it away if the page does not actually go away soon after.

The fifteen-second window matters more than it looks. Without it, a click whose navigation was cancelled would sit waiting and attach itself to whatever exit fired next, perhaps minutes later when the visitor switched tabs. The report would then say someone left for a site they never opened.

Two more choices are deliberate. The destination is stored as a bare hostname, such as github.com, with no path and no query string, because the query string of someone else's URL is exactly where email addresses and tokens end up. That rule is enforced a second time when the event arrives, not just in the script: anything that is not a bare hostname is refused. And the destination rides on the exit event that was going to be sent anyway, so recording it adds no events of its own.

This is a different design from counting outbound clicks. GA4's enhanced measurement, for example, records a click event each time a user clicks a link that leads away from the current domain, with the link's domain and full URL. That answers "which outbound links get clicked". The approach here answers "where did this visit go when it ended". Both are useful, and they will not agree, because they count different things.

Three patterns are worth looking for once the data is in.

Pages that end AI visits without a sale. Take the visits from one assistant and read their exit pages. If a large share of Perplexity visits end on a docs page with no destination, that page is where the assistant sent them and where the question stayed unanswered. It is usually the page to improve first, and it is the same page the assistant is citing.

Departures that are successes. A visitor who leaves for your payment provider's checkout, your app's sign-in domain or your own GitHub repository has not been lost. Before reading destinations as leakage, list the domains that mean the visit worked.

Departures to a competitor. A steady stream of AI visitors leaving a comparison or pricing page for one competitor's domain is a direct signal: something on that page sends people there. Sometimes that is an honest outbound link you want to keep. Sometimes it is a stale comparison that the assistant quoted and your page then contradicted.

In Traceten, destinations appear in the Exit link tab of the Pages card, which counts the visitors who left for each hostname and answers the same filters as the rest of the page, so scoping it to one assistant is one filter. Each visitor's timeline shows the exit page and the destination for every visit, and the session list you can pull through the API or the MCP server carries each session's exit page.

The honest limits are the ones in the table. Links that open a new tab are invisible as destinations, and a visitor who simply closes the tab has an exit page and nothing else. Both are better than the alternative, which is a report full of departures that did not happen.