How do you model content for a multi-audience healthcare site?

# How do you model content for a multi-audience healthcare site?

Ten document types, eight section types, audience as a field on pages rather than a folder or a second site, and providers, locations, and services as structured records that are entered once and rendered everywhere they belong. That is the whole model for most clinic, practice, health-system, and life-sciences marketing sites. Anything a specific site needs beyond it is a one-type addition that takes twenty minutes, and the discipline is in what you leave out, not in what you add.

The model has one job: let the marketing team build and change pages without a developer while the site stays coherent as they do it. Every decision below is in service of that. If a modeling choice makes editors more capable but the site less consistent, or the other way round, it's the wrong choice.

Why is audience a field and not a folder?

Because the audiences share the same providers, locations, and services, and a folder (or a separate site) forces you to enter those twice and keep them in sync by hand.

A healthcare site serves patients, referring providers, partners, and, for life sciences, investors. Their pages differ; the facts behind the pages don't. A cardiologist has one bio, one set of locations, one accepting-patients status, and both the patient page and the referral page should read them from the same record. So in the starter, audience is a field on the page document: patients or providers, with a radio button in the Studio and patients preselected. That one value drives the navigation the page shows, the URL prefix (provider pages live under /for-providers), and how the Studio groups pages for editors. One dataset, one codebase, two front doors.

Two or three audiences is the right number to structure around. The others (careers, press, caregivers) get a page, not a section. I wrote about how to decide which audiences count in Patients, providers, partners; this chapter is about what the decision looks like in the schema.

Why ten types, and which ten?

Ten because that's the set that appears on almost every healthcare marketing site, and each one either has its own URL or is referenced from more than one place. That's the test for a type.

• page. Title, slug, audience, a list of sections, SEO. The page-builder document; most of the site is these.
• service. A service line, condition, or offering. Summary, body, FAQs, related providers, medical review. Has its own URL.
• provider. Name, credentials, title, specialties, accepting patients, headshot, bio, locations. Has its own URL.
• location. Name, address, coordinates, phone, structured hours, providers. Has its own URL.
• post. Title, author, body, medical review, SEO. The blog.
• person. Author or reviewer: name, credentials, role, bio. No URL of its own; rendered as bylines and in structured data.
• faq. Question, answer, a category string for grouping. Referenced from services and from FAQ sections.
• legalPage. Privacy policy, terms, accessibility statement, notice of privacy practices. Title, body, effective date.
• redirect. From, to, permanent. Redirects are content, so editors can see and manage them (chapter 4).
• settings. One document: organization name and logo, contact, social, default SEO, analytics id, consent copy, header and footer navigation per audience.

What is not on the list: insurers, jobs, press releases, events, research, clinical trials. Every one of those is real on some sites and absent on most, so they're add-ons. In the starter a new type is a schema file, a query, a route, and a line in three lists; the walkthrough in ADDING-A-TYPE.md does insurers end to end in about twenty minutes. The rule I hold to is that a type earns a place in the base model only after two real projects needed it. In your project, add what the client needs, and nothing the client might need.

Services or conditions?

One type for both, with the title and the URL doing the work.

Patients search for conditions and symptoms ("knee pain", "sleep apnea test"). Organizations think in service lines ("Orthopedics", "Sleep Medicine"). Modeling those as two types produces two trees that have to be cross-linked and kept in agreement, and within a year the condition pages are stale because nobody owns them. Modeling them as one service type means every entry gets the same fields (summary, body, FAQs, providers, review) and the same template, and the only decision per entry is what to call it. Name and slug it the way patients search; put the department name in the body.

If a site truly needs to group services, add a category string field first, the way faq has one. Add a separate taxonomy type only if the categories need their own pages, which is rare on a marketing site.

Why are providers and locations first-class?

Because they're the pages that rank for local search, they're the data behind Physician and MedicalClinic structured data, and they change more often than anything else on the site. A record entered once and referenced everywhere is the only way those three facts stay true at the same time.

