Schema markup for healthcare: a practical implementation guide

I spent some time studying local hospital websites to understand what they were missing.

It brought me back to a basic requirement: a hospital website should clearly connect its doctors, departments, services, and locations. Those relationships need to make sense to patients and to search engines.

Schema markup for healthcare helps describe that information to search engines. It should be planned and included when the website is built, alongside the pages and the system used to update them.

My position is straightforward. A hospital should not have to commission another SEO service after launch to put this basic structure in place.

What is healthcare schema markup?

Schema markup is a set of labels added to a website’s code. These labels explain what the information on a page represents.

For a hospital website, they can identify:

• The hospital and its locations.
• A doctor and their relationship with the hospital.
• A department and the hospital it belongs to.
• A service and the organisation providing it.
• A medical article, its author, and the person who reviewed it.

Patients read the page. Search engines can also read these labels to help interpret its content. Google describes structured data as a way to provide explicit clues about a page’s meaning.

You do not need to understand the code to commission this work. You do need to ask what information is being described, where it comes from, and how it will stay accurate.

Connect the information patients need

Consider a patient looking for a cardiologist at a particular hospital branch.

The website should help them establish who the doctor is, where they practise, what service is available, and how to request an appointment.

That gives the development team a clear set of relationships to build:

Information	What the website should make clear
Doctor	Their name, verified qualifications, and specialty.
Hospital branch	Its address, contact details, and relevant operating hours.
Department	Which hospital or branch it belongs to.
Service	Where it is available and who provides it.
Appointment	The correct booking or enquiry route.

These relationships should appear in the page content and navigation. The markup should describe the same facts.

A doctor should not be shown as an employee if they are a visiting consultant. A service available at one branch should not be presented as available at every branch. These details need to be confirmed before the developer connects them.

Which schema types should healthcare websites use?

A schema type is the label used to describe something, such as a hospital, doctor, or article. Properties are the details attached to it, such as a name, address, or employer. Use the table to decide what each page needs. Your developer can then choose the appropriate fields.

Choose the most specific type that accurately describes the entity. Then choose properties appropriate to that type and the facts available.

The following table is a planning guide. Its property lists are useful starting points, not universal Google requirements.

Page or entity	Suitable schema	Useful properties	Google support boundary
Healthcare group	MedicalOrganization	name, url, logo, subOrganization	Organisation information; no dedicated medical-group rich result.
Hospital	Hospital	address, telephone, department, parentOrganization	Applicable organisation and local-business features.
Clinic location	MedicalClinic	address, openingHoursSpecification, medicalSpecialty	Applicable local-business features.
Individual clinician profile	Person	name, jobTitle, worksFor, hasCredential	No dedicated clinician rich result.
Physician as a medical provider entity	Physician	medicalSpecialty, hospitalAffiliation, availableService	Applicable organisation and local-business features.
Diagnostic laboratory	DiagnosticLab	name, url, address, parentOrganization	Organisation information; no dedicated laboratory rich result.
Pharmacy location	Pharmacy	address, telephone, openingHoursSpecification	Applicable local-business features.
Appointment or treatment service	Service	name, serviceType, provider, areaServed	No dedicated general Service rich result.
Medical information page	MedicalWebPage	about, reviewedBy, lastReviewed	No dedicated MedicalWebPage rich result.
Clinical subject	MedicalCondition, Drug, or MedicalProcedure	Subject-specific properties	No dedicated rich result for these medical types.
Editorial article	Article or BlogPosting	headline, author, image, publication dates	Supported article features, subject to Google’s guidance.
Navigation trail	BreadcrumbList	itemListElement, positions, names, URLs	Supported breadcrumb features.
Educational video	VideoObject	name, thumbnailUrl, uploadDate, video URLs	Supported video features, subject to eligibility.

Check Schema.org’s medical vocabulary alongside Google’s supported feature gallery. The two answer different questions.

Organisations, facilities, and individual clinicians

Use MedicalOrganization for an appropriate healthcare organisation and a more specific subtype, such as Hospital or MedicalClinic, where it fits.

The Physician definition needs particular care. Schema.org describes an individual physician or physician’s office considered as a medical organisation. It sits within organisation and local-business hierarchies.

