ScriptTag Audit
Run a free audit

Sample fix report

Before / after: what a fixed store looks like

This page is the standard report format delivered with every done-for-you fix (from $99): for each problem, what the scan found, what the fix does, and the after-state we verify before the job is called done. The “before” column is built from the eight finding types of our real store scans — real patterns from real public storefronts, identities anonymized. Your report lists your own store's actual rows, in this same format.

How the after-state is checked. After the fix, the same public pages are re-scanned and every row is checked against the live storefront source, item by item — the duplicate is gone, the event fires once, the retired script no longer loads. If a row cannot be verified from the public source, the report says so on that row instead of claiming success.

Problem found (before)Fix appliedVerified after-state
Two tag managers on the same store. Homepage source contains two complete GTM containers, both loading on every page; tags and consent logic split across them, events at risk of firing twice. Anything unique is migrated out of the duplicate container; the duplicate container (script + noscript pair) is removed. Re-scan shows exactly one GTM container. Every event has exactly one owner; no tag fires from a second stack.
The same events sent to three GA4 properties at once. One store's event configuration lists three GA4 destinations, so every event — including search and begin_checkout — is recorded three times, in three places. The two unintended destinations are removed from the storefront event configuration; routing to the one intended property is kept. Live configuration lists one GA4 destination. Events land in the single intended property only.
A GA4 setup wired to an invalid measurement ID. The tracking configuration carries an old Universal Analytics–format ID, and no GA4 loader of its own — if the hand-off fails, the property records nothing. The invalid ID is replaced with the store's valid GA4 measurement ID, loaded directly instead of depending on the fragile hand-off. End-to-end check: a page view on the live store is recorded in the correct GA4 property.
The same vendor script loaded two — or three — times. One store's manifest loads the same Rebuy script three times; another loads Klaviyo twice, under two different company accounts. Duplicate initializations are removed; the script loads once, under the one live account. Re-scan shows a single load per page. Attribution counts each event once.
Two consent platforms running at the same time. Osano and OneTrust both load on the homepage — duplicate consent checks, duplicate banner logic, extra blocking weight. One consent platform is kept; the other is removed, and consent is wired into every measurement path on the store. One consent platform in the page source; one banner; measurement paths read the single consent state.
Leftover scripts from dead features and old themes. A 17-entry script-tag manifest (on a homepage carrying 180 script tags) still loads a retired-class checkout script; two different builds of one loyalty script from two past theme versions initialize side by side. Retired and superseded entries are removed; each script tag still needed is moved to its post–March 1, 2027 home (web pixel, app embed, or checkout extensibility). Every remaining script has a current reason to be there, and no script tag on the list still depends on the mechanism Shopify stops loading on March 1, 2027.
A live-looking plugin token sitting in public page source. The homepage HTML contains a plugin URL with an access token in plain text — readable by every visitor, crawler and scanner. The exposed token is taken out of the page source, and the exact rotation steps for that vendor are spelled out in the report, so the old value gets killed on the vendor side too. Re-scan of the public source finds no token. The report notes the rotation step and who confirmed it.
Support chat installed twice. The same vendor's chat is installed through the app loader and again as a manual widget install, with the vendor's add-on scripts layered on top. The manual install is removed; the chat runs once, through the app embed, with its add-ons attached to that single install. One widget load per page in the re-scan; the vendor's add-ons hang off the single install.

What this sample is — and is not

  • The eight rows are the finding types from real ScriptTag Audit scans of real public Shopify storefronts (October 2026, raw page source kept on file, identities anonymized) — the same data as the findings page.
  • This is the delivery format, not a named client case study: a real engagement's report carries that store's own before/after rows and its own re-scan counts.
  • The audit reads public storefront pages only, so the after-state is verified the same way — anything a public scan cannot see is marked as such on its row, never silently passed.

Have us fix yours — from $99

Run the free audit first: your report groups your store's findings exactly like the left column above, and the fix request goes straight from that report — so we see your findings before we confirm the scope and the exact price.

Run a free audit See the real findings See a sample audit report