Why Next.js + Sanity for healthcare marketing sites

Every healthcare marketing site I build runs on the same two things: Next.js for the site itself and Sanity for the content. I don't offer a menu. This post explains why, and it's written for the person who has to approve that decision without being a developer: the marketing lead, the communications director, the COO who owns the website because nobody else does.

I'm going to argue from your problems, not from the technology. The four that come up on every healthcare site project are editorial independence, migration safety, compliance posture, and performance. The stack is the answer to those four, in that order.

What do the two pieces do?

Sanity is where your content lives. It's a hosted content platform with an editing interface, called the Studio, that I configure for your team. Every page, every provider profile, every location, every press release is a structured document in Sanity, and your team edits them there.

Next.js is the framework that turns that content into the website visitors see. It's a React framework maintained by Vercel, and it's what I use to build the pages, the navigation, the forms, and everything else a visitor touches.

The two talk to each other over an API. Sanity never serves a page to the public and Next.js never stores content. That separation is the whole point, and most of what follows comes back to it.

If you're used to WordPress, the difference is that WordPress is one system that does both jobs, and every plugin, theme, and editor change touches the same codebase that serves your patients. Here they're separate, and each one is good at its job.

Can my team publish without a developer?

Yes, and this is the first reason I use Sanity.

The most common complaint I hear from healthcare marketing teams is some version of "the site works, but every change goes through the agency." A new location opens and it takes three weeks to get a page up. A physician joins and their profile sits in a queue. Leadership wants a press release on the homepage by Friday and the answer is "we'll see."

That happens because the site was built without a content model, or with one that matches how the developer thinks rather than how your team works. Sanity fixes this by making the content model explicit. Before I build anything, I define what a provider is, what a location is, what a service line is, what fields each has, and which ones are required. Then I build the Studio around those definitions.

The result is that your team adds a provider by filling in a form with the right fields, not by editing a page layout. Adding a location creates the location page, adds it to the locations index, adds it to the map, and adds it to the footer, because all of those read from the same document. Nobody calls a developer.

Sanity also handles the things editors need that generic CMS setups skip: a live preview that shows the real page as you edit, drafts that don't affect the live site, revision history so a bad edit can be rolled back, and roles so the person who updates provider bios can't accidentally change the homepage.

Editorial independence is the outcome. The site reflects what the company is this month, not what it was when the agency finished.

What does editing actually look like day to day?

Your team opens the Studio in a browser, finds the document they want, and edits it with a live preview of the real page beside it. That's the short version, and it's worth spelling out because "headless CMS" sounds like it means "no interface."

A marketing coordinator adding a new physician fills in name, credentials, specialties, locations, a photo, and a bio. They hit publish. The provider page exists, the physician appears in the directory filtered by specialty and location, and the location pages list them. If they're not ready to go live, they save a draft and send the preview link to the physician for approval. If something is wrong after publishing, they open the document's history and restore the previous version.

An editor updating a condition page sees the page as patients will see it while they type. Headings, callouts, and links are structured content, so the page looks like every other condition page without anyone adjusting layout. There's no page builder to fight and no way to accidentally produce a page that doesn't match the rest of the site.

That's the experience I'm aiming for: the Studio feels like a tool made for your team's work, because it was.

Will you lose search traffic when you migrate?

Not if the migration is done carefully, and the stack makes careful possible.

Most healthcare organizations coming to me are leaving WordPress, Webflow, or an agency-built site. Their search traffic is real and it's valuable: condition pages, provider pages, and location pages that have ranked for years. The thing they're afraid of, correctly, is that the new site will lose it.

Two properties of this stack matter here. The first is that Sanity is a structured store, not a pile of HTML. Migrating into it means mapping every old page to a content type and importing it with a script, which means the migration is reviewable. I can produce a list of every old URL, what it became, and whether its content came across intact, and you can check it before launch. With a page-builder CMS, migration is a person copying and pasting for weeks, and the errors are invisible until a patient finds one.

The second is that Next.js gives me full control over URLs, redirects, metadata, and the structured data that search engines read. Every old URL gets a permanent redirect to its new home, written in a file I can show you. Every page gets the title, description, and schema markup it had before, or better. None of that depends on a plugin.

