Structured data is how you state facts about your practice in a form machines do not have to interpret. It is genuinely useful and routinely oversold, so this lesson separates the types that earn their keep from the decoration.
What it is and is not
Structured data is markup embedded in your pages, usually as JSON-LD, describing what the page is about in a standard vocabulary. Instead of hoping a system infers your address from a footer, you state it explicitly.
It is not a ranking shortcut. It does not make a thin page rank, and adding markup to a page with no useful content achieves nothing. What it does is remove ambiguity, which matters most for exactly the resolution problem in the previous lesson.
The types worth implementing
In order of value for a clinic:
- MedicalClinic or LocalBusiness on each office page. The essential one. It states name, address, phone, hours, geographic coordinates, and URL as machine-readable facts. Use the more specific medical type where it fits.
- Physician on each provider bio page, with name, credentials, specialty, and practice affiliation. This helps connect people to the practice entity.
- MedicalProcedure or MedicalTherapy on treatment pages, describing what the treatment is. Keep it factual and avoid outcome assertions in the markup, exactly as in your copy.
- FAQPage where you genuinely have questions and answers on the page. Useful because assistants readily extract question-and-answer pairs, and your access and logistics questions are the ones you can legitimately answer.
- BreadcrumbList, which clarifies site structure cheaply.
- Organization on your homepage, tying the practice, its logo, and its profiles together.
The critical detail on sameAs
One property deserves special mention because it addresses entity resolution directly. The sameAs property lets you list the other places your practice exists: your Google profile, your directory listings, your professional society pages.
This converts guessing into telling. Instead of a system inferring that a directory profile probably describes you, you have asserted the connection. For a practice with records scattered across many platforms, this is one of the highest-value pieces of markup available, and almost nobody implements it.
What is decoration
- Review and AggregateRating markup you author yourself. Self-serving review markup is heavily restricted and can trigger warnings. Let review platforms carry reviews.
- Markup describing things not on the page. This is a guideline violation, not a clever trick.
- Exhaustive property lists for their own sake. Accuracy beats completeness.
- Medical condition markup on pages that are really service pages, which misrepresents the content.
- Speakable, courses, events and similar types where you have none of those things.
The mistakes that make markup worthless
- Markup that disagrees with the visible page. If your footer says one phone number and your JSON-LD says another, you have added ambiguity rather than removing it.
- The same address on every office page. Common with template-driven sites, and it destroys per-location clarity.
- Markup that disagrees with your Google profile. Everything must trace to the one canonical record.
- Stale markup left behind after a move or a rebrand.
- Missing suite numbers in the address property.
- Efficacy claims inside markup, which carry the same compliance exposure as visible copy.
Getting it right
- Generate markup from your single source of truth so it cannot drift from your listings.
- One MedicalClinic block per office page, with that office details only.
- Include geographic coordinates for the entrance patients should use.
- Add sameAs links to your significant profiles.
- Validate with a structured data testing tool after publishing.
- Re-validate after any move, rename, or site change.
Chapter six covers implementation on the website side in more depth. The last lesson in this chapter is about measuring all of this honestly.