§ Service

Medical Schema Markup

Medical schema markup.

Abstract

JSON-LD implementation of MedicalBusiness and Physician types, with usNPI, hospitalAffiliation, and sameAs chained to the NPI registry profile on NPPES, the state medical board licensure page, and the ABMS verification page. The chain is the load-bearing mechanism that resolves the physician identity in Google's Knowledge Graph and transfers off-site EEAT signals to the on-site author byline.

Book a diagnostic →

Medical schema is one of seven services inside the medical seo expert practice at Praxis. The schema layer feeds the editorial bylines, the multi-location SEO architecture, and the testimonial workflow. The work usually starts here when the practice is investing in any of the other surfaces.

How the schema layer ships

Four entity surfaces. Each one chained to a public registry.

The schema work splits across four entity surfaces: the practice, the physicians, the commercial service pages, and the editorial content. Each surface carries a distinct schema type and a distinct external chain. The four together form the entity-graph foundation Google's medical evaluators read against.

MedicalBusiness over LocalBusiness for the practice entity.

Generic <code>LocalBusiness</code> markup fails Google's medical entity graph. The practice location marks up as <code>MedicalBusiness</code> (or a more specific subtype like <code>MedicalClinic</code>, <code>Hospital</code>, or <code>Dentist</code>) with <code>medicalSpecialty</code>, <code>availableService</code>, <code>acceptedPaymentMethod</code>, <code>isAcceptingNewPatients</code>, and <code>healthPlanNetworkId</code> populated against the practice's actual filtering parameters. The schema reads as a medical entity to Google's parsers, not a generic local business.

Physician.sameAs chained to NPPES, state board, ABMS.

The individual physicians marking up under the <code>Physician</code> type (inheriting from <code>Person</code> and <code>MedicalOrganization</code>) carry <code>sameAs</code> links to three external registries: the NPI registry profile on NPPES, the state medical board licensure page, and the ABMS verification page. The three references are the load-bearing chain that resolves the physician identity in Google's Knowledge Graph and transfers the off-site EEAT signals to the on-site author byline. We map every physician at the practice to those three external profiles and bake the chain into JSON-LD on every author surface.

usNPI, hospitalAffiliation, and the entity-specific slots.

Schema.org provides medical-specific properties that feed Google's Knowledge Graph directly. <code>usNPI</code> on the <code>Physician</code> node allows machine-readable linkage to the CMS National Provider Identifier registry, bypassing inference from name and address alone. <code>hospitalAffiliation</code> linking to a <code>Hospital</code> entity establishes institutional EEAT. <code>healthPlanNetworkId</code> aligns the structured data with the exact insurance-acceptance filtering parameters Zocdoc and patient aggregators use. <code>isAcceptingNewPatients</code> as a boolean drives local conversion. Each slot maps to a public-directory data point.

Commercial pages stay MedicalBusiness. Clinical types stay on editorial.

The clinical Schema.org types (<code>MedicalCondition</code>, <code>MedicalProcedure</code>, <code>MedicalTest</code>, <code>MedicalTherapy</code>, <code>Drug</code>) belong on encyclopedic editorial content authored by credentialed physicians. Applying them to a commercial service page that markets a procedure (laser hair removal, Botox, breast augmentation) reads to Google's medical-content evaluators as an attempt to manipulate medical rich results with non-encyclopedic content. The manual-action pattern for 'spammy structured data' is documented. We mark up commercial pages with <code>MedicalBusiness</code> + <code>availableService</code> and reserve the clinical types for the editorial layer.

Side by side

The medical schema layer versus the generalist default, on the five surfaces where the entity graph reads.

Practice with Praxis schema

Medical entity graph populated

Practice with generalist schema

LocalBusiness only

Practice entity type

<code>MedicalBusiness</code> (or a more specific subtype) with <code>medicalSpecialty</code>, <code>availableService</code>, <code>isAcceptingNewPatients</code> populated against the practice's actual filtering parameters.

<code>LocalBusiness</code> with hours, address, and phone. Reads to Google as a generic local entity, not a medical entity.

Physician entity

<code>Physician</code> node per attending physician with <code>sameAs</code> chain to NPPES, state medical board, and ABMS verification. <code>usNPI</code> property machine-linked to the CMS registry.

Physicians named in body copy without a structured-data node. Search engines infer identity from name and address. The chain is missing.

