Choosing an SSG for a Marketing Site with Non-Technical Editors

Developer-run blogs and documentation sites are the easy case for static site generators: the people writing content are comfortable with Markdown, pull requests and preview URLs. Marketing sites are different. The people changing them every day are campaign managers, designers and copywriters who expect to see the page as they edit it, publish without asking anyone, and build new landing pages from existing pieces — and they will judge the whole stack by how the editor feels, not by Lighthouse scores. A generator choice that ignores them produces a fast site nobody wants to edit, and eventually a request to go back to WordPress.

This guide chooses a generator and editing setup for a 250-page B2B marketing site with a team of six non-technical editors and two developers. It weighs editing experience, preview, publish speed, component flexibility, guardrails and performance, and reports what the team chose and how it worked after six months. It is part of SSG Framework Selection Matrix.

Prerequisites

• A clear list of who edits what: campaign landing pages, blog, customer stories, legal pages, navigation.
• The current publishing workflow and its pain points, from the editors themselves.
• A shortlist of generators and content sources to evaluate hands-on with real editors.

What Editors Actually Need

Interviews with the six editors produced a short list, in their priority order:

1. See it before publishing. A preview that looks exactly like the live page, reachable from the editor with one click.
2. Build pages from blocks. Hero, feature grid, testimonial, logo strip, pricing table, form — arranged per page without a developer.
3. Publish in minutes. Campaign timing matters; "live within five minutes" was the tolerance.
4. Not break anything. No way to publish a page that looks broken on mobile or loads a 6 MB image.
5. Schedule. Publish at a set time for launches.

None of this names a generator. Every item is about the content source and the workflow around the build. That shaped the evaluation: pick the editing model first, then the generator that serves it best.

Choosing the Editing Model

Three models were tried with two editors each for a week, on a copy of the site:

• Git-backed visual editor (TinaCMS on the repository's Markdown and JSON). Content stays in Git; editors see an inline visual editor. Editors liked the inline editing but were confused by branch and save states, and media management was weak.
• Headless CMS with visual preview (Storyblok, with its visual editor pointing at a preview build). Editors arranged blocks in a visual editor that updated the preview live. This was the clear favourite.
• Headless CMS without visual preview (a form-based CMS with a "preview" button opening a draft build). Workable but slower; editors missed seeing the layout while arranging blocks.

The team chose a headless CMS with visual preview. The trade-offs between these models are covered more broadly in Wiring a Headless CMS to a Static Build and Previewing Headless CMS Drafts.

Choosing the Generator

With the editing model fixed, the generator needed to: render CMS blocks as components, support a live preview mode, build 250 pages plus images quickly, and produce fast pages. Astro, Next.js static export and Eleventy were compared on the same content:

Astro won narrowly: it could run the same components in a server-rendered preview deployment (with output: 'server' on a separate preview environment) for the visual editor and as static pages in production, builds were fast enough, and landing pages shipped almost no JavaScript. Next.js was the developers' first instinct, but live preview with static export meant running a second, server-rendered Next.js app anyway, and page weight was higher. Eleventy built fastest but made the live preview harder and was least familiar.

Publish Speed

Editors publish in the CMS; a webhook triggers a production build. A full build of 74 seconds plus deploy was within the five-minute tolerance, but two changes made it comfortably fast. Processed images were cached between builds, as in Caching Processed Images Between Builds, which took a typical publish build to 31 seconds. And webhooks were debounced: several publishes within 60 seconds trigger one build instead of queueing several, using a concurrency group as in Concurrency Groups to Cancel Stale Builds. Median publish-to-live time settled at 1 minute 40 seconds.

Scheduled publishing used the CMS scheduler plus an hourly rebuild, which meant launches could be up to an hour late; for time-critical launches, editors used a "publish at" field that a scheduled workflow checks every five minutes.

Guardrails Without Gatekeeping

The editors' fourth need — not breaking anything — was solved in the content model and the build rather than by review:

• Structured blocks only. No raw HTML field. Rich text allows headings, lists, links and bold, nothing else.
• Images processed at build time. Editors upload whatever they have; the build generates AVIF and WebP at the right sizes. A 7 MB PNG upload becomes a 90 KB AVIF.
• Approved embeds only. Video, forms and calendars are blocks that load through facades, as in Facades for Chat Widgets and Maps; arbitrary embed codes are not possible.
• Budgets on previews. Lighthouse CI runs on the preview of every changed landing page and comments if LCP or CLS regress; it warns rather than blocks, and a developer follows up.

Six Months Later

The editors' verdict mattered most. In a survey after six months, five of six rated the new setup better than the old WordPress page builder, mainly for the live preview and for not having to worry about image sizes; the sixth missed being able to paste arbitrary embed codes. Requests to developers for page changes fell from 22 a month to 5, mostly new block types. On the reader side, landing pages passed Core Web Vitals in the field for the first time.

Measured Impact

Pitfalls & Rollback

• Choosing the generator before the editing model. Editors live in the CMS; start there.
• Preview that differs from production. Use the same components for both, or editors stop trusting it.
• Raw HTML fields. They bypass every guardrail; offer blocks instead.
• Queueing a build per publish. Debounce, or busy days back up the queue.
• Rollback: during migration, keep the old site live on its domain and move pages over in batches with redirects; the CMS content can be exported if the setup is abandoned.

Conclusion

For a marketing site edited by non-developers, pick the editing model first — here a headless CMS with a visual preview — and then the generator that serves it best: one that can render the same components for live preview and static production, build fast enough for minutes-to-live publishing, and keep pages light. Put guardrails in the content model and the build rather than in review. On this site that gave editors a better tool than the page builder they had, and readers pages twice as fast.

FAQ

Can a static site work for a marketing team that does not use Git?

Yes, if editors work in a headless CMS or a Git-backed visual editor rather than in the repository. The site rebuilds on publish, and a preview shows changes before they go live. The generator choice then matters mostly for build speed, preview support and component flexibility.

Which matters more, the generator or the CMS?

For non-technical editors, the CMS and preview experience matter more, because that is what they use every day. The generator decides how fast publishes appear, how flexible page building blocks are and how the pages perform, which matter to the developers and to readers.

How fast does publishing need to be?

Marketing teams typically expect changes live within a few minutes. Builds under two minutes on publish were acceptable to the team measured here; builds over ten minutes led to editors asking for a traditional CMS back.

How do I stop editors from breaking page performance?

Give them structured blocks rather than free-form HTML, process images automatically at build time, limit third-party embeds to approved components, and run performance budgets on preview builds of content changes.

Related

• Parent: SSG Framework Selection Matrix — the full selection framework.
• Best SSG for Technical Writers Without Coding Experience — the documentation-team equivalent.
• Next.js Static Export vs Astro for Marketing Sites — the two finalists compared.
• Migrating WordPress to a Static Site Generator — the migration itself.
• Netlify Build Hooks for Content Updates — publish webhooks in practice.