The GSC digest landed on the morning of 24 June. Six pages — five legal surfaces and /stamp-duty-calculator — were showing “URL is unknown to Google.” That status means Google’s crawler hasn’t attempted to load the URL at all. Not crawled and deindexed. Not crawled and found thin. Not tried.
The old approach to that signal is to start guessing. Check the sitemap. Verify the canonical. Look for a noindex tag that got committed by mistake. Poke at whether the JavaScript prerender is working. Each check is a separate tool, a separate login, a separate mental context switch. By the time you’ve gone through four of them and found nothing, you’ve spent an hour on a problem that may not be technical.
Phase 1.6 was about replacing that reflex.
What was built
Two skills: gsc-telemetry and ga-telemetry. Both stdlib-only Python — no dependencies beyond what ships with Python 3. Both live at ~/.claude/skills/. Both ship with a SKILL.md and a launchd plist for scheduled digests.
ga-telemetry is the larger of the two: six stdlib-only Python modules, a SKILL.md, and the plist. The architecture is the same across both: call the upstream API, write structured output, return the result in a format the next diagnostic step can consume directly without parsing.
The skills aren’t the interesting part. The interesting part is what they changed about the diagnostic loop.
The diagnostic loop before Phase 1.6
Before these skills existed, the operator-side view of UK Calculators was fragmented. Google Search Console and Google Analytics are both browser dashboards, both require authentication, and neither returns data in a shape that’s useful for scripted comparison. To answer “why is this page not indexed?” you would manually cross-reference the Coverage report, the URL Inspection tool, the Sitemaps report, and a manual curl to check the live response headers. That’s four separate checks, done by hand, on a dashboard that rate-limits inspection requests.
The result is that you make most decisions about technical SEO by feel. You have approximate knowledge of what Google sees. You act on that approximate knowledge and then wait. The feedback loop is measured in days.
The diagnostic loop after Phase 1.6
The gsc-telemetry digest runs on a schedule and writes a structured summary: which pages are indexed, which are excluded, which are flagged with which exclusion reason. The ga-telemetry counterpart writes traffic attribution. Neither requires opening a browser.
On 24 June, the digest had already told us those six pages were stuck at “URL is unknown to Google.” That specific status is load-bearing. It’s distinct from “crawled — currently not indexed” (Google tried but decided against it) and from “Excluded by ‘noindex’ tag” (a deterministic technical cause). “Unknown” means Google hasn’t attempted the URL at all. The problem is discovery, not indexability.
That distinction changed what we looked for next. Instead of opening four dashboards to audit technical causes, we checked the indexability signals across the six surfaces directly: HTTP response code, the robots meta tag, the canonical tag. Every page returned HTTP 200, index, follow, canonical self-pointing. Every indexability signal clean.
That ruled out the class of problem where Google is finding the pages but refusing to index them. The same pass turned up three issues that needed fixing regardless of the discovery problem: a prerender blocker, an FAQ helper that needed cleaning, and a layout that could be simplified. Those were addressed in the fix(seo) PR.
But none of them explained the “unknown” status. The gsc-telemetry digest had already told us what kind of problem this was.
What “unknown” actually points at
The five legal pages are footer-linked across the site. Footer links are crawled but carry less weight than body-prose links — crawlers deprioritise navigation chrome, and PageRank flows more freely through contextually embedded anchors. /stamp-duty-calculator was in the same position: correct, functional, no technical fault, but receiving no editorial signal that told Google “a document on this site specifically refers to this page.”
Google’s crawler needs a reason to prioritise a URL. Footer links, in isolation, aren’t that reason.
The fix was in the body prose, not in the page code.
The fix
Two layers.
The technical layer, identified during the code review of PR #153: unblock prerender, clean the FAQ helper, simplify the legal layout. Done in the fix(seo) PR on 24 June.
The crawl-equity layer: add body-prose internal links from six published, indexed articles to /disclaimer and /stamp-duty-calculator. Existing content already in Google’s index, now pointing explicitly to the targets via editorial context rather than navigation chrome.
The sequencing matters. The telemetry identified the problem class (“unknown”, not “excluded”) before any code was opened. The code review then confirmed no indexability blocker and turned up the three technical issues. The body-prose link work addressed the crawl-equity gap. Three separate actions, each aimed at the right layer, in the right order.
Out of scope: whether the “unknown” status clears for the remaining legal pages post-fix isn’t confirmed yet — GSC’s re-crawl lag means the result shows in the next digest cycle, not immediately.
Why stdlib-only matters
Two reasons.
The first is portability. A skill with no external dependencies installs in a fresh environment without a pip install step. The plist bootstraps it on a new machine with one launchctl load. There’s no virtualenv to set up, no dependency mismatch to debug.
The second is trust. When a diagnostic tool has zero external dependencies, the failure modes are limited: the upstream API, the Python interpreter, and the code itself. A tool with five transitive dependencies has a longer failure surface, and when it breaks at 06:00 because a dependency updated overnight, the failure is ambiguous. Stdlib-only is a constraint that pays off every time the tool runs unattended.
What this changes operationally
Before Phase 1.6, acting on a GSC signal required context-switching into a browser dashboard and manually correlating data across multiple views. The decision of whether to investigate a technical cause was driven by time available and operator intuition.
After Phase 1.6, the telemetry digest is a first-class input to every SEO decision. The question “what kind of problem is this?” has a programmatic answer that arrives before the morning session starts. If the digest shows “excluded by noindex”, the fix is deterministic. If it shows “crawled, not indexed”, the problem is content quality or duplicate signal. If it shows “unknown”, the problem is discovery.
The six pages on 24 June are the clearest example so far. The telemetry didn’t find the bug. It classified the bug — and that classification changed what we looked for, in what order, before a single line of page code was touched.