For a biographical profile, Person provides properties for the individual and their relationships. Use worksFor for employment and affiliation where that more accurately represents the relationship. Keep a personal identity distinct from a practice entity when both need to be described.

DiagnosticLab describes a diagnostic laboratory and inherits from MedicalOrganization. It is not automatically a LocalBusiness subtype. A laboratory serving local customers may need additional modelling appropriate to its actual operation.

Services, procedures, and medical information

Use Service to describe what a provider offers, such as a consultation service. Use MedicalProcedure to describe a clinical procedure itself. They represent different aspects of the information.

A medical information page can use MedicalWebPage, with about pointing to its subject. That subject might be a MedicalCondition or Drug. The markup should describe the actual content and its reviewed facts.

Finally, HealthCare is not a general website type. It is an enumeration value for a government benefit. Do not use it as the organisation type for a hospital or clinic.

Single-location MedicalClinic example

Here is a simple example for one clinic. It identifies the clinic, its location page, address, telephone number, and regular opening hours.

This is JSON-LD, a format used to publish schema markup in a page’s code. Your developer can generate it from the same records used to display the clinic’s details on the website.

The clinic, address, telephone number, and website below are fictional. Replace them with approved information before using the example.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "MedicalClinic",
  "@id": "https://example.org/locations/central-clinic/#clinic",
  "name": "Example Central Clinic",
  "url": "https://example.org/locations/central-clinic/",
  "telephone": "+60-3-0000-0000",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "10 Example Street",
    "addressLocality": "Kuala Lumpur",
    "addressRegion": "Wilayah Persekutuan Kuala Lumpur",
    "postalCode": "50000",
    "addressCountry": "MY"
  },
  "openingHoursSpecification": {
    "@type": "OpeningHoursSpecification",
    "dayOfWeek": [
      "https://schema.org/Monday",
      "https://schema.org/Tuesday",
      "https://schema.org/Wednesday",
      "https://schema.org/Thursday",
      "https://schema.org/Friday"
    ],
    "opens": "09:00",
    "closes": "17:00"
  }
}
</script>

The main fields explain:

• @type: this organisation is a medical clinic.
• @id: a consistent identifier for the clinic, which other pages can reference.
• name and url: the clinic’s name and its main location page.
• address and telephone: where the clinic is and how to contact it.
• openingHoursSpecification: when the clinic normally opens and closes.

If Saturday hours differ, add a separate entry. Check public holidays and other exceptions rather than assuming the weekday schedule always applies.

A clinic with several branches needs separate location records with the correct details for each branch. Do not copy one branch’s address and hours across every location page.

For production, check the example against the MedicalClinic definition and Google’s local-business requirements. This is a starting example, rather than a guarantee of a particular search appearance.

Include it in the development scope

For a new hospital website, I would include structured data in the original development scope. It depends on decisions already being made about doctor profiles, department pages, service pages, and location records.

Leaving it until after launch can mean reopening those decisions, correcting records, or changing templates that should already handle the information.

Ask for these requirements in the proposal:

1. A clear page structure. Each doctor, department, service, and location needs an appropriate place on the website.
2. Connected records. The team should be able to link a doctor to the correct hospital and services without copying the same information across several pages.
3. Suitable schema labels. The markup should describe what each page is actually about.
4. Shared information. The visible page and its markup should use the same approved records.
5. Checks before launch. The developer should inspect the published output and test representative pages.
6. A handover process. Your team should know how to update the information and who handles technical changes.

Write these into the proposal and the checks used to sign off the website. That gives both the hospital and the developer a clear basis for checking the finished work.

This belongs within the wider WordPress development scope, together with page titles, search descriptions, internal links, and the controls needed to manage content.

A plugin still needs accurate information

A plugin can help publish schema markup. It still needs the right details and relationships.

Before adding another plugin, check what the website already produces. The theme, page builder, and SEO plugin may each add their own descriptions. Those descriptions need to agree.

For example, one part of the website might publish a branch’s current address while another still uses the head office address. Installing another tool does not resolve which record is correct.

The development team should identify the source of the information and remove or correct conflicting output. Your hospital team should approve the underlying facts.

Check the work before accepting the website

