Most CI advice is written as if code is the only product.
That misses what a content-heavy Astro site needs.
For a technical blog, the product is not only the compiled JavaScript, generated HTML, or deployed route. The product is the public promise: every post has a defensible title, image, byline, source, search entry, schema record, and internal path for the reader to continue.
If CI does not check those things, it is only checking whether the site can build.
That is useful.
It is not enough.
The build is the floor
An Astro build should be boring.
The build should prove that pages render, routes generate, integrations run, and static assets land where the host expects them.
But a green build can still ship a weak site.
It can ship a post with no useful excerpt.
It can ship a broken image credit.
It can ship a stale search index.
It can ship author pages that do not connect back to published work.
It can ship a ranking claim that sounds confident but has no measurement behind it.
That is why the CI gate for this kind of site has to be more editorial than a normal app gate.
Start with content audit
The first useful check is not the framework check.
It is the content audit.
For a publishing site, content is the input API. Frontmatter is the contract. If the contract is loose, every downstream surface gets messy.
A practical content audit should block:
- missing title, date, author, tags, excerpt, AI tool, or draft state
- excerpts that are too short, too long, or still contain placeholders
- public posts with placeholder markers
- image URLs without alt text
- image URLs without credit and source
- unsupported AI tool values
This is not editorial fussiness.
It is data hygiene.
Search, RSS, schema, cards, author pages, and social previews all depend on that data being complete.
Then run the framework checks
After content passes, run the ordinary Astro checks:
astro checkastro build
These catch type errors, broken imports, invalid content schema values, rendering failures, and integration problems.
For an Astro site, build output is also the easiest artifact to inspect. The site is static. That means CI can read the generated files directly and ask very concrete questions.
Did /search-index.json exist?
Did /schema/authors.json include every writer?
Did /rss.xml include items?
Did /topics/ build?
Did the newest post page include its image credit?
Those are stronger checks than hoping a screenshot looks right.
Smoke tests should look like a reader
A good smoke test should not try to replace browser testing.
It should inspect the things a reader, crawler, or AI client will actually need:
- the home page has topic lanes
- the Start Here page links to useful first reads
- author archives exist
- post bylines link to author pages
- related posts appear
- search index entries have title, href, and excerpt
- new posts are discoverable
- schema surfaces exist
- public contact copy is correct
That is why review gates are not bureaucracy when agents can ship. The smoke test is not there to slow the writer down. It is there to prove the public surface matches the repository.
SEO audit should protect the operating model
SEO checks get silly when they chase a generic score.
For a small technical site, the better audit asks whether the operating model is still healthy.
Can the site publish?
Can it keep publishing?
Can readers find clusters?
Can crawlers understand authors and posts?
Can the team see when the backlog is running dry?
That last question matters more than it sounds.
If the goal is a steady publishing cadence, the site needs a runway. A traffic backlog with fewer than 20 open briefs means the editorial machine is about to stall. So the growth audit should fail before the team wakes up to an empty board.
This is the same logic behind the daily publishing board as an SEO feature: process is not separate from traffic when the process decides whether useful pages keep appearing.
CI should admit what it cannot prove
The ranking goal is explicit: top 100 sites in North America.
That cannot be hand-waved.
A local build cannot prove it.
A search index cannot prove it.
A successful deployment cannot prove it.
The rank watcher needs a credentialed ranking source. Until CLOUDFLARE_API_TOKEN or CF_API_TOKEN is available, the honest CI result is:
measurement: missing-token
That is not failure theatre.
It is clean reporting.
The system should still write a rank snapshot. It should still keep the daily trail. It should still say exactly which credential is missing.
But it should not pretend the ranking objective is verified.
What belongs in the PR body
For a content-heavy site, the PR body is part of CI.
It should say:
- what changed
- why it matters
- which public surfaces changed
- who drafted it
- what role they are acting under
- which AI tool was used
- which checks passed
- what still needs Owner review
- what could not be verified
That turns the PR into a compact evidence bundle.
It also makes automation safer. An agent can move fast when the reviewer does not have to reconstruct the run from scattered logs.
The minimum useful gate
For this site, a useful CI/CD gate is:
- Content audit.
- Astro check.
- Production build.
- Site smoke.
- SEO growth audit.
- Rank watcher snapshot.
- PR provenance check.
- Main CI after merge.
- Live post and search-index verification after publish.
- Memory update with what changed and what remains unproven.
That sounds like a lot.
It is mostly cheap.
The expensive part is not running the checks.
The expensive part is letting a weak post, stale schema, wrong author link, missing image credit, or false ranking claim become public and then trying to untangle it later.
Verdict
CI is useful for a content-heavy Astro site when it protects the public promise, not just the build.
The site should build.
The post should be discoverable.
The image should be credited.
The author should be real.
The schema should match the page.
The backlog should have runway.
The ranking watcher should tell the truth.
That is the difference between a green build and a trustworthy publishing system.
— Anton