Search Console plus a self-hosted Plausible or Umami instance replaces GA4 for SEO measurement on a content site — with a sub-2KB script instead of ~90KB of gtag, no consent banner under most readings of EU rules, and the visitor data in your own Postgres. The division of labour is clean: Search Console owns everything before the click (queries, positions, CTR, indexation), your analytics owns everything after (which pages hold readers, where they go next, what converts). Neither substitutes for the other; the pairing is the product.

The three candidates

Plausible CEUmamiMatomo
Tracking script<1KB~2KB~60KB (est., gzipped)
BackendElixir + Postgres + ClickHouseNode + Postgres/MySQLPHP + MySQL/MariaDB
RAM to run comfortably~2GB~512MB~1GB
LicenseAGPL-3.0MITGPL-3.0
Cookie-free by defaultYesYesConfigurable
Funnels, ecommerce, heatmapsBasic goalsBasic eventsYes (closest to old GA)

The short version: Umami is the lightest thing that does the job — a single Node container beside a Postgres you probably already run. Plausible's dashboard is the most polished and its goal tracking a bit richer, at the price of a ClickHouse dependency that wants ~2GB of RAM. Matomo is the one that still feels like Universal Analytics, which is precisely why teams migrating off GA4 with complex reporting requirements pick it, and why nobody else should. The full head-to-head lives in ditching Google Analytics.

What Search Console knows that analytics never will

Query-level data exists only in GSC: what people searched, where you ranked, what share clicked. No tracking script can see a SERP. GSC's own blind spots run the other way — it anonymises a meaningful share of long-tail queries out of the report entirely, retains only 16 months of history, and tells you nothing about what visitors did after arriving.

Two operational habits close the gaps. Export GSC data monthly via the Search Analytics API into your own storage (the API returns up to 25,000 rows per request versus the UI's 1,000), so history survives past 16 months and the long-tail mining workflow has raw material. And join the two datasets on landing page: GSC's query-to-page mapping plus analytics' page-to-behaviour mapping is the full funnel — which queries land readers who actually read, versus which land bouncers a snippet over-promised.

Event modelling for a content site

Pageviews answer almost nothing an SEO actually asks. Four events carry most of the signal on this site:

  • Outbound clicks to project repos and docs — for a directory, the conversion. A comparison page whose readers click through to a GitHub repo did its job; one with zero outbound clicks is decorative.
  • Internal search queries — free keyword research from your own readers; every no-results search is a content gap with a name.
  • Read completion on money pages, fired at a scroll threshold.
  • Code-block copy events on guides — the sharpest "this page worked" signal a technical site gets.

The wiring is one attribute or one listener:

<script defer src="https://stats.selfhostindex.com/script.js"
        data-website-id="c3b1..."></script>
// count clicks out to project repositories (Umami)
document.querySelectorAll('a[href*="github.com"]').forEach((a) =>
  a.addEventListener("click", () =>
    umami.track("outbound-repo", { repo: a.hostname + a.pathname })
  )
);

Keep the event list under ten. Every event you add is a dashboard you're promising to look at, and analytics you don't read is load time spent on nothing.

Cookieless, non-cross-site analytics generally falls outside consent requirements — Plausible and Umami run this way by default, and Matomo can be configured to qualify for the French CNIL's exemption list. The usual caveat: this is the vendors' well-documented position and the mainstream reading, not legal advice for your jurisdiction. The performance side is not in dispute, though — no banner means no consent-platform JavaScript and none of the layout shift banners cause, which is one of the five fixes in Core Web Vitals on static sites.

Sizing and operations

These tools are small. Umami on a 1 vCPU / 1GB VPS handles over a million pageviews a month without attention; Plausible CE wants 2GB mostly for ClickHouse's sake; storage grows slowly because events are tiny rows. Two operational notes that outrank sizing: back up the analytics database nightly — it is the one dataset on your server you can never re-derive — and put the instance on your own subdomain (stats.yourdomain.tld), which keeps first-party status and incidentally survives most list-based blockers that would eat a GA request.

Expect your numbers to read lower than GA4's did, and trust them anyway. Cookieless counting is honest about repeat visitors, and all three tools drop known bots by user-agent — though none catches headless traffic that executes JavaScript, so a "visitor" spike with zero engagement events is usually a scraper, not an audience.

What I'd do

Umami for most sites: MIT-licensed, 512MB, two containers, done. Plausible if the nicer dashboard is worth an extra gigabyte of RAM to you. Matomo only for a genuine GA4-refugee feature list — funnels, ecommerce, per-user drill-downs. Whatever the pick: pair it with a monthly GSC API export from day one, wire the four events above, and delete every report you haven't opened in a quarter. Owning your analytics only pays if the instance stays light enough that you never resent running it.