CMS Choices Clients Will Actually Use

The best CMS for marketing sites is the one your actual editors will open on a Tuesday without calling you. Vendor feature lists do not update tour dates, publish case studies, or fix a typo before a sales call. Client-friendly CMS work is modeling, field limits, preview, seats, and training — the surfaces a human touches after launch, not the logos on a comparison chart. This spoke sits under Websites That Feel Like Films. Stack choice lives next door in Framer vs Webflow vs custom. This page is the editor-UX half of that decision.

The short answer

• Interview the weekly editor first. If they will never log in, a “powerful” CMS is theater.
• Model jobs, not pages. Collections for Work, Dates, Press, Services, Team — not a blob “Pages” type with twenty optional layout switches.
• Cap fields and write help text. Required headline, required image with alt, optional second CTA. Reject badge 1–8.
• Preview before publish. Blind publish is how brand trust dies. Staging or a real preview URL is part of friendliness.
• Editor is not Designer. Seats, not trust circles. Training is a deliverable: two live edits, one cheat sheet.

Who actually opens the CMS after launch?

Not the founder who sat in the kickoff. Not the creative director who approved the film stills. The person who opens the CMS is usually an office manager, a marketing coordinator, a tour manager, or a junior on a Tuesday between other jobs. If you design the admin for the person who bought the site, you will ship a cockpit nobody can fly.

Ask who will perform each job in the first ninety days. Write names, not roles.

Job after launch	Typical human	If they will not do it
Fix a typo on the homepage	Coordinator / founder	You invoice a content change
Add a case study	Marketing lead	Studio publishes, or it never ships
Update tour dates	Manager / assistant	Homepage lies; bookers bounce
Swap a press quote	Same as dates	Stale social proof
Replace a team photo	Office / HR	Ghost employees stay live
Publish a blog post	Writer who is not a designer	Drafts pile up, or Designer gets abused

If the “editor” is you, say so. Studio-operated content is a valid product. Calling a git repo “their CMS” when they will never open a pull request is a lie they will resent at renewal.

I have shipped hundreds of production sites. The pattern that holds: the weekly human decides the tool. The annual human only decides the budget.

What should an editor finish in ten minutes?

Friendliness is a timed task, not a compliment. After launch, a trained editor should complete one real job without opening Designer, Slack, or a Loom from six months ago.

• Log in from the bookmark you left them (not a hunt through old emails)
• Land on the collection or page they need, not a wall of schema types
• See field labels in their language (“Show date,” not eventStartISO)
• Read help text that states size, length, and what happens if they skip it
• Upload an image that the layout can survive
• Preview the page as it will look live
• Publish — or submit for review — without touching structure

If any step requires a developer, the model is wrong or the seat is wrong. Time the first office-hours session. If the second practice edit still takes twenty minutes, cut fields before you write a longer PDF.

A ten-minute job also needs a recovery path. “I published the wrong date” should be undoable by the same editor, not a 2 a.m. emergency ticket.

First Tuesday after launch — sit with them and run this once, on their machine:

1. Open the bookmark. Confirm the seat label. If Designer is visible, stop.
2. Create one real item in the highest-cadence collection (a date, a quote, a service).
3. Leave one optional field blank on purpose. Confirm the layout holds.
4. Preview at a phone width. Fix the image if the crop is wrong.
5. Publish (or submit). Load the live URL in a clean tab.
6. Edit the same item. Publish again. Confirm they know how to unpublish.

If step 1 fails, the handoff failed. If step 3 fails, the component failed. If step 6 fails, you trained a one-shot, not an editor.

How do you interview the editor before you pick a vendor?

Do this before you open a Webflow, Framer, or Sanity account. Thirty minutes with the person who will click Publish beats two hours of vendor theater.

1. Who edits weekly, and what is their technical comfort on a 1–5 they choose themselves?
2. What content types change after launch — work, dates, blog, locations, team, menus, PDFs?
3. How often does each type change — daily, monthly, twice a year?
4. Do they need governed collections, or mostly static pages with rare edits?
5. Who is allowed to publish, and who only drafts?
6. Must legal or a manager approve before something goes live?
7. What device will they edit on — laptop, iPad, phone in a van?
8. What is the lifespan and performance bar of the site?

Score the answers into a fit, not a vibe.