Service pages (commercial)

<code>MedicalBusiness</code> + <code>availableService</code> with a <code>Service</code> node per service line. Clinical types reserved for editorial content.

<code>Service</code> or <code>MedicalProcedure</code> on the marketing page. Triggers Google's medical-content evaluator as encyclopedic-content mimicry.

Editorial content (informational hubs and spokes)

<code>Article</code> with <code>medicalAudience</code> + chained <code>MedicalCondition</code> / <code>MedicalProcedure</code> / <code>MedicalTherapy</code> where the article substantively covers one. <code>Article.author</code> points to the named <code>Physician</code> node.

<code>BlogPosting</code> with a generic author string. The medical-content evaluators have no entity to weight against ABMS board-certification.

Multi-location practice

<code>MedicalBusiness</code> node per location with <code>employee</code> / <code>member</code> properties linking attending physicians to specific locations. <code>worksFor</code> / <code>location</code> on the <code>Physician</code> side closes the chain.

One <code>LocalBusiness</code> per location with no physician-to-location mapping. Multi-physician practices lose the per-physician entity signal across the location footprint.

Practice with Praxis schema

Medical entity graph populated

Practice entity type: <code>MedicalBusiness</code> (or a more specific subtype) with <code>medicalSpecialty</code>, <code>availableService</code>, <code>isAcceptingNewPatients</code> populated against the practice's actual filtering parameters.
Physician entity: <code>Physician</code> node per attending physician with <code>sameAs</code> chain to NPPES, state medical board, and ABMS verification. <code>usNPI</code> property machine-linked to the CMS registry.
Service pages (commercial): <code>MedicalBusiness</code> + <code>availableService</code> with a <code>Service</code> node per service line. Clinical types reserved for editorial content.
Editorial content (informational hubs and spokes): <code>Article</code> with <code>medicalAudience</code> + chained <code>MedicalCondition</code> / <code>MedicalProcedure</code> / <code>MedicalTherapy</code> where the article substantively covers one. <code>Article.author</code> points to the named <code>Physician</code> node.
Multi-location practice: <code>MedicalBusiness</code> node per location with <code>employee</code> / <code>member</code> properties linking attending physicians to specific locations. <code>worksFor</code> / <code>location</code> on the <code>Physician</code> side closes the chain.

Practice with generalist schema

LocalBusiness only

Practice entity type: <code>LocalBusiness</code> with hours, address, and phone. Reads to Google as a generic local entity, not a medical entity.
Physician entity: Physicians named in body copy without a structured-data node. Search engines infer identity from name and address. The chain is missing.
Service pages (commercial): <code>Service</code> or <code>MedicalProcedure</code> on the marketing page. Triggers Google's medical-content evaluator as encyclopedic-content mimicry.
Editorial content (informational hubs and spokes): <code>BlogPosting</code> with a generic author string. The medical-content evaluators have no entity to weight against ABMS board-certification.
Multi-location practice: One <code>LocalBusiness</code> per location with no physician-to-location mapping. Multi-physician practices lose the per-physician entity signal across the location footprint.

Updated 2026-05-28

How we engage

Diagnostic, then monthly retainer. Four phases, each scoped against cited deliverables.

Weeks 0-2

Diagnostic

We read your Search Console data, your traffic data, your current Schema.org markup, your physician author bylines, your testimonial pages, and your directory-profile completeness. The diagnostic comes back with the load-bearing pages, the dead weight, the YMYL-fragile content, and the entity-graph gaps. For multi-location groups, we add a GBP audit per practicing location.
Weeks 2-6

Schema and author layer

We build the MedicalBusiness and Physician schema layer with sameAs chains to NPI registry, ABMS verification, and state medical board profiles. Author bylines surface ABMS specialty and active state license alignment. CPT-aligned service pages where the procedure mix supports it. The schema layer reflects what each page actually is, MedicalCondition / MedicalProcedure types reserved for the editorial layer.
Weeks 4-8

Reviews System alignment

Editorial content rebuilt against the Reviews System 2023+ medical-content framework. Practicing-physician reviewer signals on first-party content. PubMed-cited primary literature replacing health-magazine summaries. Topic-to-specialty alignment in every author byline (a general practitioner does not author complex oncological articles). Patient testimonial workflow routed through the 45 CFR 164.508 consent path before any testimonial lands on a service page.
Monthly

