Content calendar planning for Git-backed websites

--- slug: content-calendar-for-agencies title: "Content calendar planning for Git-backed websites" seoTitle: "Content Calendar Planning for Git-Backed Websites" metaDescription: "A practical guide to content calendar planning for agencies running Git-backed websites — set a cadence, track statuses, and map entries to scheduled publishing." focusKeyword: "content calendar planning" cat: "Content Operations" type: "Guide" read: "8 min read" excerpt: "Turn scattered client requests into a real plan. How agencies use content calendar planning, status tracking, and scheduled publishing to ship across many projects." author: "Acrosite Team" date: "2026-06-06" updated: "2026-06-06" image: "/blog/content-calendar-for-agencies.webp" imageAlt: "Abstract Acrosite illustration of a content calendar mapping planned entries to scheduled publishing dates across multiple client projects" ---

Most agencies do not have a content problem so much as a coordination problem. Briefs arrive by email, edits get approved in chat, and a publish date lives in someone's head until it slips. Content calendar planning is the discipline that turns those scattered requests into a single, visible plan: every piece has an owner, a status, and a date, and nothing reaches a client's live website by accident. When your sites are Git-backed — where published content lives as Markdown or MDX files in the client's own repository — a real calendar is what keeps the publishing pipeline calm instead of frantic.

This guide walks through how to set a planning cadence, what statuses to track, how to handle many clients at once, and how to connect your plan directly to Scheduled publishing so an approved draft commits to GitHub at exactly the moment you intended. The goal is a workflow that holds up whether you manage three websites or thirty.

Why content calendar planning matters for Git-backed sites

A Git-backed setup gives you durable, version-controlled content — but it also means publishing is a real event. Each publish commits a file to a branch and can trigger a rebuild of the live site. That is exactly why you want planning to happen *before* anything touches the repository, not during a scramble.

Without a plan, three failure modes show up again and again:

• Work happens reactively, so the most urgent request wins instead of the most important one.
• Approvals stall because nobody knows a draft is waiting on a client.
• Publishing clusters into unpredictable bursts, which makes Deployment visibility harder and review quality worse.

A content calendar fixes all three by making the pipeline legible. In Acrosite, planned work lives in the Content Calendar as Content Items — the individual entries for your Posts, Pages, and Custom Content Types — each with a clear status and a target date. The calendar is the plan; the repository is the outcome.

Turn scattered requests into a single intake

Before you can schedule anything, you need one place where requests land. An intake step prevents the calendar from becoming a dumping ground of half-formed ideas.

A simple, repeatable intake looks like this:

1. Capture the request with a working title, the target Project, and the content type (a Post, a Page, or a Custom Content Type like a case study).
2. Add the essentials: primary goal, target keyword if relevant, and any hard deadline.
3. Decide whether it is committed work or a backlog idea — only committed work gets a date.
4. Create the Content Item so the draft has a home in the app from day one.

The discipline here is small but important: a request is not "on the calendar" until it has a type, an owner, and a status. Everything else is a backlog note.

Set a planning cadence you can actually keep

Cadence is what separates a calendar that lives from one that goes stale after two weeks. Pick intervals that match how your agency really works, then protect them.

A monthly planning rhythm

• Monthly: review each Project, confirm the themes and committed pieces for the month, and slot target publish dates.
• Weekly: triage the Review Queue, unblock anything waiting on a client, and confirm next week's scheduled items are on track.
• Daily (light): a quick scan of what publishes today and what is overdue for review.

The monthly pass sets direction; the weekly pass keeps reality and the plan aligned. Most slips happen between those two — a draft that was "almost done" three weeks ago — so the weekly triage is where a calendar earns its keep.

What statuses to track

A status is a promise about what happens next. Keep the set small enough to be honest and rich enough to be useful. A practical pipeline for agency work:

• Idea / Backlog — captured, not committed, no date.
• Drafting — assigned and being written; drafts are private in the app until published.
• Internal review — sitting in the Review Queue for a Team Member to check.
• Client review — shared with a Client Reviewer, who can read, comment, and Approve or Request Changes.
• Approved / Scheduled — signed off and queued for Scheduled publishing at a set date and time.
• Published — committed to the connected repository, with the result captured in Publish Logs.

Two distinctions matter. First, internal review and client review are different stages with different audiences: Client Reviewers see only the content assigned to them and have no GitHub access, no billing visibility, and no workspace settings access. Second, "Approved" and "Published" are not the same — an approved draft can wait in the app for its scheduled moment without an early commit to the branch. Read more about how that gate works in the client review workflow.

Map calendar entries to scheduled publishing

This is where planning becomes operational. Each dated entry on your calendar should correspond to a real publish action, and Scheduled publishing is what makes the date trustworthy.

Here is the sequence for a single piece:

1. The draft is approved in the Review Queue (and by the Client Reviewer when the project requires it).
2. You set a publish date and time on the Content Item.
3. Acrosite holds the approved draft in the app — there is no early commit to the branch.
4. At the scheduled moment, the Markdown or MDX file is committed to the connected repo on the configured branch and content path.
5. A configured deployment trigger profile prompts your host to rebuild, and the steps are recorded in Publish Logs and Deployment Logs.

A published Post typically commits a file with frontmatter that mirrors the fields you defined through Custom Fields. For example, a file landing in content/posts/ might begin:

---
title: "How we cut a client's build time in half"
date: 2026-06-18
status: published
description: "A short case study on incremental builds."
---

Because the frontmatter is generated from typed Custom Fields rather than hand-edited in GitHub, the same fields you planned around in the calendar are the ones that ship. To see how scheduling holds an approved draft until its moment, see Scheduled publishing; for how the commit itself works, see GitHub publishing.

Plan across multiple clients and projects

A single-site calendar is easy. The real test is running many client websites without losing the thread. The structure that makes this manageable: a Workspace contains Projects, each Project maps to one client website and its repository, and Clients group related work.

With that structure in place, content calendar planning scales in a few ways:

• Per-project view: zoom into one client's website to plan themes, balance content types, and confirm their committed dates.
• Cross-project view: step back to see where publishing clusters across all sites in a given week, so you can spread out workload and reviews.
• Capacity check: if three clients all want a launch piece on the same Thursday, the calendar shows the collision before it becomes a late night.

Assign each Content Item to the right Project at intake so it inherits the correct repository, branch, and content path automatically. That single decision is what lets one plan drive publishing across many independent sites without crossing wires.

A quick multi-client planning checklist

• Every committed item has an owner, a status, and a target date.
• Each item is attached to the correct Project and content type.
• Client-facing pieces have a Client Reviewer assigned before they reach client review.
• Scheduled items have a confirmed publish date and time, not just a vague week.
• The week's publishing load is spread, not stacked on one day.

Keep the plan honest after publish

Planning does not end at the commit. A calendar that ignores outcomes drifts out of trust. After each scheduled publish, the Publish Logs record the steps — content validated, committed to GitHub, commit SHA saved, deployment triggered — without exposing tokens, hook URLs, or raw provider payloads. If a publish fails, you can retry it where safe and reschedule, and the calendar reflects the real state rather than an optimistic one.

Close the loop weekly: anything that published moves to done, anything that slipped gets a new honest date, and anything stuck in review gets a nudge. Over a few cycles this is what produces a steady, predictable output your clients can feel — which is the entire point of content calendar planning in the first place. If you want to see how the pieces fit end to end, the features overview and how it works pages walk through the full path from draft to live site.