How to Set Up Umami Analytics on a Static Site

June 19, 2026 · 11 min read · How-to

You cannot improve what you do not measure, but mainstream analytics scripts are heavy and cookie banners scare away early visitors. Umami is an open-source, privacy-focused analytics tool that tracks page views and events with a lightweight script—no cookies required for default pageview collection. This how-to explains how to add Umami to a static HTML site using the official Umami documentation for websites and Cloud or self-hosted instances.

Pick Umami Cloud or self-hosted

Umami Cloud (umami.is) is the fastest path: create an account, register your website, and copy a tracking snippet. Billing is usage-based with a sensible free trial for small projects. Self-hosted Umami runs on your VPS, Railway, or Fly.io with PostgreSQL or MySQL—more control, more ops. For a single landing page launch, Cloud saves time. For teams already running Docker infrastructure, self-hosting keeps data in your environment. Both options expose the same data-website-id tracking pattern.

Register your site in Umami

In the Umami dashboard, click Add website. Enter your production domain (for example, example.com) and a display name. Umami generates a website id UUID. If you test on *.pages.dev before cutover, add that hostname as a separate website entry or use a staging property—mixing staging and production data skews conversion analysis. Official docs recommend one website entity per distinct origin you want reported separately.

Install the tracking script

Umami provides a deferred script tag. Place it in <head> or just before </body> on every page you want tracked. For LaunchStatic templates, adding the snippet to a shared layout is ideal; with plain HTML duplicates, paste the same block into each file or maintain a small build step that injects it.

<script defer
  src="https://cloud.umami.is/script.js"
  data-website-id="00000000-0000-0000-0000-000000000001">
</script>

Replace the src host if you self-host (https://analytics.example.com/script.js). Replace the UUID with your real website id. The defer attribute keeps parsing non-blocking, which helps Lighthouse performance scores compared to synchronous legacy analytics.

Track custom events (optional)

Pageviews alone may not answer whether visitors clicked "Join waitlist." Umami supports custom events via umami.track() once the script loads. Add a small inline handler on important buttons.

<button type="button"
  onclick="umami.track('cta_click', { placement: 'hero' })">
  Get early access
</button>

Keep event names stable—renaming breaks historical comparisons. Document event names in your internal readme so marketing and engineering speak the same language.

Privacy, cookies, and consent

Umami's default script does not use cookies for basic pageview tracking, which simplifies cookie banners in many EU contexts. You are still collecting processing-related data (IP addresses may be truncated or discarded depending on configuration—check your instance settings and Umami's privacy documentation). Update your privacy policy to name Umami, describe what is collected, retention, and legal basis. If you also run Google AdSense later, reassess consent requirements—analytics and ads are treated differently under ePrivacy guidance.

Verify data flows before launch

Open your site in a private window, navigate across two pages, and wait 30–60 seconds. The Umami realtime view should show an active visitor. If nothing appears, check ad blockers (they often block analytics domains), confirm the website id, and verify CSP headers are not blocking script-src. Cloudflare Rocket Loader occasionally interferes with third-party scripts—disable it for HTML-only projects if scripts fail to execute.

  • Script present on all public HTML pages including 404
  • data-website-id matches dashboard entry
  • Production domain registered in Umami
  • Privacy policy mentions analytics provider
  • Custom events fire on primary CTAs

Operate after go-live

Set up weekly email reports if your plan includes them. Watch referrers to learn which launch posts drove traffic. Pair Umami with Search Console for query data Umami does not provide. Export or API-access metrics before cancelling a Cloud subscription so you retain historical launch baselines.

Exclude your own visits

Founders skew analytics by refreshing obsessively. Umami supports ignored IP addresses and browser opt-out flags—check your instance settings. Alternatively, use a browser extension blocker during development and a separate staging website id so local testing does not inflate production numbers. Document which approach you chose so co-founders do not wonder why Tuesday traffic spiked internally.

Compare Umami with Plausible and GA4

Plausible offers a similar lightweight script with hosted pricing. Google Analytics 4 is free but heavier, cookie-dependent, and subject to stricter consent requirements in the EU. For a LaunchStatic landing page, Umami or Plausible usually wins on performance and privacy copy simplicity. If you later need funnel attribution across paid ads, reassess—but do not install GA4 by default on a one-page waitlist without a consent strategy.

Self-hosting considerations

Self-hosted Umami requires a database and periodic updates for security patches. Back up analytics data before upgrades. Place the analytics subdomain on the same Cloudflare account for consistent TLS—analytics.example.com is a common pattern. Restrict dashboard login with strong passwords and ideally SSO if your team grows. The tracking script still loads from your subdomain, so include that host in your Content-Security-Policy script-src if you deploy CSP headers via Cloudflare Transform Rules.

Set a dashboard password before exposing the instance to the public internet. Scan dependency advisories for Umami releases quarterly—self-hosting shifts patch responsibility from the vendor to your team.

Document your website id in the project README next to the Formspree form id so the next deploy does not accidentally paste staging analytics into production HTML.

If you run both Umami and server-side Cloudflare Web Analytics, say so in your privacy policy. Visitors deserve clarity when multiple analytics layers fire on the same page view.

Schedule a calendar reminder to review analytics retention settings every six months—old data you no longer need should be deleted to match your published retention claims.

Related: Analytics tools comparison Privacy policy how-to Add JSON-LD schema Landing page templates

Does Umami work without a build step?

Yes. Paste the script tag into static HTML files. No bundler or npm install is required on your site.

Will Umami slow my Lighthouse score?

The default script is small and deferred. It typically impacts performance far less than legacy analytics tags.

Can I track multiple subdomains?

Create separate websites in Umami per hostname or use event properties—see Umami docs on domains and websites.

Do I need a cookie banner for Umami?

Often simplified versus cookie-based analytics, but you still need accurate privacy disclosures. Consult your counsel for EU traffic.

Measure your launch

Deploy a template, add Umami in one script tag, and know which pages convert.

Browse templates See recommended tools