What we check
Three signals, in this order: the stape fingerprint (SDK URL, load.stp and sst subdomains, the custom loader with a base64-encoded container ID), a gtm.js?id= from any domain other than googletagmanager.com, and a subdomain of your own domain with a Google measurement or loader path behind it: /gtm.js, /gtag/js, /g/collect, /mp/collect. The check is a note, never a failure. Without a server-side setup nothing is broken, the next stage is simply missing.
What the scan cannot see: the inside of the server container. Which tags are configured there and where they forward stays invisible. Where the pings actually go in the browser is what the deep scan reports as its own finding (Tracking architecture), including the DNS attribution of the endpoint to stape or another vendor.
Why it matters
Server-side tagging moves the tags from the browser to a server you control. Ad blockers and ITP no longer bite on vendor domains, the cookies run on your domain, and you decide which data leaves the house. The price: a container that needs operating, and a migration that often stalls halfway. Half migrated is the usual state. What server-side tracking delivers, what it costs and when it pays off is covered in the guide to server-side tagging.
Common causes
- There simply is no server-side setup, all tags send straight from the browser to the vendor domains.
- The server container exists, but the web container still sends to the standard endpoints instead of the first-party subdomain.
- The setup runs on a subdomain without a recognisable measurement path in the HTML, so only the deep scan shows the data flow.
- An sGTM project was started and never finished, the container idles along.