Static Site Generators vs Managed CMS for Guides

Teams publishing travel and product guides usually choose between a static site generator (SSG) workflow and a managed CMS. Both can ship beautiful pages. They differ in who owns the source of truth, how drafts stay private, and how predictable deploys feel under editorial load.

What each model optimizes for

An SSG (for example Docusaurus, Eleventy, or Next in static export mode) treats Markdown, MDX, and git as the system of record. Builds produce immutable HTML and assets you host on object storage or a Pages/Netlify-style CDN. Editors either write in git or push through a constrained content pipeline that still ends in files.

A managed CMS stores content in a hosted database with visual editors, roles, and often a live preview URL per draft. The delivery site may still be static or server-rendered, but the editorial source of truth is the CMS, not your repository.

Comparison table

Dimension	SSG + file workflow	Managed CMS
Source of truth	Repo / private work dirs	Hosted content API
Draft isolation	Easy to keep drafts off public builds	Relies on CMS permissions and preview modes
Review artifacts	Proposal digests, QA JSON, approval receipts	Comments, workflow states inside the product
Performance default	Static files at the edge	Depends on rendering mode and cache rules
Localization	Explicit locale trees or i18n plugins	Often built-in locales with varying IA control
Cost shape	Engineering time + cheap hosting	Seat/API pricing + less custom plumbing
Escape hatch	Full control of HTML/CSS	Bounded by vendor features and export quality

When an SSG fits guide sites

Choose an SSG-centered pipeline when:

• You need proof that unpublished drafts cannot appear in a normal production build
• Design acceptance requires pixel-level layout ownership (custom homepage, sticky TOC, card grids)
• Multiple skill-driven checks (QA, cover encoding, promote gates) must run as scripts against files
• Hosting should stay on Cloudflare Pages or similar with predictable static output

Guidebook’s acceptance path—private work directory, register/review/promote digests, Owner approval before public Markdown appears—is naturally expressed as files. A CMS can approximate this, but you must trust vendor preview boundaries.

When a managed CMS fits

Choose a managed CMS when:

• Non-technical editors need daily publishing without opening a PR
• You want built-in scheduling, roles, and media libraries more than custom IA
• Engineering capacity is better spent on product features than on editorial tooling
• Export or mirrored static builds are good enough for performance

CMS platforms shine for high-frequency newsrooms. They are weaker when you must demonstrate deterministic promote gates and offline QA for an acceptance suite.

Hybrid patterns

Many teams run a hybrid: CMS for drafting, scheduled export into an SSG repo, then CI build and Pages deploy. Treat the export as a promote event—hash the payload, run QA, and require Owner approval before merging into the branch that deploys production. Otherwise the “static” site quietly becomes a mirror of whatever left the CMS five minutes ago.

Decision checklist

Ask:

1. Who must approve a guide before it is public, and can that approval bind a content hash?
2. Do designers own layout in code, or in a page builder?
3. How many locales ship per guide, and who owns drift?
4. Is edge-static latency a hard requirement?
5. Can you afford seat pricing if editorial headcount grows?

If answers emphasize hash-bound approval, custom layout, and cheap static hosting, an SSG workflow with a disciplined content skill pipeline is the better fit. If answers emphasize editor autonomy and vendor workflows, pick a managed CMS—and document how previews and production stay separated.

Neither model replaces editorial judgment. Both can fail when drafts leak, covers drift, or calendars ignore locale capacity. Pick the model that makes the failure modes you care about easiest to test.