Content Modelling for Hospitals: Doctors, Departments, Procedures, Locations

This post is for the marketing lead, content manager or SEO owner at a hospital or hospital group who has found the same doctor listed three times on the website, each page slightly different, each with its own URL. It happens when branches maintain their own pages, when a migration copies content instead of linking it, or when a template builds a profile per location. The result is split signals for search engines, conflicting information for patients and a maintenance burden for editors.

This article is about prevention. It describes the content model that keeps one doctor as one entity, the slug and canonical rules that follow, and an audit method for cleaning up an existing site. The front-end build is a separate topic, covered under our headless CMS service; here the focus is the model and the rules an editorial team can run.

The examples are hypothetical and use no real clinicians. Clinical details such as qualifications and scope of practice must be approved by the provider's clinical team and, for doctors in India, kept consistent with the NMC advertising rules; our NMC advertising guidelines explainer is the place to check what a doctor profile can say.

Start from entities, not pages

A hospital website describes real things: people, places, departments, procedures. Each should exist once in your content system, with an identity that does not change. Pages are views of those entities. When people say "we have four pages for Dr X", what they usually mean is that the entity was copied four times.

Four entities carry most of the load:

• Doctor: a person with one set of qualifications, one registration, one biography.
• Location: a physical site with an address, hours and phone.
• Department: a clinical grouping, often shared across locations.
• Procedure or condition: the thing a patient is searching for.

The relationships between them are where duplication starts. A doctor works in a department at a location. That is a three-way relationship, and it has its own attributes (days, booking link, room). Model it as its own record, usually called a placement or appointment slot group, and not as copies of the doctor.

If your CMS cannot model join records, the fallback is a reference field on the placement that points to the single doctor entry. Never copy the biography.

Identity: IDs, slugs and display names

Three different things get confused.

ID: an internal, permanent identifier. It never changes and never appears in a URL unless you choose so. Use it for joins, tags and redirects.

Slug: the URL segment. It must be unique, readable and stable once published.

Display name: how the doctor's name appears on the page. It can change (a new title, a spelling correction) without touching the ID.

Doctor names collide often, especially common surnames. A slug rule has to handle that predictably. A rule that works: slug equals name plus primary specialty, for example anil-sharma-cardiology. If that still collides, append the city, then a short numeric suffix as a last resort. Write the rule down, generate slugs automatically from it, and lock the slug after publication. If a name changes, the slug stays, or the new slug is created and the old one 301-redirects to it.

Do not put the location in a doctor's slug unless the doctor works at only one site, because it ties the identity to a placement that may change. Location context belongs in the page, in a section listing placements, and in the location pages that link to the doctor.

One canonical doctor page

Each doctor has one canonical URL, for instance /doctors/anil-sharma-cardiology. Every other surface that mentions the doctor links to it: location pages, department pages, article bylines, search results.

Branch needs are met without duplicating profiles:

• A location page includes a "doctors at this location" list with a card for each placement: photo, name, specialty, days at this site, and a booking link for this site. The card links to the canonical profile.
• The canonical profile lists all placements, so a patient who found the doctor via one branch can see the others.
• A booking link can carry the location as a parameter or path, so the booking system knows which site was chosen.

This resolves the usual internal argument. Each branch wants its doctors on its site. They are on it, as cards, with the local details that matter, without a second biography.

Canonical rules when duplicates exist

You may inherit duplicates, or have legitimate reasons for location-specific pages (for example, a doctor who runs a distinct clinic at one site with different services). Set rules before editors improvise.

Google describes several ways to specify a canonical URL: a 301 redirect is a strong signal that the target should be canonical, the rel="canonical" link element is also a strong signal, and a sitemap is a weak one. Google also states that it makes the final decision about which pages are duplicates, based on similarity of content, and recommends absolute rather than relative paths in the canonical element. So the canonical element is a hint you support with consistent content and links, not a command.

A decision table:

Be consistent between the canonical element and what the rest of the site says. If the canonical points to one URL while internal links, sitemaps and breadcrumbs point to another, you are sending mixed signals.

Handle moves and departures

Placements change constantly. Treat each change as a content event with a defined effect:

1. Doctor moves to a new location: update or add a placement. The doctor URL does not change. Location pages update through their placement lists.
2. Doctor joins: create the entity, add placements, assign a clinical reviewer, publish.
3. Doctor leaves: unpublish placements first so branch pages stop listing them. Then decide about the profile (redirect or minimal page). Remove booking links so patients are not sent to a clinician who no longer consults there.
4. Duplicate discovered: merge, never delete. Choose the record with more complete data as the survivor, copy any unique data across after review, 301 the other URL to it and record the old ID in a merged-from field.

Writing these down means a new content manager follows the same process as the last one.

Structured data from the model

Generate markup from fields. According to schema.org's Physician type, Physician defines availableService, hospitalAffiliation and medicalSpecialty, and inherits further properties from its parent types. Because the doctor entity is single, there is one Physician description per person, and the placements feed the affiliation properties. Duplicate pages produce contradictory markup; a single entity cannot. For the implementation side, see our schema markup service and provider page optimisation.

Auditing an existing site for duplicate doctors

If you suspect duplication, a short audit finds it.

1. Export every doctor-like URL. Crawl the site and filter by path patterns or by the presence of Physician markup, and add everything from the sitemap.
2. Normalise. For each URL extract the name, strip titles such as "Dr." and punctuation, lowercase it, and note the specialty and location.
3. Cluster. Group by normalised name, then check clusters against a stable attribute: the registration number held in the provider's records, or the staff ID in HR. Names alone produce false matches for common names.
4. Classify each cluster using the decision table above: merge, remove, keep with a canonical, or leave alone.
5. Check inbound signals. Look at internal links and search impressions for each URL in Search Console before redirecting, so the survivor is the page with the strongest history, unless the content is clearly inferior.
6. Fix the cause. If a template generates a profile per location, change the template. Otherwise the duplicates return.

Keep the cluster list. It becomes the redirect map and the evidence for the clinical team that the right profile survived.

Editorial guardrails

Some rules belong in the editing interface, not in a document:

• The doctor slug field is read-only after publish.
• Creating a doctor requires a search for an existing entry first, with a visible "possible match" warning on similar names.
• Placements require a doctor reference; free-text biographies are not allowed on location pages.
• Clinical fields (qualifications, areas of expertise) carry a reviewer and date.
• The content team has a monthly report of new URLs that match doctor patterns.

For the wider editorial picture across many departments, the hospital content marketing strategy for 20+ departments covers planning and ownership, and our provider bio pages work covers building the profile itself.

A short checklist