Next.js + Sanity CMS for marketing teams: what editors actually get

Marketing teams evaluating a Next.js + Sanity CMS stack usually ask the same question within the first ten minutes: will my editors still need to file a dev ticket every time they want to change a headline? The honest answer is no — but only if the project is set up correctly. Here is what that setup actually looks like from the editor's side of the screen.

What Sanity Studio looks like for a non-developer editor

Sanity Studio is the CMS interface your editors use. It runs in a browser — nothing to install — and it looks like a clean, document-based admin panel. When an editor opens a page document, they see a form with clearly labelled fields: a title field, a body text area, a featured image slot, a published date, a category selector. It is not a wall of raw HTML or a maze of nested menus.

For a nonprofit we worked with, the communications manager needed to update programme descriptions, swap hero images, and publish event announcements without waiting on anyone. We structured the Studio so each programme had its own document type with a short description, a long description (formatted text with bold, links, and bullet points), an image field, and a visibility toggle. The editor learned the interface in under an hour.

The formatted text editor (called Portable Text) behaves like a stripped-down word processor. Editors can bold text, add links, insert inline images, and create callout blocks — but they cannot accidentally break the layout by pasting rogue font styles from a Word document, because the field only accepts the content types you define. That constraint is a feature, not a limitation.

Live preview: see the page before you publish

Sanity Studio has a built-in preview panel. An editor can open the live preview alongside their content form, and as they type in the title field, the preview updates on the right side of the screen showing exactly how the page will look on the actual website — design, fonts, layout, and all.

For a sports organisation client, the content team was updating match reports and player profiles multiple times a week. The preview panel meant they could check how a headline read at the actual rendered size, whether the player photo cropped correctly, and whether the squad roster displayed right — all before hitting publish. Fewer surprises, fewer back-and-forth messages with the dev team.

Image hotspot: stop guessing how photos will crop

When an editor uploads a photo, they can mark a focal point by clicking on the subject of the image. If the website displays that photo in three different formats — a wide banner on desktop, a square thumbnail in a grid, and a portrait card on mobile — the system crops around the focal point for each. The editor sets this once, and the right part of the photo stays in frame everywhere.

Before hotspot, a photo of a team huddle would get its centre cropped by default, sometimes cutting out faces. With hotspot, the editor clicks the face they want to keep centred, and every crop respects that choice. This matters enormously for nonprofit fundraising pages where a donor's face is the emotional anchor of the image.

Scheduled publishing: queue content ahead of time

Editors can set a publish date and time on any document. A marketing agency client used this to schedule a product launch campaign: landing page, press release, and three blog posts — all written and reviewed a week in advance, set to go live at 09:00 on launch day, no one needed to be at their desk pressing buttons.

This is not a third-party plugin or a workaround. It is a first-class feature of the Studio that editors can see and control themselves.

The live-site update cycle: how fast do changes actually appear?

When an editor publishes a change in Studio, a signal goes to the website automatically. The site rebuilds only the affected page — not the entire site — and within a few seconds the live URL reflects the new content. There is no manual cache-clear button to remember, no waiting ten minutes for a CDN to flush.

For practical purposes, an editor publishes a correction to a blog post and can refresh the live URL thirty seconds later to confirm the change is live. That loop is fast enough that editors stop second-guessing whether the site actually updated.

How this compares to WordPress and page builders

WordPress is familiar, and that familiarity has real value. But most WordPress installs editors actually use day-to-day are held together by a combination of plugins that conflict with each other during updates, themes that break when PHP versions change, and a block editor (Gutenberg) that varies wildly depending on which theme and plugin set the developer chose. Editors regularly encounter situations where a page looks fine in the editor and broken on the live site.

Page builders like Elementor and Divi give editors pixel-level layout control, which sounds like a win. In practice it means editors can break the design just as easily as they can improve it, and the pages they build tend to load slowly because every layout tweak adds inline CSS and JavaScript that the browser has to parse. Core Web Vitals scores suffer, and slower pages rank lower in search results — which is the opposite of what a marketing team wants.

The Sanity approach trades freeform layout control for structured, validated fields. Editors control the content; the developer controls the design system. It sounds restrictive, but after a month of using it, most content teams report fewer problems and faster publishing than they had in WordPress. The site also stays fast because editors are not accidentally injecting layout bloat.

Questions to ask a developer before you commit

Before signing a contract for a Next.js + Sanity build, ask the developer these things directly:

Can you show me a demo of the Studio with a real page document, including the live preview? If they cannot demo this, the editor experience may not have been a priority in their previous projects.

How do editors create new pages or sections without a developer? There are different answers here. Some projects require a dev to add a new page type; others are set up so editors can create new landing pages from a template. Know which model you are getting.

How is scheduled publishing configured, and are there approval or review steps? For teams with compliance requirements or editorial review processes, workflow features matter. Clarify what comes out of the box versus what needs custom work.

What happens when an editor needs a content type that was not scoped in the original build? Schema changes require a developer. This is not unusual — it is just something to plan for with a small retained hours arrangement rather than treating the initial build as a permanent closed system.

Who trains the content team, and is there documentation? A well-built Sanity project should come with a short editor guide covering the document types, field conventions, and the publish workflow specific to your site. If the developer does not mention this, ask for it to be scoped in.