CMS for marketing teams: what to set up before editors touch it

When a CMS for marketing teams goes live without proper setup, the same five problems appear within weeks: editors publish to the wrong environment, there is no review step before a page goes live, images go in without alt text, and analytics never gets wired to content changes. This post is a prioritised checklist for whoever is doing the CMS setup — whether that is the developer handing it to a marketing director or a technical founder configuring it themselves before bringing a team on.

This is not about which CMS to pick. It is about the order of operations once you have chosen one.

Start with roles, not content

Every CMS setup I have seen go sideways started by building schemas first and thinking about access last. Roles should come first because they shape everything downstream.

Before you model a single piece of content, ask:

• Who can publish directly to production?
• Who can draft and submit for review but not publish?
• Who needs read-only access for reporting or legal review?
• Do you need locale-scoped roles — someone who can edit English pages but not German?

In Sanity, this maps to the built-in Viewer, Editor, and Administrator roles, plus custom roles if you are on a paid plan. Set these up in the Sanity dashboard under Settings → Members before any editor account is created. A marketing analyst who joins the Slack workspace and gets a "try the CMS" invite should land in Viewer by default, not Editor.

If your CMS does not support document-level or field-level permissions out of the box, flag that to the marketing lead now — not after someone accidentally unpublishes a product page.

Design the content model around how marketing actually works

Developers often model content the way it maps to the database. Marketing teams think in campaigns, launches, and channels. Those two worldviews produce very different schemas.

A few practical rules:

Keep document types shallow. A landing page that embeds blog posts, case studies, and product specs as nested objects becomes a maintenance nightmare. Separate document types with references give editors flexibility without requiring a developer every time the homepage changes.

Use descriptive field labels, not developer names. A field called heroCtaLabel in the schema should surface in the Studio as "Button text (hero section)". The dropdown option secondary should read "Outlined button" in the UI. Editors should not need a glossary.

Add validation early. Required alt text on images, maximum character counts on meta descriptions, slug uniqueness — add these constraints in the schema before editors start creating content, not after a hundred pages are live without them. Retrofitting validation is painful and the errors surface at the worst possible time.

Add a content status field if your CMS does not have one natively. A simple select field — Draft, In Review, Approved, Archived — gives marketing leads a way to filter the document list without relying on draft/published state alone.

Wire up preview before you train editors

Previewing a draft before publishing is non-negotiable for a marketing team. If editors cannot see how a page looks on the actual site before it goes live, they will either publish to check, or they will stop using the CMS and paste content into a Google Doc for approval.

In a Next.js + Sanity setup, this means configuring draft mode with a preview secret and setting the presentation URL in the Sanity Studio config. That URL should point to a staging deployment — not localhost, not production. The staging environment needs to pull from the Sanity draft dataset, not the published content.

Get this working end-to-end before any editor training session. Walk through the full flow yourself: create a draft, open the preview, change something, confirm the preview updates. If that loop takes more than three clicks, simplify it. Editors will not read documentation about how to preview.

Define the publishing workflow explicitly

A CMS does not enforce a workflow unless you configure one. Most platforms support some combination of draft state, review state, and scheduled publishing. The gap between what the CMS can do and what your team actually does is where content goes live without approval.

Decide this in writing before launch:

1. Who is allowed to publish directly?
2. Is there a required review step for certain document types (e.g., press releases, pricing pages)?
3. How far in advance can content be scheduled?
4. What happens when a published page needs emergency rollback?

In Sanity, scheduled publishing requires the @sanity/scheduled-publishing plugin and is available on paid plans. If you are on the free tier, the workaround is a custom document action that moves a status field to "Scheduled" and triggers a webhook at a configured time — more setup, but it works.

For the review step, the lightest-weight approach that does not require custom development is a Slack notification triggered by a webhook when a document moves from Draft to In Review status. Someone approves in Slack, the editor publishes. That is not a proper approval gate, but it covers 90% of marketing teams without custom code.

Connect content changes to analytics before go-live

Marketing teams measure everything — traffic, conversions, bounce rate by page. But most CMS setups have no link between "we changed the hero copy on the pricing page" and "conversion rate dropped 12% that week". The connection is manual and usually does not happen.

The minimum viable setup:

• Tag deployments or revalidation events with the document ID and slug that changed. Vercel supports deploy notes and you can push them to a changelog document in Sanity itself.
• If you are using Google Analytics 4, configure content groupings by page type (blog, landing page, case study) that match your CMS document types.
• Create a simple internal changelog: a Sanity document type with fields for date, document changed, description of change, and who made it. Editors fill this in before publishing. It takes 60 seconds and saves hours of forensic investigation later.

This is not about building a full content analytics platform. It is about giving the marketing team a paper trail so they can correlate content decisions with performance data without filing a request to engineering.

Handoff: what marketing actually needs on day one

The handoff to the marketing team is not done when the CMS is technically configured. It is done when the following are true:

• Every editor has a role assigned and knows what they can and cannot publish.
• Preview works from a staging URL without developer involvement.
• The publishing workflow is written down and linked from the CMS dashboard or a pinned Slack message.
• At least one real piece of content — not placeholder lorem ipsum — has been created and published by a non-developer.
• Someone on the marketing team knows how to add a new team member to the CMS without filing a ticket.

That last point matters more than people expect. Staff turnover is constant in marketing. If adding a new editor requires a developer, the CMS becomes a bottleneck within three months.