Medical Schema Markup for Healthcare Webmasters: JSON-LD Guide

Add schema.org Medical types in JSON-LD to your condition, provider, and service pages now. That single technical step increases the probability that AI retrieval systems and search engines select your pages as credible sources. The priority types to implement first are MedicalWebPage, MedicalCondition, MedicalOrganization, Physician, Drug, MedicalProcedure, and FAQPage. According to practical implementation guidance from Rankeo, isAcceptingNewPatients is one of the most impactful individual properties for AI-driven recommendations on provider pages.

Every page you mark up should include, at minimum:

• @context, @type, and name on every entity
• @id as a stable URL for organizations and physicians (enables graph linking)
• medicalSpecialty on provider and condition pages
• isAcceptingNewPatients (boolean) on physician and organization profiles
• signOrSymptom and possibleTreatment on condition pages
• datePublished and author with hasCredential on all health content pages

Use JSON-LD as your format. It keeps markup out of the HTML body, works cleanly with CMS templates, and is the format Google explicitly recommends for structured data. After you deploy, validate every page with Google’s Rich Results Test, Schema Markup Validator, and Google Search Console’s Enhancements reports.

Key Takeaways

Properly implemented medical schema markup, starting with MedicalOrganization, Physician, MedicalCondition, and FAQPage in JSON-LD, is the most direct technical step a healthcare webmaster can take to improve AI citation likelihood and search visibility.

What medical schema markup actually covers

The term “medical schema markup” refers to the structured data vocabulary defined under schema.org’s Health and Medical types documentation. The vocabulary gives web publishers a shared language to describe clinical entities — conditions, drugs, procedures, providers, and organizations — in a way that search engines and AI systems can parse without ambiguity.

One boundary matters enormously for anyone implementing this: the schema is designed for web content discovery, not clinical data exchange or automated clinical reasoning. You are telling a search engine what a page is about, not encoding a patient record or a clinical decision tree.

“The motivation for this work is to make it easier for people to find the right web pages, not to replace existing clinical standards or health information exchanges.”
Health and medical types, Schema.org

The vocabulary supports three broad content audiences, and you can signal which one a page targets:

• Patients and caregivers — condition overviews, symptom guides, appointment booking pages
• Clinicians — procedure references, drug monographs, clinical guidelines
• Researchers — scholarly articles, trial summaries, evidence reviews

The audience property on MedicalWebPage lets you declare this explicitly. The aspect property lets you specify what dimension of a topic the page covers (symptoms, diagnosis, treatment, prognosis). These two properties alone improve how AI systems categorize and retrieve your content.

The parent type for all health entities is MedicalEntity. Every subtype — MedicalCondition, Drug, MedicalProcedure, MedicalOrganization, and others — inherits its core properties, including code (for controlled vocabulary references), guideline, recognizingAuthority, and relevantSpecialty.

Which schema types map to which healthcare page types

The table below maps common healthcare page types to their recommended schema.org types and the minimum properties that make each implementation useful.

A few prioritization notes worth making explicit:

• Provider homepage and physician profiles deliver the fastest ROI. AI assistants answer “find a cardiologist near me” queries constantly, and isAcceptingNewPatients is one of the properties that directly influences whether your provider appears in those answers.
• Top condition pages come second. These are your highest-traffic informational pages, and pairing MedicalWebPage with MedicalCondition gives AI systems two layers of context.
• Appointment and contact pages benefit from MedicalOrganization with availableService and openingHoursSpecification.
• Use MedicalWebPage alone when a page discusses a health topic broadly but does not describe a single discrete condition, drug, or procedure.

Copy-ready JSON-LD examples for common healthcare pages

The snippets below are ready to adapt. Replace every value in angle brackets with your real data, then validate before deploying.

MedicalWebPage + MedicalCondition (condition overview page)

{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "MedicalWebPage",
      "@id": "https://example.com/conditions/type-2-diabetes#webpage",
      "name": "Type 2 Diabetes: Symptoms, Causes, and Treatment",
      "url": "https://example.com/conditions/type-2-diabetes",
      "datePublished": "2024-03-01",
      "dateModified": "2025-11-15",
      "author": {
        "@type": "Person",
        "name": "<Author Full Name>",
        "hasCredential": {
          "@type": "EducationalOccupationalCredential",
          "credentialCategory": "MD"
        }
      },
      "audience": {
        "@type": "MedicalAudience",
        "audienceType": "Patient"
      },
      "about": { "@id": "https://example.com/conditions/type-2-diabetes#condition" }
    },
    {
      "@type": "MedicalCondition",
      "@id": "https://example.com/conditions/type-2-diabetes#condition",
      "name": "Type 2 Diabetes",
      "alternateName": ["Diabetes mellitus type 2", "T2DM"],
      "signOrSymptom": [
        { "@type": "MedicalSymptom", "name": "Increased thirst" },
        { "@type": "MedicalSymptom", "name": "Frequent urination" },
        { "@type": "MedicalSymptom", "name": "Fatigue" }
      ],
      "possibleTreatment": [
        { "@type": "Drug", "name": "Metformin" },
        { "@type": "MedicalTherapy", "name": "Lifestyle modification" }
      ],
      "relevantSpecialty": "Endocrinology",
      "code": {
        "@type": "MedicalCode",
        "code": "E11",
        "codingSystem": "ICD-10"
      }
    }
  ]
}

