Structured data for treatment pages
Structured data is a description of what is already on the page, written so a machine can read it without guessing. That sentence contains the whole discipline.
PrerequisitesModule 10 · Treatment page anatomyModule 13 · Risks and aftercare
Mark up a treatment page with MedicalWebPage describing the page, a MedicalProcedure describing the treatment, the clinic as the provider, a BreadcrumbList showing where the page sits, and FAQPage only for questions that genuinely appear on the page with their answers. Structured data describes what is present; marking up anything that is not visible on the page is a policy breach and, more practically, a lie told in a machine-readable format.
What you will be able to do
By the end of this module you will be able to:
- Write valid JSON-LD for a clinic treatment page.
- Choose the correct types and know which properties are worth filling.
- Understand the rule that markup must reflect visible page content.
- Test markup and interpret the results without over-reacting to warnings.
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.
Mark up one treatment page
Seventy five minutes. You will need to be able to edit the head of one page, or use whatever facility your site builder gives for custom code.
- Write the MedicalWebPage block for your rebuilt treatment page: name, description, date reviewed, language.
- Add the about property as a MedicalProcedure, using the same wording as the page itself.
- Write the clinic entity once, on the homepage, and check it against your Business Profile character for character.
- Add BreadcrumbList matching the visible breadcrumb. If there is no visible breadcrumb, add one to the page first.
- Add FAQPage only if the page has a visible question and answer section.
- Test with both the Rich Results Test and the Schema Markup Validator. Fix errors. Ignore warnings about optional properties.
Once one page is correct, it becomes the template for the rest. Do not hand-write markup for thirty pages; make the template produce it.
Questions readers ask about this module
Will structured data improve my rankings?
Not directly. It can affect how a result is displayed, which affects whether it is clicked, and it removes ambiguity about what your pages are. Treating it as a ranking device leads to over-marking, which is the failure mode this module spends most of its length preventing.
Should I mark up reviews?
Only if the reviews are collected and displayed on your own page, and only within the specific rules for review snippets. Marking up a rating aggregated from elsewhere, or displaying it only in the markup, is the exact case the guidelines prohibit.
Is JSON-LD better than microdata?
It is the format Google recommends and it is far easier to maintain, because it sits in one block rather than being woven through the HTML. There is no benefit to microdata on a new build.
How often should markup be reviewed?
When the page content changes, and once a quarter as part of the review in Module 31. The common failure is markup that was accurate when written and now describes a page that has since been rewritten.
What to do next
Mark up one rebuilt treatment page, in this order, and stop there until it validates:
- MedicalWebPage for the page itself: name, description, date reviewed, language.
- An about property as MedicalProcedure, worded exactly as the page words it.
- The clinic entity written once, on the home page, matching your Business Profile character for character.
- BreadcrumbList matching a breadcrumb the reader can actually see.
- FAQPage only where a visible question and answer section exists.
- Both the Rich Results Test and the Schema Markup Validator run, errors fixed, warnings about optional properties ignored.
The page this markup describes is built in Module 10, and the rest of this part is listed on the treatment page architecture hub. Markup is a description of what the page already says, so the page comes first and the markup follows it.
The JSON-LD templates for each block above are part of the template pack described on the workbook page. The workbook of exercises is free by email; the template pack is a paid one-off upgrade offered in that first email. Structured data does not raise rankings by itself, and we claim nothing of the sort for the templates.
Sources and primary references
Disclosure. This module links to our own workbook and template pack, which is one of the two ways this course is funded. It carries no affiliate, referral or paid third party links of any kind. This course is independently published, is free to read, and is funded by the workbook pack and by clearly labelled series sponsorship. We do not rank, review or recommend agencies or clinics.
Module 14 of 32