Nobody gets paged when a tracking script goes missing. There's no error, no failed build, no red banner in your dashboard — just a slow, quiet drop in the numbers that shows up two or three weeks later as "conversions are down" with no obvious cause. By the time someone thinks to check whether the pixel is actually still there, the data from the gap is already gone for good.
The install itself is rarely the problem. Most sites get Google Tag Manager, GA4, or Meta Pixel added correctly once. What breaks is everything that happens afterwards: a theme update, a page builder migration, a cache plugin that decides your script tag looks like something safe to strip. This post covers where these tags are supposed to live, why that placement actually matters, and the ordinary events that knock them loose. If you just want to check a site right now, our free script & pixel checker scans it in a few seconds.
Where these scripts are actually supposed to go
This isn't a matter of opinion — Google and Meta both publish exact placement guidance:
- Google Tag Manager: Google's own Tag Manager installation guide says to paste the first container snippet as high in
<head>as possible, and the second (noscript) snippet immediately after the opening<body>tag. - GA4 (gtag.js): Google's Google tag setup instructions say to place the snippet immediately after the opening
<head>tag, on every page — and not to add more than one Google tag to the same page. - Meta Pixel: Meta's Pixel setup documentation says the base code goes between the opening and closing
<head>tags on every page you want to measure, specifically to reduce the chance of it being blocked and to make sure it executes as early as possible.
Three different companies, the same instruction: get it into <head>, and get it there early.
Check where yours actually landed. Our free tool fetches any URL and tells you whether GTM, GA4, Meta Pixel and Lead Recorder are in <head> or further down the page.
Why "in the head" isn't just tidiness
A script sitting lower in the page, or injected late by a plugin after the rest of the DOM has already loaded, has less time to do its job before a visitor acts. That matters most for exactly the traffic you're paying to acquire: someone who clicks a paid ad, glances at a slow-loading landing page, and leaves within a second or two. If the tag hasn't registered yet, that visit — and whatever it would have told you about which ad, keyword, or channel brought them — never gets recorded at all.
It also compounds. GTM specifically warns against adding more than one Google tag to a page; a second container or a duplicate GA4 tag left behind by an old integration doesn't just double up harmlessly; it can cause its own conflicts and inflate or corrupt the numbers you're trying to trust.
Five ordinary ways tracking scripts come loose
- Theme or template migrations. A new theme, a page builder switch, or a "modernised" header template often gets rebuilt from a generic starting point — and whatever custom script was hand-pasted into the old header isn't part of that template.
- The "custom code" field gets migrated away from. Site builders that offer a header/footer code injection box sometimes deprecate or relocate that setting during a platform update. The script is still saved somewhere in the account, just no longer rendering on the live page.
- Performance and caching plugins. Minifiers, deferred-script loaders, and "remove unused JavaScript" optimisations are built to be aggressive. A script tag they don't recognise as essential is an easy target for delay or removal, especially on WordPress sites running multiple performance plugins at once.
- Consent management platforms, misconfigured rather than working correctly. Blocking marketing tags until a visitor consents is correct, compliant behaviour. It becomes a bug when the CMP keeps blocking a tag after consent is granted, or blocks it site-wide by default with no path to ever load.
- A second agency or freelancer adds a second container. Without a shared record of what's already installed, it's common for a new developer to add their own GTM container or GA4 tag alongside an existing one nobody remembered was there.
How to actually verify it, instead of assuming
Each platform has its own first-party way to check installation directly, and they're worth knowing about even outside of a one-off scan:
- GTM Preview mode — built into Tag Manager itself, shows exactly which tags fired on a given page load, in real time.
- Meta Pixel Helper — an official Chrome extension from Meta that checks pixel installation and flags common errors as you browse.
- GA4's own troubleshoot tag setup guide — Google's walkthrough for diagnosing why a GA4 tag isn't showing data.
- Our script & pixel checker — the fastest way to check whether a tag is present at all and whether it's sitting in
<head>, without opening dev tools.
None of these replace the others. Browser extensions confirm a tag fires on the page you're currently viewing; a URL scanner confirms what's actually in the HTML source across any page you want to check, including ones you don't have open. Using both catches more than relying on either alone.
The gap no pixel checker can close
Even a perfectly placed GTM container, GA4 tag, and Meta Pixel only tell you a session happened — not whether that visitor became a lead. Connecting a page view to an actual form fill, phone call, or booking, potentially several visits later, is a separate problem from "is the script installed." That's the part Lead Recorder's lead source tracking is built for: one script tag that stays attached to the visitor from first click through to conversion, so there's no separate pixel install to babysit and no silent gap to discover three weeks late.
Want tracking that tells you when something's wrong, instead of staying quiet? Lead Recorder ties every form fill and call straight back to its source — one script tag, nothing extra to maintain.
