The adsense-telemetry skill read GETTING_READY on 2 July. Account status was READY, no policy strikes, Auto Ads enabled. I had built a readiness audit the same day, which checked eight criteria against Google’s reviewer checklist and returned 7/8 green. The one red flag was media diversity: zero of 38 pages had a visual element. That afternoon, an ArticleFigure component shipped alongside six verified SVG diagrams across the pillar estate. By evening the gap was closed.
Eight days later, at 17:42 BST on 10 July, the decision arrived.
Rejected. The stated reason: Low value content. Ads.txt came back Authorised, which was never the question.
What was built before submitting
The submission on 2 July wasn’t impulsive. Three weeks of work preceded it.
In late June I had audited the site for thin surfaces and identified five calculator landing pages as content-sparse: short descriptions, minimal body, nothing a reviewer would read as substantive. I expanded all five via an ultracode workflow. The gilts explainer moved from a stub to a full article. The cadence clock had reset to Day 0 during this period; the content was in regardless.
The adsense-telemetry skill itself shipped on 2 July in response to a direct question: “are we ready for AdSense?” I built the skill to make that question answerable programmatically. Read-only access to the AdSense Management API v2, approval status and payment state pulled from the terminal rather than the console. The first OAuth attempt failed silently on a blank paste at the client-id prompt. The second ran clean.
The live read after auth came back: account READY, site GETTING_READY (review in progress), no policy strikes.
The media diversity gap closed that afternoon. It was the last red criterion; the audit had scored it zero, no visual element across the 38 pages. Six verified SVG diagrams shipped alongside an ArticleFigure component, specific to their pillar topics. Nominally 8/8 green.
Submission felt defensible.
What the checklist was actually measuring
This follows adsense-rejected-the-site-the-ads-txt-was-fine, which documented the rejection and confirmed ads.txt was not the issue. What that post didn’t have was the full retrospective on why three weeks of preparation failed to predict the outcome.
The readiness audit was a process checklist. It verified whether Auto Ads were enabled, whether ads.txt was configured, whether content existed in multiple formats, whether a minimum page count was met. These are necessary conditions for submission. They are not editorial criteria.
Google’s “Low value content” finding under the inventory-value policy operates on a different axis. The question is not whether content exists in the right formats. It is whether the content provides value a visitor could not find elsewhere in the same category. An SVG diagram and an expanded description on a calculator landing are improvements over a stub. They are not, by themselves, evidence of distinct editorial value.
That distinction does not appear on any checklist. It is an editorial judgement. The telemetry skill reads API status fields; it cannot read a reviewer’s content-value assessment.
The 7/8 green score was an accurate process audit. It was not a content-quality prediction, and nothing in the build-up treated it as one. The false confidence came from conflating two different claims: “the API says READY” is a statement about account configuration; “we are ready” is a claim about editorial quality. The tooling didn’t distinguish between them. Neither did I, until after the rejection.
What the root-cause audit found
On 11 July I audited line-by-line against Google’s inventory-value policy and found a literal match in the policy text. The /resources/blog and /resources/guides hub pages, whose job is to aggregate and surface the site’s editorial content, were stub listings. Near-empty. The articles existed; the navigational surface that proved they existed did not.
A reviewer landing on /resources/blog would have seen minimal copy and no article content. The editorial work existed in the site, but none of it was visible from the hub. From a reviewer’s position, the site did not have articles. It had a page that asserted it had articles.
Remediation #1 shipped the same day: real hub listings for both pages. Each hub now renders actual article previews (titles, excerpts, dates) pulled from existing content. The pages became evidence of the editorial work already done, rather than stubs that implied nothing was there.
What this covers and what it doesn’t
Remediation #1 is one fix in what will likely be several. The “Low value content” verdict does not specify which pages triggered it. The hub listings were the most obvious gap, the one with a direct match in the policy text. Whether that is the only gap will not be clear until resubmission.
Out of scope for this sprint: calculator pages where the tool output is the primary value and surrounding prose would be padding. Those require a different treatment (worked examples, structured data, comparison tables), not more description of what the tool does. Separate sprint.
The SVG diagrams from 2 July stay, the thin-surface expansions stay, and the telemetry skill keeps its job of monitoring account state going forward. None of that work was wasted; it was necessary, not sufficient. It solved process compliance when the question was editorial quality.
The check that was missing
The readiness workflow was correct for what it measured. The skill read the right fields. The checklist checked the right boxes. The gap was a check that cannot be automated.
Before submitting for AdSense review, the additional step is: walk the site as a reviewer would, not as a builder. Ask whether each page provides something that cannot be found on the other calculator sites in the same category, whether that is analysis, a worked example, or context that adds to rather than restates what the tool does. That is a judgement call. No API query returns it, and no checklist item covers it.
That check was skipped because the process audit looked clean and the bar felt met. The rejection is the record that it was not.
Remediation progress is in the devlog. Resubmission follows after at least one more sprint.
