Patients, providers, partners: structuring a healthcare site for more than one audience

Most healthcare marketing sites have to serve at least three audiences who want completely different things. A patient wants to know whether you treat their condition, whether you take their insurance, and how to get an appointment. A referring physician wants your clinical credentials, your outcomes, and a fax number. A pharmaceutical partner or investor wants to know what you've published and who runs the company. Put all three on the same homepage with equal weight and you've built a site that's mediocre for everyone.

Marketing teams know about personas. The exercise of writing down who your audience is, what they need, and what they already know is familiar. What's less familiar is applying that exercise to the structure of the site rather than to messaging. This post is about that: how to take "we have multiple audiences" and turn it into navigation, page structure, and a content model that a non-technical team can maintain.

Who are the audiences, really?

Fewer than you think, and you should name them before designing anything.

The obvious list for a health system or specialty practice is patients, referring providers, and partners. Depending on the organization, add caregivers (who often do the searching on a patient's behalf), job candidates, investors, press, and research collaborators. A biotech or life-sciences company might have patients, prescribing physicians, payers, investors, and candidates.

The mistake is treating every group that might visit as an audience the site has to be structured around. Structure around the ones whose needs are actually different and whose traffic actually matters. For most healthcare organizations that's two or three groups. The rest get a page, not a section.

For each audience you keep, write down three things: what they come to the site to do, what they already know when they arrive, and what would make them leave. A patient arriving from a search for "knee replacement near me" doesn't know your name, does know their problem, and will leave if they can't find a location and an appointment path in about ten seconds. A referring physician arriving from a colleague's recommendation knows your name, wants to confirm your credentials, and will leave if the site reads like an advertisement.

Those three answers drive everything below.

Should each audience get its own section?

Usually yes for the navigation, usually no for the content.

The pattern that works for most healthcare sites is a primary navigation organized around what patients do (find a condition, find a provider, find a location, make an appointment) with a clearly labeled path for each secondary audience ("For referring providers," "For partners," "Careers"). Patients are the majority of traffic and the navigation should serve them by default. The other audiences need to find their door within a second of landing, and a labeled link in the header or the top of the footer does that.

What you should not do is build three parallel sites with duplicated content. A provider's profile page is one page. It appears in the patient-facing directory and it's linked from the referring-provider section, but it's one document in the CMS with one URL. The same goes for locations, service lines, and conditions. The audience sections are entry points and framing, not separate copies of the site.

The reason is maintenance as much as search. If a physician's credentials exist in two places, one of them will be wrong within a year. If a condition page has a patient version and a clinician version that don't share a source, the clinical reviewer has to check both.

How does this become a content model?

By making audience a property of content rather than a folder it lives in.

This is the part where the persona exercise turns into something a developer builds and a marketing team uses. In Sanity, the site is made of content types: provider, location, service line, condition, article, and so on. Each is a structured document with fields. Audience fits into that model in two ways.

First, some content types are inherently for one audience. A referral form is for providers. A clinical trial listing is for researchers and physicians. An insurance page is for patients. Those types live in the model and appear where they belong.

Second, and more usefully, shared content types carry audience-specific fields. A condition document might have a patient summary (plain language, what to expect, when to seek care) and a clinical summary (indications, approach, outcomes data). The page shows the patient summary by default with a clearly labeled section for clinicians, or the referring-provider section renders the same documents with the clinical summary first. Either way the physician edits one document.

For a marketing team this means adding a new service line is one form with a patient description and a clinician description, not two pages built separately. It means the site stays consistent because the structure enforces it, and it means the designer and I can build one template per content type instead of one per audience.

What goes on the homepage?

The patient's next step, plus a door for everyone else.

Homepages fail when they try to greet every audience equally. The result is a carousel (please, no carousels) with a slide for patients, a slide for providers, and a slide for the latest press release, and nobody finds anything. Decide who the homepage is for. For almost every healthcare organization that's the patient or caregiver, because that's who arrives without knowing you and needs the most help.

So the homepage leads with what a patient does: find care, find a provider, find a location. Below that, the things that build trust: outcomes, credentials, a short statement of what the organization is. Then the doors: a clearly labeled band for referring providers, for partners, for careers. Each door goes to a landing page written for that audience in their language.

The secondary landing pages are where the persona work pays off. The referring-provider page doesn't say "world-class care." It says how to refer, what information to send, how quickly you'll see the patient, and how the referring physician gets updates. That's what the persona said they wanted. Write it that way.

How do you handle language and reading level?

Per audience, and the content model should make the distinction visible to editors.

Patient-facing content in healthcare should aim for roughly a sixth to eighth grade reading level, avoid clinical vocabulary or define it, and answer the question the patient actually has. Clinician-facing content can and should use clinical vocabulary, cite evidence, and skip the reassurance.

The structural fix is to label fields by audience in the Studio. "Patient summary" and "Clinical summary" are self-explaining. An editor filling in the patient summary knows who they're writing for, and a clinical reviewer knows which field is theirs. If your content model has one "description" field that has to serve both, it will serve neither, and editors will argue about it forever.

What about search?

Multi-audience structure helps search if you keep one URL per thing.

Patients and physicians search differently. A patient types "chest pain when breathing." A physician types "pleuritic chest pain differential." A single condition page with a patient summary and a clinical section can rank for both, because search engines read the whole page. Two thin pages, one per audience, compete with each other and often rank for neither.

The audience landing pages help too. A "For referring providers" page that answers the questions referring providers actually ask is exactly the kind of page that ranks for "refer a patient to [specialty] [city]," which is a search with real intent behind it.

How do you keep this working after launch?

By making the audience list part of the editorial process, not a document from the kickoff meeting.

A persona that lives in a slide deck nobody opens is decoration. A persona that's built into the content model is enforced every time someone adds a page. That's the practical reason to do this work in the structure of the site rather than in a strategy document: it keeps working when the people who wrote the strategy have moved on.

Review the audience list once a year. Organizations change. A practice adds a research arm and suddenly has a fourth audience. A biotech gets an approved product and patients start arriving where only physicians used to. When that happens, the content model gets a new field or a new type, and the site adapts without being rebuilt.

What should you take from this?

Name your audiences, keep the list short, and write down what each one comes to do. Build the navigation around the primary audience with clear doors for the others. Keep one document per thing in the CMS, with audience-specific fields instead of audience-specific copies. Lead the homepage with the patient's next step. Label content by audience so editors and reviewers always know who they're writing for.

Do that and "we have multiple audiences" stops being a reason the site is confusing and becomes the reason it's organized.