Repository navigation
make the site measurable — ownership tag, GA4 behind a host check, named CTAs - #23
Merged
Merged
Conversation
…tag, GA4 behind a host check, named CTAs The page already had every on-page tag a crawler wants and no way to find out whether any of it landed. This adds the two things that answer that. Verification is the HTML-tag method and not the Google Analytics one: the loader below it is injected by script, and the verifier reads the served HTML without running any of it — the GA route would look at this page and find no analytics at all. The loader runs only on the site's own host. This repo is public and this file is what a fork gets: a fork with Pages on would otherwise report its own visitors into our property, from a domain we do not control, and GA4 filters nothing by hostname on its own. The same check keeps a local http.server out of the numbers — which is also why this guard cannot be exercised anywhere but production. Six links here share one GitHub URL, so GA4's own outbound_click can say they left for the repo and never from where. data-cta names them. .github/SEO.md is the operator's copy: what is set where, the three property settings that do not backfill, and the six places holding the site's address. HOSTS is listed among them because it is the only one whose omission leaves the page working while silently recording nothing. Co-Authored-By: Claude Opus 5 (1M context) <[email protected]> Claude-Session: https://claude.ai/code/session_01VGYnqPKtsrWfugEKyASb7a
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The page already had every on-page tag a crawler wants and no way to find out whether any of it landed. This adds the two things that answer that.
Verification is the HTML-tag method and not the Google Analytics one: the loader below it is injected by script, and the verifier reads the served HTML without running any of it — the GA route would look at this page and find no analytics at all.
The loader runs only on the site's own host. This repo is public and this file is what a fork gets: a fork with Pages on would otherwise report its own visitors into our property, from a domain we do not control, and GA4 filters nothing by hostname on its own. The same check keeps a local http.server out of the numbers — which is also why this guard cannot be exercised anywhere but production.
Six links here share one GitHub URL, so GA4's own outbound_click can say they left for the repo and never from where. data-cta names them.
.github/SEO.md is the operator's copy: what is set where, the three property settings that do not backfill, and the six places holding the site's address. HOSTS is listed among them because it is the only one whose omission leaves the page working while silently recording nothing.