Ongoing retainer

Monthly cadence on the rest of the site, plus content cadence for the queries the diagnostic surfaced. Quarterly review against your traffic data and Search Console movement. Re-audit of the entity-graph reconciliation when physician rosters change. Re-audit of the consent workflow when state medical board advertising rules change.

Common questions

Questions practice administrators ask before booking a diagnostic.

01.

Why does generic <code>LocalBusiness</code> schema fail for a medical practice?

Generic LocalBusiness tells Google the entity is a local business with hours and an address. It does not carry the medical entity signals Google's Knowledge Graph and Reviews System medical-content framework evaluate against. MedicalBusiness (and its subtypes MedicalClinic, Hospital, Dentist) carries the medical-specific properties: medicalSpecialty, availableService with MedicalProcedure nodes, healthPlanNetworkId for insurance acceptance, isAcceptingNewPatients for conversion-relevant filtering. The medical entity graph reads these. A generalist agency shipping LocalBusiness on a medical practice is shipping an HVAC-template schema layer on a regulated entity.

02.

What is the <code>Physician.sameAs</code> chain and why does it matter?

The sameAs property on the Physician node accepts a list of external URLs that refer to the same entity. For a physician, the three references that consolidate the entity graph are the NPI registry profile on NPPES, the state medical board licensure page, and the ABMS verification page. Google's Knowledge Graph uses these references to reconcile the physician identity across the public directory ecosystem and to weight the off-site EEAT signals against the on-site author byline. Without the chain, the practice's editorial content competes against directory authority (Healthgrades, Zocdoc, Vitals) that does carry the chain, and the practice loses the entity-resolution play.

03.

What happens if we mark up commercial pages with <code>MedicalProcedure</code> schema?

Google's medical-content evaluators read MedicalProcedure, MedicalCondition, MedicalTest, MedicalTherapy, and Drug as encyclopedic editorial content authored by credentialed physicians. Applying these to a commercial service page that markets a procedure (the practice's marketing copy for laser hair removal or Botox or breast augmentation) reads as an attempt to manipulate medical rich results with non-encyclopedic content. The documented downstream is a manual action for 'spammy structured data.' Commercial pages mark up as MedicalBusiness + availableService with a Service node per service line. The clinical types stay on the editorial layer where the substance and author credentials support them.

04.

How do you handle schema for a multi-location practice?

Each location gets its own MedicalBusiness node with location-specific address, hours, and accepted insurance. The employee and member properties on the MedicalBusiness node link attending physicians to that specific location, and the worksFor and location properties on the Physician side close the chain. A physician practicing at three locations carries three worksFor references; each location carries the physician in its employee list. The mapping consolidates the entity graph across the multi-location footprint and supports the local-pack ranking signal at each location.

05.

Where does the <code>usNPI</code> property live and why is it load-bearing?

The usNPI property lives on the Physician type and accepts the 10-digit National Provider Identifier. The NPI is the permanent, intelligence-free entity key the CMS National Provider Identifier registry uses to track physicians across job changes, location changes, and licensure changes. Open data initiatives and Google's entity-resolution algorithms use the NPI to cross-reference physician identity across NPPES, state medical board licensure databases, and third-party directories. Populating usNPI directly is the machine-readable shortcut: Google does not have to infer the physician identity from name and address; the registry linkage is explicit.

06.

How does this connect to the rest of the SEO work?

The schema layer is the entity-graph foundation the rest of the SEO architecture rests on. The editorial content carries Article with Article.author pointing to the named Physician node; the testimonial component depends on the MedicalBusiness + author byline structure to render against the consent workflow; the multi-location SEO work depends on the per-location MedicalBusiness + per-physician worksFor chain. Practices coming to us for any one Tier 2 service usually find the schema layer needs the rebuild before the other surfaces stabilize.

Stop watching your competitors rank

If your physicians have NPI numbers but no sameAs chain in their schema, Google's entity graph reads the practice as anonymous.

The diagnostic audits the current schema layer against the MedicalBusiness, Physician, and entity-chain standards, maps every physician to NPPES + state medical board + ABMS verification, and rebuilds the JSON-LD across the commercial and editorial surfaces. Comes back inside two weeks.

Book a diagnostic → Email us