Aren't visible hit counters a good way to show popularity?

Usually not. A public counter rarely helps a prospective customer decide anything, and it typically counts page loads or requests rather than people. Keep operational traffic data in a private dashboard, and publish social proof that's specific and verifiable instead — genuine testimonials, accurate and current claims.

Do I need a cookie banner if I use privacy-friendly analytics?

Not necessarily — but "cookieless" is not the legal test. What matters is whether the deployed setup stores or accesses anything on the visitor's device, uses other tracking techniques, or processes personal data. Personal data needs a lawful basis and privacy information under GDPR; nonessential storage or tracking generally needs prior consent, while strictly necessary technologies may be exempt. Rules vary by country and configuration, so a vendor's label never proves compliance — check how your actual setup behaves.

How do I find my most common broken links from a log file?

In a verified log format, filter for 404 responses and count the normalized paths (usually without query strings). Fix broken internal links first; use a 301 only where the URL permanently moved to a relevant replacement, and let genuinely gone content answer an honest 404 or 410. Referrers help trace the source but are often missing — crawl your own site as well.

Are you measuring useful actions, not vanity traffic?

A raw pageview total is rarely useful by itself: it goes up, it feels good, and without context it decides nothing (its honest uses are spotting outages, seasonality and big demand shifts). What's worth measuring is what informs a decision — inquiries, confirmed conversions, which pages support important actions and where visitors abandon a process, broken links, which sources send engaged visitors. Server logs and correctly configured analytics can answer those questions — provided you track successful outcomes and know what each source misses.

Skip vanity counts, watch actions

The old "You are visitor 000487" badge incremented on page requests — people, bots and reloads lumped together — and put the tally on display, which mostly looks dated. Delete it. What matters isn't how many hits you had, but what people did:

Conversions and inquiries — form submissions, calls, bookings, sign-ups. Track confirmed outcomes where possible — the accepted form, the completed payment — not just clicks on a submit button, and reconcile the totals against real orders now and then.
Where visitors arrive, stay, and act — and which page is often the last one they see. A high exit isn't automatically a "leak": the visitor may have finished, called, or downloaded what they came for, so read exits alongside goal completions and referrers before concluding a page loses people.
Referrers — which sources send engaged visitors. Knowing the data is incomplete: apps, private messages, copied links and privacy protections all strip referrers, so "direct" traffic is a mixed bag, not people typing your address.

A metric with no decision attached is decoration. For every number you track, ask: "if this changes, what would I do?"

What your logs tell you

With access logging enabled, Apache or Nginx records the requests that reach that server — behind a CDN or proxy, cached responses and edge-served errors may only exist in the edge service's logs, and the origin needs client-IP restoration from the trusted proxy only or every line shows the proxy's address. Scan for:

404s — broken internal links, mistyped URLs, or files you deleted but still link to.
5xx responses — server-side failures visitors may hit without anyone reporting them; read the whole range (502/503/504 included) and correlate with your monitoring.
Redirects — individual 301/302 lines don't reveal chains; follow important URLs with a crawler or curl -I to find multi-hop paths, each hop costing a round trip for whoever meets it.
Bot traffic — crawlers and scrapers can materially inflate request counts. Filter, knowing some automation always slips through.

For a standard (Combined) log format, one line answers "which missing paths get requested most":

awk '$9 == 404 { split($7, u, "?"); print u[1] }' access.log | sort | uniq -c | sort -rn | head

Verify your log format first — field positions are configurable — and remember one more thing: logs are personal data. They hold IPs, user agents and referrers; restrict access, keep them only as long as needed, and never log secrets or personal details in URLs.

Analytics without the privacy baggage

Analytics estimates what measured browsers do after a page loads — it can include undetected automation and misses visitors who block scripts or decline consent, so treat the numbers as directional. Prefer a configuration that minimizes data, avoids cross-site advertising identifiers, and uses no nonessential storage on the visitor's device — tools marketed as privacy-first (Plausible, Fathom, Matomo, Cloudflare Web Analytics are examples) can be set up this way, but it's the deployed configuration that counts, not the label: verify what's stored, what's collected, where it goes, and what your legal duties are (see the FAQ). The useful output is the same either way: top pages, referrers, entry and exit points, goal completions.

Exclude identifiable test and staff traffic where practical — on a low-traffic site your own team can visibly distort the numbers — and document the exclusion rule so it doesn't quietly swallow real customers on shared networks.

Measure what leads to a decision, act on it, and let real visitor behavior guide what you fix and build next.

What to do

Set a recurring reminder (weekly or monthly) to actually look at the data — it's worthless unread.
Remove any visible hit-counter widget; keep your dashboard private.
Define the actions that matter and track their confirmed outcomes as goals, reconciled against reality.
Work through your top 404s: fix internal links, 301 genuinely moved URLs to relevant replacements, and let gone-for-good content answer 404/410 honestly.
Filter bots and staff traffic before trusting any count — and treat logs as sensitive data with restricted access and limited retention.
Use longer trends for business conclusions — and investigate any single-day change that's large or unexpected, because that's how outages and broken tracking announce themselves.