Fields to replace: page URL, author name and credential, datePublished, dateModified, condition name, symptoms, treatments, and ICD code.

MedicalOrganization (clinic or practice homepage)

{
  "@context": "https://schema.org",
  "@type": "MedicalOrganization",
  "@id": "https://example.com/#organization",
  "name": "<Practice Name>",
  "url": "https://example.com",
  "telephone": "<+1-555-000-0000>",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "<123 Main Street>",
    "addressLocality": "<City>",
    "addressRegion": "<State>",
    "postalCode": "<00000>",
    "addressCountry": "US"
  },
  "medicalSpecialty": "<Cardiology>",
  "isAcceptingNewPatients": true,
  "availableService": {
    "@type": "MedicalTherapy",
    "name": "<Cardiac Stress Testing>"
  }
}

Physician profile page

{
  "@context": "https://schema.org",
  "@type": "Physician",
  "@id": "https://example.com/doctors/jane-smith-md#physician",
  "name": "Jane Smith, MD",
  "medicalSpecialty": "Cardiology",
  "hasCredential": {
    "@type": "EducationalOccupationalCredential",
    "credentialCategory": "MD",
    "recognizedBy": {
      "@type": "Organization",
      "name": "American Board of Internal Medicine"
    }
  },
  "worksFor": { "@id": "https://example.com/#organization" },
  "isAcceptingNewPatients": true,
  "availableService": [
    { "@type": "MedicalTherapy", "name": "Echocardiography" },
    { "@type": "MedicalTherapy", "name": "Holter Monitoring" }
  ],
  "telephone": "<+1-555-000-0001>",
  "url": "https://example.com/doctors/jane-smith-md"
}

Notice that worksFor references the organization’s @id rather than duplicating its address data. That graph link is what allows AI systems to understand the relationship between the physician and the practice.

MedicalProcedure page

{
  "@context": "https://schema.org",
  "@type": "MedicalProcedure",
  "name": "Coronary Angiography",
  "procedureType": "Noninvasive",
  "bodyLocation": "Heart",
  "preparation": "Fasting for 4–6 hours before the procedure.",
  "followup": "Avoid strenuous activity for 24 hours post-procedure.",
  "relevantSpecialty": "Cardiology",
  "code": {
    "@type": "MedicalCode",
    "code": "75574",
    "codingSystem": "CPT"
  }
}

Drug page

{
  "@context": "https://schema.org",
  "@type": "Drug",
  "name": "Metformin",
  "alternateName": ["Glucophage", "Fortamet"],
  "activeIngredient": "Metformin hydrochloride",
  "administrationRoute": "Oral",
  "prescriptionStatus": "PrescriptionOnly",
  "relevantSpecialty": "Endocrinology",
  "code": {
    "@type": "MedicalCode",
    "code": "6809",
    "codingSystem": "RxNorm"
  }
}

FAQPage (patient FAQ section)

{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "What are the early signs of Type 2 Diabetes?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Early signs include increased thirst, frequent urination, unexplained fatigue, and blurred vision. A fasting blood glucose test can confirm a diagnosis."
      }
    },
    {
      "@type": "Question",
      "name": "Is Type 2 Diabetes reversible?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Type 2 Diabetes can go into remission with sustained weight loss and lifestyle changes, though it requires ongoing monitoring."
      }
    }
  ]
}

Pro Tip: Inject JSON-LD server-side, inside a <script type="application/ld+json"> tag in the <head>. Client-side injection via JavaScript means crawlers and AI retrieval systems may never see it — server-side rendering is the decisive technical factor for whether a provider page gets cited by AI assistants.

One firm rule across all snippets: never assert clinical efficacy or safety claims in structured data properties that your page body cannot substantiate with sourced, attributed content. The markup describes what the page says — it does not replace the editorial and clinical review that makes the claim credible.

