Two tag managers on the same store
What we found. In two of the stores we scanned, the homepage source contained two complete Google Tag Manager containers — each with its own script and noscript pair, both loading on every page.
Why it matters. Dual containers are almost never intentional outside a migration. Tags and consent logic can exist in one container and not the other, events can fire twice, and nobody can say which container owns which measurement. When GA4 routes through GTM, its accuracy depends on untangling this first.
What fixed looks like. One surviving container. Anything unique is migrated out of the other, the duplicate is removed, and every event has exactly one owner.
The same events sent to three GA4 properties at once
What we found. A beauty store's storefront event configuration listed three different GA4 properties as destinations — the same events (including search and begin_checkout) were delivered to all three.
Why it matters. Every event is recorded three times, in three places. No single property holds one clean record of what happened, and every report or audience built on top inherits the split.
What fixed looks like. Events flow to the one intended property; the extra destinations are removed and the live configuration is verified against the store's reporting.
A GA4 setup wired to an invalid measurement ID
What we found. A jewelry store's tracking configuration carried a GA4 identifier in the old Universal Analytics number format — not a valid GA4 measurement ID — and the page had no GA4 loader of its own, so GA4 measurement depended entirely on that configuration feeding the tag manager.
Why it matters. The whole GA4 setup hangs on one hand-off through a mis-formatted ID. If that hand-off fails, the property records nothing — and nothing on the storefront looks broken.
What fixed looks like. A valid GA4 measurement ID, loaded directly and verified end-to-end: page view in, event recorded in the right property.
The same vendor script loaded two — or three — times
What we found. A cookware store's legacy script-tag manifest loaded the exact same Rebuy script three separate times. Another store loaded Klaviyo twice, under two different company accounts. A beverage store's product page carried three separate Klaviyo loaders at once.
Why it matters. Each duplicate is a redundant download, parse, and execute on every page view. Two accounts of the same vendor initializing on one storefront also means duplicate event tracking and a real risk of double-counted email and SMS attribution — the data the lifecycle team optimizes against.
What fixed looks like. One load, under the one live account. The other initializations are removed, and attribution counts each event once.
Two consent platforms running at the same time
What we found. One store's homepage loaded two different consent-management platforms — Osano and OneTrust — side by side.
Why it matters. Running two CMPs adds duplicate consent checks, duplicate banner logic, and extra blocking weight before content renders — for a job only one of them can actually own.
What fixed looks like. One consent platform, with consent wired correctly into every measurement path on the store.
Leftover scripts from dead features and old themes
What we found. An apparel store's script-tag manifest — 17 entries, on a homepage carrying 180 script tags in total — still loads a checkout script of a class Shopify has retired, served from a third-party CDN. In another store, two different builds of the same loyalty script, served from two different past theme versions, initialize side by side. The heaviest stacks we scanned carried 111 and 125 script tags on the homepage alone, the 125 spread across more than 15 external hosts.
Why it matters. A discontinued script is dead weight at best and an unmaintained third-party dependency at worst. Old builds left behind by theme upgrades keep initializing on every session, and in aggregate this is the weight every shopper's browser has to push through before the page settles.
What fixed looks like. The retired and superseded entries are removed — several removals in stacks like these are zero-risk — and every remaining script has a current reason to be there.
A live-looking plugin token sitting in public page source
What we found. A beverage store's homepage HTML contained a plugin URL with a live-looking access token in plain text. (We do not reproduce the value.)
Why it matters. Anything rendered into public source is public — every visitor, crawler, and scanner can read it. Tokens like this should be rotated, and where the vendor supports it, restricted or moved server-side.
What fixed looks like. The token is rotated, the old one is dead, and secrets no longer ship inside page source.
Support chat installed twice
What we found. A food brand had its support chat installed two ways at once — through the vendor's app loader and through a separate manual install of the same vendor's widget — with the same vendor's conversion and contact-form scripts layered on top.
Why it matters. Two installs of the same widget load on every page: duplicate weight, two copies of the same tooling to keep in sync, and two chances for the installs to drift apart.
What fixed looks like. One install, through the app embed, with the vendor's add-ons attached to that single install.
How these findings were gathered
- Scans read public storefront pages only (home and product pages), fetched in October 2026. The raw page source behind every finding above is kept on file.
- Store names and domains are anonymized. Vendor names and failure patterns are reported as found.
- A public scan cannot see tags injected only at runtime, or scripts that load only on checkout and order-status pages. A store not appearing here is not proof that a store is clean — the same limits apply to every audit we run, and we print them on every report.