A provider carries what a patient and a referrer both need: name without credentials, credentials separately, a title (Cardiologist, Nurse Practitioner), specialties as tags, whether they're accepting patients, a bio, and the locations they practice at. A location carries a structured address, coordinates, a display phone number (the dialable link is derived), and hours as days, opens, and closes rather than free text, because the openingHoursSpecification in the structured data needs them that way and a free-text "Mon–Fri 8–5" can't be turned into it reliably.

References go one direction: provider to locations. A location's provider list is derived from that unless an editor curates it explicitly. The same pattern applies to the page sections: a providers section with no references shows every provider (the directory); with references it shows a chosen subset. So when a physician moves to a different office, one document changes and the directory, the location page, the service pages that list them, and the structured data all follow. On a site where provider bios are copied into page bodies, that same move is a search-and-replace across the site and something always gets missed.

Where does medical review live?

As two fields, reviewedBy and reviewedAt, on the types that make clinical claims: service and post.

The reviewer is a person document, so a physician who reviews forty pages is one record with one set of credentials, not forty retyped bylines. The fields render as a byline on the page and go into the Article structured data, which is what search engines look at when deciding whether health content is trustworthy. The Studio requires a review date when a reviewer is set, and warns (rather than blocks) when a post has no reviewer, because some posts are operational (new parking, holiday hours) and don't need one.

The same two fields are the audit trail from chapter 5: when counsel or a regulator asks who signed off on a clinical claim, the answer is on the page.

What are sections, and why only eight?

Sections are the blocks an editor composes a page from: hero, rich text, call to action, cards, FAQs, providers, locations, form. Eight because each one either presents a structured type or holds prose, and once you go past that you're building a design tool, not a content model.

The distinction matters. A providers section doesn't contain providers; it references them, or shows them all. An FAQs section references faq documents. The section decides layout; the document holds the facts. That's what keeps a page-builder from decaying into page-builder soup, where every page is a one-off and nothing is reused.

The same principle limits the navigation. Header nav is capped at six links and one button per audience, enforced by validation in the Studio. A site that needs a mega-menu needs a different starting point, and it's better to find that out in week one than at launch.

What should stay out of the CMS?

Three things: anything a patient typed, anything that's configuration rather than content, and anything that lists everything.

Form submissions never touch the CMS. The CMS holds the form's definition (fields, which receiver it posts to); the submission goes to the receiver and nowhere else. The Studio warns when a field key looks like protected health information (date of birth, diagnosis, member id), which is a nudge for the editor and a tripwire for the reviewer. Chapter 5 covers why.

Secrets and integration configuration live in environment variables, not in settings. The analytics id and consent copy are content (marketing owns them); the webhook URL that receives forms is not.

Index pages (/providers, /locations, /services, /blog) are code, not page documents. They list everything and need no editorial input; making them editable only creates a way to accidentally hide half the providers. Those slugs are reserved so an editor can't create a page that collides with one.

How do you move existing content into this model?

Map, don't lift. Every URL in the inventory from chapter 2 gets assigned a type before anything is moved, and most old pages turn out not to be pages.

On a typical WordPress site, provider bios are pages or a plugin's custom post type; they become provider documents. Location pages become location documents. Condition and service pages, often forty or more, become service documents with the same template. FAQ blocks scattered across pages become faq documents that services reference. The blog becomes posts with an author and, where the content is clinical, a reviewer. What's left, usually the homepage, about, a handful of campaign pages, and the audience landing pages, becomes page documents built from sections.

In my experience, somewhere between sixty and eighty percent of the old page count collapses into structured records. That's the number to put in front of the client early, because it changes what "migrate the content" means: less copying, more deciding. Structured data, sitemaps, and internal linking then come from the model rather than from anyone remembering to add them.

Checklist

Migration - [ ] Every inventoried URL assigned a type before any content moves - [ ] Provider and location records deduplicated: one document each - [ ] Structured data checked on one provider, one location, and one service page after import Companion code in the Healthcare Sanity Starter: sanity/schema/ (the ten types and eight sections), docs/ADDING-A-TYPE.md (adding a type end to end), docs/DECISIONS.md (the schema decisions and why).