Medical Schema Markup: MedicalOrganization, Physician, FAQPage

Medical schema markup is JSON-LD code that describes a healthcare page to search engines: which practice, which provider, which specialty. Core types are MedicalOrganization for the practice, IndividualPhysician for providers, and FAQPage for patient questions. It makes pages eligible for supported rich results and helps machines resolve your entities correctly.

TL;DR

• Three types cover most healthcare sites: MedicalOrganization for the practice, IndividualPhysician for each provider, FAQPage for patient questions.
• Physician is an organization type in schema.org, not a person type, and Person carries none of the medical properties you need [3].
• FAQ rich results stopped appearing in Google Search on May 7, 2026, for every site including health sites [1].
• Google states that structured data is not required for generative AI search and that no special markup exists for it [2].
• @id references, not duplicated objects, are what turn separate nodes into one entity graph.
• Validate with two tools: the Schema Markup Validator for vocabulary, the Rich Results Test for Google eligibility.

One-liner: Correct types and clean entity links outlast every rich result Google retires.

Key Numbers

What Medical Schema Markup Does in 2026 (and What It Stopped Doing)

In short: Schema markup makes your pages machine-readable and eligible for supported rich results. It is not a switch that puts a practice into AI Overviews, and two of the types healthcare sites lean on hardest no longer produce any Google rich result at all.

Medical schema markup is JSON-LD code that tells search engines what a healthcare page describes: which practice, which provider, which specialty. It makes pages eligible for supported rich results and helps machines resolve your entities correctly. It does not place your content in AI Overviews.

That second sentence contradicts most of what ranks for this query, so here are the dates behind it.

The AI question has a documented answer too. Google’s guide to optimizing for generative AI features states that structured data is not required for generative AI search and that no special schema.org markup exists for it, while still recommending markup as part of an overall SEO strategy because it supports rich-result eligibility [2]. Pages promising that schema feeds AI assistants are selling a mechanism Google says it does not use.

The same guide names the gate that actually governs AI visibility: a page has to be indexed and eligible to appear with a snippet, and the site has to be included in Search generative AI features in Search Console [2]. Markup sits downstream of both. For the wider picture on how healthcare sites earn AI citations, see our guide to generative engine optimization for healthcare.

So why bother? Because entity clarity survives every rich-result deprecation. Correct types tell Google which of the four Dr. Chens in your metro area wrote the page, which clinic employs her, and what she treats. That work compounds. It is also uncrowded: IndividualPhysician, the type built for exactly this, appears on somewhere between 1,000 and 10,000 domains as of July 2026 [3].

The Four Things to Collect Before Adding Medical Schema Markup

In short: Gather verified practice data, provider NPIs, a canonical URL per entity, and the visible page content each node will mirror. Then decide where the code lives before you write any of it.

Collect these four first:

1. Verified NAP and hours, matched three ways. Name, address, phone, and opening hours have to agree across the visible page, your structured data, and your Google Business Profile. When those three disagree, search engines lose confidence in all of them rather than picking a winner. Audit all three before you write the markup, not after.
2. Provider roster with NPIs and specialties. Every physician has a ten-digit National Provider Identifier issued by the Centers for Medicare and Medicaid Services, and the registry is public and free to search [3].
3. One canonical URL per entity. The practice, each provider, each location. These become your @id values in Step 5, so decide them now rather than retrofitting.
4. The visible content each node will describe. Mark up only what a patient can see on the page. This rule governs every step that follows, and breaking it is the most common finding in a medical schema audit.

Two notes that prevent errors downstream. The medicalSpecialty property expects a value from schema.org’s MedicalSpecialty enumeration, so PrimaryCare resolves and “family medicine practice” does not [3]. And usNPI takes the raw ten-digit number with no formatting [3].

Then pick a placement method:

Keep two tools open throughout: the Rich Results Test for Google eligibility, and the Schema Markup Validator for vocabulary correctness [4]. They answer different questions, which matters in the validation step.

Step 1: Choose Between MedicalOrganization, MedicalBusiness, and Physician

