What to check before publishing content to GitHub

A solid publishing checklist is the difference between a clean release and a frantic rollback. When your website content lives in a Git repository, every publish is a commit — a permanent, timestamped change that downstream tooling reacts to immediately. There is no "preview only" once the file lands on your branch and your build kicks off. So the few minutes you spend verifying frontmatter, paths, links, and approvals before you click publish are some of the highest-leverage minutes in your whole content operation.

This guide walks through a practical, ordered pre-publish checklist for teams using a Git-backed workflow, with Acrosite as the working example. Acrosite is a Git-backed publishing platform: your content lives as Markdown or MDX with YAML frontmatter in your own GitHub repository, and non-technical people publish through the dashboard instead of editing files directly. Each item below explains not just what to check, but why it matters and what breaks if you skip it.

Why a pre-publish checklist matters in a Git-backed workflow

In a traditional CMS, "publish" flips a database flag and the change is easy to reverse. In a Git-backed setup, publishing commits a file to your repository on a configured branch and content path, then a deployment trigger tells your hosting provider to rebuild. That commit is the event. It is visible in version control, it can trigger a production deploy, and undoing it means another commit and another build.

That permanence is a feature, not a bug — you get a full history, clean diffs, and content that travels with your codebase. But it raises the cost of a sloppy publish. A missing required field can break a build. A wrong content path can scatter files where your framework never looks for them. A draft that skipped review can put unapproved client copy on a live site. A checklist turns those risks into a quick, repeatable habit.

The pre-publish checklist

Here is the sequence to run before you publish any Content Item — a Post, a Page, or an entry of a Custom Content Type. Work through it top to bottom; the order roughly follows how a real publish unfolds.

1. Confirm required fields and frontmatter are complete and valid.
2. Verify the target content path and branch are correct.
3. Check every media reference resolves.
4. Test internal links and slugs.
5. Review SEO fields — title, description, canonical, social.
6. Confirm review approval is in place.
7. Set the schedule and double-check the timezone.
8. Confirm the deployment trigger and watch the logs.

1. Required fields and frontmatter

Frontmatter is the YAML block at the top of the file that your framework reads to render the page. If a required field is missing or malformed, a strict static build will often fail outright, and a permissive one may render something broken.

In Acrosite, Custom Fields define the typed fields on a content type — text, rich text, image, an SEO field, and so on — so the editor surfaces exactly the fields your content type needs. Before publishing, confirm the required ones are filled and that types make sense: a date field holds a real date, an image field points at a real asset, a slug is present. A clean Post might commit to content/posts/ as:

---
title: "How we cut build times in half"
slug: "cut-build-times-in-half"
date: 2026-06-06
description: "A practical look at caching, parallel steps, and what actually moved the needle."
tags: ["performance", "ci"]
draft: false
---

Pay attention to draft. If your framework keys off a draft flag, make sure it reflects your intent before the file lands on the branch.

2. Content path and branch

A Git-backed publish writes to a specific branch and content path. Posts typically go to something like content/posts/, Pages to content/pages/, and each Custom Content Type to its own directory. If the path is wrong, the file commits successfully but your site never displays it, because the framework looks elsewhere.

Branch matters just as much. Publishing to main when your production build watches production, or vice versa, means your change either goes live unexpectedly or never appears. Confirm both before you publish, especially the first time you publish a new content type or onboard a new Project. To learn more about how committing to your own repository works, see GitHub publishing.

3. Media references

Broken images are one of the most common post-publish embarrassments. Every image or file referenced in the body or frontmatter has to resolve to a path your built site can actually serve. A reference that worked in a preview can break if the asset was never committed, if the path is relative in a way the build does not expect, or if the file name's capitalization differs from the reference (case-sensitive hosting will not forgive Hero.png vs hero.png).

Before publishing, scan the content for every media reference and confirm each one points at a committed, correctly named asset. If your framework expects images in a particular directory, make sure they are there on the same branch you are publishing to.

4. Internal links and slugs

Internal links break quietly. Nothing fails at build time when you link to /blog/old-slug that no longer exists — the page just 404s for real visitors. Before publishing, check that internal links point at slugs that exist or will exist, and that the new Content Item's own slug is the one you intend, because the slug usually determines the published URL.

Be especially careful when renaming. Changing a slug changes the URL and orphans any existing inbound links and bookmarks. If you must rename, plan the redirect in your framework or hosting layer as part of the same release.

5. SEO fields

SEO fields ship with the commit, so getting them right before publish avoids a re-publish later. Walk through the essentials:

• Title and meta description: present, accurate, and within sensible lengths.
• Canonical URL: correct, especially for content that exists in more than one place.
• Open Graph and social fields: a title, description, and a social image that actually resolves.
• Structured data, if your content type uses it: valid and matching the content.

A dedicated SEO field on the content type keeps this consistent across entries. Helpful SEO is the goal — complete and correct — not overwhelming. Fill what matters and leave the rest to sensible defaults.

6. Review approval

For client work and team workflows, publishing should never get ahead of approval. In Acrosite, Client Reviewers are invited per Project and see only the content assigned to them; they can read drafts, comment, and Approve or Request Changes, with no GitHub access, no billing visibility, and no workspace settings access. Internally, work moves through the Review Queue.

Before you publish, confirm the item has the approval it needs. If a Client Reviewer requested changes, those should be resolved and re-approved — not quietly published over. This is the step that keeps unapproved copy off a live client site. For more on this, see client review and the deeper write-up on client review workflows.

7. Schedule and timezone

If you are not publishing immediately, you are scheduling — and scheduling is where timezone mistakes hide. With Scheduled publishing, Acrosite holds the approved draft in the app and commits it at the chosen time, with no early commit to the branch. That keeps "ready" and "live" cleanly separated.

The one thing to verify carefully is the time and its timezone. "9:00 AM" is meaningless without knowing whose 9:00 AM. Confirm the scheduled moment is what you intend in the relevant timezone, and sanity-check the date — scheduling a launch for last Tuesday by accident is a classic slip. Planning a run of posts at once is easier from the Content Calendar, where you can see the whole sequence laid out.

8. Deployment trigger and logs

A commit makes the content real in your repository; a deployment makes it visible on the live site. After the commit, a configured deployment trigger profile tells your hosting provider to rebuild — manually or automatically. That last step is easy to forget to verify.

The first time you publish in a new Project, test the deployment trigger end to end so you know the rebuild actually fires. After any publish, use Publish Logs to confirm each step ran: content validated, committed to GitHub, commit SHA saved, deployment triggered — all without exposing tokens, hook URLs, or raw provider payloads. Deployment Logs record the trigger results. If a publish fails partway, you can retry where it is safe to do so, and Deployment visibility tells you whether the rebuild succeeded rather than leaving you guessing.

A quick before-you-click summary

If you only remember a short version, remember this: a publish is a commit, and a commit is hard to take back. Confirm the frontmatter is complete and valid, the path and branch are right, the media and links resolve, the SEO fields are filled, the review is approved, the schedule and timezone are correct, and the deployment trigger is configured. Then publish with confidence.

Most of these checks take seconds once they are habit, and the platform does the heavy lifting — surfacing the right Custom Fields, holding scheduled drafts privately, gating on approvals, and logging every step. You can explore how the pieces fit together across all the features, or see how teams structure this on the how it works page.