Server-side tracking in place
Why this matters
Server-side tagging sends events through your own infrastructure, so ad blockers and browser privacy settings cannot block them.
How this tool detects it
The tool looks for the usual markers of server-side tagging: loader identifiers such as firstPartyLoader or first-party-loader, the fpl.js script, and server-container naming like ss-gtm or gtm.server.
This check is marked optional rather than failing, because it depends on your traffic mix and advertising spend — it is not a requirement.
One thing worth stating plainly: the internal configuration of a server-side container is out of scope for static analysis. This page can tell you whether server-side tagging is enabled, not whether it is configured correctly.
Where this check can mislead you
Static analysis has limits. These are the cases where this particular check will report a result that does not match reality — worth knowing before you act on it.
- Enabled does not mean configured correctly. The tool can only recognise the loader signature. It cannot verify the tag configuration inside the server container, whether events are sent twice, or whether consent state passes through correctly. This is the main limitation of the check.
- Double counting against client-side tags is not checked. The classic migration accident is server and client sending at the same time, counting conversions twice — entirely invisible at the static level.
- Custom domain DNS and certificate setup cannot be verified. From the browser side these only show up as failed or silently dropped requests.
Examples
<script async src="https://cdn.example.com/fpl.js"></script>
<script>window.firstPartyLoader = true;</script>Conversion events are sent through your own subdomain, where ad blockers cannot intercept them directly.
<!-- server-side container handles GA4, client-side copy still present -->
<script async src="https://www.googletagmanager.com/gtag/js?id=G-ABC123"></script>
<script>window.firstPartyLoader = true;</script>This tool reports "server-side is in place" — but conversions are now counted twice. The only way to notice is to compare event volumes between the two paths.
How to fix it
- Decide whether it is worth it. If your audience has a high ad-blocker rate, or you advertise heavily into markets with strict privacy regulation, server-side tagging earns its cost.
- Pick an approach: Google's official server-side container, or a third-party host such as Stape. The official route is free but needs a runtime such as Cloud Run; the hosted route is simpler and billed on traffic.
- When you migrate, move the events that matter first — conversions and purchases. Browsing events can stay client-side.
- After switching, run both in parallel for at least two weeks: send client-side and server-side at once, compare volumes in GA4 DebugView, and only switch the client off once you have confirmed nothing is double-counted.
- Verify the DNS and SSL configuration on your custom domain is correct.
Verify it worked
After making changes, confirm delivery rather than assuming. These steps require your Google login, which is exactly why this tool stops short of them.
- Run both in parallel for at least two weeks. Send client-side and server-side simultaneously, compare event volumes in GA4, and only switch the client off once duplication is ruled out.
- In the server platform live event log, confirm requests genuinely arrive with complete parameters.
- Test with different tools: ad blockers off and on, private browsing, separate browsers — confirm all record data.
- Check that the custom domain SSL certificate is valid and DNS resolution is correct.
Related checks
Check whether your site has this problem — no login required.