Schema Markup for Medspas: What Search Engines Can Use

What is med spa schema markup?

Med spa schema markup is structured data that labels a clinic's public facts in a machine-readable format. JSON-LD is the script format most teams use because Google lists it as recommended. The code belongs on the page it describes and must agree with what a visitor can see.

Schema reduces ambiguity. It can identify a business, physical location, article, breadcrumb trail, or other supported entity. Google's general structured data guidelines require relevant, current, visible information and warn that valid markup can still be ineligible when it is misleading or incomplete.

This guide supports the med spa website optimization service. The broader AI search checklist for medspas covers Google's separate guidance that there is no special AI schema.

Which schema type should a medspa use?

Choose the most specific type that the real operation can support. Google tells publishers to use the most specific applicable LocalBusiness subtype and to describe each physical location as its own LocalBusiness. If more than one type is genuinely accurate, Google accepts an array of types rather than the unsupported additionalType property.

A medspa is not one uniform business category. For example, some clinics operate for medical purposes under licensed healthcare oversight. Others are day spas or beauty and wellness businesses. Schema.org defines MedicalBusiness as a business for medical purposes, while MedicalClinic describes a facility devoted to diagnosis or healthcare. Use either only when the clinic's real role and visible page support it.

The type does not grant a license, credential, or regulatory status. Schema.org's health and medical vocabulary is web publishing markup, not clinical data exchange. Ask the clinic owner and qualified counsel to confirm the public description when the business model sits between medical and nonmedical services.

How should clinic facts become JSON-LD?

The Clinic Schema Truth Map is a five-layer release control for identity, location, services and people, page purpose, and validation. The visible page is the first publication surface. Structured data mirrors that approved record, and the validator checks the code after the factual review is complete.

The map below prevents a common failure: syntactically valid code that describes stale hours, the wrong branch, an absent provider, or a review that users cannot see. A green validator result cannot detect every quality problem. Google says automated tests catch technical errors, while relevance and visibility still require human review.

What belongs in the core clinic record?

Start with the facts a visitor needs to identify and reach one location: name, canonical URL, image, phone, postal address, hours, and coordinates when verified. Google's LocalBusiness documentation lists name and address as required for its local business feature and recommends additional properties that improve the record.

Give the entity a stable @id that does not change with a redesign. Use the same identifier when an article, provider page, or service record refers back to the clinic. For a multi-location group, each branch needs a separate location page and a separate entity. The parent brand can remain an Organization.

The sample below is deliberately fictional. Every example.com URL, phone number, address, hour, image, and coordinate must be replaced with the clinic's approved public record. Delete any property the clinic cannot verify instead of leaving a plausible placeholder in production.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "MedicalBusiness",
  "@id": "https://example.com/#clinic",
  "name": "Example Aesthetic Clinic",
  "url": "https://example.com/",
  "image": "https://example.com/images/clinic-exterior.jpg",
  "telephone": "+1-512-555-0100",
  "priceRange": "$$$",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "100 Example Avenue",
    "addressLocality": "Austin",
    "addressRegion": "TX",
    "postalCode": "78701",
    "addressCountry": "US"
  },
  "geo": {
    "@type": "GeoCoordinates",
    "latitude": 30.2672,
    "longitude": -97.7431
  },
  "openingHoursSpecification": [
    {
      "@type": "OpeningHoursSpecification",
      "dayOfWeek": [
        "https://schema.org/Monday",
        "https://schema.org/Tuesday",
        "https://schema.org/Wednesday",
        "https://schema.org/Thursday",
        "https://schema.org/Friday"
      ],
      "opens": "09:00",
      "closes": "17:00"
    }
  ]
}
</script>

Which markup belongs on each clinic page?

Match the main schema type to the page's main job. The homepage or primary location page can establish the business entity. A branch page describes one location. A provider page can identify a real person, while an editorial guide can use BlogPosting and its visible breadcrumb trail can use BreadcrumbList.

Service is a Schema.org type, but Google does not list a general Service rich result. Use it only when it helps describe visible service information in a maintainable graph. Do not add unsupported types simply to make the graph larger. Google's guidance says the main type should reflect the page's main focus.

Structured data does not replace the service explanation, provider context, consultation path, or limitations. The med spa website optimization checklist covers those surrounding controls.

How do BlogPosting and BreadcrumbList work together?

A clinic article can use BlogPosting for the editorial item and BreadcrumbList for its place in the site. Google's Article documentation recommends author, date, headline, and representative image properties. Its breadcrumb guide requires ordered ListItem entries.

Keep the visible byline and dates aligned with the JSON-LD. If the author is an organization, say so on the page. Do not invent a clinician reviewer, certification, or author profile to satisfy a plugin warning. Truthful Organization authorship is better than a fabricated Person entity.