In short: Pick the most specific type that accurately describes what the page is about, then let inheritance supply the rest. For most healthcare sites that means MedicalOrganization or one of its subtypes on the practice pages and IndividualPhysician on provider bios.

Two distinctions decide most of these.

MedicalBusiness or MedicalOrganization. MedicalBusiness descends from LocalBusiness and carries physical-location properties like opening hours and geo coordinates. MedicalOrganization descends from Organization and assumes no physical place. Several types, including MedicalClinic, inherit from both, which is why a clinic page can hold hours and organization properties at once [3]. If the page describes a place patients visit, favor the type that inherits from LocalBusiness.

Physician is not a person. This is where most implementations break. In schema.org, Physician is a subtype of MedicalOrganization, and IndividualPhysician inherits from Organization and Place [3]. Neither descends from Person. The type was redefined in schema.org v24 precisely because “Physician” kept getting applied to individuals when it described an office, so IndividualPhysician and PhysiciansOffice were added to separate the two readings [5].

The practical consequence:

Wrong:  "@type": "Person",  "medicalSpecialty": "Cardiology"
  Right:  "@type": "IndividualPhysician",  "medicalSpecialty": "Cardiology"

Person has no medicalSpecialty, no usNPI, no hospitalAffiliation, and no practicesAt. A validator will pass that node without complaint, because nothing is malformed. It simply carries none of the medical meaning you were trying to express.

Service and condition pages have their own types. MedicalProcedure describes a treatment you perform, MedicalCondition describes something you treat, and both carry clinical properties that no generic type offers: procedureType, bodyLocation, and preparation on the first, signOrSymptom, riskFactor, and possibleTreatment on the second [3].

The value shows up when you link them. A condition page pointing possibleTreatment at a procedure, and a procedure page pointing back at the conditions it addresses, describes your clinical scope as a connected graph rather than a set of unrelated pages. Build these after the practice and provider nodes are stable, since they depend on the same @id discipline.

Get the type right and the properties you need are already there. Get it wrong and you have valid code that says nothing.

Step 2: Mark Up the Practice with MedicalOrganization

In short: Build one node for the practice, give it a stable @id on your canonical URL, and fill the properties that answer real patient questions. MedicalClinic is the usual working choice because it inherits from both the Organization and LocalBusiness branches.

{
    "@context": "https://schema.org",
    "@type": "MedicalClinic",
    "@id": "https://www.yourpractice.com/#organization",
    "name": "Your Practice Name",
    "url": "https://www.yourpractice.com/",
    "telephone": "+15551234567",
    "image": "https://www.yourpractice.com/images/exterior.jpg",
    "address": {
      "@type": "PostalAddress",
      "streetAddress": "100 Main Street, Suite 200",
      "addressLocality": "Your City",
      "addressRegion": "TX",
      "postalCode": "75001",
      "addressCountry": "US"
    },
    "geo": {
      "@type": "GeoCoordinates",
      "latitude": 32.386,
      "longitude": -96.848
    },
    "medicalSpecialty": "https://schema.org/PrimaryCare",
    "isAcceptingNewPatients": true,
    "healthPlanNetworkId": "Blue Cross Blue Shield PPO",
    "areaServed": "Your County, TX",
    "openingHoursSpecification": [{
      "@type": "OpeningHoursSpecification",
      "dayOfWeek": ["Monday", "Tuesday", "Wednesday", "Thursday", "Friday"],
      "opens": "08:00",
      "closes": "17:00"
    }],
    "sameAs": [
      "https://www.google.com/maps/place/your-practice-listing",
      "https://www.healthgrades.com/group/your-practice"
    ]
  }

Four properties do most of the work.

A few rules that keep this node clean. medicalSpecialty takes a value from schema.org’s MedicalSpecialty enumeration, so PrimaryCare resolves and “family medicine practice” does not [3]. Every value here has to match what a patient can see on the page and what sits in your Google Business Profile, since conflicting signals are worse than missing ones [4]. And set @id as a hash fragment on the canonical URL, which is the convention Google’s own examples follow [1].

