Structured data for treatment pages

What structured data actually is

It is a block of machine-readable description embedded in the page, using a shared vocabulary defined at Schema.org, saying explicitly what the page and its subject are. It does not make a page rank. It makes a page legible, which is a different and more durable benefit.

The practical value for a clinic is that it removes ambiguity about three things a search engine would otherwise infer: what kind of thing the page is about, which organisation provides it, and where the page sits in the site. Inference is usually right. Explicit is always right.

The nesting for a treatment page

In practice this is a single JSON-LD script in the head of the page. The shape:

• MedicalWebPage as the outer type, with the page's name, description, the date it was last reviewed, and the language.
• about: MedicalProcedure, naming the treatment, describing how it is performed and what it is used for, in the same words as the page.
• provider, pointing at the clinic entity described in the next section.
• BreadcrumbList as a separate block, mirroring the visible breadcrumb trail.
• FAQPage as a separate block, only if the page carries a genuine question and answer section.

Do not attempt to fill every available property. A small number of accurate properties is worth more than a large number of guessed ones, and several of the medical properties in the vocabulary are for clinical reference works rather than for clinic websites.

The clinic as an entity

Your clinic should be described once, consistently, as a MedicalClinic or the appropriate LocalBusiness subtype, with its name, address, telephone number, opening hours and URL. That description should match your Business Profile and every directory listing character for character, which is the consistency problem covered in Module 27, Citations and the consistency problem.

Put this block on the homepage and reference it from other pages rather than repeating a slightly different version on each. Repetition is how inconsistencies enter, and inconsistency is the thing this markup exists to prevent.

FAQ markup, and its limits

FAQ markup is legitimate where a page carries real questions with real answers, visible to the reader. It is not a device for inserting keyword variations into a page, and treating it as one is both against the guidelines and pointless, since the questions must appear visibly anyway.

Two constraints worth knowing. The questions must be ones the site is answering, not ones users can submit answers to. And how any of this is displayed in results is entirely at the engine's discretion and changes over time, so the reason to do it is legibility rather than a promised appearance.

The rule that governs everything

Markup must describe content that is present and visible on the page. This single rule resolves almost every question a clinic will have about structured data.

If you would have to add something to the markup that a reader cannot see on the page, the answer is not to add it to the markup. It is to add it to the page, or to leave it out.

The temptations are predictable: marking up review ratings the page does not display, marking up prices that are not published, marking up a procedure the clinic does not perform. All three are breaches of the structured data guidelines, all three risk the markup being ignored across the whole site, and all three are, in ordinary language, false statements in a format designed to be trusted.

Testing, and which warnings matter

Two tools matter: the Rich Results Test for whether an engine can parse and use the markup, and the Schema Markup Validator for whether the markup is valid against the vocabulary. They disagree usefully, because the first tells you what is supported and the second tells you what is correct.

Errors matter. Warnings usually do not: most warnings are about optional properties you have chosen not to fill, and filling them with guesses to clear a warning is exactly the wrong response. The Search Console report for structured data is the one to watch over time, because it tells you when something that was working has stopped, which is usually a symptom of a template change elsewhere.

Module 31, What to measure, and what to ignore deals with the wider question of what to monitor and how often, and structured data belongs in that monthly review rather than in a weekly anxiety.