How to model entity relationships and reference controlled vocabularies

The @id pattern is the backbone of a well-structured medical knowledge graph on your site. When a Physician entity references "worksFor": { "@id": "https://example.com/#organization" }, you are not just adding a field — you are telling AI retrieval systems that these two entities are connected, which strengthens confidence in both.

The code property on MedicalEntity is where controlled vocabularies enter the picture. It accepts a MedicalCode object with two fields: code (the identifier string) and codingSystem (the vocabulary name). Common systems to reference:

• ICD-10 / ICD-11 — for conditions and diagnoses (e.g., "code": "E11", "codingSystem": "ICD-10")
• SNOMED CT — for clinical concepts with finer granularity than ICD
• RxNorm — for drugs and medications (e.g., "code": "6809", "codingSystem": "RxNorm")
• MeSH — for research-oriented content and scholarly articles
• CPT — for procedure codes on clinical service pages

When to include code values versus plain text depends on your audience and publishing risk. Patient-facing condition overview pages benefit from ICD codes because they signal precision to AI systems without confusing readers (the code sits in JSON-LD, not visible text). Drug pages should always carry RxNorm codes. Procedure pages for clinician audiences warrant CPT codes. For general wellness content with no discrete clinical entity, plain text is acceptable.

Common pitfalls when linking entities:

• Broken @id references — the URL in @id must resolve or at least be stable and consistent across all pages that reference it. A physician’s @id on their profile page must exactly match the string used in worksFor on every other page.
• Circular graph references — avoid having MedicalCondition A list MedicalCondition B as a possibleTreatment, which then lists A as a signOrSymptom. Crawlers can handle it, but it creates confusing entity signals.
• Inconsistent @id formats — mixing http:// and https://, or trailing slashes versus no trailing slashes, creates duplicate entity nodes in search engine graphs.
• Omitting @id on organizations entirely — without it, physician worksFor references have nothing to anchor to, and the relationship is lost.

Pro Tip: Maintain a single @id registry document (a simple spreadsheet or CMS field) that lists every canonical entity URL for your organizations, physicians, and major conditions. Every developer and content editor references it before writing new JSON-LD. This prevents the broken-reference problem at scale.

YMYL safeguards and E-E-A-T signals in healthcare structured data

Medical content sits squarely in Google’s Your Money or Your Life (YMYL) category, which means the trust signals you embed in structured data carry real weight. The direct answer: include credentials, authorship, and sourcing in your markup, but never assert unverified clinical outcomes in schema properties.

The trust signals to mark up on every health content page:

• author with @type: Person, full name, and hasCredential listing the relevant degree or board certification
• recognizingAuthority on MedicalCondition and Drug entities (e.g., the FDA, a medical board, or a professional society)
• datePublished and dateModified — AI systems weight recency, and outdated health content is a trust liability
• citation or isBasedOn pointing to published guidelines or peer-reviewed sources in the page body (not only in JSON-LD)
• medicalSpecialty to signal that the content is within a defined clinical domain

The editorial review checklist before publishing schema on any medical page:

• [ ] Does every clinical claim in JSON-LD properties appear verbatim or equivalently in the visible page body?
• [ ] Is the author identified by name, credential, and specialty — both in the page body and in structured data?
• [ ] Does the page cite a published guideline, peer-reviewed source, or recognized authority for its core claims?
• [ ] Are datePublished and dateModified accurate and current?
• [ ] Has a clinician or qualified reviewer approved the content before the schema went live?

The healthcare SEO guidance from DexCare makes a point worth repeating: structured provider pages with accurate credentials and availability status are what AI platforms treat as high-value signals when answering health queries. Inaccurate data — a physician listed as accepting new patients when they are not — damages trust with real patients and undermines the credibility signals you are trying to build.

For more on how structured data for doctors fits into a broader SEO strategy, the SEO for Medical Professionals guide covers the full picture.

How to test, validate, and roll out schema at scale

A staged rollout prevents a bad template from propagating across thousands of pages before you catch the error.