Large facilities have a hierarchy worth expressing. A Hospital node can nest other medical organizations through the department property, each with its own openingHoursSpecification [3]. That matters when the emergency department runs around the clock and the pharmacy closes at six. One set of hours on the parent building sends patients to a locked door.

Multi-location practices build one node per location, each with its own @id, address, and hours. Join them with parentOrganization pointing at the practice-level entity, so the graph describes a group with branches instead of a set of unrelated clinics that share a name.

Set the @id pattern before you build the first one. A predictable path such as https://www.yourpractice.com/locations/northside/#organization scales cleanly. Ad hoc identifiers do not, and renaming them later breaks every reference that points at them.

Doing that across a dozen sites is most of what a healthcare SEO services engagement handles at the technical layer.

Step 3: Physician Schema, Using IndividualPhysician Correctly

In short: Give each provider their own IndividualPhysician node, identify them with usNPI, and connect them to the practice with practicesAt. That last property is the one almost nobody uses, and it is what turns two isolated nodes into a graph.

{
    "@context": "https://schema.org",
    "@type": "IndividualPhysician",
    "@id": "https://www.yourpractice.com/providers/jane-doe/#physician",
    "name": "Jane Doe, MD",
    "honorificSuffix": "MD",
    "url": "https://www.yourpractice.com/providers/jane-doe/",
    "image": "https://www.yourpractice.com/images/jane-doe.jpg",
    "telephone": "+15551234567",
    "medicalSpecialty": "https://schema.org/PrimaryCare",
    "usNPI": "1234567890",
    "occupationalCategory": "29-1215.00",
    "practicesAt": {
      "@id": "https://www.yourpractice.com/#organization"
    },
    "hospitalAffiliation": {
      "@type": "Hospital",
      "name": "Regional Medical Center",
      "url": "https://www.regionalmedical.example/"
    },
    "hasCredential": {
      "@type": "Credential",
      "name": "Board Certified in Family Medicine"
    },
    "sameAs": [
      "https://www.healthgrades.com/physician/dr-jane-doe",
      "https://www.doximity.com/pub/jane-doe-md"
    ]
  }

Three properties deserve attention.

practicesAt points an individual practitioner at the MedicalOrganization where they work, and it exists only on IndividualPhysician [3]. Note the value: an @id reference to the exact string from Step 2, not a repeated copy of the practice node. Repeating creates two practices where you meant one.

usNPI is the strongest disambiguator available. Ten digits, one provider, one federal registry [3]. No other property in the vocabulary identifies a physician that precisely, which matters when three doctors in your county share a surname.

hospitalAffiliation expects a Hospital specifically, while practicesAt accepts any MedicalOrganization [3]. Admitting privileges go in the first, day-to-day practice locations in the second.

Watch for properties that do not belong here. Several published property tables list alumniOf and worksFor under Physician. Both are Person properties, and IndividualPhysician descends from Organization, so neither exists on it [3]. Use practicesAt for employment and hasCredential for training instead.

Person is not banned, it is scoped. Use it where the provider genuinely acts as a person: as the author of an article they wrote, or nested under the practice’s employee property. When a physician writes a blog post or a condition explainer, that page gets its own Article or MedicalWebPage node with the provider as author, referenced by @id to their IndividualPhysician node. The provider stays one entity across the site, appearing as an organization on their bio page and as an author on the content they wrote. Keeping those roles separate is the kind of entity clarity that AI search actually rewards, which we cover in AI search optimization for healthcare.

Multi-provider practices repeat this node once per physician, every one pointing practicesAt at the same practice @id.

Step 4: FAQPage Schema After Google Dropped the Rich Result

In short: FAQPage markup no longer produces a Google rich result for anyone, including health sites. It is still valid vocabulary that other systems parse, Google says leaving it in place causes no problems, and the implementation has not changed.