This second sample uses a small @graph so the article can reference the clinic publisher. It also uses three image aspect ratios, which Google recommends for best Article image coverage. The names and URLs remain fictional placeholders.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "MedicalBusiness",
      "@id": "https://example.com/#clinic",
      "name": "Example Aesthetic Clinic",
      "url": "https://example.com/"
    },
    {
      "@type": "BlogPosting",
      "@id": "https://example.com/blog/skin-consultation-guide#article",
      "headline": "What to Ask During a Skin Consultation",
      "datePublished": "2026-08-01T09:00:00-05:00",
      "dateModified": "2026-08-06T09:00:00-05:00",
      "image": [
        "https://example.com/images/consultation-guide-16x9.jpg",
        "https://example.com/images/consultation-guide-4x3.jpg",
        "https://example.com/images/consultation-guide-1x1.jpg"
      ],
      "author": {
        "@type": "Organization",
        "name": "Example Aesthetic Clinic",
        "url": "https://example.com/about"
      },
      "publisher": {
        "@id": "https://example.com/#clinic"
      },
      "mainEntityOfPage": {
        "@type": "WebPage",
        "@id": "https://example.com/blog/skin-consultation-guide"
      }
    },
    {
      "@type": "BreadcrumbList",
      "@id": "https://example.com/blog/skin-consultation-guide#breadcrumb",
      "itemListElement": [
        {
          "@type": "ListItem",
          "position": 1,
          "name": "Home",
          "item": "https://example.com/"
        },
        {
          "@type": "ListItem",
          "position": 2,
          "name": "Blog",
          "item": "https://example.com/blog"
        },
        {
          "@type": "ListItem",
          "position": 3,
          "name": "Skin Consultation Guide"
        }
      ]
    }
  ]
}
</script>

Which schema mistakes create the most risk?

Do not add AggregateRating to the clinic's own site expecting stars. Google's current review snippet rules make LocalBusiness and Organization pages ineligible for self-serving review stars, including reviews embedded through a third-party widget. Visible testimonials may still help people, but the markup does not create that Google feature.

Do not promise FAQ dropdowns. Google's Search documentation updates record that FAQ rich results stopped appearing on May 7, 2026, and the feature documentation was removed in June. Visible FAQs can still answer real questions, and Schema.org FAQPage remains a vocabulary type, but adding it for a Google rich-result promise is outdated advice.

Keep patient data out of public markup. HHS guidance explains that protected health information can include identifying information tied to a person's health, care, or payment. JSON-LD on a public page is public website content, so do not place patient names, treatment histories, appointment details, or private records in it. Ask privacy counsel about the clinic's specific duties.

How should a medspa validate schema markup?

Use two tests because they answer different questions. The Schema Markup Validator checks Schema.org vocabulary across all extracted items. Google's Rich Results Test checks which supported Google search features the code may qualify for. A type can be valid Schema.org markup without producing a Google rich result. Test code before release, then test the public URL after deployment. Fix syntax and critical property errors, but review warnings in context rather than adding facts that do not apply. Save the result, test date, page URL, and code version so the clinic can compare the next update. The evidence below comes from the two fictional examples in this article, tested on August 6, 2026. It proves that the samples parse in the named tools on that date. It does not prove that the example.com records are real, that Google indexed a page, or that any search feature will appear.

Bing also processes Schema.org JSON-LD and says its crawlers compare annotated data with the surrounding page. After launch, use Bing URL Inspection's markup card and Google Search Console URL Inspection on the real canonical. The validator is the start of release evidence, not the end.

How should a clinic deploy and maintain the markup?

For example, a WordPress site may generate schema through its theme, SEO plugin, local plugin, page builder, and custom code. Check every source before adding another block. In a server-rendered application, generate JSON-LD from the same record that renders the page. Either approach can work; the release fails when two systems publish conflicting entities.

Recheck markup whenever a location, phone number, opening hour, provider, service, article date, canonical, or image changes. The medspa redesign checklist covers migration controls that protect structured data during a relaunch.

Download the 40-control medspa schema release checklist for page-by-page ownership and evidence. The checklist is a project-control method created for this guide. It is not a search-engine metric, prediction, or guarantee.

What should a medspa do next?

Start with one high-value canonical: the homepage or a true location page. Confirm the clinic type, record the public facts, publish the smallest accurate entity, and run both validators. Then expand only where a provider, article, breadcrumb, or service page has enough visible content to support its own record.

Last verified August 6, 2026. The editorial policy explains source review, contact for corrections, and update dates. The About page identifies the publisher and its scope.