This Best Practices document is intended to support content creation teams. Our goal is to ensure pages contain the all content required for a robust knowledge graph in an HTML format that interfaces well with the Schema App Highlighter. Use this document as a checklist during the ideation and development phases of the template. If you are exclusively using the Schema App Editor, you can ignore some of the constraints or suggestions related to authoring at scale.
The Strategy and Typical Page Content sections are best used during high-level design and brainstorming phases. The Schema.org Properties & Associated Code section is best used during the template development and coding phase. The Physician type is not independently eligible for a Rich Result, but there are possible related types to explore, including Review, and Profile Page.
TABLE OF CONTENTS
- Choosing the Most Appropriate Type for Physician Pages
- List of Suggested Content for Physician Pages
- Physician Schema.org Properties & Associated Code Requirements
Choosing the Most Appropriate Type for Physician Pages
Pages about people can be confusing when there are several possible Types to use. The content and intent of a page will be important in deciding which Type(s) to use.
IndividualPhysician
- Best suited for: a page about a specific medical practitioner. IndividualPhysician is particularly useful for clearly specifying expertise and affiliation information (e.g. practicesAt).
- Should not be used for: Pages describing people who are not physicians (e.g admin, and/or paramedical professionals)
Physician
- Best suited for: independent physicians with a private practice and/or independent clinic. Note that the subType IndividualPhysician has additional opportunities to clarify affiliation information.
- Should not be used for: Pages describing people who are not physicians (e.g admin, and/or paramedical professionals)
ProfilePage
- Best suited for: a page about a specific person in the context of authorship and content creation. Google’s documentation on Profile Page is geared towards content attribution in the context of Forums, Google Perspectives and other content such as Articles or Recipes.
- Should not be used for: pages describing people who are not content creators. Sometimes physicians and medical staff are also content creators. These cases should be discussed in more detail with your CSM to identify the best strategy.
Person
- Best suited for: multi-typing to complement an IndividualPhysician or Physician page (e.g. Person & IndividualPhysician). Using Person type will allow us to use properties like hasCredential, jobTitle, worksFor, honorificSuffix, etc. It is advisable to use multi-typing for Person and Physician to fully capture all common on-page content.
List of Suggested Content for Physician Pages
This section describes content commonly seen on this type of page. This checklist is best used during high-level design & brainstorming as you design templates & decide what information you intend to display.
Physician |
|
Physician Schema.org Properties & Associated Code Requirements
The second section of this document lists schema.org properties that may be used when mapping page content & generating JSON-LD for a Provider Page. Prerequisite code or content requirements will impact your ability to use certain schema.org properties as intended.
If you have any questions, please contact your CSM or [email protected].
Schema.org Property | Content and HTML Requirements | Example |
name,honorificPrefix, honorificSuffix | Consider how easily names, and honorifics (e.g. M.D, Dr., etc) can be programmatically isolated. For example, information like educational suffixes can be contained in a uniquely identifiable HTML element. Note: honorifixPrefix and honorificSuffix are only available when multityping or nesting a Person type. | <p>Dr. T Geisel <span id = “hon”>MD</span> </p>) |
image | Google requires that images have an accessible image address, to be indexed and displayed in search. | |
address, hospitalAffiliation, practicesAt | Utilize internal linking wherever possible! If the places mentioned have an entity home (i.e a Hospital location page), ensure that URL is present on the page to be referenced. Consider how easily unique location entities can be programmatically isolated (e.g contain all location info in a unique <div> rather than a series of undifferentiated <p> elements). | <p>Dr. Whynn works from the following locations: <ul> <a href = "/clinics/west_moorelake"> West Moore Lake Clinic</a> </ul> |
hasMap | The map URL should be accessible within the HTML document. Nested #document data is inaccessible to the Schema App Highlighter. | |
| 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 a Physician has multiple telephone numbers for distinct scenarios, 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>Dr. Choi's office: <input type="tel"> 987-123-4567</input> </p> |
availableService | Utilize internal linking wherever possible! If the services mentioned have an entity home (i.e a Medical Service page), then ensure that entity’s URL is present. Consider how easily the various Test. Procedure, and Therapy entities can be programmatically isolated. For example contain all Test type info in a unique <div> rather than a series of undifferentiated <p> elements), in succession with Procedure and Therapies in their own unique HTML elements. | <p>Services offered by Dr. Singh include: : <ul><a href = "/service/blood_test"> Blood Tests</a></ul> </p> |
medicalSpecialty,Person multitype: | 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. | <p>Dr. LaCroix specializes in: <ul><a href = "/area/oncology"> Oncology</a></ul> <ul><a href = "/area/kidney"> Renal Systems</a></ul> </p><p>Dr. LaCroix has experience with: <ul>Cancer Research</ul> </p> |
hasCredential, hasCertificationPerson multitype: alumniOf, memberOf | Ideally, all entities targeted by the same property (e.g alumniOf, or hasCredential) should be contained within a single parent component. | <p>Dr. LaCroix studied at: <ul>New York Medical COllege</ul> </p><p>Dr. LaCroix is a member of: <ul>New York College of Physicians</ul> </p> |
review, aggregateRating | Reviews and Ratings on an Physician's profile page must be about the Physician themselves. 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> |
subjectOf~FAQPage | 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 |
US NPI | A unique 10-digit identification number issued to health care providers in the United States by the Centers for Medicare and Medicaid Services. |
Insurance Network ID | Use the name or unique ID of the Physician’s network. |
Name, Honorific, and Educational Suffixes
Content & Code Requirements
Consider how easily names, honorifics, and suffixes can be programmatically isolated (e.g can educational suffixes be contained in a uniquely identifiable HTML element like <p id = “hon”>MD</p>)
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