Ask for evidence from the finished pages, rather than a screenshot of an enabled plugin setting.

The checks should answer three questions:

• Is the information accurate? Names, locations, hours, qualifications, and affiliations should match the approved content.
• Can the markup be read correctly? The Schema Markup Validator checks the use of schema labels and relationships.
• Does it meet Google’s relevant requirements? The Rich Results Test checks supported Google search features.

A successful test does not guarantee a special appearance in search results. Some medical schema types have no dedicated Google search feature. Check Google’s structured data guidance.

Test at least one page of each relevant type. Include a doctor who works across locations and a record with optional information missing. Check the live website after launch as well.

Keep the records accurate after launch

Doctors move. Clinics change hours. Services become available at new locations.

The website should let your team update these records without asking a developer to edit code each time. Where practical, one approved change should update both the page content and its markup.

Assign responsibility for the information:

• The team responsible for doctor records confirms profiles and hospital relationships.
• Operations confirms addresses, contact details, and opening hours.
• Medical reviewers approve clinical content and review dates.
• The website team checks how pages are built and what information they publish.

Public markup should use approved public information. Patient records, private appointment details, and sensitive booking data should stay out of it.

Where ongoing SEO fits

Including schema in the build does not mean all future search work is complete.

Ongoing technical SEO may involve investigating search problems, improving content, reviewing new services, or adapting to changes in search requirements. That work should have a defined purpose and scope.

The distinction matters when commissioning a new website. Basic page structure, connected records, and the agreed structured data should be delivered as part of the build. Later work should respond to new needs or identified problems.

Schema also does not establish medical credibility on its own. Accurate content, verified credentials, and proper clinical review still matter.

What schema should a hospital or clinic website use?

Use the type that matches what the page describes. Hospital suits a hospital, MedicalClinic suits a clinic, and Person can describe an individual doctor’s profile. Services and articles need their own relevant types. One label should not be applied to every page without checking its purpose.

Frequently asked questions

Should healthcare schema be included in the website quotation?

For a new hospital or clinic website, I would include it in the original development scope. The quotation should state which pages it covers, how the information will be connected, and what checks will be completed before handover.

Can an SEO plugin handle everything?

A plugin can publish markup, but someone still needs to supply accurate information and connect the right records. Ask your developer to check what the plugin actually produces, including whether it conflicts with other parts of the website.

Will schema markup improve our Google rankings?

It helps Google interpret information and can support eligible search features. It does not guarantee higher rankings, a special search appearance, or more patient enquiries. Google explicitly states that correct markup does not guarantee a rich result.

How should we handle several hospital branches?

Give each branch its own record with the correct address, contact details, and hours. Link doctors and services to the branches where they are actually available. Keep one consistent identity for a doctor who works across locations.

Can we use patient reviews to get stars in Google search results?

Reviews about a hospital or clinic on its own website are ineligible for Google’s review stars under the organisation and local-business rules. Embedding reviews from another platform does not remove that restriction. Genuine feedback can still help visitors, subject to the hospital’s consent and publication process.

How do we know the markup has been implemented correctly?

Ask for checks on the finished pages using the Schema Markup Validator and Google’s Rich Results Test. Also confirm that the information matches the visible page. A technical test cannot establish whether a doctor’s qualifications, hospital relationship, or opening hours are accurate.

How much does healthcare schema implementation cost?

The scope depends on the number of page types, locations, doctors, and systems involved. For a new website, ask for the work to be included and defined in the build quotation. For an existing website, inspect the current setup first so the quotation addresses the actual changes needed.

Questions to ask your website developer

Before approving a hospital website proposal, ask:

• Is healthcare schema included in the build, and which pages does it cover?
• How will doctors, departments, services, and locations connect?
• Will page content and markup use the same approved records?
• How will you check for missing or conflicting information?
• What evidence will you provide before handover?
• Can our team maintain the records after launch?

For an existing website, inspect what is already there before commissioning changes. Some sites need a focused correction. Others need changes to how their information is stored and connected.

Include the structure in the build. Check it before handover. Give someone responsibility for keeping it accurate.

If you are planning a hospital website or reviewing an existing one, discuss the requirements with Ulement.