Set a Publishing Cadence You Can Actually Keep

Pick a sustainable publishing cadence from your real 8-week git log, with a 0.8x floor formula, a backlog-buffer script, and a weekly streak check you drop into your repo.

Most indie content sites die not from bad content but from inconsistent shipping. A 12-week burst followed by 4 months of silence is worse than half the volume on a steady schedule. The data backs this up: in Orbit Media’s 2025 blogger survey of 808 bloggers, those who publish more frequently and consistently were more likely to report “strong results,” while the overall baseline sits at just 21%. The goal of cadence is not maximum output. It is predictability, and you measure it from your actual git log, not your hopes.

TL;DR

  • Measure your last 8 weeks from git log, not memory.
  • Multiply by 0.8 to get a floor you can hold on bad weeks. Round down to a clean schedule.
  • Document fixed publish days in CONTENT.md and keep a 2-3 article backlog buffer.
  • Track one binary per week: did I publish, yes or no. Ignore word count and hours.
  • Reassess every 13 weeks. Raise or lower by one article/month. Never adjust mid-quarter.

Why consistency beats bursts

Google does not literally reward a “post every Tuesday” pattern, but its Query Deserves Freshness behavior rewards sites that keep shipping relevant content over time, and a substantive new article is a stronger signal than a backdated republish with no real change. AI answer engines raise the stakes further: as of June 2026, multiple SEO analyses report that pages updated within the last 30 to 90 days get cited by tools like ChatGPT and Perplexity at noticeably higher rates, and that AI-cited pages skew meaningfully fresher than the traditional Google organic average.

The harder constraint is you. Without a cadence, content gets pushed to “later” indefinitely. A measurable cadence plus a small backlog plus a weekly publish-day check is the smallest system that actually holds.

Signs your cadence is off

  • You publish in waves: fast weeks followed by silence.
  • You set a target months ago and have not held it.
  • You feel guilty about your publishing rate (a sign the target is wrong, not you).
  • Your last 8-week average is well below the number you committed to publicly.

Quick verdict: Pick the lowest cadence you are 90% sure you can hit for 12 months straight, even on bad weeks. That is your real cadence. Everything above it is bonus.

What a realistic cadence looks like

For a solo indie site, the sustainable sweet spot most 2026 surveys point to is 1 substantial post per week, with 2-3/week reserved for teams or competitive niches. Anchor your expectations against real benchmarks rather than what other sites claim:

Metric (Orbit Media 2025, n=808)Value
Average blog post length1,333 words
Average time to write one post3 hours 46 minutes
Bloggers reporting “strong results” (baseline)21%
Strong-results rate for 2,000+ word posts39%

The takeaway for cadence math: budget roughly 4 hours per article and assume your average will be long-form. If 2 articles/week means 8+ focused hours you do not have on a bad week, your floor is lower than you think.

Step by step

1. Measure honestly from git log

Published dates live in frontmatter, but the git log proves when you actually shipped:

# unique articles touched in the last 8 weeks
git log --since="8 weeks ago" --pretty=format:'%ai' --name-only -- 'src/content/articles/' \
  | grep '\.mdx$' | awk -F/ '{print $NF}' | sort -u | wc -l

# NEW articles added (A = added) in the last 8 weeks
git log --since="8 weeks ago" --pretty=format:'%ai' --diff-filter=A --name-only \
  -- 'src/content/articles/' \
  | grep '\.mdx$' \
  | awk -F/ '{print $NF}' | sort -u | wc -l

Or even simpler, straight from frontmatter:

grep -rh '^publishedAt:' src/content/articles \
  | awk '{print $2}' \
  | awk -F- '{print $1"-"$2}' | sort | uniq -c
# articles per year-month; the last few months tell the truth

2. Multiply by 0.8 to get your floor

If you shipped 16 in 8 weeks, your true cadence is 16 × 0.8 / 8 = 1.6 articles/week. Round down to a clean schedule (1/week, 2/week). The 0.8 multiplier is the buffer for the weeks you get sick, travel, or burn out. A floor you only hit on good weeks is not a floor.

3. Pick fixed publishing days