Situation	CMS direction
Marketing team needs collections + visual build	Webflow CMS
Designer-led brand or campaign site, lighter content ops	Framer content model — know the limits
Engineering-owned, performance-first, structured content	Headless (Sanity, Contentful) + Astro/Next
Rare edits, studio-operated	Git-based MD/MDX or a thin admin
Trades / SMB with phone-first updates	Simple CMS or structured Webflow with ruthless fields
Legal must approve every publish	Stack with real draft/review states, or you operate it

There is no universal winner. There is a wrong winner for your editor. Stack tradeoffs that are not editor UX belong in Framer vs Webflow vs custom.

Why model jobs instead of pages?

Collections should map to jobs: Projects, Services, Shows, Locations, FAQs, Team, Downloads. Avoid a blob “Pages” collection where every layout is a snowflake of optional fields. Optional fields are how homepages become junk drawers.

A job has a start, a finish, and a definition of done. “Update the Atlanta show” is a job. “Edit the homepage modules” is a playground.

Job	Collection	Required fields	Forbidden extras
Publish a project	Work	Title, year, one image + alt, one-line constraint, one outcome	Layout mode, badge 1–8, optional video and gallery and embed
Add a date	Tour	Date/time, city, venue, ticket URL	Freeform HTML for the poster
Swap a quote	Press	Outlet, quote, link, optional logo	Rich text for a single sentence
Update a service	Services	Name, short promise, proof, CTA	Per-service color themes
Replace a headshot	Team	Name, role, photo + alt	“Fun fact” that becomes a novel
Host a rider or menu	Downloads	Title, file, updated date	Files buried in random rich text

Empty collections shame the editor. Full, maintained collections make the site feel alive. Websites That Feel Like Films depends on proof that stays current. The CMS is how proof stays current.

Resist a collection for every whim. If nobody will fill it in the first quarter, it is not a collection. It is a future 404 with a pretty empty state.

How do you cap fields and write help text editors will read?

Every field is a future mistake. Prefer required headline, required short support, required image with alt, optional secondary CTA. Reject “badge 1–8,” “optional layout mode,” and freeform HTML unless you have a trained power user and a review path.

Webflow’s collection fields let you mark a field required and attach help text when you add it. Framer’s collection field editor does the same: rename, helper text, required toggle. If you leave those blank, you taught the editor nothing.

Help text that works is specific:

Field	Help text that earns its pixels
Hero image	2400×1600, under 400KB if you can. No text in the image.
Alt	Describe the photo for someone who cannot see it. Not "image" or the filename.
Support line	One sentence. Max ~90 characters. This sits under the headline, not in the hero as a paragraph.
Show date	Local venue time. Homepage pulls the next three dated items automatically.
Ticket URL	Full https link. Test it after you paste.
Outcome	One measurable or observable result. Not a slogan.

Help text that fails: “Enter the title.” They already knew that.

Sanity Studio validation can go further: field-level rules and document-level rules that block publish when a featured item is missing proof. That is friendliness with teeth. Warnings for “this headline is long” beat a live site that wraps into three lines on a phone.

Field-count rule I use on marketing collections:

1. Count the fields the template actually binds.
2. Delete anything the template ignores.
3. Require anything whose absence leaves a hole.
4. Make optional only what the component already collapses.

If a field exists “for later,” it will be filled with junk now.

What does a usable preview and publish path look like?

If editors cannot see the page before publish, they will either fear publishing or publish blind. Staging, Webflow preview, or draft modes are not luxuries. They are how you keep brand trust.

Headless stacks do not get a pass because the schema is pretty. Contentful’s content preview is a configured URL per content type — slug tokens, environment, locale — so the editor opens the real page, not a JSON blob. If you skip that setup, you sold them a form, not a CMS.

Sanity list previews are a different surface: title, subtitle, media in the desk so editors can find “March 22 Atlanta” instead of drafts.tour-14. A desk that shows twenty identical “Untitled” rows is hostile.

Preview checklist before you call the build done:

• Draft state exists and is the default for new items
• Preview URL matches the live template, including mobile width
• Empty optional fields do not explode the layout in preview
• Publish is a named action with a confirm, not a hidden toggle
• Unpublish / revert is possible without a developer
• Two people editing the same item have a rule (Webflow’s content-editor docs are blunt: last edit wins — coordinate, or you will overwrite)

Legal-approval shops need workflow states, not a Slack “look ok?” thread. If the CMS cannot hold draft → review → live without duct tape, you chose wrong for this client — even if the visual editor looked nicer in the demo.

Who gets which seat after launch?

Not everyone needs Designer or Admin. Editors edit. Publishers publish. Someone owns the structure. Client-friendly does not mean everyone can invent new components at 11pm.