{
    "@context": "https://schema.org",
    "@type": "FAQPage",
    "@id": "https://www.yourpractice.com/patient-questions/#faq",
    "mainEntity": [
      {
        "@type": "Question",
        "name": "Do you accept new patients?",
        "acceptedAnswer": {
          "@type": "Answer",
          "text": "Yes. We accept new patients at all three locations and can usually schedule a first visit within two weeks."
        }
      },
      {
        "@type": "Question",
        "name": "Which insurance plans do you take?",
        "acceptedAnswer": {
          "@type": "Answer",
          "text": "We are in network with Blue Cross Blue Shield PPO, Aetna, Cigna, and Medicare. Call the front desk to confirm your specific plan."
        }
      },
      {
        "@type": "Question",
        "name": "Do I need a referral to schedule an appointment?",
        "acceptedAnswer": {
          "@type": "Answer",
          "text": "No referral is needed for primary care visits. Some specialist visits require one depending on your plan."
        }
      }
    ]
  }

The timeline in the opening section covers the dates. The practical version: no site, in any vertical, gets the expandable FAQ dropdown from Google anymore [1].

So why is this block still here? Three reasons. FAQPage remains valid schema.org vocabulary, unchanged by anything Google did to its own display feature. Other crawlers and answer engines still parse it. And Google’s own guidance says unused structured data causes no problems for Search, with no need to remove it proactively [1].

That last point is the instruction most practices need right now. If you already have FAQPage markup, leave it alone. Stripping it out spends developer hours to gain nothing.

Two implementation rules still apply, and the first matters more now than it did. Every acceptedAnswer string has to match the visible answer on the page word for word. No rich result masks a mismatch anymore, so a drifted answer is pure liability. And QAPage is not a substitute here. It remains supported, but it describes a genuine one-question, multi-answer page such as a forum thread, not a practice FAQ block.

This article ships FAQPage markup in its own graph, knowing Google will show nothing for it. That is the whole argument in one decision.

Step 5: The Complete Medical Schema Markup Block

In short: Put every node in one @graph, connect them with @id references instead of repeated objects, and ship it as a single script tag. This is what turns three separate declarations into one entity graph a machine can follow.

<script type="application/ld+json">
  {
    "@context": "https://schema.org",
    "@graph": [
      {
        "@type": "WebSite",
        "@id": "https://www.yourpractice.com/#website",
        "url": "https://www.yourpractice.com/",
        "name": "Your Practice Name"
      },
      {
        "@type": "WebPage",
        "@id": "https://www.yourpractice.com/#webpage",
        "url": "https://www.yourpractice.com/",
        "name": "Your Practice Name, Primary Care in Your City",
        "isPartOf": { "@id": "https://www.yourpractice.com/#website" },
        "about": { "@id": "https://www.yourpractice.com/#organization" }
      },
      {
        "@type": "MedicalClinic",
        "@id": "https://www.yourpractice.com/#organization",
        "name": "Your Practice Name",
        "url": "https://www.yourpractice.com/",
        "telephone": "+15551234567",
        "medicalSpecialty": "https://schema.org/PrimaryCare",
        "isAcceptingNewPatients": true
      },
      {
        "@type": "IndividualPhysician",
        "@id": "https://www.yourpractice.com/providers/jane-doe/#physician",
        "name": "Jane Doe, MD",
        "usNPI": "1234567890",
        "medicalSpecialty": "https://schema.org/PrimaryCare",
        "practicesAt": { "@id": "https://www.yourpractice.com/#organization" }
      },
      {
        "@type": "FAQPage",
        "@id": "https://www.yourpractice.com/#faq",
        "mainEntity": [
          {
            "@type": "Question",
            "name": "Do you accept new patients?",
            "acceptedAnswer": {
              "@type": "Answer",
              "text": "Yes. We accept new patients at all three locations and can usually schedule a first visit within two weeks."
            }
          }
        ]
      }
    ]
  }
  </script>

The practice and provider nodes here are trimmed for readability. Restore the full property sets from Steps 2 and 3 before you ship, and add the remaining questions to the mainEntity array.

