The gsc-telemetry digest on the morning of 24 June listed six pages as “URL is unknown to Google”: five legal pages and /stamp-duty-calculator. Not six newly published pages. These were established surfaces already returning HTTP 200, with index, follow meta and self-referencing canonicals. I ran a code review across all six and confirmed no technical SEO blocker before 10am. The diagnosis was non-technical. No crawl-weight from article body to those surfaces. The fix was six body-prose internal links, committed by midday alongside prerender unblocking, FAQ helper cleanup, and legal layout simplification. The afternoon was publishing.
That sequence is the operator loop when it runs: morning digest, sub-10am diagnosis, midday fix.
What Phase 1.6 added on 20 June
The ga-telemetry and gsc-telemetry skills both shipped on 20 June. Same architecture, different upstream APIs. ga-telemetry lives at ~/.claude/skills/ga-telemetry/: six stdlib-only Python modules, a SKILL.md, and a launchd plist. gsc-telemetry follows the same shape against Search Console.
Three other actions went in the same push: a sitemap canonical fix, twelve Request-Indexing nudges via the Search Console API, and IndexNow going live. Those were manual interventions against known gaps. The skills were the instrument going forward, not the fix for that day.
Before Phase 1.6, indexation status required manual pulls from Search Console: check when you remember, with an interval of days or longer. After, the signal arrived every morning. That is the change this section describes, nothing more. The editorial strategy was already set; the publishing backlog was already defined. The loop changed when the signal arrived, not what it reported.
The three-day sprint
22 June was eight PRs across four surfaces. Three articles published. YMYL schema retrofitted across the affected pages, clearing technical debt in the same session as new content. The IHT pillar opened with its Tier-1 publish: T-001, IHT-on-pensions. The editorial cron had a near-miss and recovered in the morning before any editorial work started. A topic-authority research bundle was assembled and committed alongside the publishing work.
23 June closed the eight-pillar map. Six additional articles. The Tier-1 trilogy finished. The AdSense “low value content” signal surfaced during the session: a diagnosis against the monetisation surface, not a blocker to publishing. Diagnostics ran in parallel with editorial work rather than sequencing around it.
24 June was the fix session the morning digest had already scoped. Six pages unknown to Google. Diagnosis confirmed non-technical. Six internal links, prerender unblock, layout simplification — all before noon.
Improving on the earlier account in eight-pillars-published-adsense-said-low-value-content-the-bottleneck-was-never: that article documented what closed and what AdSense flagged. This one is about the mechanism. The telemetry skills are what made a three-day closure possible rather than a three-week one. Without next-morning indexation signal, 24 June’s session would have started with a Search Console pull rather than a defined fix list. The six unknown pages would have stayed unknown until someone thought to check.
The operator loop
Four steps:
- Morning digest arrives from gsc-telemetry
- Gaps identified: coverage status, indexation failures, crawl anomalies
- Fix committed: internal links, schema corrections, prerender unblocks
- Request-indexing nudges fired where warranted
Next morning, the digest reports whether the nudges landed. That’s a tight feedback cycle for SEO work, which normally runs on days-to-weeks lag. The telemetry doesn’t compress Google’s crawl cycle. What it eliminates is human lag: not knowing a page is unindexed until someone thinks to check.
The 24 June session is the clearest illustration. Six pages in the digest. I confirmed via code review that no technical blocker was present. The gap was crawl-weight. Fix committed before noon because the agenda was set at 6am, not assembled through manual Search Console inspection at 10am.
The 22–23 June sessions ran on the same shape. The IHT pillar landed on 22 June; the digest the next morning reported indexation status; the 23 June session continued with additional publishes rather than spending time on diagnosis. The loop handled the monitoring. The sessions handled the publishing.
What the loop does not do
The loop is an instrument. It reports gaps. I close them.
Eight PRs on 22 June, six article publishes on 23 June, IHT pillar research, YMYL schema work, AdSense diagnosis: none of that is a product of observability. It is a product of knowing each morning what requires attention and what does not. The distinction matters. “We had good observability” is a different claim from “observability changed the pace.”
The evidence here supports the latter. The six unknown-to-Google pages existed before ga-telemetry and gsc-telemetry shipped, then appeared in the digest the morning after the skills went live. The loop made them visible on schedule; the sessions made them go away.
Out of scope for this phase: automated remediation. The loop is observe → human decision → fix. Whether any step becomes autonomous is a later question, not Phase 1.6.
What runs now
Both skills are operational. The daily digest is the default operating posture. The eight-pillar map is complete, but the loop continues: pages publish, Google takes time to discover them, the digest reports the gap the next morning, the fix follows.
The Phase 1.6 sprint set a reference point: three publishing days to close an eight-pillar topic-authority map, running diagnostic and editorial work in parallel. That pace was not a function of writing capacity. It was a function of signal latency, and the signal latency is now one day.
Build log entries for the sprint are dated 2026-06-20 through 2026-06-24 in docs/devlog.md. The telemetry skills are at ~/.claude/skills/ga-telemetry/ and the gsc-telemetry counterpart.