Webflow’s content editor role is built for this: copy, assets, CMS items, comments, and publish if you toggle it. Content editors cannot change design, component structure, page slugs, custom code, or CMS settings, and they cannot create new collections. That restriction is the product.

Webflow is also mid-migration. The legacy Editor is scheduled to go away on August 4, 2026, with existing users moved to a content-editor seat in the core product. If your 2024 handoff PDF still says “open the Editor from the live site,” rewrite the cheat sheet before that date, not after a confused Tuesday.

WordPress’s default roles already separate Editor from Administrator. An Editor can manage posts and pages. An Administrator can install plugins, switch themes, and delete the site. Handing a marketing coordinator Administrator because “they might need it” is how brand sites grow a plugin graveyard.

Contentful custom roles (Premium plans) can allow or deny by content type and environment — read-only in master, edit in a sandbox. Use that when the weekly editor should never see schema.

Seat rules I write into handoff:

Human	Seat	Must not have
Weekly editor	Content editor / Editor / custom “can edit”	Designer, Admin, plugin install
Publisher (if separate)	Same plus publish	Schema, locales they do not own
Studio / engineer	Designer or Admin	Shared password with the editor
Intern “just looking”	Comment or view	Publish
Former employee	Nothing	A lingering seat from last year

Review permissions quarterly. People leave agencies and client companies; seats linger. Access hygiene is CMS craft, not IT trivia. Pair this with who owns the site when you leave — a CMS login in the studio’s workspace is not client ownership.

When is Webflow the client-friendly default?

Webflow earns its place when non-developers must maintain structured marketing content and the design can live inside its component and collection model. I use it when the alternative is “email the developer to change a sentence.”

What makes Webflow client-friendly in practice:

• Collections with clear names and help text
• Components that lock layout so editors change content, not structure
• Element-level editing permissions so a decorative lockup cannot be “improved”
• Style-guide pages that show allowed patterns
• Training recorded once, with a one-page cheat sheet
• Image size guidance written into field help
• A content-editor seat, not a Designer invite “to keep it simple”

What makes Webflow fail for clients:

• Designer access for people who only needed Editor
• Unbounded rich text that becomes a poster of fonts, embeds, and H1s inside a card
• Interactions tied to content that break when a field is empty
• No training, only a Loom dump the week of launch
• A cheat sheet that still describes the legacy Editor after the 2026 cutover
• Empty collections you added to look complete in the sales deck

Webflow is not automatically friendly. A sloppy Webflow build is a beautiful trap. The edit role in Designer can edit dynamic content on canvas and manage alt text — useful, still not a reason to hand over Design.

If the marketing team will live in collections for years, Webflow is often the lightest tool that covers the jobs. If a designer will own motion and the content ops are light, read the Framer row in the stack spoke and stay honest about CMS depth.

When do Framer, headless, WordPress, or git fit the editor?

Framer. Designer-led brand and campaign sites with light content ops. Collections, items, and fields are real — helper text and required flags exist — but you are not buying Contentful-grade roles. Choose Framer when a designer will own the system and the weekly jobs are few: a notes collection, a team list, a shows list. Do not choose it because the homepage motion looked expensive.

Headless (Sanity, Contentful, and kin). Wins when engineering owns the front end, you need multi-channel content, or you want schemas and preview pipelines you can put in git. Client friendliness then depends on the admin you configure. Sanity’s Structure Builder exists so the sidebar can be “Tour dates” and “This week’s drafts,” not a dump of every schema type. Sanity Studio will not do that work for you. A default desk is an engineering admin. A structured desk is an editor product.

Do not sell headless to a client who wanted “something like Squarespace but premium” unless you are also selling ongoing ops. The schema is half the product. The editorial experience is the other half.

WordPress. Familiar login. That familiarity is the trap. Gutenberg plus a page-builder plugin plus Administrator for three people is how a cinema-grade marketing site becomes a collage. If you use WordPress, lock templates, restrict the Editor role, and treat plugins as a change-control problem. Familiar is not the same as safe.

Git-based Markdown. Excellent for studios and technical founders. A bad client-friendly CMS for most marketing managers. If the client will not open a PR, do not call the repo their CMS. Either you operate content for them, or you pick a real admin.

Decision list when the editor interview is done:

1. Weekly non-technical editor + structured marketing content → Webflow, strict model.
2. Designer-owned, few collections → Framer, honest limits.
3. Engineering-owned, multi-year, multi-channel → headless + preview you actually built.
4. Writers already live in WordPress and you can lock templates → WordPress, Editor only.
5. Studio publishes, client never logs in → git or a thin admin you operate.