Three things make this work.

One @context, one array. Three separate script tags leave a machine to guess whether your practice, your provider, and your FAQ describe related things. A graph states the relationships instead of implying them.

References, never duplicates. practicesAt holds an @id and nothing else. The moment you paste the practice object into the provider node instead, you have declared two practices that happen to share a name.

A WebPage node anchoring the rest. Without it the graph is a set of floating assertions. With it, isPartOf and about tie every claim to a specific URL on a specific site.

Placement is simpler than most guides suggest. One <script type="application/ld+json"> element, head or body, either is fine. Order inside the array does not matter, because @id does the connecting. A ten-provider practice adds ten IndividualPhysician nodes to the same array, each pointing practicesAt at that one practice @id, following the multi-location pattern from Step 2.

The One Rich Result a Medical Page Can Still Earn

In short: Review snippets are the realistic rich result for a healthcare page, earned by nesting Review or AggregateRating inside a medical node. The catch is that Google’s guidance sets aside the exact case most practices have in mind.

Every guide in this space tells practices to add AggregateRating to provider pages and collect stars in the search results. The stars are real. The eligibility is narrower than advertised.

Google clarified its local business documentation in August 2023 to state that review and aggregateRating are recommended for sites capturing reviews about other local businesses [1]. That is the self-serving review guideline applied to local markup. A practice publishing its own patient testimonials and marking them up is the case that clarification excludes.

Where it works: a health system marking up reviews of affiliated providers it does not own, or a directory rating practices across a metro area. Where it does not: your own testimonials page, no matter how genuine the reviews are.

The practical route for patient reviews runs through Google Business Profile, where they surface in the local pack without any markup on your part. Put the effort there, and keep aggregateRating off your own provider nodes.

Five Common Medical Schema Markup Mistakes (and How to Fix Them)

In short: Most broken healthcare implementations fail the same five ways: invisible content, wrong type for providers, duplicated nodes, free text where an enumeration belongs, and a generic business type that drops every medical property.

Two of these deserve a closing note.

The visible-content rule catches more sites than the other four combined, and it usually starts with good intentions. A marketer knows the practice accepts twelve insurance plans, sees that healthPlanNetworkId exists, and adds all twelve to the markup while the page shows a generic “we accept most major insurance” line. The fix runs the other direction: put the twelve plans on the page, then describe them.

The duplication mistake is the quiet one. Nothing errors. The Rich Results Test reports no problem. You simply end up with two practices in the graph where you meant one, and every property you carefully added gets divided between them. Search your JSON-LD for repeated name values on the same entity. If a name appears twice, one of those should be an @id reference.

Testing Medical Schema Markup: Two Tools, Two Different Answers

In short: The Rich Results Test tells you whether Google sees a supported rich result. The Schema Markup Validator tells you whether your vocabulary is correct. A healthy medical graph often passes the second and returns nothing from the first, and that is the expected outcome.

Run three checks, in this order:

1. Before deploy, paste the code into the Schema Markup Validator. It checks the vocabulary itself: real types, real properties, correct value shapes. This is where a misspelled practicesAt or a free-text specialty surfaces [4].
2. After deploy, run the live URL through the Rich Results Test. Testing the pasted snippet skips the question that matters, which is whether the markup survives rendering on the actual page [4].
3. Then confirm in Search Console that the page is indexed. Markup on a page Google has not indexed does nothing at all [1].

Expect the Rich Results Test to report no eligible rich results for MedicalOrganization and IndividualPhysician on their own. Google publishes no medical-specific rich result, so unless the page carries review markup that meets the guidelines covered above, there is nothing for the tool to find. That screen alarms people who assume it means broken code. It means the type is doing entity work rather than display work, which was the point.

Search Console reports structured data issues under Enhancements, and template-level errors surface there before anyone notices them in traffic. Note that the reporting surface shifted during 2026: the FAQ rich result report was removed in June 2026, and API support for it ended that August [1]. A missing FAQ report is the feature being gone, not your markup failing.

