A repeatable article publishing checklist: from source file to verified live URL

An automated publishing task is complete when the intended article is available at its canonical live URL and passes the agreed checks. A content write, a queued build and a successful local preview are useful intermediate states. Recording them separately prevents a workflow from marking an article published while an older release is still serving.

1. Give the article and destination stable identities

Before generating or uploading anything, resolve the selected brand into its repository, source path, public origin and media destination. Carry that selection through the execution. Do not infer the brand later from an image upload response or whichever row happens to be first in a sheet.

Give each editorial item a stable ID and intended path. Keep the original publication date when updating an existing article. Make the content format explicit: a body fragment should not contain a second page header, footer or stylesheet. The site template should own those elements so new and existing articles use the same navigation and layout.

2. Validate the content before writing it

Check the title, summary, body, real author, date and status against the destination’s contract. Read the article as a person would: does it answer its main question, explain the next step and support material claims? Inspect comparison tables for consistent criteria rather than treating a table as decoration.

Verify internal links in context. A related guide should help a reader continue the task. For a publishing workflow, Stack & Method’s REST API and webhook comparison is a useful explanation of request and event patterns. Avoid adding the same unrelated network links to every article.

Keep unsupported executable markup out of generated content. Validate any permitted interactive component separately, including keyboard behavior and reset states. A calculator that looks correct but never responds is a failed feature, even if the article text renders.

3. Confirm media belongs to the destination

Upload files to the selected site’s media storage or commit repository-owned assets where that is the site’s standard. Check the public image URL, content type and dimensions. Use concise descriptive alt text for meaningful images; do not insert production-process commentary into that description.

Open the article on desktop and mobile. Check that the hero is appropriate, logos remain modest and centered, tables can be read, and pop-ups do not hide the navigation or reading controls. Verify the actual image rather than assuming an upload response proves the CDN URL is public.

4. Treat the repository write as a staging event

When publishing through GitHub’s Contents API, file content is Base64 encoded and updates require the file’s existing blob SHA. These requirements are documented in GitHub’s create-or-update endpoint. A successful response proves the source write, not the site deployment.

Record the commit and build identifier. Make retries safe: first determine whether the intended item already exists, and avoid creating duplicate articles after a lost response. Preserve the last known good version until the replacement has passed its checks. If a conflict occurs, reread the current state rather than repeatedly overwriting it.

5. Check the generated site and release configuration

Run the build and inspect the emitted HTML. Confirm one meaningful H1, the preferred canonical, archive discoverability, useful navigation and working local links. Parse every structured data block and compare it with the visible article using our JSON-LD validation procedure. CheckMySchema and its Machine Interface provide additional checking routes.

Confirm which branch and output directory the host deploys. Cloudflare documents distinct production and preview branch controls and build output configuration. Review the project’s actual setup against branch controls and build configuration; a healthy preview does not establish that the canonical domain received it.

6. Verify the live URL before completing the queue

Retrieve the canonical URL after deployment and match it to the intended revision. Check the real response, article heading, body, images and JSON-LD. Confirm the archive links to it and the sitemap contains the preferred public URL. Recheck redirects and public indexing settings with the crawler access procedure.

Only then mark the queue item Published with its live URL and verification time. Keep a failed build or mismatched release in a recoverable state with an actionable error. Finish the record with the source commit, deployment result, live checks and any remaining limitations. That small receipt is what makes the next publishing run—and the next repair—repeatable.