This Best Practices document is intended to support digital marketing teams in optimizing Google’s understanding of a specific MedicalCondition, particularly as it relates to your Organization. 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.
The Strategy section and Typical Page Content sections are best used during high-level design and brainstorming phases. The Content & Code sections for Medical Condition and MedicalWebPage are best used during the template development, coding, and markup authoring phases.
Medical Condition is not eligible for any direct Rich Results. If the content on the page is extensive, explore nested Article markup. Review the Structured Data Type Definitions section for up-to-date information regarding required and recommended properties for Article Rich Result eligibility.
TABLE OF CONTENTS
- Consider Page Intent, Nesting, Citations, and References when Authoring Content and Schema Markup
- List of Suggested Content for Pages About Medical Conditions
- MedicalCondition Schema.org Properties and Associated Page Requirements
- Medical WebPage Schema.org Properties and Associated Page Requirements
Consider Page Intent, Nesting, Citations, and References when Authoring Content and Schema Markup
Medical Condition pages focus on a particular condition affecting the human body and provide factual information about that particular condition (Signs & Symptoms, Risk Factors, Treatment Options). These pages may also include actionable real-world information (e.g. a list of Physicians who specialize in a particular condition). Use internal linking to clarify the relationship between a Medical Condition page and other content on your website!
To access all the desired properties, there are two equivalent strategies for describing the primary entity of a medical condition page:
MedicalCondition ~ subjectOf ~ MedicalWebPage
MedicalWebPage ~ about ~ MedicalCondition
High-quality, informational pages with references are an excellent way to improve the E-E-A-T signals. Consider including references or citations whenever relevant. Additionally, If your pages are reviewed or edited by a governing body, consider including that information on your website. Collaborate with your Customer Success manager to ensure this information is properly formatted, and accessible to the Highlighter.
List of Suggested Content for Pages About Medical Conditions
This section describes content commonly seen on a page about a medical condition. The section has been broken into lists that address the two key components of the MedicalWebPage:
- The condition itself (MedicalCondition) and
- The content that describes it (MedicalWebPage)
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 MedicalCondition and MedicalWebPage schema markup.
Note: To target or include a specific property, the associated content must be present in the HTML of your page.
MedicalCondition | MedicalWebPage or Article |
|
|
MedicalCondition 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 MedicalCondition 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 support@schemaapp.com.
Schema.org Property | Content and HTML Requirements | Example |
name | Ensure the name of the Medical Condition is easy to isolate. If the content of the page title varies, consider nesting the name of the Medical Condition in a <span>. | <h1>An Overview of <span>Retinal Detachment</span> and Treatment Options</h1> |
description | Ensure a brief description of the Medical Condition is included, ideally in a standardized way. | The first <p> element includes a <span> containing a brief definition of the condition. |
associatedAnatomy | If the condition is associated with a specific body part, AnatomicalStructure, or AnatomicalSystem, reference or define that anatomy. Existing metadata (e.g Breadcrumbs or Tags) may be helpful here. | A page about strokes could include the tags #brain, #cardiovascularsystem, and #neuromuscularsystem. |
possibleTreatment | Use internal linking wherever possible to reference MedicalTherapy entities associated with this MedicalCondition. Ideally, the MedicalTherapy should have an associated informational or service-related page. If you're authoring at scale, consider how easily MedicalTherapy entities can be programmatically isolated - this is a secondary benefit of internal linking! | <p>Possible therapies for Strokes include: <ul> <a href = "/services/physical_therapy"> Physical Therapy </a> </ul> |
possiblePrevention | Medical Condition has two opportunities to define preventative medical therapies:
Use internal linking wherever possible to reference MedicalTherapy entities associated with this MedicalCondition. Ideally, the MedicalTherapy should have an associated informational or service-related page. If you're authoring at scale, consider how easily MedicalTherapy entities can be programmatically isolated - this is a secondary benefit of internal linking! | <p>Possible therapies for T2 Diabetes include: <ul> <a href = "/info/nutrition"> A healthy balanced diet</a> </ul> |
riskFactor | This property expects a MedicalRiskFactor data item. Consider how easily unique risk factors can be programmatically isolated. For example, contain the name of each risk factor within a list element or a header. Avoid listing all risk factors in an undifferentiated block of text. If you're authoring at scale, consider how easily MedicalRiskFactor entities can be programmatically isolated - this is a secondary benefit of internal linking! | <p>Possible risks for heart attack include: <ul> <a href = "/info/smoking_cessation"> Smoking</a> </ul> </p> |
signorSymptom | This property expects the MedicalSignOrSymptom data item. If you're authoring at scale, consider how easily the MedicalSignOrSymptom entity can be programmatically isolated - this is a secondary benefit of internal linking! | <p>Possible symptoms of stroke include: <ul> <a href = "/condition/headache"> Sudden Severe Headache</a> </ul> </p> |
typicalTest | This property expects the MedicalTest data item. Consider how easily the MedicalTest entity can be programmatically isolated - this is a secondary benefit of internal linking! | <p>Possible tests for pregnancy include: <ul><a href = "/service/blood_test"> Blood Test </a></ul> </p> |
drug | This property expects the Drug data item. If you have a page on your website that discusses the entity, reference that. Otherwise, use entity linking to reference external standards (e.g. Wikidata). If you're authoring at scale, consider how easily the Drug entity can be programmatically isolated - this is a secondary benefit of internal linking! | <p>Medications for Type 1 Diabetes include: <ul><a href = "/treatments/insulin_program"> Insulin</a></ul> </p> |
relevantSpecialty | This property expects an enumeration member from the Schema.org list of Medical Specialty enumerations. Ideally, the language used on your site should match the language for enumeration members (we can omit spaces if necessary). Using non-visible metadata (e.g. CMS categories or tags) may be helpful here. If you have a page on your website that discusses the entity, you can also reference that URL. You may want to discuss this further with your CSM. | <p>Dr.Nguyen's specialties include: <ul><a href = "/service/pediatric_care"> Pediatrics</a></ul> </p> |
Other Properties Available to Medical Condition
MedicalCondition has other properties available to it, that may be less common as they may not make sense to include in your page content. Many of the same best practices referenced above are relevant to these properties. If you have any questions, contact support@schemaapp.com or your CSM.
Medical WebPage 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 MedicalWebPage. 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 support@schemaapp.com.
Schema.org Property | Content and HTML Requirements | Example |
articleBody | Ideally, we want all entities targeted by the articleBody property to be contained within a single parent component. | <div id = "contentBody"> <p>Article description </p> <h2>Subheader</h2> <ol>List Content</ol> </div> |
author, editor, publisher | Author content on an Article page should ideally include a name and a URL to an author’s bio page or social media profile(s). Additional content (a bio or a profile picture) is useful but not necessary. We recommend you create a standalone profile page for each author. If an article has more than one author, each author will ideally have their own HTML element If an article has an author and an editor, they should either have some element to differentiate them or a very consistent ordering. If the author is not a Person but instead an Organization, you can attribute authorship to that Organization. | Recommended Structure for multiple authors: <p id = “author”>Martha van Berkel</p> <p id = "author"> Mark van Berkel </p> Recommended Structure for Author and Editor data: <p id = "author"> Mark van Berkel</p> <p id = “editor”>Jasmine Drudge-Wilson</p> |
citation | Citations should follow a standardized format across articles. Ideally, citations should include a URL. If you are targeting content with the Highlighter, citations should be contained within a uniquely identifiable HTML element | <div id = “citation”> <a href = "https://www.who.int/"> World Health Organization<a/> </div> |
datePublished, timeRequired | Date information in structured data should follow the ISO 8601 format. Consider a human-readable format (e.g. 4 minutes) with a hidden ISO 8601 attribute. | <div content ="PT4M"> <p>Reading Time: 4 minutes"<p/> </div> |
image | Google requires that images have an accessible image address, to be indexed and displayed in search. | |
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> |
review, aggregateRating | Reviews and Ratings on an Article must be about the Article 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> |
video | Embed URL should be accessible within the HTML document. Nested #document data is inaccessible to the Schema App Highlighter. Special attention is required for Brightcove embed URLs. | <video embed-url= "https://youtu.be/dQw4w9WgXcQ?si=k0zOC1HL563FUkL6"> <a> Click Here To Start </a> </video> |
If you have follow-up questions, please reach out to us at support@schemaapp.com.
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