Measuring a Site With No Analytics

This site loads no analytics, no tag manager, no third-party fonts, and no third-party scripts of any kind. Not "no tracking cookies". No third-party requests at all. The content security policy is 'self' across every directive plus one hashed inline script, so if somebody added a tag tomorrow the browser would refuse to run it.

That is a defensible position to hold and an inconvenient one to live with, because the obvious next question is how you know whether anything is working. This is the answer we arrived at. It is narrower than a dashboard and, for a site like this, sufficient.

Why the constraint exists

Two reasons, and only one of them is about privacy.

The privacy reason is straightforward: the site's own privacy policy and cookie notice state that there is no analytics and no tracking. Adding a tag would make those documents false, and would create a genuine consent obligation where currently none exists. The cheapest consent banner is the one you never need.

The security reason is the one engineers underrate. A third-party script is executing code you do not control, on a page where your users are, delivered from infrastructure you do not own. A strict script policy is the single highest-value header a static marketing site can ship, and it only works if the exception list is empty. One analytics tag does not slightly weaken it; it establishes that the list can have entries, and then it has entries.

The cost is real and worth stating: no session recording, no funnels, no attribution, no real-user performance data, no A/B testing. If your business depends on those, this posture is not for you. If it does not, you are paying for them in consent complexity and attack surface without noticing.

What you can still see, and it is more than people expect

Search Console, which needs no page tag

This is the one people forget is server-side. Search Console reports what happened in search results, and it learns nothing from your page: verification can be done at the DNS layer, and a domain property covers every subdomain under it, so one record covers a corporate site and a product site together.

What it gives you that matters:

Query-level impressions, clicks, position, and click-through rate. This is the important one, because it is the only source that tells you what people were looking for, as opposed to what they did once they arrived. An analytics tag cannot tell you that at all any more.
Page-level performance, which is enough to answer whether a page is earning attention.
Indexing state per URL, including the difference between "not indexed" and "indexed but not ranking", which are entirely different problems with entirely different fixes.
Rich-result validity for your structured data, which is how you find out that a schema change broke something.

The important habit is comparing periods rather than reading absolutes. A new site's numbers are meaningless on their own and informative against last month.

CDN access logs, which are the closest thing to server-side analytics

Both of our distributions write standard access logs to object storage. Every request, with timestamp, path, status, bytes, referrer, user agent, and edge location. No client script involved, because the CDN is already in the path.

From raw logs you can derive, with nothing more than text processing:

Requests per page over time, which is your traffic trend.
Referrers, which is your discovery mix, including the ones search consoles never show you.
Status-code distribution, which surfaces broken internal links and missing assets far faster than any crawl.
Crawler behaviour by user agent, separated from human traffic, which matters more than it used to now that assistants fetch pages on a user's behalf.
Rough sequencing: the same client requesting page A then page B is a reasonable proxy for a path, which is not a funnel but is enough to see whether an internal link is used.

Two caveats to state honestly. Logs count requests, not people, and caching means a returning visitor may not generate one. And retention is finite: ours expires on a schedule, which means a baseline you did not take is a baseline you cannot recover. Take the snapshot before you change anything.

The application's own structured logs

Anything that involves your own backend is measurable without a client tag, because the request already reaches your code. Form submissions, verification steps, API calls: all countable server-side. The privacy discipline is the same as everywhere else, which is that these are user records subject to the same handling rules, not an exempt telemetry zone.

What you genuinely cannot get

Being specific about this is the difference between a posture and a rationalization.

Scroll depth and time on page. Gone. There is no server-side proxy for engagement, and the honest response is to stop using engagement as a metric rather than to approximate it badly.
Cross-page sessions with confidence. Log-based sequencing is an approximation and degrades with caching and shared addresses.
Real-user performance data. Lab tools measure a synthetic visit, not your actual visitors' devices and networks.
Attribution. Referrers tell you the last hop, not the path. If you need multi-touch attribution, you need a tag, and you should price the consent and security cost into that decision honestly.

The measurement discipline this forces, which is the actual benefit

Removing the dashboard removes the temptation to watch it. What replaces it is narrower and, we would argue, better suited to a site whose job is to be found and to be read.

Take a baseline before changing anything. Export the query and page reports, and archive the log summary. Without this, every later number is uninterpretable.
Define what each page is for before publishing it, in terms of the queries it should own. A page with no query set is a page you cannot evaluate.
Review on a slow cadence. Search results move on a timescale of weeks. Daily checking produces noise and the false sense that something is happening.
Watch for the two pages competing. If two of your own URLs trade positions on one query, that is a content problem no analytics tool would have told you about, and Search Console shows it plainly.
Treat "indexed but not ranking" as the interesting case. It usually means the page exists and does not deserve the position yet, which is a writing problem rather than a technical one.

Would we recommend this to a client?

For a marketing site whose goal is discovery and credibility, yes, and we would point out that most of the analytics on most such sites is never acted on. For a product with a conversion funnel worth optimizing, no: instrument it, and do it server-side where you can, so the data stays in your own boundary and the consent story stays simple.

The version of this argument that generalizes: the reason to avoid a third-party script is not ideology, it is that you cannot audit what you cannot see, and a marketing site is an odd place to make your first exception. It is the same reasoning we apply to model providers and to where a model runs: know what leaves your boundary, and decide it deliberately rather than by default.

Measuring a site with no analytics