Most health system websites are built like a mine. You start at the top, pick a tunnel, and keep descending: Services, then a specialty, then a program, then the condition you were actually looking for. If you came in the front door, that works, more or less. But almost nobody comes in the front door anymore, and the pages at the bottom of those tunnels tend to be the loneliest pages on the site.
I recently worked through this with a large academic health system: a main site plus several specialty subsites, hundreds of services, and a growing list of condition pages. The question we kept coming back to was easy to ask and hard to answer. How do you make sure no page ends up stranded at the end of a long tunnel? Our answer was taxonomy. Not as a filing system, but as the thing that generates the links between pages.
The tunnel problem
A strict hierarchy gives every page exactly one home and exactly one way in. That's tidy for the people organizing the site and rough for the people using it. A page about a specific heart rhythm condition might sit four levels deep under a surgery program. A patient who needs that same condition explained from the cardiology side has no structural path to it at all. Someone has to remember to add a link by hand.
Hand-built links are where things fall apart. They're added when a page launches, they drift as programs change, and nobody owns them. Six months later a new service exists that treats the condition, and the condition page has no idea. Multiply that by a few hundred services across several subsites and you get a directory where the relationships live in people's heads instead of in the system.
The fix isn't a better tree. It's accepting that some relationships are parent and child, and most are not.
One taxonomy, three page types
We started by naming the three kinds of page that carry clinical content, and agreeing that they're the same record seen from different altitudes.
- Area of Care. The broad specialty a patient recognizes, like heart and vascular care. It's the front page of a service line.
- Service. A capability: what a team does, who does it, and where. A surgery program, an imaging service, a clinic.
- Condition. A diagnosis or symptom. The thing a person actually types into a search bar.
Each page type has a different job, and the links between them aren't authored. They're read out of shared tags. A Service is tagged to its Area of Care, so the Area lists it. A Condition is tagged to every Service that treats it, so each of those Services lists the Condition, and the Condition lists them back. Hover a page in the diagram below to see what it links to.
Two kinds of line
The most useful distinction we made was between two kinds of connection, and we drew them differently in every diagram so nobody could confuse them.
Solid lines are parent and child. The directory lists the Area of Care. The Area of Care lists its Services. These are the rigid bones of the site: they set the breadcrumb, the rail navigation, and where a page sits in the directory. Every page has exactly one primary parent.
Dashed lines are tags. A Condition is tagged to every Service that treats it, so it can belong to more than one, and it rolls up to the Area of Care automatically. Tags are many-to-many by design. They don't move a page in the hierarchy; they make it show up wherever it's relevant.
Once you separate the two, a lot of arguments go away. Nobody has to decide whether atrial fibrillation belongs to electrophysiology or to cardiac surgery. It gets one primary home for its breadcrumb, and tags for everywhere else it matters.
Search enters from the bottom
We design directories from the top down: hub, then Area of Care, then Service, then Condition. Search uses them in the opposite order.
A patient describes a symptom to Google or an AI assistant. The answer names a condition, and the condition page becomes the first thing that person ever sees of the health system. They didn't come through the homepage. They never saw the service line. They landed at the bottom of the tunnel.
Once the condition makes sense, they climb: the Service that treats it, the Area of Care around it, then out into the wider directory and the specialty subsites. Every rung has to hand off cleanly to the next, and in a strict hierarchy the rungs often aren't there. With tags doing the linking, the condition page always knows who treats it, so the climb is built in.
Every area is its own cluster
The tagging pays off a second time in search. Each Area of Care acts as a pillar page, and the Services and Conditions tagged to it form its cluster, linked to one another without anyone maintaining the links. Cross-cutting content like news stories, provider profiles, and locations attaches to the same tags and joins the cluster too.
To search engines and large language models, that density reads as topical authority: depth on a subject rather than a scattering of pages. And because the pattern comes from the model, not from editorial effort, it repeats across every Area of Care on the site.
Each page has a job
Connecting pages only helps if each page knows what it's for. We framed it around three audiences (patients, referring physicians, and job seekers) and asked what each page type has to do for them.
- Area of Care pages carry institutional credibility, not clinical depth. They answer “why here,” then offer a curated path down into services and providers rather than an exhaustive list.
- Service pages are the busiest page type. Nearly every audience question lands here: what's offered, who does it, what it costs, and how to schedule, with scheduling built into the page instead of handed off.
- Condition pages are mostly for patients and caregivers. They lead with direct answers about symptoms, causes, and treatment options, written to be cited by AI answers, and they point to the services that treat the condition.
- Provider profiles carry prestige and the most direct path to an appointment.
Three audiences with different questions, all heading toward the same place: confidence in the organization.
Authors tag, the site links
None of this works if it's hard to maintain, so the authoring model is deliberately small. The author picks a page type first, and the taxonomy fields change with that choice.
- Areas of Care sit at the top. There's nothing above them to tag.
- Services are always tagged with an Area of Care.
- Conditions are tagged with a Service, an Area of Care, or both.
Those tags are the only relationships anyone authors. Every listing, cross-link, related-services module, and directory filter is read back out of them.
The same structure stretches across subsites. A cancer subsite can keep the language its patients search with, calling its groupings cancer types and its services treatments, while sitting inside the same model as every other Area of Care. Different vocabulary, same three page types, same rules.
What it changes
- Coverage by construction. Every Condition surfaces every Service that treats it, not only the ones someone remembered to link.
- One edit, not four. Adding or renaming a page means tagging it once instead of updating two to four parallel lists by hand.
- Both ways in stay equal. Diagnosis-first and capability-first searches land on sibling pages at the same depth, not one nested under the other.
The rigid hierarchy doesn't go away. Pages still have parents, breadcrumbs, and a place in the directory. The taxonomy lives alongside that structure and does the connecting the hierarchy can't.
The whole web
Zoom all the way out and this is what it looks like. Each band around the edge is an Area of Care, colored by the subsite it lives on. Inside are its Services and Conditions. The lines crossing the middle are the relationships the tags create: Services that treat Conditions in another area, and pages that belong to more than one Area of Care. Hover any point to see how far one page reaches.
That's the picture I wish every site map looked like. Not a stack of tunnels, but a web where any page you land on is a few steps from everything related to it. No page sits at the end of the line, because there's no end of the line.