Two copies of the same tracking code — one added by a plugin, one hardcoded in the theme, one left over from a previous developer — will often both fire, which inflates pageviews, double-counts events, and quietly distorts every report built on top of that data, without producing any error message anywhere to flag that it’s happening.
Count how many times the tag fires per page load
View the page source (Ctrl+U or Cmd+Option+U) and search for your GA4 measurement ID or “gtag” — if it appears more than once, or if you find both a gtag.js snippet and a separate Google Tag Manager container, that’s a real, direct sign of duplication rather than something to guess at.
Duplicate / conflicting tracking code removal
The same GA4 tag firing more than once, quietly inflating every number built on top of it.
- Full backup taken before we start
- If we can’t fix it, you get your money back
- We never ask for your own password
This or something else?
| The same tracking ID appears more than once in the page source | This fix covers it |
| Two different tracking IDs (old and new) are both present | This fix covers it; the old one usually needs removing |
| Numbers look inflated but you can’t find duplicate code | Worth a closer diagnosis; the cause may be elsewhere |
| GA4 isn’t tracking at all, rather than tracking twice | GA4 not tracking – diagnosis & fix, the opposite problem |
| You’re not sure if what you’re seeing is really duplication | This fix covers it; we confirm it as the first step |
What you are seeing
- Pageview or session numbers that seem higher than traffic actually justifies
- The same event appearing twice in DebugView for a single action
- Tracking code visible more than once when viewing page source
- Numbers that don’t reconcile with a separate source, like server logs
Common causes
- A tracking plugin installed on top of code already hardcoded in the theme
- A previous developer’s tag left in place after a new one was added elsewhere
- Both Google Tag Manager and a direct GA4 plugin installed simultaneously, each firing the tag
- A theme update reintroducing an old tracking snippet that was previously removed
- Site migration copying over old tracking code alongside a newly configured one
What we do
- Locate every instance of tracking code across the theme, plugins, and page source
- Confirm which installation is the one intended to remain
- Remove duplicate or conflicting code safely
- Verify with DebugView that the tag now fires exactly once per action
- Confirm no other tracking IDs (old properties, test accounts) are still present
- Check that legitimate tracking still works correctly after cleanup
What is included
- Duplicate tracking code identified and removed
- A single, confirmed-correct tracking installation remaining
- Verification that events fire once, not multiple times
- The pre-fix backup, kept for 30 days
Not included
- Correcting historical data already skewed by the duplication — that data stays as recorded
- Setting up tracking from scratch if none currently exists correctly
- Auditing tracking codes beyond Google Analytics, such as unrelated marketing pixels
- Ongoing monitoring for future duplication as more plugins are added
Questions about this fix
Can you fix my historical reports that were inflated by this?
No — GA4 recorded what it recorded, and there's no way to retroactively separate genuine visits from duplicated ones in data already collected.
How would duplicate tracking even happen without anyone noticing?
Easily — nothing about the site visibly breaks when a tag fires twice, so it tends to go unnoticed until someone compares traffic numbers against another source and finds they don't add up.
Which one should stay if I have both a hardcoded tag and a plugin?
Usually whichever is easier to maintain going forward, typically the plugin — we'll tell you which makes more sense for your specific setup rather than assuming.
Could this also be affecting my Google Ads conversion data?
Potentially, if conversion tracking relies on the same duplicated code — worth mentioning if you're running ads, since we'd check that specifically too.
Will removing the extra code break anything else on the site?
Not if it's genuinely just tracking code, which is what we confirm before removing anything — we take a backup first regardless.
Related fixes
If this is the second time this year
A bad update breaking the site is a symptom of updates not being tested first. Care plans run every update on a staging clone before it reaches your live site, which is the actual fix for this happening again.
Your access, your rules
Create a separate admin account for us and delete it when we are done. For anything else, we get in touch and agree a method — never a form field on this site, never by reply to an email.
We back up first, always
Before anything is touched we take a full backup and keep it for 30 days. If a fix goes wrong, we put the site back exactly as it was.
If it is not what you bought
If the problem turns out smaller than what you ordered, we refund the difference. If it is bigger, we stop and send a quote before doing any extra work.
If we cannot fix it
You get back what we received. Diagnosis is on us — you only pay when the problem is actually solved. The payment processor takes its fee before the money reaches us, so we never hold it and it is not ours to return. That is true here as everywhere else.
If it comes back
Reply within seven days of delivery and we put it back on the bench at no cost. The fix is not finished until it holds.
What we are responsible for
If something goes wrong with a fix, our responsibility is limited to what you paid for it. We take a full backup first so mistakes can be undone, and we tell you before doing anything outside what you bought.