How to add analytics to a WordPress site
WordPress ships with no analytics of its own - unless you're on WordPress.com, where some stats are built in. The four ways to add real visitor tracking to a WordPress site, what each one costs you, and how to pick.

First: which WordPress do you have?
Everything about WordPress analytics depends on a distinction that trips up almost everyone at least once. WordPress.com is a hosted service run by Automattic - you sign up, they run the servers, and some analytics come built in. Self-hosted WordPress (the software from WordPress.org, installed on your own hosting) is what most business sites run, and it ships with no analytics at all. Not a visitor counter, not a pageview total, nothing. If you've been staring at your WordPress admin looking for traffic numbers that aren't there, this is why.
The distinction matters because the advice splits completely. WordPress.com users should start with what's already installed. Self-hosted users have to add something - and since W3Techs measures WordPress at 40.7% of all websites, "adding analytics to WordPress" is arguably the most common analytics task on the internet. There are four honest ways to do it, and the rest of this guide walks through each.
One thing this guide assumes: you know why you want analytics at all. If you're still deciding what's worth measuring on a new site, start there and come back.
What WordPress.com already gives you
Every WordPress.com site includes Jetpack Stats: views, visitors, likes and comments, with a traffic chart on the dashboard. On the free plan the useful history is shallow - detailed traffic data covers about the last seven days, and the longer views unlock with paid plans, as do UTM tracking and device breakdowns further up the tiers.
For a personal blog, that's often enough. You can see whether anyone came, which posts they read, and where they arrived from. The ceiling shows up when you ask harder questions: no conversion tracking, no funnels, no way to follow a visitor's path. When those questions arrive, WordPress.com sites on plans that allow plugins can install anything a self-hosted site can - so the rest of this guide applies to you too, just with a working baseline already in place.
Self-hosted sites can get the same Jetpack Stats by installing the Jetpack plugin, but the free tier has narrowed: Jetpack's pricing now caps free commercial use at 10,000 views a month, with segmentation and UTM features held back for paid tiers. It stopped being the automatic free answer a while ago.
Route 1: Google Site Kit, the official plugin
Site Kit is Google's own WordPress plugin, and with over five million active installs it's the most common way WordPress sites run Google Analytics. Install it, connect your Google account, and it wires up Analytics without you touching a line of code - and pulls Search Console, PageSpeed Insights and AdSense into the same WordPress dashboard while it's at it.
The Search Console piece is the quiet win. Most site owners never connect Search Console at all, and it's the only tool that shows which Google searches bring you visitors. Site Kit sets up the link as part of onboarding.
What Site Kit doesn't change is GA4 itself. The dashboard cards in WordPress are summaries; every real question still sends you to the Google Analytics interface, with everything that implies. Site Kit removes the installation problem, not the complexity problem. If you don't have a GA4 property yet, create one first - Site Kit can walk you through that too, but knowing what the account, property and stream mean makes the wizard less mysterious.
Route 2: a wrapper plugin around Google Analytics
A whole plugin category exists to soften GA4: MonsterInsights (over two million installs) and ExactMetrics (about three hundred thousand) install the tracking code and then rebuild the important reports inside WordPress admin, in friendlier form than Google's own interface. For a site owner who finds GA4 hostile - a defensible position - the appeal is real: the numbers live where you already work.
Two things to weigh before choosing this route. The free versions are limited on purpose, with the useful features (ecommerce reports, form tracking, custom dimensions) sitting behind paid licenses that renew yearly - you're paying a subscription to make a free tool bearable. And you're adding a second layer of software between you and your data: one more thing to update, one more dashboard that can disagree with the source. The minimalist counter-option is GA Google Analytics (about four hundred thousand installs), which inserts the tracking code, adds no reporting at all, and stays out of the way.
Route 3: no plugin at all
Any analytics tool, Google's included, ultimately needs one thing: its snippet in your pages' head. WordPress can do that without a dedicated analytics plugin, and sites that guard their plugin count often prefer it.
The clean way is a small code-insertion plugin like WPCode (three million installs, formerly "Insert Headers and Footers"): paste the snippet into its header box, save, done. The plugin-free way is adding the snippet to your theme - either in a child theme's header template or hooked via functions.php - with one famous trap: edits made directly to a theme's files vanish on the next theme update. If you don't know what a child theme is, that sentence is the reason the WPCode route exists.
Manual installation treats analytics as what it mechanically is, a script tag. It works identically for GA4, for Bigdelta, for any tool - which makes it the route that keeps your options open.
Route 4: a lighter tool than Google Analytics
The fourth route questions the default. Google Analytics became the reflex answer for WordPress because it's free and everywhere, but for a site whose questions are "how many visitors, from where, reading what", GA4 is a lot of machine for the job - in setup, in interface, and in page weight. On that last point the lightweight vendors are happy to do the measuring: Plausible's own comparison puts Google's script at roughly 110KB gzipped against their 2.5KB. It's a competitor's measurement, so treat the ratio as marketing and the direction as true - Google's tag genuinely is one of the heavier things on a small WordPress page.
Lighter tools install through any of the mechanisms above. Bigdelta ships a WordPress plugin that installs the snippet and keeps it updated - pageviews, scroll depth and form submissions tracked without touching theme code, and custom events defined from the dashboard rather than in code. The same goes for the rest of the category: one snippet, no wrapper plugin needed. If cost is the filter, the genuinely free tiers are catalogued separately.
The trade-off to state plainly: no lightweight tool replicates GA4's advertising integrations. If you run Google Ads seriously, GA4 (or GA4 alongside a simpler tool - a common pairing) stays in the picture.
The plugin-bloat question
WordPress folk wisdom says every plugin slows your site, and the wisdom is directionally right - each active plugin can add code, database queries and scripts to every page load. Analytics choices sit in an odd corner of that problem: the plugin itself is usually light, and the weight lives in the tracking script it loads. A minimal inserter plus a heavy script costs more than a mid-size plugin plus a tiny script.
So audit the combination, not the plugin count. A wrapper plugin loading gtag.js carries both layers. WPCode loading a 2KB counter is close to free. And whichever way you go, run the check that settles arguments: your site's speed measured before and after, not vibes.
Common WordPress tracking mistakes
None of these are exotic. They're worth this list because each one produces data that looks fine and is quietly wrong, which is worse than no data.
The failures that show up in support threads, in rough order of frequency:
- Double tracking - a theme option and a plugin both inserting the same tag, so every visit counts twice. If your numbers look implausibly good, view your page source and search for how many times your Measurement ID appears.
- Counting yourself - logged-in admins browsing the site all day. Most wrapper plugins can exclude logged-in roles; on the manual route, exclude your IP in the analytics tool instead.
- A caching plugin serving stale pages - you added the snippet but visitors get the cached version without it. Clear the site cache after installing.
- The snippet on some templates but not others - common with manual installs on themes that use multiple headers. Spot-check a post, a page and the homepage.
- A staging or dev copy of the site running the same tag and polluting production data - give staging its own property, or filter its hostname.
The cookie banner question
If your site has EU visitors, analytics and consent arrive together. Google Analytics sets cookies, which under European rules generally means asking before the script fires - and Google's Consent Mode exists to wire your banner's answer into the tag's behavior. WordPress has mature plugins for exactly this: Complianz (a million installs) and CookieYes (one and a half million) both manage the banner and the script-blocking, which regulators increasingly check actually works rather than merely exists.
Two honest notes on what consent does to your numbers. Every visitor who declines is invisible to your analytics, so consented numbers undercount reality - plan for that instead of being alarmed by it. And cookieless tools change the shape of the question, though whether they remove the banner requirement depends on jurisdiction and configuration, not on the vendor's landing page. Nothing in this section is legal advice; it's the map of what to ask about.
Which route fits you?
Whichever you choose, verify it the same way: open your site in one tab and your analytics tool's realtime view in another, and watch yourself arrive. For GA4 specifically, the setup guide covers verification and the five settings worth changing on day one.
Running two tools at once is also legitimate, not indecision. A common WordPress pairing is GA4 (installed via Site Kit, mostly ignored, kept for the ads plumbing and Search Console link) plus a lightweight tool that someone actually reads. Their numbers won't quite match, for reasons that are documented rather than sinister.
Compressed to a decision:
- You're on WordPress.com and your questions are simple - use the built-in stats and stop here.
- You want Google Analytics with the least friction, or you care about Search Console - Site Kit.
- You want GA4's data but can't stand its interface - a wrapper plugin, priced accordingly.
- You keep plugins minimal and don't mind pasting a snippet - WPCode or a child theme, with any tool.
- You want visitor numbers without GA4's weight and ceremony - a lightweight tool via its plugin or a snippet.
What to look at in week one
Once something is counting, the first week's job is calibration, not conclusions. Check that your own visits are filtered out - on WordPress it's easy to be your own top visitor, between previews, editing sessions and the odd logged-in refresh. Check that the numbers pass a smell test against your host's bandwidth stats or Search Console's click counts; big gaps usually mean the snippet is missing from some template or firing twice on others (a classic WordPress failure when a theme and a plugin both insert it).
Then pick a tiny routine and keep it: visitors, sources, top pages once a week, plus whatever the site exists to produce - orders, form fills, signups - once conversion tracking is wired. A blog measured weekly with three numbers beats one measured never with forty.
The practical takeaway
Self-hosted WordPress gives you nothing until you add something, and the four routes differ less than their marketing suggests - they all end with a script in your head tag and a dashboard somewhere. Pick by what you'll actually open: Site Kit if that's Google's tools, a wrapper if it's WordPress admin, a lighter tool if GA4's interface has defeated you before. The analytics that works is the one you look at weekly - and if a setup has sat unread for a month, that's data too, about the setup.


