# Server-side tracking > Server-side tracking records a request where it arrives — at the server or edge — rather than from a script running in the visitor's browser. For crawler measurement it is not an optimisation but the only option: an AI crawler takes the HTML and leaves without executing JavaScript, so a browser tag never runs and never reports. **Category:** Analytics **Also known as:** server-side analytics, log-based analytics **Updated:** 2026-09-09 **Source:** https://truestat.io/glossary/server-side-tracking --- ## The blind spot, precisely A browser analytics tag is JavaScript. It reports a page view when the browser parses the page and runs the script. A crawler that requests the HTML, reads it and closes the connection never runs anything — so from the tag's point of view the visit did not happen. This is not a gap any client-side product can close, and it applies to every one of them equally. If your analytics has never mentioned `GPTBot`, that is why. ## What server-side sees that a tag does not The crawler visits, obviously. Also: requests that returned a 404, which a tag cannot report because there was no page to run it on; requests for `robots.txt`, `sitemap.xml` and `llms.txt`, which are the clearest deliberate-machine-reading signals available; and the source address, which is what makes verification possible at all. The last one matters most. Verification needs the IP, and the IP is only present server-side. ## What it does not replace Everything about human behaviour on the page. Scroll depth, clicks, time on page, whether a form was abandoned halfway — all of that happens in the browser and stays there. The two are complements rather than alternatives. A browser tag for people, a server-side path for machines, and separate figures for each — mixing them is how a crawler sweep turns into a traffic spike nobody can explain. ## Where the measurement runs Three places, with different trade-offs. **In the application.** A middleware or request hook reports each request as it is handled. Simplest to add, sees exactly what the application sees, and misses anything served before the application runs — a cached page, a static asset, a request the CDN answered. **At the edge.** A worker at the CDN reports before the origin is reached, so cached responses are counted too. More complete, and it costs an edge invocation per request. **From the logs.** Parsing access logs after the fact catches everything and requires no code in the request path at all. It is also the slowest to arrive and the most awkward to operate, since log formats differ by server and rotation makes real-time reporting impractical. For crawler measurement specifically the first is usually enough: crawlers request pages rather than assets, and a page request reaches the application on most setups. The reason to move to the edge is a heavily cached site, where the origin never sees the traffic being measured. ## What goes wrong - Sending every request to the analytics endpoint. Human page views already arrive through the browser tag; forwarding them again double-counts. - Forgetting asset requests. Images, stylesheets and framework paths are not page views, and counting them inflates crawler numbers by an order of magnitude. - Counting your own infrastructure. Measured here: a favicon fetcher on our side produced 336 phantom crawler records in a day against 98 real ones, and billed the customer for them. ## Worth doing - Filter at read time rather than at ingest — a dropped event never comes back, while a labelled one can be re-evaluated. - Keep the crawler figures on their own axis. A training sweep is not a traffic spike and should never be drawn as one. ## Questions ### Does server-side tracking need a cookie? No, and for crawlers the question does not arise — a crawler carries no cookie and needs no identity beyond the operator and the address. ### Will this slow down my site? It should not. The report is fired without waiting for it and its failure is swallowed, so a slow or broken analytics call cannot hold up a page. Anything that does not work that way is a bug. ### Can I run both server-side and a browser tag? Yes, and for most sites that is the right setup — the tag for human behaviour, the server path for machines. The thing to avoid is counting the same human page view through both, which doubles your numbers and your bill. ## Related - https://truestat.io/glossary/bot-filtering - https://truestat.io/glossary/ai-answers - https://truestat.io/glossary/cookieless-analytics --- From the TrueStat glossary — https://truestat.io/glossary. Privacy-first web analytics that also shows you which AI assistants are reading your site.