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, because Google treats sudden silence as a signal the site is dying. The goal of cadence is not maximum output; it is predictability — and you measure it from your actual git log, not your hopes.
Background
Google does not literally reward a “post every Tuesday” pattern, but it does reward sites that keep getting fresh, relevant content over time. More importantly, you yourself need a cadence to stay in the habit. Without one, content gets pushed to “later” indefinitely. A measurable cadence + a small backlog + a weekly publish-day check is the smallest system that actually holds.
How to tell
- You have published in waves — fast weeks followed by silence.
- You set a target cadence months ago and have not held it.
- You feel guilty about publishing rate (a sign your target is wrong, not you).
- Your last 8 weeks publishing count averages well below the public commitment you made.
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.
Before you start
- You have an editorial-control surface (git log, content folder).
- You can spend 30 min to set up the measurement script below.
- You’re willing to commit to a number publicly only after the math works.
Step by step
- Measure honestly from
git log: published dates are in frontmatter, but the git log proves when you actually shipped:
# articles added/modified in last 8 weeks, by week
git log --since="8 weeks ago" --pretty=format:'%ai' --name-only -- 'src/content/articles/' \
| grep '\.mdx$' | awk -F/ '{print $NF}' | sort -u | wc -l
# total unique articles touched
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
# total NEW articles added (A = added)Or even simpler from frontmatter:
grep -rh '^publishedAt:' src/content/articles \
| awk '{print $2}' \
| awk -F- '{print $1"-"$2}' | sort | uniq -c
# articles per year-month, last few months tell the truth-
Multiply by 0.8 — that is your sustainable 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, etc.).
-
Pick fixed publishing days. Tuesday + Friday is a common pattern. Write the schedule into
CONTENT.md:
# 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- Build a small backlog buffer. A simple
drafts/folder with articles ready to ship:
ls drafts/*.mdx | wc -l
# warn if < 2:
[ "$(ls drafts/*.mdx 2>/dev/null | wc -l)" -lt 2 ] && echo "WARN: backlog below 2"Add to your weekly checklist; the warning before the warning is the warning.
- Track only “published this week, yes/no”. Don’t track word count or hours — they don’t correlate with outcomes. 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 as a weekly cron or a Friday-morning manual ritual.
- Reassess quarterly. A 13-week summary:
grep -rh '^publishedAt:' src/content/articles \
| awk '{print $2}' \
| awk -F- '{print $1"-W"int(($2*30+$3)/7)}' \
| sort | uniq -c | tail -13If the cadence felt easy for 12 weeks, raise it by one article/month. If it felt hard, lower it. Don’t adjust mid-quarter.
- Don’t front-load. A 20-article launch week followed by 8 weeks of silence is worse than 2/week steady. Spread across at least the first 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.
After-launch verification
- 12 weeks in: streak count from
git logmatches target. - Backlog never went below 1 article.
- Search Console “new pages discovered” is steady, not spiky.
Common pitfalls
- Setting cadence based on “what other indie sites do”. You are not them, your life is not theirs.
- Front-loading the first month. A 20-article launch week looks great and then 8 silent weeks. Spread it out.
- Skipping the backlog. Without it, one bad week breaks the streak.
- Using a complicated content calendar tool. A Google Sheet or Notion table works fine; the tool is not the bottleneck.
- Tracking input metrics (words written, hours) instead of output (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.
- What if I miss a week?: Publish from your backlog. If the backlog is empty, publish a short article the next available day — don’t skip to “next week”.
- Should I batch-write months in advance?: Some batching helps, but don’t batch beyond 4-6 weeks. The market and your interests shift and stale-batched content reads stale.
- Does posting time of day matter?: For SEO, no. For social and email amplification, your audience’s timezone matters slightly. Don’t over-optimize.
- How do I handle holidays / travel?: Pre-publish from backlog. Schedule the deploy if your stack supports it (
publishedAtin the future + a daily build cron).
Related
- Content volume vs quality
- Managing a content site after 1,000 articles
- Scaling content with AI without tanking quality
- When to refresh old articles
- New site breadth or depth
Tags: #Indie dev #Content ops #SEO #Website planning #Workflow