How do image and rich-text fields keep the film intact?

Cinema-grade sites die when CMS freedom invents new folds. Images and rich text are the two fields that do it fastest.

WCAG 2.2 Success Criterion 1.1.1 requires a text alternative for non-text content that is presented to the user. An optional alt field that stays empty is not a CMS feature. It is an accessibility defect you scheduled. Require alt on every content image. Write help text that says what to describe. Decorative marks in the design system should not be editor-uploadable.

Image rules I put in the model and the cheat sheet:

Rule	Why the editor cares
One required image per hero / card	Absence leaves a hole or a broken ratio
Pixel size in help text	Stops 8MB phone dumps
File-weight target in help text	Stops Lighthouse from becoming your problem next quarter
No type in the image	Type in pixels cannot be edited or read
Crop / focal point if the stack has it	Faces stay in frame on mobile
Multi-image only when the gallery is real	Five optional slots become five mismatched stills

Rich text is for long-form that already has a typography system: case-study body, blog, bio. Webflow rich text can take headings, images, video, embeds, and code. That is a magazine tool. It is a weapon inside a three-line card.

Rich-text rules:

• One rich-text field per collection, maximum, unless the template has two named bodies
• Character min/max when the stack allows it
• A style-guide page that shows H2 / H3 / list / quote — and nothing else
• No rich text for a headline, a date, a URL, or a quote
• Embeds off unless a named human owns them

Empty optional fields should not leave holes. Components must tolerate absence, or the field must be required. Field limits are the design system. The Figma file is not.

What training actually sticks?

Training is a deliverable, not a courtesy. A Loom of the Designer canvas is not training. It is a recording of you enjoying your own build.

My minimum:

1. 45–60 minutes live on the actual collections they will use — not a tour of every panel
2. A one-page cheat sheet: login URL, which seat they have, edit X, preview, publish, what not to touch
3. Two practice edits during the session with real content, not lorem
4. Office hours in the first two weeks after launch
5. A rewrite of the cheat sheet if the product UI moved (Webflow’s 2026 Editor cutover is the current example)

If they only need to update tour dates and press quotes, do not train the entire Designer surface. Teach the two collections. Confidence comes from narrow mastery.

Cheat sheet outline I leave in their drive:

• Bookmark this login
• You are a content editor. If you can see Designer, stop and tell us
• Collection A: when to add an item, required fields, image sizes
• Collection B: same
• How to preview on phone width
• How to publish, and who else must approve
• What to do if you published the wrong thing
• Who to ping (studio vs their publisher)

Record the session. Do not make the recording the only artifact. People do not rewatch a 54-minute video to change a date.

What happens when the login goes unused — or you promise “CMS later”?

Failure mode: you ship a cinema-grade site, hand over seats, and thirty days later nothing has been published. That is a signal, not a personal failure of the editor.

Diagnose in this order:

Symptom	Likely cause	Fix
Never logged in	Bookmark missing, SSO mess, wrong email	Sit with them once. Watch the first login.
Logged in, no publish	Fear of breaking the film	Preview path + two supervised publishes
Drafts pile up	No time, or publish is the wrong person	Split editor vs publisher, or you operate it
They asked for Designer	Model cannot do the job, or they want to “tweak”	Fix the job in fields, or refuse Designer
They email you every change	CMS was theater	Invoice content ops, or delete the unused collections
Site drifted for a year	No monthly pass	Retainer for QA, or a paid cleanup

Shipping a static marketing site with a promise of “CMS in phase two” often means phase two never comes, or comes as a rewrite. If post-launch edits are certain, model them before launch — even if only two collections are live. Retrofitting structure into a snowflake page build is where budgets go to die.

If edits are truly rare, skip the CMS and invoice for content changes. Honesty beats a dusty CMS login nobody uses.

A silent CMS at the first check-in is cheaper to fix than a year of intern experiments in Designer. Ask what blocked them. Then change the system: fewer fields, a better seat, a shorter job, or you take publishing back.

Who owns the CMS when the studio leaves?

A friendly editor UX is worthless if the workspace, seats, and billing sit in the studio’s account. Ownership is a checklist: workspace, roles, 2FA, export, and who pays for the next seat. The full exit list is who owns your website when you leave. The CMS-specific slice:

• Client owns the Webflow / Framer / Sanity / WordPress workspace (or a documented transfer date)
• Weekly editor has their own seat, not a shared studio+client@ login
• Studio Admin is documented and removable
• Export path exists (CSV, dataset, XML) and has been run once
• Content model is written down outside the tool — field names, required flags, image rules
• Cheat sheet still matches the live UI

If you cannot leave cleanly, they do not own the publishing path. They rent a Tuesday they cannot take with them.

Name an owner on the client side. One human. Not “marketing.” When that human leaves, the successor gets a 30-minute handoff, not archaeology.

What does a monthly content ops pass look like?

Studios that disappear after launch leave clients with a tool and no operating rhythm. A light retainer for content QA is often cheaper than an emergency redesign when the site has drifted for a year.

Once a month, the editor and (if retained) the studio should run this pass:

• What published, what stalled in draft
• Next three dates / proofs still true
• Broken links on new items
• Oversized new images
• Alt text present on new media
• Expired campaigns and old CTAs
• Form delivery test (one real submit)
• New page requests: recipe (existing collection) or one-off (studio)
• Seats: anyone gone, anyone over-permissioned

This meeting keeps the CMS honest. Without it, even friendly tools decay into abandoned drafts and outdated team photos.

Also run a permissions pass on a quarterly cadence. Same meeting can absorb it. Do not wait for a former intern to publish a draft homepage.

Scenarios that tell you the monthly pass is working:

Scenario	CMS job	Pass that proves it
Trades company, services twice a year	Tiny services + testimonials	Phone number and proof still true
Music manager, dates weekly	Tour collection, homepage pulls next three	Dates match the flyer
Multi-location brand	Unique proof per city, or do not build the pages	No doorway spam
Studio, studies quarterly, blog twice a month	Separate collections	Studies still have constraint + result
Legal on every publish	Draft → review → live	Nothing live without the state change

If the closest scenario is “we will figure it out,” you do not have a CMS requirement yet. You have a hope.

How I choose on Spurlock Studios projects

I interview the editor, list the update types, and pick the lightest tool that covers those types without inviting layout invention. Webflow shows up often for marketing teams. Custom plus headless shows up for long-lived brand systems with engineering. Framer shows up when design velocity dominates and content ops are light. The craft standard stays the same: Websites That Feel Like Films.

Worked example — a studio marketing site. Collections I will actually train:

Collection	Fields I keep	Fields I refuse
Work	Title, year, industry, constraint, featured image + alt, short case body, related services	Layout picker, optional motion, six badges
Services	Name, summary, starting-point CTA	Per-service palette
Notes	Title, date, lane, body	Author bio snowflake
FAQs	Question, answer, category	Rich text with embeds
Downloads	Title, file, updated date	Files inside Notes body

That is enough for most marketing sites. International characters and artist titles get a font and CMS check before launch, not after a broken glyph on a poster name.

I do not pick a CMS from a Twitter war. I pick it from the Tuesday human, the jobs table, and whether preview and seats exist in the stack we can staff. If you need a site where marketing can ship updates without wrecking the composition, that is a sprint constraint — not a plugin you add later.

FAQ

What is the best CMS for marketing sites in 2026?

The one your weekly editors will use: often Webflow for marketing teams, headless for engineering-owned stacks, and lighter models when content barely changes. There is no single best vendor. Interview the editor and the jobs before you interview the sales deck.

What makes a client-friendly CMS?

Clear collections, few fields, real preview, correct permissions, and training on the tasks they actually perform — not a tour of every feature. Help text and required flags are part of the product. A pretty Designer canvas is not.

Is Webflow good for clients?

Yes when you lock structure, write help text, limit Designer access, and train Editors on specific collections. No when you hand over the keys to an unbounded build. Plan for the 2026 move off the legacy Editor so the cheat sheet still matches the seat they have.

Should every brand site have a CMS?

No. If content changes twice a year and you operate the site, git or manual updates can be cleaner. Add a CMS when cadence or staffing demands it. A login nobody opens is not a feature.

How do we stop the CMS from breaking the design?

Required fields, component-locked layouts, image guidance, and rejecting freeform layout modes. Design the absence states. Keep rich text out of cards and headlines. If an intern can invent a new fold, the model failed.

How long should CMS training take?

Long enough to complete two real edits confidently — usually under an hour for a focused model, plus a cheat sheet and early office hours. Train the collections they will touch. Do not train Designer for people who should never see it.

CTA

Need a brand site whose editors can publish without wrecking the film? Start on Websites or book a sprint at contact.