This Best Practices document is intended to support digital marketing teams in optimizing Google’s understanding of a specific MedicalOrganization, typically a Hospital, or a MedicalClinic. The goal of this documentation is to ensure pages contain all the content required for a robust knowledge graph, and follow an HTML format that interfaces well with the Schema App Highlighter. Ideally, your team will document as a checklist during the planning and development phases of the HTML template. If you are exclusively using the Schema App Editor, you can ignore some of the constraints or suggestions related to authoring at scale.
There are two common scenarios for using MedicalOrganization and its subtypes on a website.
- A website dedicated to a single MedicalOrganization
An example of this would be an individual Physician with a private practice, or an independent MedicalClinic. In this case, you will likely want to use the most specific Type on your homepage, to communicate that it is the primary entity of the website. - A website dedicated to a MedicalOrganization that has multiple subOrganizations.
An example of this would be a health care system (e.g Baptist Health) with a multitude of Hospitals, MedicalClinic, and similar entities described on their website. In this case you will likely want to specify that the MedicalOrganization described on the home page, is the parentOrganization of the other entities described on the website including Hospitals or MedicalClinics.
The recommendations in this document are broad, as we intend to cover both of these use cases. For simplicity, this document will use the term "Hospital", but most (if not all) of the recommendations provided will also apply to MedicalClinic, Physician, and MedicalOrganization types.
The Strategy and Typical Page Content sections are best used during high-level design and brainstorming phases. The Schema.org Properties & Guidelines section is best used during the creation phase. Google’s Rich Result documentation for Organizations is subject to change.
If you are unsure which Type to target, or how to nest & connect your data items, contact [email protected] and we will be eager to assist you.
TABLE OF CONTENTS
- Which Type Should You Target for your Medical Organization?
- Typical Page Content
- Schema.org Properties & Guidelines
Which Type Most Appropriately Describes Your Medical Organization?
Schema.org vocabulary has several Types to describe specific subtypes of MedicalOrganizations. This section describes some of the criteria that may help you decide which Type is most appropriate for describing your content.
Note: If you are using a Highlighter template to target pages, your template should target a pageset that has a single primary entity (e.g all pages are about a Hospital as opposed to an MedicalClinic type).
Hospital
- Best suited for: Pages that describe Hospitals.
- Should not be used for: Pages that describe other kinds of medical facilities (e.g clinics, labs, pharmacies, etc). A Hospital might include, or encompass these facilities in which case you could state that a Hospital has a department that is a Pharmacy.
Medical Clinic
- Best suited for: Pages that describe clinics. Per Schema.org, a Medical Clinic is a facility that is often associated with a hospital or medical school, and is devoted to a specific diagnosis and/or domain of healthcare. A clinic primarily Previously limited to outpatients but with evolution it may be open to inpatients as well.
- Should not be used for: a physician’s office. In this case, use the more appropriate Physician or Individual Physician.
DiagnosticLab
- Best suited for: Pages that describe diagnostic labs. Per Schema.org, a DiagnosticLab. A medical laboratory that offers on-site or off-site diagnostic services.
- Best suited for: Pages that describe a pharmacy or a drug store.
- Should not be used for: entities that do not have a physical location.
Physician
- Best suited for: Independent physicians with a private practice and/or independent clinic. The physician may or may not be affiliated with a Hospital.
- Should not be used for: pages describing people who are not physicians (e.g admin, and/or paramedical professionals).
IndependentPhysician
- Best suited for: Independent physicians with a private practice and/or independent clinic. (Note that Physicians IndividualPhysician is a subType of Physician and has more opportunities to clarify affiliation information).
- Should not be used for: pages describing people who are not physicians (e.g admin, and/or paramedical professionals).
MedicalOrganization
- Best suited for: Pages that describe an Organization that is medical in nature but does not fit the requirements for Hospital, MedicalClinic, DiagnosticLab, Pharmacy, or Physician/IndependentPhysician. An example may be a medical device manufacuturer, or research instition.
- Should not be used for: Pages about Organizations with no medical expertise or authority.
List of Suggested Content for Hospital or MedicalOrganization
This section describes content commonly seen on Hospital and other MedicalOrganization pages. We recommend including as much of the following content as possible as you design and author content for these pages. The content in this list aligns with common properties that Schema App recommends for markup about Hospitals and other MedicalOrganizations.
Note: To target or include a specific property, the associated content should be present in the HTML of your page
Hospital, MedicalOrganization, Physician, MedicalClinic |
|
Hospital or MedicalOrganization Schema.org Properties and Associated Page Requirements
This section lists schema.org properties or property paths that may be used to map page content to schema markup for a Hospital or MedicalOrganization page. Your ability to target, or include this content in your schema markup will depend on the page's content and, if you're using the Highlighter, the page's HTML structure. This section lists some of the content and code requirements you'll need to consider. If you have any questions please contact your CSM or [email protected].
Schema.org Property | Content and HTML Requirements | Example |
name | There should only be one official “name” chosen for the Hospital. | Grey Sloan Memorial Hospital |
alternateName | The “alternateName property” can be useful for calling out other common names for your Hospital. Former names may also be included here. | Seattle Grace Hospital |
legalName | This should reflect the registered, legal name of the Hospital. | |
logo | This can either be an ImageObject or a URL. The image must be larger than 112 x 112px, the image URL must be indexable, and it must be in a Google-supported format. Consider how the logo will appear on a mostly white background. | |
numberOfEmployees | This can be included as an exact number or as a range using the Quantitative Value type. | |
employee | This property expects a Person data item. Consider how easily individual providers and their names can be programmatically isolated. For example, contain the name of each person within a list element or a header. Avoid listing all employees in an undifferentiated block of text. Utilize internal linking wherever possible! If the people mentioned have an entity home (i.e a Profile page, or an Individual Physician page), ensure that URL is present on the page to be referenced. | <p>Staff: <ul> <a href = "/physician/Meredith_Grey"> Meredith Grey, M.D., F.A.C.S</a> </ul> </p> |
foundingDate | The founding date can reflect a year or a specific date. | |
sameAs | Use the sameAs property to reference other locations on the Web that describe or define your Hospital. Examples can include: social media profiles, Better Business Bureau listings, review sites (e.g Yelp), and others. Be judicious with your sameAs links! Not everything is appropriate to include under sameAs. A key question to ask is: does the primary entity of the URL you’re referencing share an identity with your Hospital? If not, it is not appropriate to reference it as a sameAs URL. | |
| If your Hospital has multiple email addresses with distinct departments or functions, you can specify them using multiple Contact Point data items. Consider how easily the components for email addresses and departments can be programmatically isolated | <p>For billing inquiries: <ul><a href = "[email protected]"> [email protected] </a></ul> </p> | |
telephone | Include the country code. Dashes and parentheses are optional. If your Hospital has multiple telephone numbers for distinct departments, you can specify them using multiple Contact Point data items. Consider how easily the components for email addresses and departments can be programmatically isolated. | <p>Emergency Department: <input type="tel"> 987-123-4567</input> </p> |
openingHoursSpecification | Each day of the week should be described in your page content (e.g avoid "Mon-Fri: 9-5" . Ideally, the day of week and the hours are nested together in an HTML element. |  |
address~PostalAddress | Your address may be a physical or a mailing address. Include as many properties as possible (e.g streetAddress, addressLocality, addressRegion, postalCode). If your Hospital has multiple postal addresses or locations, you can specify them using multiple Postal Address data items. Consider how easily the address components can be programmatically isolated. | <p>Emergency Department <span id = "address">418 Holland Drive</span> <span id = "locality">Rochester </span> NY, 94230 </p> |
review, aggregateRating | Reviews and Ratings on an Hospital landing page must be about the Hospital itself. Nested #document data is inaccessible to the Schema App Highlighter. Ideally, Rating information should be aggregated and submitted on the page itself. Google has their own content requirements for Reviews and Ratings. Always check their documentation page for the most up to date content requirements. When in doubt, discuss Rating and Review content with your CSM. | <div id = "rating-container"> <p>Total Ratings: <span id = "rating-count">36</span></p> <p>Aggregate Rating: <span id = "agg-rating-value">4.8</span></p> </div> |
availableService | Utilize internal linking wherever possible! If the services mentioned have an entity home (i.e a Medical Therapy overview page), then ensure that the URL of the entity home is present. Consider how easily various Test, Procedure, and Therapy entities can be programmatically isolated. E.g: contain all Test type info in a unique <div> rather than a series of undifferentiated <p> elements), in succession with Procedure and Therapies in unique divs. | <p>Services offered at GSMH include: : <ul><a href = "/service/blood_test"> Blood Test</a></ul> <ul><a href = "/service/physio_clinic"> Physiotherapy</a></ul> </p> |
medicalSpecialty | Ideally, all entities targeted by the same property (e.g specialty, or knowAbout) should be contained within a single parent component.To target specific Medical Specialty enumeration members, the content of the JSON-LD must match the Schema.org Medical Specialty enumeration list. Discuss strategies to achieve this with your CSM. Existing metadata (e.g Breadcrumbs or Tags) may be helpful here. | |
hasPart~FAQPage | If FAQs are written in the body of a broader piece of content (e.g an Article), ensure all FAQs follow a standardized HTML format & structure. If the answer element is a sibling to the question element, ideally it should contain the entirety of the answer text (e.g <div id = faq-answer> with nested elements. If FAQs are written in an accordion, ideally that accordion should be differentiated from other accordions (e.g <div id = “faq_accordion”>). Ensure all content is accessible to the Highlighter & present on the same URL (e.g avoid Answers contained in Javascript generated pop-up windows). | Nested Elements <h3>What does FAQ stand for? <p>FAQ stands for Frequently Asked Question</p> </h3> Sibling Elements <h3>What does FAQ stand for?</h3><div id = "faq-answer"> <p>FAQ stands for Frequently Asked Question</p> <p>It is an excellent way to respond to common queries</p> </div> |
Organizational Metadata
Typically, we advise that all the content in your schema markup must be present on your webpage. This advice is less relevant for identification codes and similar forms of metadata. You can include these values in your markup without calling attention to them in your web content.
| Schema.org Property | Content Requirements |
Vat ID | This is the Value Added Tax code associated with your Hospital, if applicable. |
LEI Code | This is the Legal Entity Identifier (LEI) for your Hospital, defined in ISO 17442. Note: This value can also be added under the iso6523Code if you use the prefix “0199” |
Tax ID | This is the Tax ID associated with your Hospital. The country associated with your Tax ID must match the Country listed in your Hospital’s Postal Address. |
Dun and Bradstreet Number | This is the Dun & Bradstreet number for your Hospital. You can query the Dun & Bradstreet database here. Note: This value can also be added under the iso6523Code if you use the prefix “0060” |
ISO 6523 Code | An ISO 6523 code is a globally standard 2-part identification number. The first part defines the identification system, and the second part defines the identification value. Google recommends separating the two parts with a colon. ISO 6523 codes are Google’s preferred way to reference Dun & Bradstreet Numbers, LEI Codes, and Global Location Numbers. |
| NAICS Code | This is the North American Industry Classification System (NAICS) code for your Hospital. The NAICS code for General Medical and Surgical Hospitals is 622110. You can find that information and specific subtypes related to that value here. |
| Global Location Number | This is the GS1 Global Location Number identifying the location of your Hospital. Note: This value can also be added under the iso6523Code if you use the prefix “0088” |
Was this article helpful?
That’s Great!
Thank you for your feedback
Sorry! We couldn't be helpful
Thank you for your feedback
Feedback sent
We appreciate your effort and will try to fix the article