How to track website traffic without cookies or trackers
Every request a browser makes already tells the server which page was asked for, when, and usually which site sent the visitor. Counting those requests on the server, without storing anything in the visitor's browser, answers the questions most small sites have: how many visits, from where, and whether a change made a difference.
What a request tells you
When someone opens a page, their browser sends a request with a few headers. Three matter for analytics:
- The URL
- Which page, plus any query string such as
?utm_source=newsletterthat you added to a link yourself. Referer- The page the visitor came from, if any. MDN's Referer reference explains that the browser's referrer policy decides how much is sent; for links from other sites, browsers usually send only the origin, such as
https://www.google.com/, not the full search. User-Agent- The browser or program making the request. It separates people's browsers from search crawlers and AI crawlers that announce themselves.
From those alone you can build a daily count by source: search, social, AI assistants, other sites, direct visits and campaigns you tagged. No cookie, no script and no stored identifier is involved.
Setting it up, in order
- Decide the questions first. "How many people found us through search this month?" and "Did the newsletter send anyone?" are answerable. "What did each visitor do?" is not, without tracking individuals.
- Pick where counting happens. Your host's built-in statistics, your web server's logs, or a privacy-focused analytics service that counts on its own servers. Avoid anything that sets a cookie or loads a third-party script if your aim is to skip consent.
- Drop what isn't a person. Filter known crawler user agents, prefetch requests and repeated requests from the same page. Keep crawler counts separately: they're useful in their own right.
- Group referrers into sources. Map hosts to categories (google.com and bing.com to search, linkedin.com to social, chatgpt.com to AI) and keep a list for anything else.
- Tag your own links. Add UTM parameters to links in emails, adverts and posts, so visits from them are counted under the campaign rather than lumped into direct.
- Store totals, not people. Keep counts per day and source. Don't store IP addresses or full user agents beyond what you need to filter bots.
What this data can and can't answer
| Answers well | Can't answer reliably |
|---|---|
| Visits per day and how they change | Unique visitors over a week or month |
| Which sources send people | How many times one person came back |
| Whether a campaign link was used | The path one visitor took through the site |
| How often crawlers visit | Which visit led to a sale days later |
| Busy days and quiet periods | Anything about who the visitor was |
If you need the right-hand column, you need identifiers, and with them come consent and privacy duties. Many small sites find they don't.
Does cookieless analytics still need consent?
The consent rules for cookies cover storing or reading anything on the visitor's device, not just cookies. The ICO's guidance on cookies and similar technologies says consent is needed unless the storage is strictly necessary for a service the visitor asked for. Counting requests on the server stores nothing on the device, so that rule isn't triggered. Fingerprinting, which builds an identifier from device details, is a different matter and is generally treated like a cookie. You still describe your analytics in your privacy policy. The cookie banner guide goes into the consent question in detail; this is practical guidance, not legal advice.
Common mistakes
- Counting bots as visitors. A spike at 3am from one user agent is a crawler, not a viral post.
- Treating direct as "typed the address". Direct also includes apps, email clients and links that stripped the referrer. Tag campaign links to shrink it.
- Comparing with a cookie-based tool's numbers. The two count different things. Pick one and compare it only with itself over time.
- Reading single days. Small sites have noisy daily counts. Look at weeks, and at the same weekday across weeks.
Check it's working
Visit your site from a link in an email you send yourself, tagged with utm_source=test, and from a search result. The next day you should see one campaign visit and one search visit. Then open the site directly and confirm it shows as direct.
Analytics on Anticode sites
Anticode counts page views per site per day by source, without cookies, and shows them in the dashboard. Sources include referrals from AI assistants, and AI and search crawlers are counted separately from people. Published pages carry no third-party trackers. The Intelligence page answers questions about visits since publish from cited metrics, and only forecasts once there are fourteen days of data.
Limits worth knowing: the counts are daily totals per site and source, with no per-visitor journeys, no unique-visitor figures, no heatmaps and no A/B testing, and no third-party analytics can be added to design-engine pages because they run no scripts. For campaign tagging, see UTM parameters explained.
Questions people ask
Can I count unique visitors without cookies?
Not reliably. Any method that recognises the same person on a later day needs an identifier, whether a cookie or a fingerprint, and that brings back the consent question.
Are server logs enough?
For basic counts, often yes. They record each request with its referrer and user agent. You'll need to filter bots and group sources yourself, or use a tool that reads logs for you.
Why do AI assistants show up as a source?
When someone clicks a link in an assistant's answer, the browser usually sends the assistant's site as the referrer, so the visit can be grouped like search or social.
Sources
- MDN: Referer header, checked
- ICO: Cookies and similar technologies, checked