Tuesday + Friday is a common pattern. Write the schedule into CONTENT.md so it survives your future doubts:

# Publishing cadence
- Target: 2 articles/week
- Days: Tuesday 10:00 ET, Friday 10:00 ET
- Backlog buffer: 2-3 articles ready at all times
- Reassess quarterly; no mid-quarter adjustments

4. Build a backlog buffer

A simple drafts/ folder with articles ready to ship absorbs your bad weeks:

ls drafts/*.mdx | wc -l
# warn if below 2:
[ "$(ls drafts/*.mdx 2>/dev/null | wc -l)" -lt 2 ] && echo "WARN: backlog below 2"

Add it to your weekly checklist. The warning before the warning is the warning.

5. Track only “published this week: yes/no”

Do not track word count or hours. They do not correlate with the outcome you care about (a published page). A tiny tracker:

// scripts/cadence-check.mjs
import { execSync } from 'node:child_process';
const since = new Date(Date.now() - 7 * 86400 * 1000).toISOString().slice(0, 10);
const out = execSync(
  `git log --since="${since}" --diff-filter=A --name-only -- 'src/content/articles/'`
).toString();
const newArticles = out.split('\n').filter(l => l.endsWith('.mdx')).length / 2; // en + zh
console.log(`This week: ${newArticles} new articles`);
if (newArticles === 0) console.log('STREAK BROKEN');

Run it as a weekly cron or a Friday-morning ritual.

6. Reassess every 13 weeks

A quarterly summary by ISO-ish week:

grep -rh '^publishedAt:' src/content/articles \
  | awk '{print $2}' \
  | awk -F- '{print $1"-W"int(($2*30+$3)/7)}' \
  | sort | uniq -c | tail -13

If the cadence felt easy for 12 weeks, raise it by one article/month. If it felt hard, lower it. Do not adjust mid-quarter, or you will rationalize your way back to chaos.

7. Do not front-load

A 20-article launch week followed by 8 weeks of silence is worse than 2/week steady, both for the freshness signal and for your own habit. Spread the first batch across at least the opening quarter.

Implementation checklist

  • 8-week baseline measured from git log, not memory.
  • Public cadence is at or below 0.8 × measured.
  • Fixed publish days documented in CONTENT.md.
  • Backlog buffer of 2+ articles maintained.
  • Weekly “did I publish?” check is automated or ritualized.

Verify it held

  • 12 weeks in: streak count from git log matches target.
  • Backlog never dropped below 1 article.
  • Search Console “Pages discovered” trends steady, not spiky.

Common pitfalls

  • Copying other sites’ numbers. You are not them, your life is not theirs. Measure your own log.
  • Front-loading the first month. A 20-article launch week looks great, then 8 silent weeks erase the gain.
  • Skipping the backlog. Without it, one bad week breaks the streak.
  • Over-tooling the calendar. A Google Sheet or Notion table works fine. The tool is not the bottleneck.
  • Tracking inputs (words, hours) instead of outputs (articles published). Inputs are not commitments.

FAQ

  • Is two articles a week enough? Yes, if you can hold it for a year. A consistent 2/week beats an unsustainable 5/week almost every time on indie sites, and most 2026 SEO surveys put 1-2 quality posts/week in the sustainable-growth sweet spot.
  • What if I miss a week? Publish from your backlog. If the backlog is empty, publish a short article the next available day. Do not skip to “next week.”
  • Should I batch-write months in advance? Some batching helps, but do not batch beyond 4-6 weeks. Your interests and the topic landscape shift, and stale-batched content reads stale.
  • Does posting time of day matter? For SEO, effectively no. For social and email amplification, your audience’s timezone matters a little. Do not over-optimize it.
  • How do I handle holidays or travel? Pre-publish from the backlog. Schedule the deploy if your stack supports it (publishedAt set in the future plus a daily build cron).
  • Should I republish old posts to keep things “fresh” instead? Only with substantive changes. Search engines and AI answer engines weigh the volume of real change in an update; a backdated date with no new content does not earn the freshness signal.

External: Orbit Media 2025 Blogger Survey for the underlying benchmarks.

Tags: #Indie dev #Content ops #SEO #Website planning #Workflow