Adding Search Console

This site has been running for years, optimised for traffic, with no connection to the one free tool that reports how search actually sees it. That gap got closed on 2026-08-09. This records what the thing is, why it was worth doing, and what to measure afterwards.

What Search Console is

It is not analytics. That distinction is the whole reason it matters.

Plausible — which this site already runs — counts page loads. It sees a visitor once they have arrived. Everything upstream of the click is invisible to it.

Search Console reports the layer above: what Google indexed, which queries the site appeared for, how many times each result was shown, and how often anyone clicked.

The gap between them is the interesting part:

	Plausible	Search Console
Impressions — you appeared in results	no	yes
Position — where you appeared	no	yes
Query — what was typed	no	yes
Click-through rate	no	yes
What happened after arrival	yes	no

Click-through rate is clicks divided by impressions. Plausible has the numerator and none of the denominator, so a whole class of question is simply unanswerable without Search Console: are we not being found, or are we being found and not clicked? Those have opposite fixes — one is a content and indexing problem, the other is a titles and descriptions problem — and analytics alone cannot tell them apart.

It also reports things nothing else will: pages Google refused to index and why, manual actions, structured-data errors, and which queries the site ranks 8th–20th for, which is the cheapest list of improvements available anywhere.

Why this was urgent, and not just useful

Search Console does not backfill. Not a single day.

Data collection starts at verification. Everything before it is gone permanently — not withheld, not behind a paywall, never recorded for you. Google keeps its own logs but does not hand you history you weren't verified for.

So every day this wasn't set up was a day of query data destroyed. That framing is what moved it from "should do eventually" to "do tonight." It's also why it had to happen before the dates experiment rather than alongside it: that test needs a baseline, and a baseline cannot be retroactive.

The 16-month retention window compounds it. Even now, data ages out — so the earlier verification happens, the longer the usable history.

What was done

Domain verification for thomasrones.com via DNS TXT record in Route 53. Domain property rather than URL prefix, so it covers every subdomain and both protocols without separate properties. Verified 2026-08-09.

Five other domains were verified in the same sitting — apresapply.com, talktop.us, insightsmesh.com, fxf.social, sceneforscenes.com — but this experiment covers thomasrones.com only, and the cohort below is this site alone. The others have their own baselines starting the same day; they are not part of this measurement.

One thing worth recording from the DNS work: the apex already carried an openai-domain-verification TXT record from an earlier setup. So one AI channel had domain ownership confirmed well before any of this, which matters to the citation question and was not something I remembered doing.

The visibility toolkit covers what else is worth setting up alongside it.

This is a milestone, not a controlled experiment

Being straight about what this can and cannot show.

Adding Search Console does not change the site. It's a measurement instrument, not an intervention. It cannot itself cause traffic to move.

What it does mark is a point in time worth measuring around — and the confounds are substantial and known in advance:

• More articles are being published continuously. The corpus grows, so traffic grows.
• Projects are being built and shipped, generating their own referral traffic.
• The slug work landed the same week: 68 articles moved off UUID URLs onto readable ones, which is a real SEO change with its own independent effect.
• Structured data and the published field are planned for the same period.
• Search algorithms move on their own schedule.

Any traffic increase over the next quarter has at least five plausible causes and this isn't one of them. Do not read a rise as evidence that Search Console worked. It's an instrument being switched on, and the honest claim is only that the data starts existing here.

The cohort, which is what makes later comparison possible

The largest confound — publishing more articles — is the one that can actually be controlled for, so it has been.

_cohort-2026-08-09.json freezes every routed article that existed on the day of verification: 475 articles, with id, link, path, title and last-update date.

When the data gets pulled, the comparison restricts to those links. An article published in October cannot inflate the result, because it isn't in the set. Traffic to the frozen cohort answers a much sharper question than total traffic does: is existing content being found more, or is the site simply bigger?

The id is what makes this durable. Slugs and paths can change — 68 of them changed this week — but a UUID doesn't, so the cohort survives reorganisation. Match on id first and fall back to link.

Next check

2026-11-09, roughly 90 days out.

pk_todo: collect Plausible data for the frozen cohort and compare against the same window a year prior. Also pull the first Search Console figures — impressions, average position, CTR, and the queries ranking 8th–20th.

90 days is chosen over six months for a specific reason: Search Console's window is 16 months, and waiting longer means the earliest data is already ageing out of comparison range by the time anyone looks at it.