MedicalProcedure Markup on Treatment Pages: What Google Reads and What It Ignores

This post is for SEO leads and developers who maintain treatment pages for clinics and hospitals, such as knee replacement, cataract surgery, endoscopy or IVF cycles, and who have been told to "add MedicalProcedure schema". It assumes you have already read a general guide to healthcare markup and want to know what each property is for, what to leave out, and what the markup can honestly be expected to do.

It answers three questions. Which MedicalProcedure properties map to content that a treatment page really contains? Which of them does Google act on, and which are only vocabulary? And how do you build the markup so it stays truthful after the clinical team edits the page?

The earlier articles on this site, including the complete implementation guide, the implementation guide and the advanced markup piece, cover syntax and the wider set of types. This article goes property by property on one type.

What Google reads and what it ignores

Start with the unglamorous fact. Google's structured data gallery lists the features that can change how a result looks, and none of them is a medical procedure feature. There is no rich result you earn by marking up a procedure.

That does not make the markup worthless, but it changes what you promise. Google's general structured data guidelines say it does not guarantee that markup will appear as a feature, and its 2023 note on FAQ and HowTo changes said that unused structured data causes no problem for Search but has no visible effect. For a type with no feature, that is the realistic expectation: no visible effect in Google's result pages.

What remains is a modest, defensible benefit. The markup is a machine-readable restatement of what the page already says. It may help a crawler, a parser or an AI tool identify that the page is about a named procedure, performed on a body part, with a preparation and a follow-up. We cannot show that any specific system uses these fields, and nothing in Google's documentation says it does. If someone promises a ranking lift from MedicalProcedure, ask for the evidence.

The rule that does apply is the visibility rule: do not mark up content that readers cannot see on the page. Every value you emit should be traceable to words on that URL.

The type tree matters more than you think

MedicalProcedure sits under MedicalEntity. Its direct subtypes are DiagnosticProcedure, PalliativeProcedure, PhysicalExam, SurgicalProcedure and TherapeuticProcedure. MedicalTherapy is a subtype of TherapeuticProcedure.

Choose the most specific subtype that is true.

• A biopsy or an endoscopy to examine something is a DiagnosticProcedure.
• An operation such as a joint replacement is a SurgicalProcedure.
• A course of treatment such as radiotherapy or physiotherapy fits MedicalTherapy and its subtypes, for example RadiationTherapy and PhysicalTherapy.
• When nothing more specific is accurate, use plain MedicalProcedure.

The classification is a clinical judgement as much as a markup one. Ask the department to confirm it, and record the answer in the content register so it does not change by accident.

Property by property

The properties below are those the schema.org page defines specifically for MedicalProcedure. Each row says what to put in, where it comes from on the page, and the main trap.

procedureType

The value is a member of the MedicalProcedureType enumeration, which contains NoninvasiveProcedure and PercutaneousProcedure. SurgicalProcedure is not a member; it is a type. A common mistake is to write "procedureType": "SurgicalProcedure". If you want to say that a procedure is surgical, give the node the type SurgicalProcedure. If you want to say it is noninvasive or percutaneous, use the enumeration. Where neither fits cleanly, leave the property out rather than forcing a value.

bodyLocation

It takes text, so consistency is your job. Decide on a vocabulary, for example "knee" rather than a mix of "knee joint", "knees" and "genu", and keep it in one field in the CMS. The same discipline helps your internal search, your breadcrumbs and your condition and treatment SEO work.

preparation, howPerformed and followup

These three correspond to the sections that good treatment pages already have. Use them as summaries of those sections, in plain sentences, not as places to paste entire paragraphs. Keep them factual and neutral. Clinical instructions such as fasting times or medication changes must come from the clinical team's approved text. If the page says "your doctor will advise", the markup should not say anything more specific.

followup deserves care. Recovery language often drifts towards outcomes: "return to work in a week", "pain free". A marketer should not write those claims, and a schema field is not a loophole. If the provider's clinical team has approved a statement on the page, you may summarise it; otherwise leave the field empty.

status

The definition on schema.org describes the status of a study. It is not a hook for "now available" or "new". Omit it.

Properties inherited from MedicalEntity

Your procedure also inherits a few useful properties from MedicalEntity.

• code takes a MedicalCode: a code and the coding system it comes from. If your billing or clinical teams already use a recognised code set for the procedure, this gives you a precise identifier. Use only codes the clinical or coding team has confirmed for that exact procedure. A wrong code is worse than no code.
• relevantSpecialty takes a MedicalSpecialty and ties the procedure to a department.
• guideline, recognizingAuthority and study exist but are heavy. Add them only when the page visibly cites a guideline or study.

From Thing, add url, description (a one-sentence summary of the visible intro) and sameAs pointing to a stable external reference only when you are certain it describes the same procedure.

Connecting the procedure to the hospital and the page

A procedure node on its own is a label. To make it useful, connect it.

• On the hospital or clinic node, availableService lists the procedures offered at that facility. On Hospital, the expected value is a MedicalProcedure, MedicalTest or MedicalTherapy. Reference the procedure by @id, not by repeating its body.
• On the page node, use mainEntity or about to say what the page is about. A treatment page is mainly about the procedure.
• If a clinician has reviewed the page, reviewedBy and lastReviewed are defined on WebPage. Use them only when the visible page shows the same reviewer and date.

That last step is a trust signal for humans first. Our E-E-A-T authority building work treats visible review dates and named reviewers as content, and the markup follows the content.

A worked example, clearly hypothetical

Take a cataract surgery page at an imagined eye hospital. The content register, approved by the department, holds: name "Cataract surgery"; alternate name "Phacoemulsification" only if the page uses that word; classification SurgicalProcedure; body location "eye"; relevant specialty ophthalmology; reviewer and review date as shown on the page.

The preparation summary is whatever the page says in its preparation section, no more. If the page only says that the team will give written instructions at the pre-surgery assessment, the field says that. The follow-up summary says that a review visit is arranged, if the page says so, and nothing about vision outcomes.

This looks sparse, and it should. A sparse, true node is better than a rich, speculative one. If an editor later adds a new paragraph on anaesthesia options, the template picks it up only when someone adds a field for it, which forces a conversation about whether it belongs in the markup.

Build it from fields, not from prose

The reliable way to keep markup honest is to generate it from structured fields in the CMS, not to write JSON by hand per page.

1. Create fields for procedure name, alternate names, classification, body location, preparation summary, how performed, follow-up summary, specialty and reviewer.
2. Render the visible page from the same fields, so the page and the markup cannot drift apart.
3. Make the schema template skip any empty field instead of emitting an empty string.
4. Validate a sample of generated pages with the Rich Results Test and the Schema Markup Validator. The first checks eligibility for Google features and will not show a MedicalProcedure feature, which is expected. The second checks that the vocabulary is valid.

Our schema markup service page describes how we add such fields to a build.

Failure modes to test for

• The classification field is blank and the template falls back to plain MedicalProcedure on pages that are plainly surgical.
• bodyLocation is a free-text field that editors fill differently each time.
• Preparation text in the markup was updated by the clinic but the visible page was not, or the reverse.
• A procedure is listed under availableService on a facility where it is no longer performed.
• Recovery summaries contain promises that the clinical team has not approved.

Decision rule for this quarter

Mark up the procedure types you already have clean content for, using only fields that exist on the page, and ask the clinical team to approve the classification and the three summaries. Treat the result as a labelling exercise, not a growth lever. If the content is thin, fix the content first; markup on thin content just describes a thin page precisely.