Clinic schema guide: MedicalClinic, Physician and FAQ
Setting up MedicalClinic and Physician schema for clinic sites, multilingual consistency, review constraints and the removal of FAQ rich results in May 2026.
By Roozbeh Nazari · CEO
On clinic websites, schema markup usually sits as a JSON-LD block that a plugin generated automatically and nobody ever read: type "Organization", address missing, no specialty. Yet schema.org defines two types precisely for clinics, MedicalClinic and Physician, and Google's local business documentation explicitly recommends using the most specific subtype possible. This article explains how to set up these two types, which fields actually matter, and where the FAQ schema that clinic sites favoured for so long stands in 2026.
Let us draw a boundary first: structured data is not a ranking guarantee; it is a declaration that helps Google understand the page. Google's own documentation says repeatedly that correct markup does not guarantee a rich result. For clinics the value of schema is that Google recognises the clinic consistently as a place, a healthcare organisation and the holder of specific specialties; we covered consistency between Google Business Profile and the site in the GBP optimisation article.
MedicalClinic: the clinic itself
On schema.org, MedicalClinic sits under LocalBusiness, Organization and Place by way of MedicalBusiness and MedicalOrganization; it inherits every field of a local business and adds two specific ones: availableService (MedicalProcedure, MedicalTest or MedicalTherapy) and medicalSpecialty. Google's local business documentation lists only name and address as required; among the recommended fields are geo, telephone, url, openingHoursSpecification and priceRange.
The practical setup for a clinic: a single MedicalClinic block on the homepage; name identical to the name in Google Business Profile, address as a PostalAddress including the country code, geo coordinates matching GBP, telephone in international format, url the homepage. For medicalSpecialty use values from schema.org's MedicalSpecialty list (Dentistry, PlasticSurgery, Dermatology and so on); do not write free text. For availableService, define each treatment as a MedicalProcedure and give the URL of the related treatment page; repeat the same MedicalProcedure on the treatment page so that the two pages confirm each other.
On a multilingual site each language page carries name and description in its own language, but fields such as address, geo, telephone and url are language-independent and must be identical in all four languages. Seeing a Latin-script clinic name on the Arabic page and an Arabic name on the Turkish page is a contradiction for Google and a loss of trust for the user.
Links to the clinic's other identities are also established in this block: add the Google Business Profile link and the official social accounts to sameAs, so that Google matches the clinic on the site with the clinic on the map. In health tourism, one of the first places a patient looks is the Ministry's list of authorised facilities; showing the authorisation certificate on the visible page and adding it to the schema as an identifier improves consistency, but never write a title on the page or in the schema that the certificate does not state.
Physician: doctors as separate entities
In health tourism the patient often chooses a doctor rather than a clinic. On schema.org, Physician is also a MedicalBusiness and LocalBusiness subtype, and it carries the hospitalAffiliation, medicalSpecialty and availableService fields. One Physician block on each doctor page: name, image, medicalSpecialty and the doctor page as url. Link the doctor block to the clinic with parentOrganization; the hospitalAffiliation field expects a Hospital type, so use it only if the doctor really is affiliated with a hospital. This link lets Google understand the doctor as part of the clinic.
There is a second boundary here: Turkey's regulation on promotion in healthcare services determines what can be written on doctor and clinic pages, and schema fields fall within its scope. Writing text into the description field that promises a treatment outcome or claims comparative superiority has the same legal consequence as writing it on the visible page. Keep the schema limited to text the legal team has seen.
FAQ schema: what is left in 2026
For a long time the most widespread schema type on clinic sites was FAQPage, because it produced a rich result that took up space on the results page. That is no longer the case. Google announced in August 2023 that it was limiting FAQ rich results to authoritative sources; Google Search Central's update log then states in its entry dated 8 May 2026 that the feature would no longer appear in Google Search from 7 May 2026, and in its entry dated 15 June 2026 that the FAQ rich result documentation was removed entirely.
The practical consequence: FAQPage markup remains a valid type on schema.org but produces no visibility feature on Google. If the question-and-answer section on the page is valuable to users, it should stay; there is no longer a reason to spend extra effort on its schema or to pay for a plugin. The same log also lists HowTo as removed in 2023 and other types such as course and salary in 2025 and 2026; rather than setting a schema strategy once and forgetting it, this log needs to be read a few times a year.
Review and rating: handle with care
Google's local business documentation counts aggregateRating and review among the recommended fields. For a clinic, two constraints overlap here: Google's own review rules and the approach of Turkey's promotion regulation to patient opinions. We covered how patient reviews can be used from an E-E-A-T angle in the patient reviews and E-E-A-T article; the short rule is to put only content in the markup that you really display on the page, that has a clear source and that complies with the regulation.
Treatment pages: MedicalProcedure
The third piece that completes the clinic and doctor blocks is the MedicalProcedure on the treatment page. Fields such as name, description, bodyLocation and procedureType can be written here; but the regulatory limit on description is the same as described above. The block on the treatment page must carry exactly the same name as in the clinic block's availableService list; writing the name in English in one place and in Turkish in the other means two different services to Google. The price field needs separate attention: we covered the balance between regulation and conversion on price pages in a separate article, and writing a price into the schema is subject to the same rules as writing it on the page.
Testing and maintenance
After writing the block, test it with Google's Rich Results Test and the schema.org validator; the first checks what Google sees, the second checks the schema's syntax. The schema generator tool on our site can be used to fill in the fields and get the JSON-LD output. Adapting the generated block for each treatment page is more correct than copying a single block across the whole site; a copied block means every page claims the same thing.
On the maintenance side there are three regular jobs: checking the errors in Search Console's rich result reports monthly, reflecting address, phone and hours changes from GBP into the schema, and adding availableService for new treatment pages. These checks are fixed items in a technical SEO audit.
Conclusion
The right layout for clinic schema is one MedicalClinic on the homepage, one Physician on each doctor page and one MedicalProcedure on each treatment page; all consistent with GBP, all limited to regulation-compliant text. FAQPage is no longer part of that layout; Google has not shown FAQ rich results since May 2026. What schema gives you is not ranking but consistency, and the return on consistency shows only over months and only when it is set up correctly.