AI search visibility for regulated products
A page structure spec for answer-engine retrieval
A buyer asks an assistant which home oxygen concentrators a distributor can supply, or what a spinal implant system is indicated for. The assistant answers in four sentences and cites two pages. Most device manufacturers will not be one of them, and the usual reason is the shape of the page.
Answer engines retrieve passages, not pages. A product page built as a hero image, a PDF brochure and a “request a demo” form gives a retrieval system very little it can lift. The page below is built the other way round.
What should a regulated product page look like to an answer engine?
A stack of self-contained sections, each headed by the question a buyer would ask and opened by a short answer that stands alone. The regulatory status sits near the top with its 510(k) number. Everything a buyer needs is in the HTML as served, with nothing hidden behind JavaScript, a PDF or a form.
The spec that follows makes it concrete enough for a web team to build against, section by section, with the markup and the rules that keep a regulated page defensible.
REGULATED PRODUCT PAGE: structure spec v1
One device family per URL. Server-rendered. Every section readable with JavaScript off.
<head>
title <Device name>: <generic device type> | <Manufacturer>
meta description one sentence: what it is, who uses it, regulatory pathway
link canonical self
JSON-LD Organization (sitewide)
Product + MedicalDevice (this page): describe visible content only
BreadcrumbList
§1 H1 <Device name> <generic device type>
§2 Answer block 40 to 60 words, no heading, directly under the H1:
what it is · who uses it · setting · regulatory status · how it is obtained
§3 Regulatory status (visible, not a footnote)
pathway: 510(k) | De Novo | PMA | exempt
number: K______ / DEN______ / P______ → link to the FDA database record
product code, decision date
"cleared" only with a K or DEN number; "approved" only with a P number
§4 H2 What is <device> used for?
indications for use, quoted verbatim from the clearance. Nothing broader.
§5 H2 Who uses <device>, and who orders it?
user · prescriber or specifier · purchaser · care setting
how to buy: direct, named distributor locator, or both
§6 H2 How does <device> work?
mechanism in plain language; one diagram with alt text that says the same thing
§7 H2 What are the specifications?
HTML <table>, not an image and not only a PDF
model numbers / SKUs as text so they can be matched exactly
§8 H2 What evidence exists for <device>?
published studies and trial registry IDs, each linked
no statement that goes beyond the cleared indication
§9 H2 How is <device> supplied and supported?
packaging, configurations, training, service, IFU (HTML page + PDF)
§10 H2 Questions buyers ask about <device>
3 to 6 real questions from sales and support logs
each answer self-contained, 40 to 60 words, no "as noted above"
§11 Page facts last reviewed <date> · reviewed by <role: regulatory, not marketing>
change log of material edits
SITE LEVEL
robots.txt decide each token deliberately and write the decision down:
search crawlers OAI-SearchBot · Claude-SearchBot · PerplexityBot
training / control GPTBot · ClaudeBot · Google-Extended
declare the sitemap
sitemap product URLs listed under a stable /products/<slug> pattern
WAF / bot rules verified crawler IP ranges allowed through; test with each published UA
/llms.txt optional; a curated index of product and IFU URLs if kept at allWhat does the teardown show device sites doing now?
Very little of it. Across 52 manufacturer sites drawn from recent 510(k) applicants, no homepage carried Product, MedicalDevice or FAQPage markup. Only 3 of 19 product pages used a question-form heading. Just 2 sites named any AI crawler in robots.txt, which means the other 50 made no explicit decision.
The broader picture is uneven. Structured data exists, but it is mostly the generic kind a content management system emits by default. Organization markup appeared on 21 of 52 homepages, and any JSON-LD at all on 25. On product pages, Product markup appeared on 3 and MedicalDevice on 2, out of 19 where a product page could be found through the site’s own sitemap.
Some of the basics are in better shape. Meta descriptions were present on 43 homepages, and 17 of 19 product pages had exactly one H1. Only 5 homepages served fewer than 150 words of text before JavaScript ran, so the fear that device sites are invisible shells is mostly unfounded in this sample.
The /llms.txt file, much discussed, appeared on 7 of 52 sites. Question-form headings, which cost nothing to write, appeared on just 5 homepages.
Why do question headings matter more than schema?
Because retrieval works on passages, and a heading is what tells a parser where one passage ends and the next begins. Schema describes a page; a question-headed section with a short answer is the unit an engine actually lifts. Google now says no special markup is needed for its AI features.
Google’s guidance on AI Overviews says a site does not need “new machine readable files, AI text files, or markup” to appear, and lists structured data that matches the visible text among its basic practices. Google also retired the FAQ rich result in May 2026. A page that leaned on FAQPage markup for visibility lost that return, and nothing in Google’s guidance replaces it with another markup trick.
Carmine’s view is that this strengthens the case for the spec. The markup in the spec is hygiene: it describes what a reader can already see. The work is in §2 and §4 to §10, where every section can be lifted out of the page and still make sense. That is the same discipline this site applies to its own articles, described in the P3 pillar.
The FAQ block in §10 survives the retirement for a different reason. Sales and support logs contain the questions buyers ask before they call. Answering them on the page, in the buyer’s own words, is how those questions get matched.
Which AI crawlers should a device site allow?
Treat search crawlers and training crawlers as separate decisions. OpenAI, Anthropic and Perplexity each publish a search crawler that controls whether a site can appear in their answers, distinct from crawlers or tokens tied to model training. Blocking the wrong one removes a site from answers it wanted to be in.
The vendors are explicit about this. OpenAI’s documentation says sites opted out of OAI-SearchBot “will not be shown in ChatGPT search answers”, and that each of its robots settings is independent. Anthropic documents Claude-SearchBot separately from ClaudeBot. Perplexity says PerplexityBot is not used to crawl content for foundation models. Google-Extended is a control token rather than a separate crawler.
In the teardown, 2 of 52 sites named any of these tokens, and both blocked at least one. The remaining sites inherit whatever their wildcard rule says, which is a decision made by default. A regulated manufacturer may reasonably choose to refuse training crawlers and allow search crawlers. It should make that choice on purpose, write it down, and review it when vendors change their tokens.
The quieter problem sits in front of robots.txt. Of 65 candidate domains, 8 refused a declared, non-browser user agent at the homepage before any robots rule applied. A bot-protection layer that blocks every unfamiliar agent also blocks the crawlers a site has allowed. The spec’s WAF line exists for that.
How does the spec keep a regulated page defensible?
By tying every claim on the page to a record a reviewer can check. §3 puts the 510(k) number next to the word “cleared” and links it to the FDA database. §4 quotes the cleared indication verbatim. §8 links evidence instead of summarising it. §11 names who reviewed the page and when.
Answer engines compress. A page that says slightly more than its labelling will be compressed into an answer that says more again. The only safe input is one where the widest statement on the page is the cleared indication itself, quoted, with the source one click away. The open 510(k) data this relies on is the same file behind where new device competitors are entering.
The same logic applies to evidence. §8 lists studies and registry identifiers rather than paraphrasing results, which keeps marketing out of the business of restating clinical findings. Carmine’s analysis of who generates device clinical evidence is a useful check on what a category actually has to cite.
§5 is the section most device pages skip. It separates the user, the person who prescribes or specifies, and the organisation that pays, and it says how a buyer actually gets the product. In a distributor business that answer is the difference between a cited page and a dead end, and it mirrors the separation in Carmine’s lead-source schema for distributor channels.
Where does the spec break?
Four places. Families with dozens of configurations, where one URL per family stretches §7 too far. Multi-country sites, where the cleared indication differs by market. Products sold only through a distributor, where §5 depends on data the manufacturer may not hold. And any site whose review process cannot keep §11 honest.
Large families. When a family carries many sizes and variants, keep one page per family and move the full matrix to a linked specification page with its own §7 table. Splitting every variant into its own URL produces pages too thin to answer anything.
Multiple markets. A page that serves several regulatory regimes has to state which one each indication belongs to. Mixing them on one URL is how a page ends up describing an indication that is not cleared where the reader sits.
Distributor-only products. If the manufacturer does not know who stocks the product in a given region, §5 should say how to find out rather than guess. A wrong distributor name in an answer is worse than none.
Review capacity. §11 is a promise. A “last reviewed” date that never changes tells a careful reader the page is not maintained. If regulatory review cannot be scheduled, publish fewer pages and keep them current.
How was the teardown run?
The sample frame was openFDA 510(k) applicants with decision dates from 2023-01-01 to 2025-12-31, taking the first 30 applicant names in each of three review panels: Orthopedic, Physical Medicine and Anesthesiology. That produced 90 applicant strings, mapped by hand to 65 candidate domains.
A candidate was accepted only if its homepage returned a 200 response and a verification token from the applicant’s name appeared in the homepage HTML. That left 52 measured sites; 13 candidates were excluded, and 21 applicant strings had no identifiable public domain. Every mapping and exclusion reason is recorded in the teardown file.
For each accepted site the teardown fetched the homepage, /robots.txt, /llms.txt and one product page, chosen mechanically as the first product URL in the site’s own sitemap. It parsed JSON-LD types, H1 to H3 headings, meta tags and the visible text in the HTML as served. robots.txt rules were evaluated with a standard parser for each crawler token. The run date was 2026-09-30.
What can this teardown not tell you?
It measures whether a structure is present and cannot say whether it works. Nothing here shows that a question heading or a Product block causes a citation, and the sample is too small to test it. The teardown describes current practice, and current practice is not evidence of what engines reward.
The product-page figures rest on 19 pages, one per site, chosen by a sitemap rule rather than by hand. A few of those selections are catalogue or category pages rather than a single device, and the rule was left alone rather than corrected site by site. Treat the product-page shares as indicative.
The sample also leans toward larger filers, because it takes the applicants with the most recent clearances in each panel. Many Physical Medicine applicants had no identifiable domain and fell out, so that panel is under-represented. Raw HTML was measured as served; engines differ in whether they execute JavaScript, and robots.txt states a request to crawlers without recording their behaviour.
What is the smallest first step?
Pick the product page that sales sends most often. Add the §2 answer block and the §3 regulatory status with its linked 510(k) number, then rewrite the existing headings as the questions buyers ask. That is an afternoon of work and it makes the page citable before any markup changes.
Then make the robots.txt decision explicit. List the search crawlers and the training tokens, decide each one, and test that the bot-protection layer lets the allowed ones through. Only after that is it worth adding Product and MedicalDevice markup, because markup should describe a page that is already worth describing.