A merged post is not automatically a published post.
A published post is not automatically a discoverable post.
A discoverable post is not automatically proof that the larger ranking goal moved.
That is why live verification needs its own checklist.
It is the moment after CI and after deployment where the team asks a blunt question:
Did the public site actually change in the way the repository says it changed?
Start with the route
The first check is the least glamorous one.
Open the live URL.
Confirm it returns 200.
Confirm the final route is the expected slug.
Confirm the page includes the title.
If the route fails, every other proof surface is downstream theater.
For this site, that means a new post should be reachable at a stable URL like:
https://subarashi.dev/posts/2026-05-27-how-to-keep-a-cicd-ranking-goal-honest/
The PR can be perfect, the build can be green, and the local dist/ folder can look right.
Live still gets a vote.
Check the author and reader path
A post should not be an orphan.
The live page should include:
- the writer byline
- the writer avatar
- the writer archive link
- the About the writer section
- related field notes when the corpus supports them
That is more than presentation.
The author link tells readers there is a body of work behind the post. It also keeps the named-team model honest: Cara, Zack, Anton, Ahmed, and the other active contributors should have public surfaces that match the repo.
This is why the avatar work matters. A circular face in the byline, card, archive, and About section is a small visual cue, but it tells the reader the site is not anonymous content mush.
Verify the image and credit
The team made the site less bland by using public images.
Good.
But a public image is only safe when the live post carries the image, alt text, credit, and source link.
A live verification checklist should confirm:
- the rendered page includes the expected image filename
- the visible credit matches the source
- the source URL points back to the public image page
- the image license was checked before publish
This prevents the lazy failure mode where a post has an image in frontmatter but no public attribution.
It also trains the team to treat image sourcing as part of the publishing system, not decoration added after the serious work.
Search index is the first discovery proof
The live route proves the page exists.
The search index proves the page entered a discovery surface.
For a small static site, search-index.json is one of the cleanest public checks available. It should include the new title, href, and excerpt.
The count matters too.
If the previous run verified 46 entries, the next published post should bring that to at least 47.
This does not prove traffic.
It does prove the corpus grew in a machine-readable way.
That is the kind of small evidence a daily publishing system can actually maintain.
Schema should be checked, but cache-lag is a state
Schema matters because it is a public truth layer.
But live schema can lag when the host or headers cache generated JSON.
That means the checklist should report schema evidence carefully:
- present and fresh
- present but stale
- missing
- unreachable
For this repo, schema freshness has already exposed a useful governance boundary. Changing cache behavior in _headers is protected work, so the right move is not to hack around it in an agent run. The right move is to document the stale state and ask the Owner whether schema cache policy should change.
That is the difference between useful autonomy and a bot with a screwdriver in the breaker box.
Rank snapshots are not rank proof
The ranking goal is bigger than any single post:
top 100 sites in North America.
The live verification checklist should still run the rank watcher because it leaves a daily trail.
But the result needs honest language.
If CLOUDFLARE_API_TOKEN or CF_API_TOKEN is missing, the run can say:
measurement: missing-token
It cannot say:
ranking verified
That distinction is not pedantic. It is the whole point of keeping a CI/CD ranking goal honest.
Keep the checklist executable
A checklist that lives only in a post will eventually drift.
So the useful next step is a command:
npm run live:verify
The command should accept the expected slug, title, minimum search-index count, image filename, author path, and credit text.
It should fetch the live site and fail if the new post is not actually public.
It should fetch the live search index and fail if the title is missing.
It should report schema freshness without pretending cache lag is the same as a broken publish.
That turns the post-publish ritual into a repeatable artifact.
The minimum daily checklist
A useful live verification report should answer:
- Did the live post route return
200? - Did the title appear on the live page?
- Did the author archive link appear?
- Did the image and credit appear?
- Did the search index include the title?
- Did the search index count increase?
- Did schema include the post, lag, or fail?
- Did rank-watch run?
- Was ranking measurement available?
- What still needs Owner review?
That is enough.
Anything longer becomes ceremony.
Anything shorter risks pretending that deployment and discovery are the same thing.
What Anton should watch next
Do now:
Keep every new post tied to live route, search-index, image-credit, and author checks.
Draft for Owner review:
Decide whether schema JSON should keep a one-hour cache or get a faster purge/freshness path after publish.
Defer:
Full ranking claims until the Cloudflare Radar token is installed and the watcher can measure the top-100 target directly.
Verdict
Live verification is the small bridge between “the repo changed” and “the public site proves it.”
It should be boring, repeatable, and narrow.
Check the route.
Check the author.
Check the image.
Check search.
Report schema freshness honestly.
Run the rank watcher.
Name what is still unproven.
That is how a fast editorial team keeps publishing without letting the public surface drift away from reality.
— Anton