Skip the audit calendar and watch for triggers instead. Re-check after a CMS or plugin update, when a provider joins or leaves, when a location moves, and after any template change. Plugin updates are the sneakiest of the four, because the output shape can change without anyone touching the site’s content.

The failure this catches most often is stale markup. A provider left eighteen months ago, their page redirects, and their node still sits in the practice graph pointing practicesAt at a clinic they no longer work in. Nothing errors. The graph is simply wrong, and it has been wrong the entire time.

Start with One Page, Then Expand

In short: Mark up the homepage with a MedicalOrganization node, validate it, add one provider, then repeat. Proving the pipeline on a single page is faster than planning a rollout you never begin.

The first pass takes about thirty minutes:

1. Build the practice node from Step 2 and put it on the homepage.
2. Run it through the Schema Markup Validator, then the live URL through the Rich Results Test.
3. Add one IndividualPhysician node on one provider page.
4. Connect the two with practicesAt and merge them into a single @graph.
5. Validate again, then repeat for the remaining providers and locations.

Be realistic about scope. A single-location practice with three providers is an afternoon. A twelve-location group with sixty providers is a templating project, and treating it like a copy-paste job is how these efforts stall at location four.

Most of the work after that is maintenance rather than implementation, which is where an outside team usually earns its keep.

Frequently Asked Questions

What is medical schema markup?

Medical schema markup is JSON-LD code that describes healthcare pages to search engines using schema.org types built for medicine. The main types are MedicalOrganization for a practice, IndividualPhysician for a provider, and FAQPage for patient questions.

Is Physician schema for a person or a practice?

In schema.org, Physician is a subtype of MedicalOrganization, and its subtype IndividualPhysician inherits from Organization and Place rather than Person. Use IndividualPhysician for a provider bio page and PhysiciansOffice for a location page.

Does FAQ schema still work in 2026?

FAQ rich results stopped appearing in Google Search on May 7, 2026, and Google removed the documentation on June 15, 2026. The FAQPage type is still valid schema.org vocabulary and other systems continue to parse it.

Does schema markup improve my search rankings?

Structured data is not a ranking factor. It makes pages eligible for supported rich results and helps search engines understand what a page describes. Google’s guidance frames it as part of overall SEO rather than a lever that moves position directly.

Should I remove my existing FAQPage markup?

No. Google has stated that structured data which is not being used causes no problems for Search and there is no need to remove it proactively. Removing it costs developer time and gains nothing.

Does schema markup help with AI Overviews?

Google’s guidance states that structured data is not required for generative AI search and that no special schema.org markup exists for it, while still recommending markup for rich result eligibility. Visibility in AI features depends on indexing and snippet eligibility first.

What is the difference between MedicalOrganization and MedicalBusiness?

MedicalOrganization descends from Organization and assumes no physical location. MedicalBusiness descends from LocalBusiness and carries place properties like opening hours and coordinates. Several types, including MedicalClinic, inherit from both.

Do I need one script or several?

One is better. A single @graph array lets nodes reference each other by @id, which states the relationships between your practice, providers, and FAQ instead of leaving a machine to infer them.

Why does the Rich Results Test find nothing for my medical markup?

Google publishes no medical-specific rich result, so MedicalOrganization and IndividualPhysician return no eligible result even when correct. Use the Schema Markup Validator to confirm the vocabulary is valid.

Definition Bank

Entity Cards

MedicalOrganization

IndividualPhysician

FAQPage

Sources

1. Google Search Central. Latest documentation updates. developers.google.com/search/updates. Accessed September 2026.
2. Google Search Central. Optimizing your website for generative AI features on Google Search. Last updated July 10, 2026.
3. Schema.org. IndividualPhysician, Physician, and MedicalOrganization type definitions. Version 30.0, released March 19, 2026.
4. Google Search Central. Structured data general guidelines and Rich Results Test. Accessed September 2026.
5. Schema App. Schema.org v24.0 release, changes to Physician schema markup. Accessed September 2026.