Schema.org Structured Data Guide for Medical & Aesthetic Clinics

Schema.org Structured Data Guide for Medical & Aesthetic Clinics

A complete walkthrough of implementing, auditing, and optimising JSON-LD structured data for a doctor-led medical clinic. Covering everything from base setup to advanced rich result eligibility.

1. Core Organisation Node — MedicalClinic

The foundation of your schema. Every other node references back to this.

• @type: "MedicalClinic" — use this over generic LocalBusiness for medical entities
• Include name, legalName, url, logo, image, and description
• Add slogan for brand identity signals
• Set foundingDate in ISO format (YYYY-MM-DD)
• Set isAcceptingNewPatients: true — directly used by Google for medical listings
• Add priceRange (e.g. ££££) — optional but removes Google Search Console warnings
• Add paymentAccepted to list accepted payment methods
• Include medicalSpecialty using schema.org URIs (e.g. http://schema.org/Dermatologic)
• Use knowsAbout array to list all treatments and specialities — strengthens topical authority
• Add award array for accreditations and achievements

2. Address, Contact & Opening Hours

• Use a full PostalAddress object — include streetAddress, addressLocality, addressRegion, postalCode, and addressCountry
• Add GeoCoordinates with latitude and longitude for map visibility
• Add both top-level telephone and a ContactPoint object — the ContactPoint can include email, areaServed, and availableLanguage
• Define openingHoursSpecification for open days with exact opens and closes times
• Explicitly define closed days (e.g. Saturday, Sunday) with opens: "00:00" and closes: "00:00" — avoids Google inferring incorrect hours

3. Booking Action

One of the highest-impact additions for conversion — enables a direct booking link in search results.

• Add potentialAction with @type: "ReserveAction" to the main organisation node
• Use an EntryPoint with urlTemplate pointing to your booking or consultation page
• Specify actionPlatform for both desktop and mobile web
• Add a human-readable name to the action (e.g. “Book a Consultation”)

4. Physician / Doctor Entity

For doctor-led clinics, the physician node is critical for E-E-A-T (Experience, Expertise, Authoritativeness, Trustworthiness).

• Use dual type ["Person", "Physician"] — Person alone is insufficient for medical authority signals
• Add honorificPrefix: "Dr."
• Include alumniOf with the medical school as a CollegeOrUniversity
• Add hasCredential with EducationalOccupationalCredential specifying the medical degree
• Include medicalSpecialty using schema.org URIs
• Add telephone, address, and priceRange to the physician node — Google treats Physician like a local business and expects these fields
• Link to professional profiles via sameAs (LinkedIn, Instagram, etc.)
• Connect to the organisation via worksFor referencing the clinic’s @id

5. Services — Dual Typing for Medical Clinics

• Define each service as a separate node in @graph with a unique @id
• Use dual type ["Service", "MedicalProcedure"] — improves medical relevance signals beyond generic Service
• Add serviceType to categorise services (e.g. “Regenerative Aesthetics and Dermal Injectables”)
• Always include a detailed description
• Link back to the clinic via provider referencing the organisation’s @id
• Reference services from hasOfferCatalog inside the main organisation node using @id references

6. Ratings & Reviews

• Add aggregateRating with ratingValue and reviewCount
• Do not include itemReviewed inside a nested aggregateRating — this causes a directional conflict warning. itemReviewed is only needed when aggregateRating is defined as a standalone node
• Add individual Review objects in a review array — each with author, datePublished, reviewRating, and reviewBody
• Include bestRating: "5" inside each reviewRating

7. FAQPage Schema

One of the most impactful additions for organic visibility — eligible for expanded FAQ rich results in Google Search.

• Add a FAQPage node to @graph with a unique @id
• Define each question inside mainEntity as a Question object
• Each Question must have a name (the question) and an acceptedAnswer containing an Answer with a text field
• Keep answers factual and directly useful — do not use FAQ schema for promotional content

8. Site-Level Nodes

• Add a WebSite node with a SearchAction — enables Google Sitelinks search box
• Add a WebPage node linked to both the website and organisation via isPartOf and about
• Add a BreadcrumbList node — required for breadcrumb rich results on inner pages

9. Social Profiles & Brand Consistency

• Use sameAs on the organisation node to list all official social media profiles and Google Maps listing
• Use sameAs on the physician node to link professional and personal social profiles
• Consistent NAP (Name, Address, Phone) across all nodes is essential for local SEO

10. Implementation & Validation

• Always wrap your JSON-LD in <script type="application/ld+json"> — omitting the type attribute causes browsers to parse JSON as JavaScript and throw errors
• Use a single @graph array to define all nodes in one script block — avoids duplicate context issues
• Validate using Google Rich Results Test after every change
• Non-critical warnings (optional missing fields) do not block rich results but should be resolved where possible
• Critical errors must be resolved — they prevent the page from being eligible for rich results entirely