Structured data for practices, and what AI engines actually read

Which types, and why JSON-LD only

For a healthcare practice the defaults are MedicalClinic (or Dentist, Physiotherapy where the specific subtype exists) for the organisation, Physician for each practitioner, Service or MedicalProcedure for what's offered, and FAQPage only where a page has questions and answers a patient actually asked. Everything goes in JSON-LD in the head. Microdata scattered through a page-builder template breaks the first time someone edits the layout; a single JSON-LD block survives.

{
  "@context": "https://schema.org",
  "@type": "MedicalClinic",
  "name": "Example Physiotherapy",
  "url": "https://example.co.za/",
  "telephone": "+27 11 000 0000",
  "address": { "@type": "PostalAddress", "streetAddress": "12 Example Road",
    "addressLocality": "Johannesburg", "addressRegion": "Gauteng",
    "postalCode": "2194", "addressCountry": "ZA" },
  "medicalSpecialty": "Physiotherapy",
  "employee": [{ "@type": "Physician", "name": "Dr A. Example",
    "medicalSpecialty": "Physiotherapy", "sameAs": ["https://www.hpcsa.co.za/..."] }],
  "sameAs": ["https://www.google.com/maps/place/..."]
}

Two details do more work than the rest. sameAs ties the entity to its other identities (the Business Profile, the professional register, a LinkedIn page) so a search engine can be sure this clinic is that clinic. And practitioner credentials, spelled the same way everywhere, give the entity the authority that generic "our team" copy never will.

Two validators that disagree, usefully

Run every block through both Google's Rich Results Test and the Schema.org validator. They check different things. Google's tool only cares about the types it shows rich results for and will happily pass a MedicalClinic block with a broken address, because it isn't looking. The Schema.org validator checks the vocabulary and will flag the malformed address and the property that doesn't exist on that type. A block that passes both is a block you can defend.

What AI engines read

AI Overviews, ChatGPT search and Perplexity don't read schema the way a rich-result parser does, but they reward the same underlying work: entity clarity. When the practice name, address, phone number and practitioner credentials are consistent across the site, the Business Profile, the professional register and the directories, the engine can resolve the entity confidently and is more willing to cite it. When they conflict, it hedges or picks someone else.

Three things on the page itself move the needle:

• Quotable declarative statements. A service page that says "Initial physiotherapy assessments in Northcliff take 45 minutes and cost R650" gives an engine a sentence it can lift. "We offer a range of tailored solutions" gives it nothing.
• Questions answered in full. Not an FAQ accordion of marketing lines, but the actual questions the front desk answers every day, each with a complete answer in the first sentence.
• An llms.txt file. Still an emerging convention, but cheap: a plain-text map of the site's key pages and what each is for, at the root, alongside robots.txt. Some engines read it now; the ones that don't yet ignore it.

Measuring visibility you can't see in Search Console

There's no Search Console for ChatGPT. What there is: a fixed set of the practice's target questions, asked monthly across the engines, with the answer and the cited sources recorded. It's manual, it takes half an hour, and after three months it's the only trend line that shows whether the entity work is paying off. Put it on the same dashboard as everything else so the client sees it alongside rankings and vitals, not as a separate "AI" line item.

Rich results are the old reason to get structured data right. Being the practice an AI engine names is the new one, and it's the same work.