Analytics installation looks like a tiny task.

Copy the tag. Paste it into the site. Build. Done.

That is how it should work. But in real production websites, the failures are usually boring and easy to miss. The tag gets added locally but never deployed. It lands inside a framework’s client-side script helper instead of the initial page source. The build passes, but the public domain is still serving the previous version. The analytics setup screen says the tag was not detected, and now everyone is guessing.

The better rule is simple: analytics setup is not finished until the live page source proves it.

The Code Editor Is Not the Source of Truth

When you add Google Analytics, Google Tag Manager, Meta Pixel, call tracking scripts, or conversion snippets, the local file only tells you what should happen.

The production HTML tells you what visitors and verification tools actually receive.

That distinction matters more with modern frameworks. A Next.js, Astro, React, or Vue site may render scripts differently depending on where the snippet is placed. Some script helpers load after hydration. Some only appear after JavaScript runs. Some are fine for tracking but not obvious to a setup detector that scans the initial HTML response.

If the tool says “tag not detected,” do not argue with the dashboard. Check the live response.

The fastest test is usually:

curl -L https://example.com | grep "G-"

For non-Google scripts, search for the vendor domain, pixel ID, container ID, or conversion ID.

If the identifier is missing from the live HTML, the problem is not the analytics dashboard. The production site is not serving the tag yet.

Small Snippets Still Need a Release Process

Tracking snippets are small enough to feel exempt from deployment discipline. They are not.

A good analytics install should follow the same release path as a real feature:

Add the tag in the framework-approved global layout or document head.
Build the site locally.
Deploy to production.
Fetch the live public URL.
Confirm the tag ID appears in the live HTML.
Retry the analytics platform’s detector.

That whole loop can take five minutes. It saves the much longer loop of refreshing the analytics setup screen, wondering whether Google is delayed, and accidentally changing the wrong thing.

Put Verification Close To The Deploy

The best habit is to verify immediately after deployment, while the change is still fresh.

Do not only check the generated preview URL. Check the real domain too. Deployment platforms often create a unique deployment URL first, then alias the production domain after the build is ready. If the preview has the tag but the public domain does not, the alias or production promotion is the issue.

Also watch for caching. A response header can tell you whether the page is freshly generated, served from cache, or still carrying an older build. Most of the time a redeploy clears this up, but the live URL is the only place to know.

The Takeaway

Analytics tags are not installed when they are pasted.

They are installed when the production domain serves them, the page source contains the right ID, and the analytics tool can detect them.

For marketing teams, that difference matters. Without verification, campaign data, conversion tracking, retargeting audiences, and attribution can quietly fail before a single report is created.

The practical habit: every tracking install should end with a live-source check. Not a screenshot. Not a local build. Not “it should be there.” Fetch the production page and prove the tag is actually shipping.