Daily blog release checklist
A route by route release checklist that separates build success from content acceptance and public verification.
daily blog release checklist
Start with the accepted route roster, not the files that happen to be ready. Freeze the ordered slugs, target date, routine identity, and expected count in the release record. Compare that record with the actual content export before touching a build.
A missing route and an extra route are both failures, even when every page that remains can compile. Name one release owner who can stop the batch when identities disagree.
1. Inspect the editorial payload
Review the diff route by route. Confirm title, description, category, author, focus phrase, publication date, reading time, sections, citations, internal links, frequently asked questions, and media. Open cited sources for consequential claims instead of checking only that their URLs respond.
Read the final copy for unsupported certainty, copied scaffolding, accidental private context, and punctuation prohibited by the content standard. Record exceptions before running automated gates.
2. Run gates from a clean understanding
Run the repository's content tests, type check, dependency audit, production build, and policy checks exactly as maintained. Do not weaken a threshold to make the batch fit. Save each command, exit status, and relevant warning.
A warning may be accepted only when its meaning is understood and the repository policy permits it. If a generated file changes unexpectedly, stop and explain the cause before continuing.
3. Check route level representations
Use the built artifact to inspect every accepted route, not just the index page. Compare the visible title, opening answer, canonical URL, dates, image, internal links, and FAQ text with the source record. Inspect the sitemap and structured data representation for the same identity.
A valid schema object can still describe the wrong page, and a correct page can still be absent from discovery surfaces. Both conditions block release.
4. Hold instead of improvising
Stop when the route count changes, a slug is substituted, authorship is wrong, a claim lacks support, media is missing, an internal destination falls outside the accepted set, visible FAQs disagree with schema, or any required command fails. Assign the defect to a named owner and rerun the affected gate after repair. Never hide a failed check beneath a later successful build, since compilation and editorial acceptance answer different questions.
5. Preserve a reproducible release record
When all gates pass, record the immutable revision, exact command results, accepted roster digest, and verification time. Public verification should request every route from the released revision and compare the response with the approved list before publication is reported complete. Keep failures and reruns in sequence so another operator can reconstruct what happened.
The checklist closes only when repository evidence and route evidence point to the same batch.
6. Reconcile the repository before release
Fetch the canonical branch immediately before creating the release candidate. Compare the local base, remote head, active worktrees, and open family work so two batches cannot rewrite the same content registry or sitemap ownership at once. Preserve unrelated changes and stop when the candidate cannot be separated from another owner's work.
Rebase the accepted diff onto the exact remote head, rerun affected checks, and stage only runtime content, governed media, manifest data, and behavior-preserving support changes. Reports, caches, credentials, rejected drafts, and internal queues do not belong in the release tree. Inspect the staged diff again because a clean working tree does not prove that the right files were selected.
7. Verify discovery and page identity
Check the Blog index, canonical tag, recursive sitemap path, title, H1, byline, publication date, image, Article data, internal links, external source, and FAQ content for every route. Compare rendered HTML with the accepted record rather than relying on a component preview. Request media directly and confirm that each asset belongs to the intended article.
Scan rendered text for prohibited punctuation, hidden placeholder copy, unsupported claims, and duplicated scaffolding. Check that each first H2 matches its focus keyword and that short paragraphs remain readable in the actual layout. A route that returns successfully can still fail editorial identity or discovery ownership.
8. Prove the deployed revision
Revalidate the deployment application, repository, branch, and production domain before starting a release. Poll the scoped deployment to a terminal result and record the revision reported by the platform. Do not treat a push, webhook, or deployment start as proof that readers received the candidate.
After success, request every new canonical route and required index or sitemap from production. Compare titles, headings, media, links, schema, and cardinal rules with the frozen manifest, then save sanitized evidence with the immutable revision and verification time. Publication is complete only when the deployed identity and the live responses agree.
Sources
- Article structured data, Google Search Central. Documents Article properties including headline, image, datePublished, and dateModified, supporting the route representation checks in this checklist.
Related GTM guides
Frequently asked questions
Does a successful production build approve the blog batch?
No. A build shows that the application compiled under its build rules. The release still needs the frozen roster, editorial fields, evidence, links, media, schema, sitemap, and route responses to match the accepted batch.
What should the release owner save?
Save the ordered roster and digest, immutable revision, commands and exit statuses, defect decisions, rerun results, and route verification time. That record should let a second operator reproduce why the batch was accepted without relying on private chat history.
When can publication be reported complete?
Report completion only after the deployment reaches terminal success, the platform identifies the expected immutable revision, and every accepted route plus its discovery surfaces passes live verification on the canonical domain.