1. Build and validate in staging. Write your JSON-LD template, inject it on a staging page, and run it through Google’s Rich Results Test. Fix every error and warning before touching production.
2. Cross-validate with Schema Markup Validator. The Schema Markup Validator at validator.schema.org catches property-type mismatches and invalid enumeration values that the Rich Results Test sometimes passes.
3. Deploy to a sample set. Push the template to 5–10 representative pages in production — one physician profile, one condition page, one FAQ page. Monitor for crawl errors in Search Console’s Coverage report within 48–72 hours.
4. Check Enhancements reports in Search Console. Once Google processes the pages, the Enhancements tab shows which pages are eligible for rich results and flags any remaining issues.
5. Scale to full site. After the sample set is clean, roll out via CMS template or server-side generation to all pages of that type. Use a deployment checklist that includes a post-deploy validation run for at least 10% of pages.
6. Set up log-based monitoring. Track crawl frequency on structured-data pages using server logs or a log analysis tool. A drop in crawl rate after a template change is an early warning that something broke.
7. Automate JSON-LD generation for dynamic data. Provider availability (isAcceptingNewPatients) and credentials change. Build your CMS or EHR integration to regenerate JSON-LD automatically when those fields update, rather than relying on manual edits.

Tools to keep bookmarked:

• Google Rich Results Test — primary validation for rich result eligibility
• Schema Markup Validator — property-level validation against the full schema.org spec
• Google Search Console Coverage and Enhancements reports — production monitoring
• Server log analyzers (Screaming Frog Log File Analyser, Splunk, or similar) — crawl behavior monitoring

Pro Tip: For large hospital networks or multi-location practices, version-control your JSON-LD templates in the same repository as your front-end code. When a schema.org property is deprecated or a new required field is added, you can update the template once and deploy across all pages in a single release.

Common mistakes that break rich results and how to fix them

Most structured data failures fall into a short list of repeating patterns. Knowing them saves hours of troubleshooting.

Frequent issues and their fixes:

• Mismatched visible content and JSON-LD — the physician’s name in JSON-LD differs from the name displayed on the page. Fix: treat the visible page as the source of truth; JSON-LD must reflect it exactly.
• Broken @id references — worksFor points to an @id that does not exist on any page. Fix: audit all @id values against your entity registry and correct mismatches.
• Missing required properties — FAQPage without acceptedAnswer, or MedicalCondition without name. Fix: run Schema Markup Validator and address every “missing required property” error before deploying.
• Invalid enumeration values for medicalSpecialty — using “Cardiology” when the spec expects a MedicalSpecialty URL like https://schema.org/Cardiovascular. Fix: reference the schema.org enumeration list for medicalSpecialty and use the correct value.
• Client-side-only JSON-LD — markup injected via JavaScript after page load is invisible to most crawlers. Fix: move JSON-LD to a server-rendered <script> tag in <head>.
• Stale isAcceptingNewPatients values — a physician retired or closed their panel, but the boolean is still true. Fix: connect this field to your practice management system so it updates automatically.

Troubleshooting checklist when a page fails the Rich Results Test:

1. Confirm the JSON-LD is present in the raw HTML source (not just in the browser-rendered DOM).
2. Check for JSON syntax errors — a missing comma or unclosed bracket invalidates the entire block.
3. Verify that all required properties for the @type are present.
4. Confirm @id values are consistent with other pages in the graph.
5. Re-run Schema Markup Validator for property-type errors the Rich Results Test does not surface.

Multilingual and multiregional considerations:

For healthcare sites serving multiple languages, each language version of a page needs its own JSON-LD with name, description, and other text properties in that language. Use hreflang tags for canonicalization alongside your structured data. The @id for the same entity (a physician, a condition) should remain consistent across language versions — only the text properties change. Never use the same @id URL for two different language pages; use the canonical URL as the @id and let hreflang handle the language mapping.

What to expect after implementing healthcare structured data

Healthcare schema markup makes clinical content machine-readable for AI systems, which improves performance at two distinct stages. During retrieval, search engines and AI systems use structured entity properties to identify your page as a credible match for a specific query. During generation, AI systems use the structured attributes — specialty, credentials, accepting status — to compose accurate answers. Pages without this markup compete on text alone; pages with it compete on both text and entity signals.

Practical metrics to monitor after rollout:

• Organic impressions and clicks in Google Search Console, segmented by page type (condition pages, provider pages)
• Rich result eligibility in the Enhancements report — an increase here confirms Google is reading your markup correctly
• Knowledge panel appearances for your organization and key physicians
• AI citation mentions — track branded queries in Search Console and monitor whether AI assistants surface your providers when answering local specialty queries
• isAcceptingNewPatients impact — watch for changes in appointment-related query impressions after toggling this boolean on provider profiles

Timeframes vary. Rich result eligibility typically appears in Search Console within two to four weeks of a clean deployment. Organic impression changes for condition pages take longer — often two to three months — because they depend on recrawling and reindexing at scale. AI citation patterns are harder to measure directly but tend to correlate with improvements in branded and specialty-specific query impressions.

The SEO advantages for healthcare practices extend well beyond rich snippets. Structured data is the foundation that makes every other SEO investment — content, link building, local optimization — more legible to the systems that decide what gets cited.

