Treatment pages that survive being quoted: how to build one

What does a passage lose when it leaves the page?

Everything around it. When an answer quotes a page, what appears is a sentence or a paragraph and, where the answer shows its sources, a link. The heading above the passage, the practice's logo, the address in the footer and the fee table further down do not come along. A sentence that leaned on any of them arrives in the answer saying less than it did on the page, or something that was never true.

Each rewrite is a few words longer and reads a little formally on the page. That is the trade: a sentence that carries its own subject, place and date can be quoted without the rest of the page and still say what the practice means. Citability is the name for that property, and on a treatment page it is built one sentence at a time.

The answer goes in the first sentence

Every heading on a treatment page is a question a patient asks, and the sentence under it answers that question before anything else. Which questions those are, and what each answer should say, is set out in a page for each treatment, and the pages a practice needs besides are in the overview for physiotherapy practices. How an answer paragraph is shaped is in writing to be cited, and the heading structure in structuring content for AI. On a treatment page it comes down to one habit: the fact first, the explanation after.

The top of the page follows the same rule. Its first paragraph, under the h1, says what the treatment is, that this practice provides it and where: "[Practice name] in [town] offers manual lymphatic drainage, given by [therapist names and titles]." A patient who reads nothing else knows whose page it is, and so does any passage lifted from that paragraph. A page that opens with "Welcome to our clinic" spends its most quotable sentence on nothing.

Named, placed and dated

Three kinds of words make a passage attributable, and they belong in the passage, not only in the page around it. The practice's name, written the same way on every page, tells a reader whose statement it is. The place, meaning the town and the location where a practice has more than one, tells them where it holds. And a date on every fact that changes (fees, session lengths, hours, which therapist provides what) tells them when it held.

Put the dates where a reader sees them: "Fees as of [month, year]" beside the fee, and "Last reviewed [date] by [name, title]" at the foot of the page. The same dates go into the markup. schema.org defines lastReviewed and reviewedBy on WebPage for exactly this, the date the content was last checked for accuracy and who checked it, alongside dateModified for when it last changed. Move the review date only when someone has checked the facts; a date a template refreshes every night says nothing about freshness.

In the HTML the server sends

A passage has to be in the page's HTML to be lifted from it, and on a treatment page facts can slip out of the HTML in small ways: a fee inside an image, session lengths in an accordion that a script fills only when clicked, therapist profiles in a carousel loaded by script, a fee schedule kept as a PDF. An accordion is fine when its text is in the HTML and only folded away; the problem is text fetched only when someone clicks.

The crawler behind our figures ran no JavaScript. In our audit of 9,483 small business websites (40 trades, 90 metros, late August to early September 2026), 3.0% rendered their content only in JavaScript, and 2.1% kept real content, such as a price list, in a PDF; neither figure is specific to physiotherapy. Google renders scripts as a separate, deferred step, as its JavaScript documentation explains, and the assistants' crawler documentation describes no such step.

To test a page, view its source, or fetch it with curl, and search the result for the fee and the session length. If they are not there, a fetcher that runs no scripts does not see them either. Moving a fee schedule out of a file is covered in the PDF trap.

Markup that repeats the page

The markup, the page's structured data, says in schema.org's vocabulary what the page already says in words, and nothing more. Google's introduction to structured data recommends JSON-LD, asks for markup of visible content only; its general guidelines add that a correctly marked-up page is still not guaranteed a feature. A physiotherapy practice has a type of its own: Physiotherapy, a subtype of MedicalBusiness. The practice's node lives on the homepage or the location page, under one @id that every other page refers to, the way building an entity describes.

{
  "@context": "https://schema.org",
  "@type": "Physiotherapy",
  "@id": "https://www.example.com/#practice",
  "name": "[Practice name]",
  "url": "https://www.example.com/",
  "telephone": "[main number]",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "[street and number]",
    "addressLocality": "[town]",
    "addressRegion": "[state or province]",
    "postalCode": "[postal code]",
    "addressCountry": "[two-letter country code]"
  },
  "openingHoursSpecification": [{
    "@type": "OpeningHoursSpecification",
    "dayOfWeek": ["Monday", "Tuesday", "Wednesday", "Thursday"],
    "opens": "[07:00]",
    "closes": "[20:00]"
  }]
}

A treatment page then carries three nodes of its own: the page, with its dates and its reviewer; the treatment, as a Service the practice provides, with the fee as an Offer; and the therapist, as a Person with the title and license the page states.

{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "WebPage",
      "@id": "https://www.example.com/lymphatic-drainage#page",
      "name": "Manual lymphatic drainage at [Practice name], [town]",
      "about": { "@id": "https://www.example.com/lymphatic-drainage#service" },
      "dateModified": "[YYYY-MM-DD]",
      "lastReviewed": "[YYYY-MM-DD]",
      "reviewedBy": { "@id": "https://www.example.com/team/[name]#person" }
    },
    {
      "@type": "Service",
      "@id": "https://www.example.com/lymphatic-drainage#service",
      "name": "Manual lymphatic drainage",
      "provider": { "@id": "https://www.example.com/#practice" },
      "offers": {
        "@type": "Offer",
        "price": "[fee]",
        "priceCurrency": "[currency code]",
        "description": "One session of [minutes] minutes. Fees as of [month, year]."
      }
    },
    {
      "@type": "Person",
      "@id": "https://www.example.com/team/[name]#person",
      "name": "[Therapist name]",
      "jobTitle": "[title, as the licensing body writes it]",
      "worksFor": { "@id": "https://www.example.com/#practice" },
      "hasCredential": {
        "@type": "EducationalOccupationalCredential",
        "credentialCategory": "license",
        "recognizedBy": { "@type": "Organization", "name": "[licensing body]" }
      }
    }
  ]
}

What the blocks leave out is deliberate. There is no aggregateRating: Google's local business documentation recommends it only for sites that capture reviews about other businesses, and its review snippet rules treat reviews a business controls about itself as self-serving. There is no isAcceptingNewPatients, availableService or medicalSpecialty, because schema.org defines those for other medical types and not for Physiotherapy; the referral policy and the plans billed stay in the text.

Nor is there a PhysicalTherapy node. schema.org has one, a type for the therapy as a medical concept, and its properties include contraindications and serious adverse outcomes. A page that makes no clinical claims has nothing true to put in them, and markup should never say more than the page. Where each block goes and how to test it is in setting up schema.org correctly.

Which of your pages do the answers cite?

Only the answers can say, and only those that show their sources; AI search engines at a glance sets out which assistants show them and how. An answer written from what a model learned in training may show no source at all, so a missing citation proves nothing about whether a page was read.

1. Run the panel from what being named means for a physio practice on four assistants, three runs each, the same questions monthly; our methodology runs a narrower one for clients, twelve questions put to Claude at the baseline, again once the fixes are live and every month with monitoring.
2. For every answer that shows sources, copy each source URL into the record beside the verdict, in the order the answer lists them.
3. Mark each URL as yours, a directory or booking platform, another practice, or something else, and for yours note which page it is: a treatment page, the homepage, the fees page, a therapist's page.
4. Once a month, count per page how many answers cited it, for which questions and from which assistant.
5. Read every answer that cites one of your pages against that page, fact by fact. A citation shows the page was drawn on, not that it was quoted correctly.

None of this says why an answer chose a page. It says which pages carried the practice into answers and which never did, month by month, and that is enough to decide which page to fix next. Each cited URL is an AI citation you can count; the reasons behind it are not something the record can hold.