The short version: yes, Google Analytics needs its tracking snippet present on every page you want data from, but that doesn’t mean you manually paste code into each page one by one. Do it once through your theme header, a tag manager, or your CMS settings, and it applies everywhere automatically, which means the real risk isn’t forgetting to add it, it’s a handful of pages quietly slipping outside that system without you noticing.
What “every page” means
Google Analytics 4 works by firing a small piece of JavaScript, the gtag.js snippet, every time a page loads. That script sends a hit back to Google’s servers saying “someone just viewed this page.” If the snippet isn’t present, that page is invisible. No hit, no data, no record it ever happened.
So technically, yes, every single page needs that code running on it. But here’s where people get confused. They picture themselves opening every HTML file on their site and pasting a chunk of JavaScript into each one by hand. Nobody does that, and nobody should. If your site has 200 pages, you don’t touch 200 files. You add the snippet once, in one place, and every page inherits it because of how websites are built.
How the code reaches every page
Most sites use a shared template. Your header, your footer, your navigation, these are the same file or the same include across the whole site. When you add the GA4 snippet to that shared header file, it appears on every page that uses that header, which on most sites is all of them.
- WordPress: you add it once in the theme’s header.php, or more sensibly through a plugin like Site Kit or Insert Headers and Footers, and it propagates to every page and post automatically.
- Shopify: you paste it into theme.liquid, once, and it covers the whole storefront including product pages, collections and checkout (with some caveats I’ll get to).
- Squarespace and Wix: there’s a dedicated field in settings for your GA4 measurement ID, no manual paste at all.
- Custom-built sites: whoever built your site should have it in a global template partial, not repeated per page.
If you’re not sure which measurement ID you’re even looking for, I’ve written a separate walkthrough on where to find your Google Analytics tracking ID, worth checking before you start hunting through code.
Where it goes wrong (a real example)
I audited a client’s site last year, a coaching business with around 340 pages once you counted blog posts, service pages and a resources library. Their GA4 dashboard showed roughly 3,800 sessions a month, which felt low given the ad spend and email list size they had.
I ran the site through Screaming Frog and searched the raw HTML for their measurement ID string. Forty-seven pages didn’t have it. Not because anyone was careless, but because their web developer had built a separate landing page flow for paid campaigns using a page builder plugin that sat outside the main theme template. Those 47 pages, which were getting the bulk of the paid traffic, were sending zero data to GA4. The campaigns looked like they were underperforming. They weren’t underperforming. They were untracked.
That’s the uncomfortable bit nobody likes to say out loud: most “my analytics numbers look wrong” problems aren’t Google’s fault or a tracking bug, they’re a handful of pages that were built outside the normal system and never got the snippet at all. Landing page tools, checkout flows, gated PDF download pages, subdomains for a blog or a shop, these are exactly the places code goes missing, because they’re not part of the template everything else shares.
How to check every page is tracked
You don’t need to guess. Here’s the ten-minute version I use on client audits:
- Crawl the site with Screaming Frog (the free version handles up to 500 URLs, which covers most small business sites).
- Go to Configuration, then Custom, then Search, and add a filter for your GA4 measurement ID, something like “G-XXXXXXX”.
- Run the crawl. It’ll flag every page where that string does not appear in the source.
- Cross-check the flagged pages manually, since some are built with different template systems on purpose (payment gateways, third-party booking widgets).
If Screaming Frog feels like overkill, Google’s own Tag Assistant browser extension will tell you page by page whether the GA4 tag fired, which is slower but free and works fine for a smaller site.
What Google Tag Manager changes, and what it doesn’t
A lot of people think installing Google Tag Manager solves the “every page” problem completely, and it mostly does, but it doesn’t remove the requirement, it just moves it. You still need the GTM container snippet on every page. What changes is that once GTM is there, you manage all your tags, including GA4, from inside the GTM interface rather than editing code again for every new tracking need.
So the practical upside is real: add a new conversion tag, a Facebook pixel, a heatmap script, whatever, and you never touch the page code again, you just add a tag inside GTM and publish. But if GTM itself is missing from a page (same landing-page-builder problem as before), nothing fires. It’s not magic, it’s one snippet instead of several, which is still one snippet you have to make sure is everywhere.
The places code most commonly gets missed
- Subdomains. If your blog lives on blog.yoursite.com and your main site is yoursite.com, GA4 treats these separately unless you’ve set up cross-domain tracking in your data stream settings.
- Landing page builders. Unbounce, Instapage, and similar tools sit outside your main CMS, so the snippet has to be added inside that tool’s own settings, not assumed to carry over.
- Checkout and payment pages. Shopify’s checkout pages, in particular, sometimes need the tag added through the Shopify admin’s separate analytics field rather than theme.liquid, because checkout isn’t part of the regular theme.
- PDFs and downloadable resources. These aren’t HTML pages at all, so no snippet can run on them. If you want download data, you need an event trigger set up separately, not the standard page-view snippet.
- Old or orphaned pages. Pages that predate your current template, or that were hand-coded once and forgotten, quietly stop matching whatever your current install method is.
Understanding this matters because otherwise you end up staring at your reports assuming they show your whole site, when they only show the parts that happened to inherit the code. If you want to see exactly what GA4 is capable of recording once it’s firing everywhere, I go through it in detail in what Google Analytics tracks on your website (and what it quietly misses), which is worth reading alongside this.
Do multiple properties change the “every page” answer?
If you run more than one site, or a site with separate business units, you might be tempted to spin up multiple GA4 properties and worry about which snippet goes where. The tracking rule doesn’t change, each property still needs its own snippet on every page it should measure, but the account structure question is a different one and I’ve laid out the actual limits in how many Google Analytics accounts you can set up, since the free tier caps things in ways that catch people out.
Consent adds another layer
Since GDPR enforcement tightened, adding the snippet everywhere isn’t the whole job anymore. In the UK and EU, GA4 shouldn’t fire and set cookies before a visitor has given consent, which means your consent banner logic has to run on every page too, in step with the tracking code, not as an afterthought bolted on later. I’ve covered the specifics in whether Google Analytics requires cookie consent under GDPR, but the short version is that having the tag on every page and having consent handled on every page are two separate checks, and skipping the second one is its own kind of exposure.
My actual recommendation
If you’re building or rebuilding a site, decide on your method once and stick to it: theme template, plugin, or GTM container, pick one, install it site-wide, and treat any page that skips your normal build process (landing pages, checkout, subdomains) as a page you must manually verify rather than assume. Run a Screaming Frog check every few months, especially after a redesign, a new plugin, or a developer handover, because those are the moments code silently drops off pages nobody thought to double-check.
And if you’re only just setting analytics up for the first time, it’s worth reading when you should start using Google Analytics first, because getting the install right from day one saves you the exact audit headache I described above.
Frequently asked questions
Do I need to add the Google Analytics code separately to each page?
No, you add it once to a shared template, theme header, or through Google Tag Manager, and it applies to every page automatically. Manually pasting it page by page is unnecessary and error-prone.
What happens if a page is missing the GA4 tracking code?
That page sends no data at all. It won’t show up in your reports as low traffic, it simply won’t exist in Google Analytics, which is why missing pages are easy to overlook rather than easy to spot.
Does Google Tag Manager still require code on every page?
Yes. GTM still needs its own container snippet installed on every page, it just means you only ever edit that one snippet, since all your actual tags including GA4 are managed inside the GTM interface afterward.
How do I check if Google Analytics is installed on every page of my site?
Crawl your site with a tool like Screaming Frog, filter for your GA4 measurement ID in the page source, and it will list any pages where the code doesn’t appear so you can fix them individually.