Practical audit and rollout checklist for SEO teams

A repeatable process matters more than a perfect first implementation. Here is the playbook.

Audit phase:

1. Crawl the site with Screaming Frog or a similar tool and export all URLs by template type (condition pages, physician profiles, service pages, FAQs).
2. For each template type, score priority by traffic volume and query intent (informational condition pages and physician profiles rank highest).
3. Identify which pages already have structured data and audit it for errors using Schema Markup Validator.
4. Document the gap: pages with no markup, pages with incorrect markup, and pages with outdated property values.

Implementation phase:

1. Content team creates or updates page-level data fields (author credential, specialty, accepting status, ICD/RxNorm codes) in the CMS.
2. Development team builds JSON-LD templates using @graph patterns so multiple entity types on one page share a single script block.
3. QA team validates a sample of generated pages in staging using both Rich Results Test and Schema Markup Validator.
4. Staged production rollout: physician profiles first, then condition pages, then procedure and drug pages, then FAQs.
5. Post-deploy: run a full crawl of the new pages and verify JSON-LD is present in raw HTML source.

Roles and responsibilities:

• Content owner — maintains credential data, specialty listings, and accepting-status fields; reviews clinical claims before schema deployment
• Development owner — builds and maintains JSON-LD templates, manages @id registry, handles CMS integration for dynamic fields
• QA / SEO owner — runs validation tools, monitors Search Console Enhancements, flags errors and regressions

Update cadence: Review physician availability and credential data quarterly at minimum. Condition and procedure pages should be reviewed annually against current clinical guidelines. Any time a physician joins or leaves the practice, trigger an immediate update to their profile and the organization’s availableService list.

Pro Tip: Link your structured data to human-readable proof stored on your own site — a physician’s CV page, a publications list, a board certification verification link. AI systems and Google’s quality raters both follow these signals. Schema that points to verifiable, on-site evidence carries more weight than schema that asserts credentials with nothing to back them up.

For hospital networks managing dozens of locations, the SEO for hospitals guide covers multi-location rollout patterns that pair well with the @graph approach above.

Why schema alone will not save a weak healthcare site

The most common mistake I see teams make is treating medical schema markup as a shortcut. They add JSON-LD to thin, unreviewed condition pages and expect AI citation to follow. It does not work that way.

Schema markup amplifies what your content already is. A condition page written by a board-certified physician, citing published guidelines, with a clear author byline and a current review date — that page gets a meaningful lift from structured data. A thin, uncredentialed page with the same JSON-LD gets flagged by quality systems, not elevated by them. The markup is a signal multiplier, not a signal creator.

The other underappreciated reality: isAcceptingNewPatients is one of the highest-leverage single properties in the entire medical vocabulary for practices that want AI visibility. AI assistants answering “find a rheumatologist accepting new patients in [city]” are explicitly filtering on this boolean. If your provider pages do not include it, you are invisible to that query class regardless of how well the rest of your markup is structured.

My honest recommendation for teams with limited bandwidth: do the physician profiles and the top five condition pages first, do them correctly, and validate them before moving on. A small set of accurate, well-structured pages outperforms a large set of hastily marked-up ones every time. Schema markup for healthcare is a long-term infrastructure investment, not a one-time task — and the teams that treat it that way are the ones whose pages show up when patients are looking for care.

Toddstager’s healthcare SEO and schema implementation services

Implementing medical schema markup correctly across a healthcare site takes more than copying snippets. It requires an audit to identify gaps, templates built for your CMS, a staged rollout process, and ongoing monitoring as providers join, leave, or change their availability.

Toddstager’s SEO for Medical Professionals service covers the full cycle: structured data audit, JSON-LD template development, YMYL-safe content review, and Search Console monitoring. Every engagement follows a process designed to protect provider data and keep markup current as your practice evolves. If you are managing a hospital network or a multi-specialty group, the same process scales to multi-location rollouts with consistent @id graph patterns across all sites. To get started with a schema audit for your healthcare site, contact Toddstager directly through the medical SEO services page.

Sources

Use these resources throughout your implementation and ongoing maintenance:

• Schema
• GEO for Healthcare Websites: A Practical Guide – DexCare

This article is general information, not a substitute for advice from a qualified doctor. Consult a qualified healthcare professional about your own circumstances before acting on anything here.

Recommended

• What Is Schema Markup and How It Affects SEO
• SEO for Medical Professionals – Todd Stager
• SEO Advantages for Healthcare Practices in 2026
• SEO for Hospitals Guide: Drive Patient Growth in 2026