Tag: site health

My mentions agent already sent a weekly email. It told an athlete what people said about them that week: new mentions, the one ad-ready quote, a game plan. Good, but half a report. An athlete’s presence online is two things, what people say about you and how your site is doing. So I built the second half, and this is the story of the weekly AI report, version one.

This is the build behind the promise on every Athlete Spotlight weekly report: your site and your mentions, what changed and what to do next. It is part of my Positive Mentions System, built by Cam Hazzard and developed with Dennis Yu, and it runs on the MAA framework (Metrics, Analysis, Action). Here is exactly how the second half got built, with the real numbers and the honest gaps.

What the weekly AI report needed

The assignment was easy to say and easy to get wrong: add a “your site this week” section to the existing mentions digest without touching the email safety rails. The source material was the production digest engine (digest.py) and the MAA framework from canon. The deliverable shipped as one new module, site_signals.py, 455 lines of Python, wired into the digest and committed on 2026-07-02.

The goal category is the honest one: a client deliverable, and the part of an Athlete Spotlight subscription that makes it worth renewing. A report that reads like a person wrote it, that a 16-year-old athlete’s parent can understand, and that never says anything we did not measure.

How I built it, step by step

First rule I set: free APIs only. That is a standing constraint in my system (no billing), and it forced honest engineering instead of buying a dashboard. The section collects six signal families, all real numbers.

1. Site status: up or down, the actual HTTP status code, and response time in milliseconds, from a plain stdlib fetch with no key.
2. Uptime over the last 7 days: from UptimeRobot’s free API, the monitor matched by hostname.
3. Speed score out of 100, plus LCP and CLS: from Google PageSpeed Insights on mobile.
4. SSL certificate: days until renewal, read straight off a TLS handshake.
5. Search basics: does the homepage have a title tag and JSON-LD structured data.
6. Week-over-week deltas on all of it, computed against a history file capped at the last 60 snapshots.

Then the MAA shape from the framework. Metrics are the numbers above. Analysis is one short rule-based paragraph that names the weakest area and the week-over-week movement. Action is up to three concrete items, and the first one always targets the weakest signal, in a fixed priority order: site down beats SSL trouble beats slow responses beats uptime slips beats speed beats search basics.

The safe test path matters as much as the feature. A --render-only flag writes the full HTML preview and never sends, never stamps the send date, and never writes to the history file. Previews cannot skew next week’s deltas, so I can check a report before an athlete ever sees it.

The calls I’d defend

Three decisions in this build I would defend to anyone.

A 403 is not “down.” Bot protection returns 403s all day. The report states the real HTTP code the site returned instead of crying outage, and when the failure is on our side of the network, it retries once, then says “check inconclusive this week.” It never invents a confirmed outage.

Opt-in per athlete, byte-identical otherwise. The section only renders when an athlete’s config has both a site URL and the report switch on. Without both keys, the digest output is byte-identical to the old behavior, verified by diff at build time. Existing subjects felt nothing.

Don’t claim what we can’t measure. Google Search Console queries, clicks, and traffic need the owner’s OAuth per site. There is no free keyless path, so the report says “not yet connected” instead of faking it. The sales-copy guardrail is written into the module’s own docs: here is what is honest to say, here is what is not yet.

What it cost, honestly

Honest label first: I do not have a token receipt for this build. The session metrics extractor is still an open gap in my system, so the numbers below are documented estimates, not measured figures.

Task	Agent time (est.)	Human time (est.)	Agent cost (est.)	Human cost (est.)
Design and build site_signals.py (455 lines) plus digest wiring	~2 to 3 hours of session time	2 to 3 days for a developer	low single-digit dollars in tokens	$560 to $840 at $35/hr

Running cost is the part I like: $0. Every API in the report is free tier. The two optional keys (UptimeRobot and PageSpeed) are free accounts, and the HTTP, SSL, and search-basics checks need no key at all.

What the agent did, and what a human owns

Autonomous: collecting every signal, computing deltas against history, writing the analysis paragraph and the three actions, rendering the branded email, and previewing safely. Also failing gracefully, so a dead API can never block the mentions half of the report.

Human required: consent. Emailing is gated exactly like before (a real recipient plus an explicit send). Connecting UptimeRobot monitors and any future Search Console OAuth are owner actions. And the report is generated as a file first, so nothing auto-publishes anywhere.

What the agent read

Production code read: the digest engine, the mentions knowledge-base layer, and the subject config contract. Canon loaded: the MAA framework and the no-em-dash rule (every generated line is scrubbed by construction). External docs: the UptimeRobot API v2 and PageSpeed Insights references. Tokens: not measured (see the cost section). Voice profile: not needed for the build, applied to this write-up.

How it scores against our own gate

This article ran through the same 18-step article gate we use on client work. What passes now: first sentence under 10 words, zero banned AI words, zero em dashes, contractions throughout, real numbers with estimates labeled as estimates, and the canonical parent linked (the Positive Mentions System, built by Cam Hazzard and developed with Dennis Yu). What still needs a human: the featured image, a final fact pass by Cam, and live cross-link verification after publish. That honesty is the point of a meta article: show the work, including the parts a person still owns.

See the standard, and get started

The live standard this build serves is The Athlete Weekly AI Report, the article that defines what every Athlete Spotlight report is built to. This meta article is one of three documenting that build; the next covers how positive mentions were wired into athlete sites.

When you are ready, get started for $30 per month and the weekly report starts once your site is live. Parents are welcome to check out on an athlete’s behalf.

The takeaway is the same one I keep coming back to: be so good they can’t ignore you, and be honest enough that they trust you when they look. A report built on numbers nobody had to pay for, that never says anything we didn’t measure, earns that trust.

Built by Cam Hazzard, developed with Dennis Yu.