Statistics

What Each Card Shows

1. Page views by hour — every page load reported by the browser over the last 24 hours, broken down by the hour in UTC, most recent first. The number on the right is the 24-hour total. A row's bar is proportional to the busiest hour in the list, so it shows the shape of the day rather than an absolute scale. 2. Visitors and activity — a visitor is a distinct in-memory session id, not a person and not a device. Reloading a page counts as another view but not another visitor; opening a second tab is a second session. Views per visitor is views divided by visitors over the same window. Events are the interactions the script records, currently clicks on outbound links and the time a page stayed visible. 3. Day by day — calendar days in UTC rather than a rolling window, so the figures line up with how a report would quote them. The number on the right is the seven-day total, which is a rolling figure and therefore does not equal the sum of the rows shown once there are more than ten days of data. 4. Most viewed pages — the ten paths with the most views in the last 24 hours. A path with many views but few visitors is usually one person navigating back and forth rather than many people arriving; comparing the two numbers is the point of the card. 5. Sources, masked to a network — the share of views by originating network. The address is truncated at the collector before anything is written to disk: IPv4 keeps three octets and IPv6 keeps four groups, so a row reads 203.0.113.0/24 or 2001:db8:1:2::/64. A network can be a household, an office or a data centre; it is never a person and a full address is never stored, so one can never be published. The ring shows the ten busiest networks with everything else grouped as Other. 6. Where visitors came from — the share of arrivals by referring host, taken from the browser when it arrives from another site. Only the host is kept, never the full referring URL. Direct visits, bookmarks, links in apps and most AI assistant links carry no referrer at all, so they cannot appear in this card; that is why the totals here are small compared with page views. 7. Browsers — a coarse family (Chrome, Safari, Firefox, Edge, Other) derived from the request when it is collected. It answers the only question this site needs it for: does the site work for the browsers people actually use. The full user-agent string is never stored. 8. Viewports — the window class at the time of the page view: under 768px counts as mobile, under 1200px as tablet, otherwise desktop. It comes from the window width, not from the device model, so it describes the layout in use rather than the hardware. 9. Languages — what the browser asks for in its Accept-Language header. It says what the visitor expects, not where they are: no location data is collected or inferred anywhere on this site. 10. 🔎 Search engine referrers — which engine sent traffic and how many times, with the time the figures were last rolled up. The figures are read from our own server logs over the last 24 hours, so they include every request that arrived with a search or AI referrer — including clients that never run JavaScript. A referrer identifies the engine, never the query: engines stopped sending search terms in 2011. Where the browser beacon has seen engines of its own, they appear in the same matrix underneath, counted from people only. 11. What AI engines fetch most — counted from the server logs rather than the beacon, so it covers crawlers that never run JavaScript. Each row is a path, the number of requests from recognised search and AI engine user agents in the window, and which engines they came from (Googlebot, ClaudeBot, PerplexityBot, OAI-SearchBot, ChatGPT-User, CCBot and similar). This is the closest honest signal of what AI engines index here. It is not a list of queries: engines do not send those. 12. Referrers and the keywords we cannot see — the referring host next to the landing page it sent the visitor to, plus why the query itself is absent: search engines stopped passing search terms in the referrer in 2011 and AI assistants pass none at all, this site stores the referring host only and never the full URL, and we do not reconstruct queries by tracking people. If a query reaches us in a form we can see — a contact form, an email — it stays where the visitor wrote it. the honest statement of why query terms are absent and what is used instead.

How This Data Is Collected

Source. One small script of ours, /assets/stats.js, is served from this domain and runs on every page. When a page loads it reports a page view to our own endpoint with navigator.sendBeacon() — the W3C Beacon API, chosen because it does not block the page and survives the tab being closed — with fetch(keepalive) as a fallback. When the page is hidden or left, it reports the dwell time. There is no analytics product in the chain and no third party receives anything: the request goes from your browser to this server and nowhere else.

Definitions. A view is one page load reported by the browser. A visitor is a distinct in-memory session id, deliberately not a person and not a device: two people on one laptop are two sessions, one person in two tabs is two sessions, and a reload is another view but not another visitor. An event is one recorded interaction, currently outbound clicks and the visible dwell time. Each card states its window, and the JSON copies carry the same window and the same definitions.

Privacy by construction. No cookie is set and nothing is written to your device, so there is no storage or read on terminal equipment for Article 5(3) of the ePrivacy Directive (2002/58/EC) to bite on, and there is nothing that follows anyone between visits. Do Not Track is honoured as set out in the W3C Tracking Preference Expression. The raw IP address never reaches disk: the collector truncates it first — IPv4 to /24, IPv6 to /64 — then keeps only a salted one-way hash for rate limiting. Truncating the last IPv4 octet is the same boundary Google Analytics applies in its IP-anonymisation setting, and the Article 29 Working Party's Opinion 05/2014 on anonymisation techniques is the reference for why truncation and one-way hashing reduce identifiability; /64 is the end-site prefix that RFC 6177 assigns to a single subscriber. Referrers are reduced to the host (the Referer field of RFC 9110, §10.1.3, is the only source) and user agents to a browser family; no location data is collected or inferred.

Scope. Visits from our own networks and the paths we use for load testing are excluded when these figures are rolled up, so the numbers are not our own testing. The raw events stay in our database untouched, and the exclusion is declared in the JSON as excluded_internal.

Refresh and retention. The beacon reports as you browse; the roll-up that turns events into the figures above runs every five minutes, and this page is rebuilt from that roll-up, so numbers can lag a few minutes behind a visit. Raw events are kept for ninety days and then deleted; only the published aggregates remain.

What this data cannot show. It cannot show search terms: engines stopped passing them in the referrer in 2011, and assistants pass none at all, and we do not reconstruct them by tracking people. It cannot show anyone who does not run JavaScript, which includes most crawlers — crawlers are identified by user agent, the field the Robots Exclusion Protocol (RFC 9309) governs, and are counted on the log side at /live/. It cannot show location. And it cannot inflate a small number: the site is young, the traffic is genuinely small, and a real small figure beats an impressive invented one.

Check it yourself. The same aggregates are published as JSON at stats.json, traffic.json and pages.json; the numbers there and on this page are written by the same job; and the script producing the raw data is a single readable file, /assets/stats.js.

Sources and Standards

Where this page makes a claim about how measurement works, the claim comes from one of these, in the order they are first relied on above.

• RFC 9110 — HTTP Semantics, §10.1.3 Referer: the field a referrer is read from, and why only the host survives our reduction.
• Google, “Making search more secure” (October 2011): the change after which search terms are no longer passed in the referrer, which is why card 10 and card 12 can show an engine but never a query.
• W3C, Referrer Policy: the cross-origin defaults under which an HTTPS search sends only the origin, not the path or query.
• W3C, Beacon API: the one-shot, non-blocking report this page’s script uses.
• W3C, Tracking Preference Expression (Do Not Track): the signal we honour.
• Directive 2002/58/EC (ePrivacy), Article 5(3): the rule about storing or reading information on terminal equipment, which this measurement does not engage because it stores nothing on the device.
• Article 29 Working Party, Opinion 05/2014 on anonymisation techniques: the reasoning behind truncation and one-way hashing as a reduction in identifiability.
• RFC 6177 — IPv6 Address Assignment to End Sites: why /64 is the network boundary used here.
• RFC 9309 — Robots Exclusion Protocol: the user-agent field that separates crawler traffic from human traffic.