MedicalBusiness vs LocalBusiness for dentists.
The Schema.org inheritance chain
LocalBusiness is the generic Schema.org type covering any local business. MedicalBusiness is a subtype under LocalBusiness that adds the medical-vertical slots: medicalSpecialty, availableService with MedicalProcedure values, healthPlanNetworkId, acceptedInsurance, isAcceptingNewPatients. Dentist is a further subtype under MedicalBusiness. The Dentist type also inherits from MedicalOrganization through Schema.org's multiple-inheritance pattern, which unlocks hasCredential and hasCertification for the practitioner credential chain. A practice that deploys flat LocalBusiness leaves every layer of medical-vertical metadata on the table. The Dentist schema type hub covers the full slot map and the per-specialty taxonomy.
How Google parses the difference
Google's Knowledge Graph uses schema-type signals to classify entities. Dentist as a MedicalBusiness subtype routes the entity into the medical-vertical understanding: the YMYL classification under the Helpful Content System, the Reviews System's medical-content framework, the medical-specialty disambiguation that lets Google distinguish a pediatric dentist from a general dentist when both terms appear on the page. Flat LocalBusiness routes the entity into the generic local-business understanding (the entity reads as a coffee shop that happens to have a dentist's name). The downstream effects compound: the wrong subtype dilutes everything from local-pack ranking to author EEAT to the relevance of FAQ schema attached to the entity. Multi-location DSOs amplify the effect across every location's node.
The migration from LocalBusiness to Dentist
Update the @type value, then populate the subtype-specific slots. medicalSpecialty mapped to the 12 ADA-recognized specialties (the values the practice legally operates under per the practitioner's training and board status, not aspirational positioning). availableService rebuilt against CDT codes rather than invented marketing terminology. The CDT code mapping spoke covers the procedure-code work; the insurance surfacing spoke covers the healthPlanNetworkId question. isAcceptingNewPatients set per location. hasCredential arrays added per practitioner with state license verification and board certification entries. The migration takes a discovery pass on the practice's actual scope first; dental schema markup is the engagement surface that runs the work, and the broader program sits at Bright.
What practices ask about MedicalBusiness vs LocalBusiness.
What's the difference between <code>MedicalBusiness</code> and <code>LocalBusiness</code> for dentists?
LocalBusiness is the generic Schema.org type covering any local business. MedicalBusiness is a subtype under LocalBusiness that adds the medical-vertical slots (medicalSpecialty, availableService with MedicalProcedure values, healthPlanNetworkId, acceptedInsurance, isAcceptingNewPatients). Dentist is a further subtype under MedicalBusiness. A practice that deploys flat LocalBusiness leaves all the medical-vertical metadata on the table.How does Google parse the difference?
Dentist as a MedicalBusiness subtype routes the entity into the medical-vertical understanding (the YMYL classification, the Reviews System medical-content framework, the medical-specialty disambiguation). Flat LocalBusiness routes the entity into the generic local-business understanding (the entity reads as a coffee shop with a dentist title). The downstream effects compound: the wrong subtype dilutes everything from local-pack ranking to author EEAT to FAQ schema relevance.What does the migration from <code>LocalBusiness</code> to <code>Dentist</code> look like?
@type value, then populate the subtype-specific slots. medicalSpecialty mapped to the 12 ADA-recognized specialties (the values the practice legally operates under). availableService rebuilt against CDT codes rather than invented marketing terminology. healthPlanNetworkId populated per insurance network the practice participates in. isAcceptingNewPatients set per location. hasCredential arrays added per practitioner with state license and board certification entries. The migration takes a discovery pass on the practice's actual scope first.What values are valid for <code>medicalSpecialty</code> under <code>Dentist</code>?
medicalSpecialty takes values from the Schema.org MedicalSpecialty enumeration. For dental practices, the relevant values include Dentistry (the general value), Orthodontic, Endodontic, Periodontic, plus references to the 12 ADA-recognized specialties through structured naming. The values must align with the practice's legally defensible scope of practice per the practitioners' training and board certifications, not aspirational positioning. Misalignment with the ADA-recognized specialty list trips ADA Section 5.I.1 for general dentists and exposes specialty practices to board complaints from competitors.Pick the right subtype. Populate the medical-vertical slots. Stop deploying schema that reads as a coffee shop with a dentist title. Book a diagnostic.
We audit your current schema deployment, identify the LocalBusiness-to-Dentist migration scope, and ship the per-slot rebuild plan with the ADA-taxonomy alignment and the CDT-code mapping. The diagnostic comes back inside two weeks.