WordPress analytics: GA4 and privacy-friendly options

You need traffic data. You do not need five analytics plugins, three overlapping JavaScript beacons, and a privacy policy that nobody updated since Universal Analytics died.

This guide is for WordPress owners who want a sensible analytics pick and a security bar that matches any other extension. It is not a feature-by-feature scorecard that goes stale in six months. Revisit consent and cookie notices with your own counsel; this is not legal advice.

What WordPress analytics actually does

Analytics on WordPress usually means one of these:

• A plugin (Google Site Kit, MonsterInsights, Matomo plugin, and others) that injects tracking code
• A tag manager snippet in the theme or a small custom plugin
• Host or CDN stats (no WordPress plugin required)
• A first-party script on your own domain (self-hosted Umami, Matomo, and similar)

All of them answer: who came, what they viewed, and sometimes how they arrived. None of them stop malware or patch a vulnerability. Treat the install like any other plugin decision.

Quick comparison: GA4 and common alternatives

Choose based on legal needs, budget, and how deep reports must go. A freelancer blog and a WooCommerce store with ad spend do not need the same stack.

Why WordPress sites stack trackers (and why to stop)

The usual pile-up:

1. Site Kit installed during a “connect Google” moment
2. MonsterInsights left from an old agency setup
3. A GTM container in the theme header
4. A Facebook Pixel plugin that also loads Google tags
5. A theme demo script nobody removed

Each layer loads JavaScript on every page view. That hurts performance, pollutes data, and widens the plugin supply chain. When a tracking plugin is abandoned, it becomes the same class of risk as an abandoned form plugin.

Rule: one primary analytics path. If marketing owns GTM, load GA4 through GTM and turn off the WordPress plugin duplicate.

Security checklist for analytics on WordPress

Before you install or keep a tracking plugin:

1. Source and updates. Same checks as how to tell if a WordPress plugin is secure: official directory or vendor site, recent releases, real support thread activity.
2. Permissions. Analytics plugins should not need exotic capabilities. If a stats plugin wants to manage users or run arbitrary remote code, stop and read why.
3. What loads on every page. Open DevTools Network on the front end. Count third-party domains. Unexpected ad or fingerprint domains are a red flag.
4. Admin access. GA properties and tag manager containers are credentials. Use MFA on the Google account. Remove former staff from Analytics admin, not only WordPress.
5. Content Security Policy. If you run CSP, analytics domains must be allowlisted deliberately. See the Content Security Policy doc for script-src patterns instead of loosening the whole policy.
6. Remove orphans. Delete unused tracking plugins. “Disabled” in wp-admin still means code on disk that can be re-enabled or exploited later.

Analytics scripts do not replace security hardening. Keep updates, backups, and login protection on the WordPress security checklist. Numbers do not help if the site redirects visitors to malware.

WordPress install hygiene

• Prefer one analytics method: plugin, tag manager, or host integration
• Document who owns the Google, Matomo, or Plausible account in your runbook
• After migration, audit the live HTML once, not only the plugin settings screen
• Pair traffic monitoring with server-side signals: spikes with flat analytics often mean bot noise (see 404 hammering and your host metrics)
• For broader plugin risk context: WordPress plugins as security risks

Picking a path (short decision guide)

Choose GA4 when marketing already lives in Google Ads or Search Console, you need funnel exploration, and you can maintain consent tooling where required.

Choose Matomo when you need GA-like depth but want self-hosting or EU-friendly data handling.

Choose Plausible, Fathom, or similar when you want simple traffic dashboards without running infrastructure.

Choose host or CDN stats when the question is capacity and abuse, not campaign ROI.

Choose self-hosted Umami when cookieless aggregate stats are enough and you want a small first-party script.

Any path works if it is one path, maintained, and audited like code you ship.

Bottom line

Analytics is not optional for growth, but duplicate trackers are optional for risk. Pick one tool, install it carefully, remove the rest, and hold it to the same standard as firewall and login plugins. Your reports get cleaner and your supply chain gets smaller.