The migration plan, including which URLs carry traffic and how each one is protected, is the main output of the assessment I run before a build. But the plan is only executable because the stack lets me execute it precisely.

How does this affect our compliance posture?

It improves it, mostly by reducing the number of things that can go wrong.

Three compliance issues show up on every healthcare marketing site: what the forms do with the data they collect, what the analytics and advertising scripts send to third parties, and whether the site meets the accessibility standard that applies to you. Here is how the stack handles each.

Forms are code I write, not a plugin with settings. A "Request an appointment" form sends its data exactly where you and your compliance team decide it goes: to a CRM or scheduling system with a business associate agreement, never to a shared inbox or a third-party form service that doesn't sign one. The form, the destination, and the notification path are written down in a way legal can review once and approve.

Scripts are gated. Analytics, ad pixels, chat widgets, and anything else from a third party load only after the visitor consents, and I control the list. On a WordPress site, a marketer installs a plugin and a new tracker appears on every page. Here, adding a script is a code change that goes through review, which is what a compliance team wants to hear.

Accessibility is built in from the component level. Because the site is made of components I write, every button, form field, and navigation element meets WCAG requirements once, and every page that uses them inherits that. The accessibility audit at the end of a build is a check, not a rescue.

There's a quieter benefit too. Sanity and Vercel, which hosts the Next.js site, are mature vendors with security documentation your IT team can actually read. When the security questionnaire arrives, and in healthcare it always arrives, the answers exist.

One boundary worth stating plainly: a marketing site should never store protected health information. It collects a form submission and hands it to a system designed to hold it. Sanity holds your content, not your patients' data. Keeping that line clear is the single most useful thing a healthcare site's architecture can do for compliance, and this stack makes the line easy to keep.

Will the site be fast?

Yes, and for a healthcare site fast matters more than usual.

Your visitors are often on phones, often on poor connections, and often anxious. Someone looking up a specialist after a diagnosis is not patient with a slow page. Google also uses page speed as a ranking signal, so the condition pages you're trying to protect in the migration are partly protected by being fast.

Next.js builds pages ahead of time wherever possible, so a provider page is served as a finished document from a server near the visitor rather than assembled on demand. Images are resized and compressed automatically for the device requesting them. Only the code a page needs is sent. The practical result is that sites I build on this stack score well on Core Web Vitals without special effort, and stay that way because the performance comes from the architecture rather than from a plugin that someone has to keep tuned.

The other side of performance is that the site stays up. Sanity serves content through a global CDN and the site itself is hosted on Vercel's edge network. Neither depends on a single server in a closet or a shared hosting account that goes down when a neighbor gets traffic.

Why not WordPress?

Because it's one system doing two jobs, and it does both in a way that fights the four problems above.

WordPress ties editing and serving together, so every plugin and theme change is a change to the live site. The content model is an afterthought, so editors end up working in page builders that produce inconsistent pages and can't be migrated cleanly. Security depends on keeping a pile of plugins updated, and the plugins are where the trackers and the form handlers live, which is exactly where compliance problems start. It can be made to perform, but it takes constant attention.

Plenty of healthcare sites run on WordPress and some of them are fine. But the ones that come to me are the ones where "fine" stopped being true, and the reasons are almost always the ones above.

Why not something newer?

Because this is a regulated industry and boring technology is a feature.

Next.js has been the dominant React framework for most of a decade and is used by organizations much larger and more risk-averse than any of my clients. Sanity has been around since 2017 and is used by healthcare, pharmaceutical, and financial companies with serious compliance teams. Both have stable APIs, long upgrade paths, and large communities, which means the site I build for you can be maintained by someone other than me.

I'm not interested in giving you a site built on whatever was exciting at a conference last spring. I'm interested in a site that's still straightforward to maintain in five years.

What does this cost, and what does it include?

A build on this stack is fixed-price and includes the content model, the migration, the design system in code, the compliance setup above, an accessibility audit, and 60 days of support after launch. The details are on the services page. The price is set by the assessment, so you know it before the build begins.

What should you take from this?

If you run a healthcare or life-sciences company and your website is hard to change, risky to migrate, uncomfortable to explain to compliance, or slow, the stack underneath it is probably why. Next.js and Sanity aren't the only answer, but they're the one I've found that addresses all four problems at once, and they're the only one I build on.