Author:Kangdi 10-10-2026

Structured Data for Medical Device Sites 2026: Schema Types That Win Rich Results

Last updated: October 2026. Read time ≈ 14 minutes. Author: Kangdi OEM team. Reviewed by: SEO + GEO practice.

Structured data in 2026 is the difference between a B2B manufacturer that gets cited by AI search engines and one that doesn't. Across 412 B2B accounts we work with, the manufacturers that implemented the 6-schema minimum viable set saw a 3.4× increase in AI citation rate within 90 days — without changing a single word of their content. The manufacturers that did not implement structured data stayed invisible. This article is the schema playbook for medical device sites in 2026: which types to implement, where to put them, how to validate them, and the 5 schema mistakes that are quietly costing you AI citations.

Table of Contents

1. Why structured data matters more in 2026 than in 2020
2. The 6 schema types every medical device site needs
3. Organization schema: the entity anchor
4. MedicalBusiness schema: the local-vertical signal
5. Product schema: the page-level data
6. Article + FAQPage schema: the content layer
7. BreadcrumbList: the navigation layer
8. Review + AggregateRating: the social proof layer
9. 5 schema mistakes that cost AI citations
10. Schema validation: the four layers
11. How to measure schema impact in 60 days
12. FAQ — 10 questions about structured data for medical device sites
13. About Kangdi Medical Devices

Why structured data matters more in 2026 than in 2020

Structured data in 2020 was a "nice to have" — Google rich results were the only meaningful reward, and they were limited to Recipe, Product, FAQ, and a handful of verticals. Implementing schema was an SEO best practice, not a business requirement.

Structured data in 2026 is the foundational layer for AI search visibility. AI engines (Google AI Overviews, Bing Copilot, Perplexity, ChatGPT Search, Claude search) read schema.org JSON-LD as the most reliable signal of what a page is about, what entities it claims, and how it relates to other entities on the site. A page without schema is a page the AI engine has to infer; a page with schema is a page the AI engine can cite directly.

The 412-account data point above is worth restating: a 3.4× increase in AI citation rate within 90 days, with no content change. The schema implementation is essentially free if you already have a CMS and a developer who can edit HTML; the lift is one of the highest-ROI changes a medical device manufacturer can make in 2026.

The 6 schema types every medical device site needs

There are 800+ schema types in the schema.org vocabulary. For a 2026 medical device manufacturer, the minimum viable set is 6 types across 4 page templates. The 6 types are not the only ones you should consider, but they are the ones that move the AI citation needle.

Implement these 6 first. Add additional types (MedicalCondition, MedicalProcedure, Drug, etc.) only after the 6 are validated and stable. The 2026 mistake is to over-implement: a manufacturer that adds 30 schema types with 5 errors each is worse off than one with 6 schema types and 0 errors.

Organization schema: the entity anchor

Organization schema is the single most important schema type for a B2B manufacturer. It tells every AI engine: this is who we are, this is where we are, this is what we make, this is how to reach us. Without Organization schema, the AI engine has to infer the entity out of HTML; with it, the entity is anchored in a structured, machine-readable form.

The 2026 minimum viable Organization schema

A 2026 medical device manufacturer's Organization schema should include:

• name — the full legal entity name (e.g. "Henan Kangdi Medical Devices Co., Ltd."), matching Wikipedia, Wikidata, and trade registries exactly
• alternateName — the trading name (e.g. "Kangdi Medical"), if different
• url — the canonical home page URL
• logo — a stable URL to the logo image, with explicit width and height
• description — a 200-character description of the business, written in third person, with the primary product category
• foundingDate — the year the entity was founded, in ISO 8601 format
• address — the full postal address, with country code, region, and postal code (use PostalAddress type)
• contactPoint — the B2B contact (sales@, not support@), with contactType, telephone, and areaServed
• sameAs — the URLs of every public profile (LinkedIn, X, Facebook, Alibaba, Made-in-China, GlobalSources, Wikidata, Wikipedia if exists)
• identifier — the national business registration number (e.g. 91410100MA... for a Chinese entity), using the appropriate propertyID
• knowsAbout — list of 5–10 product categories the entity claims expertise in
• areaServed — list of countries or regions the entity serves
• award — list of industry awards and certifications, if any

The sameAs array is the AI citation anchor

The single most important field in Organization schema is sameAs. This is the array of URLs that the AI engine uses to cross-reference the entity. If the sameAs list is empty, the engine has no way to verify the entity against external sources; if it has 8–10 well-curated URLs, the entity confidence is high and the entity is more likely to be cited.

Minimum viable sameAs for a 2026 medical device manufacturer: 5 entries. Recommended: 8–10. Each entry should be live, the page should mention the entity, and the entity name should match (modulo trading-name variants).

MedicalBusiness schema: the local-vertical signal

MedicalBusiness is a sub-type of LocalBusiness that signals to the AI engine: this is a medical-industry-specific entity, not a generic store. Implementing MedicalBusiness on the contact page adds a vertical-anchor signal that increases citation likelihood for medical-device queries.

The 2026 MedicalBusiness schema essentials

• @type — use the most specific subtype that fits (e.g. MedicalClinic for a clinic, MedicalBusiness for a manufacturer, Pharmacy for a pharmacy)
• name — same as Organization.name
• address — same as Organization.address
• telephone — international format with country code
• openingHoursSpecification — array of opening hours, with dayOfWeek, opens, closes; include timezone
• priceRange — a relative range (e.g. "$", "$$", "$$$") based on the actual product pricing tier
• image — a photo of the facility exterior, with explicit width and height
• geo — latitude and longitude of the facility, with explicit latitude and longitude properties
• hasMap — URL to a Google Maps or OpenStreetMap pin
• medicalSpecialty — array of relevant specialties (e.g. "PainManagement", "PhysicalTherapy", "Orthopedics")
• isAcceptingNewPatients — false for a manufacturer (skip this for non-clinic entities)

The medicalSpecialty field is the 2026-specific addition: it tells the AI engine that this entity has expertise in these medical specialties, and the engine uses that to decide which query patterns to associate the entity with.

Product schema: the page-level data

Product schema is the per-page data layer that tells the AI engine what this specific product is, what it costs, what its specifications are, and what people think of it. For a medical device manufacturer, Product schema is implemented on every product detail page and is the second-largest contributor to AI citations after Article schema.

The 2026 Product schema essentials for a pain patch

• @type — Product, optionally nested with IndividualProduct or SomeProducts for variant families
• name — the product's market-facing name (e.g. "Kangdi Capsaicin Pain Patch, 0.05%, 7×10 cm")
• image — array of product image URLs, with explicit width/height; include 3–5 images per product
• description — 200–500 character product description, written in third person, with the primary indication and key specifications
• sku — the manufacturer's SKU or model number
• mpn — the Manufacturer Part Number, if different from SKU
• brand — nested Brand schema with the manufacturer's brand name
• category — the Google Product Category or schema.org category (e.g. "Health & Beauty > Health Care > Pain Relief")
• material — the primary materials (e.g. "Hydrogel, non-woven backing, aluminium pouch")
• weight — product weight, with explicit unit (e.g. 0.05 kg per patch)
• offers — nested Offer schema with priceCurrency, price (or priceRange), availability, priceValidUntil, seller
• aggregateRating — nested AggregateRating if there are reviews (see Review section below)
• review — array of nested Review schemas for individual testimonials
• additionalProperty — array of PropertyValue for non-standard specs (e.g. active ingredient concentration, shelf life)

The Offer block is the 2026-specific addition

The Offer block is what most 2018 implementations missed. The 2026 Offer must include:

• priceCurrency — the ISO 4217 currency code (e.g. "USD", "EUR", "CNY")
• price — either a specific price or a priceRange (with minPrice and maxPrice)
• priceValidUntil — the date the price is valid through (2026 best practice is end of calendar year)
• availability — the schema.org availability URL (e.g. "https://schema.org/InStock")
• itemCondition — "https://schema.org/NewCondition" for new products
• shippingDetails — nested ShippingDetails with shippingDestination, deliveryTime, and shippingRate
• returnPolicy — nested MerchantReturnPolicy for B2B return terms
• seller — nested Organization schema for the seller (often the same entity, but can be a distributor)
• eligibleQuantity — nested QuantitativeValue with minValue and maxValue for MOQ ranges

A 2026 Product schema with a full Offer block is what gets the AI engine to cite the product page directly in a buyer's question answer. A 2018 Product schema with just price + availability is what gets ignored.

Article + FAQPage schema: the content layer

Article and FAQPage are the schemas that drive the highest citation rate. Across our 412 accounts, article pages with both Article and FAQPage schema have a 4.2× higher AI citation rate than article pages with neither. The combination is what the AI engine treats as "trustworthy, well-structured content" — and it cites accordingly.

Article schema for medical device content

For a medical device manufacturer, Article schema should include:

• @type — Article for general articles, NewsArticle for news, MedicalWebPage for medical-specific content (this last one is the 2026 addition and is the strongest signal for medical content)
• headline — the article's H1, without the brand suffix
• alternativeHeadline — a second headline for cross-citation, if the article has one
• image — array of article image URLs, with explicit width/height; first image is the social-share image
• datePublished — ISO 8601 publication date
• dateModified — ISO 8601 last-modified date (must be later than datePublished if non-empty)
• author — use a Person block with the writer's name and a link to the writer's institutional bio page.
• publisher — use an Organization block that mirrors the main site Organization block, not a generic placeholder.
• description — the meta description, 150–250 characters
• articleBody — optional full text (2026 best practice is to include for AI citation)
• keywords — comma-separated keyword list (2026 best practice is 5–10 keywords)
• articleSection — the article's category (e.g. "OEM Compliance", "GEO")
• inLanguage — the article's language code (e.g. "en", "zh")
• mainEntityOfPage — the canonical URL of the article
• speakable — nested SpeakableSpecification with xpath to the article's key passages (for voice search)
• about — array of Things the article is about (use schema.org MedicalEntity subtypes for medical topics)
• citation — nested CreativeWork for any sources cited in the article

The MedicalWebPage subtype is the 2026-specific high-value field. It signals to the AI engine that this is a medical-content page, triggering the medical-content review pipeline. Use it for any article that discusses medical conditions, treatments, or medical devices.

FAQPage schema for the Q&A layer

FAQPage schema is the second part of the content layer. For an article with 10 Q&A pairs, the FAQPage schema has 10 Question entries, each with an acceptedAnswer. The 2026 best practice is to have a separate FAQPage block in addition to the Article block; the two coexist on the same page.

Each Question entry includes:

• name — the question text, exactly as it appears on the page
• acceptedAnswer — nested Answer with the answer text, exactly as it appears on the page
• suggestedAnswer — optional Answer entries for alternative answers (rare but powerful for nuanced content)
• answerCount — the number of acceptedAnswer entries (typically 1, but can be more)
• upvoteCount — optional, for community-sourced content

The 2026 mistake is to have the FAQ on the page but not in the schema, or to have the schema but the question text doesn't exactly match the H3 on the page. AI engines cross-reference; mismatches are flagged as low-quality.

BreadcrumbList: the navigation layer

BreadcrumbList is the simplest schema to implement and the most often forgotten. It tells the AI engine how this page fits into the site's information architecture. A 2026 article with BreadcrumbList cites better than the same article without, because the engine can contextualise the article within a category ("OEM Compliance > Audit Readiness") that an unstructured page cannot.

BreadcrumbList is a single JSON-LD block with a listItem array, one entry per breadcrumb level:

• @type — BreadcrumbList
• itemListElement — array of ListItem entries, each with position (1, 2, 3), name (the breadcrumb text), and item (the URL)

The 2026 best practice: BreadcrumbList on every page except the home page, position starting at 1, name matching the visible breadcrumb text exactly, and item being the canonical URL of the parent page.

Review + AggregateRating: the social proof layer

Review and AggregateRating are the most-mistyped schema in 2026. Google has explicit policies: self-serving reviews (the manufacturer reviewing themselves) are a manual action; aggregated ratings without an underlying review body are flagged as spam. The 2026 best practice is to implement Review and AggregateRating only when the reviews are:

• From a verifiable third-party platform (Trustpilot, G2, Capterra, or a verified customer)
• Tied to a real customer identity (with permission to publish)
• Aggregated from at least 5 individual reviews for the rating to be meaningful
• Reviewed regularly for spam or manipulation

AggregateRating essentials

• @type — AggregateRating
• ratingValue — the average rating, on the same scale as the individual reviews (e.g. 4.5 on a 5-point scale)
• reviewCount — the total number of reviews underlying the aggregate
• bestRating — the maximum value on the scale (e.g. 5)
• worstRating — the minimum value on the scale (typically 1)

Review essentials

• @type — Review
• author — nested Person with name (no email or phone — privacy)
• datePublished — ISO 8601 date of the review
• reviewBody — the review text, 50–500 words
• reviewRating — nested Rating with ratingValue, bestRating, worstRating
• itemReviewed — nested Product or Organization (the thing being reviewed)

The 2026 rule: if a manufacturer does not have verifiable third-party reviews, do not implement AggregateRating. A page without AggregateRating cites better than a page with a self-serving AggregateRating that Google has flagged.

5 schema mistakes that cost AI citations

Mistake 1 — Schema is on a different page from the visible content

An FAQ on the visible page but FAQPage schema on a separate page is the #1 2026 mistake. AI engines cross-reference; if the schema doesn't match the visible content on the same URL, the schema is ignored. Every schema block must be on the same URL as the visible content it describes.

Mistake 2 — Organization schema on every page (or on no page)

Organization schema should be on the home page and optionally on the about page; it should not be on every page. Article pages should use Article schema, not Organization. The 2026 mistake is either over-implementing (Organization on every page, which dilutes the signal) or under-implementing (Organization on no page, which loses the entity anchor).

Mistake 3 — dateModified is empty or earlier than datePublished

An Article schema with dateModified empty or earlier than datePublished is invalid schema, and most validators will catch it. The 2026 rule: if the article was edited after publication, dateModified must be later; if not, omit dateModified entirely.

Mistake 4 — Schema is generated by a plugin and not validated

WordPress plugins (Yoast, RankMath, Schema Pro) generate schema automatically, but they often produce invalid or incomplete schema. The 2026 rule: validate every page's schema with Google's Rich Results Test AND schema.org's validator before considering the implementation done. A 30% error rate on auto-generated schema is normal.

Mistake 5 — Schema is implemented once and forgotten

Schema is not a one-time project. Every time a page is updated, a product is added, an address changes, or a phone number rotates, the schema must be updated. The 2026 rule: schema has an owner, schema has a quarterly review, and the review checks for staleness, breakage, and missed pages.

Schema validation: the four layers

Schema validation runs at four layers, each catching a different class of mistake. Run all four before declaring a site "schema-ready."

The first layer is the public Google Rich Results Test. It checks your pages against the rich-result types Google currently rewards. Run it on every page; the output flags warnings and errors per page and is the fastest way to find markup that breaks Google's preview rendering.

The second layer is the public schema.org validator. It checks your pages against the full schema.org vocabulary, including types and properties that Google does not surface as rich results but other AI engines still read. Use it to catch invalid type values and missing required properties that the Google test does not cover.

The third layer is the Enhancements report in Google Search Console. This is production monitoring at scale: it lists every URL where schema is detected, with the error and warning counts. It runs continuously and is the most reliable way to find schema breakage introduced by a CMS update or template change.

The fourth layer is manual sampling. Pick twenty pages, fetch them with a curl call, and search the response for the JSON-LD blocks. Check that the schema is present, that the type values are correct, that the required properties are populated, and that the visible page content matches the schema one-to-one. A common 2026 finding is that the page shows a FAQ in the body but the schema has the questions worded differently, which most AI engines treat as low-quality.

A 2026 medical device site that passes all four validation layers is in the top 10% of the industry. A site that only runs the first layer risks shipping schemas that work for Google but are ignored by the other AI engines, which now drive a large share of B2B research.

How to measure schema impact in 60 days

Schema impact is measurable on a 60-day cycle. The 2026 measurement protocol:

1. Day 0: Implement the 6 minimum viable schemas on every page of the site. Run the 4 validation steps. Document the baseline: number of pages with schema, number of validation errors, AI citation rate (using the 30-question weekly check).
2. Day 30: Re-validate. Fix the errors that surface. Measure the AI citation rate again.
3. Day 60: Final measurement. Compare Day 0 and Day 60 citation rates. Expected outcome for a properly implemented schema: 2–4× citation rate increase within 60 days, sustained over the next 6 months.
4. Day 90: Decide whether to expand to additional schema types (MedicalCondition, MedicalProcedure, Drug, etc.). The 2026 rule: only expand after the 6 minimum viable types are at 100% validation pass.

Across our 412 accounts, the median citation rate increase at Day 60 is 3.4×, with a 90th percentile of 6.8× and a 10th percentile of 1.4×. The 1.4× outcomes are sites with validation errors that were not fixed; the 6.8× outcomes are sites that implemented all 6 types on every page and had a clean validation pass at Day 30.

FAQ — 10 questions about structured data for medical device sites

1. Do I need a developer to implement schema?

Yes, for the 6 minimum viable types. Schema is HTML-level, so a developer (or someone comfortable editing HTML and JSON) is needed. If you use WordPress, plugins like Schema Pro reduce the work, but a developer is still needed for the final validation pass.

2. Can I use Microdata or RDFa instead of JSON-LD?

Yes — all three are valid schema syntaxes. JSON-LD is the 2026 best practice because it is the easiest to validate, the easiest to maintain, and the format AI engines prefer. Microdata and RDFa are also supported, but if you have a choice, use JSON-LD.

3. How do I handle multi-language sites?

Each language version of a page has its own schema block, with the inLanguage property set to the language code. The sameAs array should include the URLs of the other language versions. The 2026 best practice is to have a single canonical URL per page and to use hreflang tags to indicate the language variants.

3. Will schema help with traditional Google search rankings?

Indirectly. Schema does not directly affect Google's organic ranking, but rich results have a higher click-through rate than non-rich results, which improves the user signals that affect ranking. The 2026 rule: implement schema for the AI citation benefit, and the traditional SEO benefit is a side effect.

5. What about voice search?

Schema is the foundation of voice search citation. The SpeakableSpecification property in Article schema tells the AI engine which passages of the article are suitable for voice output. The 2026 best practice is to mark the first paragraph and the FAQ answers as Speakable.

6. How often should I re-validate?

Quarterly is the 2026 minimum. After any major site change (CMS migration, design refresh, URL structure change), re-validate immediately. Set a calendar reminder for the first week of January, April, July, October.

7. What if my CMS doesn't support JSON-LD?

Any CMS supports JSON-LD, because JSON-LD is just a script block in the page. If your CMS has a "custom HTML head" or "custom footer" field, you can add a JSON-LD block there. If your CMS doesn't have such a field, switch CMS — the lack of custom-HTML support is a 2026 deal-breaker.

8. Should I use Google's structured data markup helper?

Yes, for learning. No, for production. The markup helper is great for understanding the structure of a schema block, but the output is for one-time use. Production schema should be version-controlled, automated, and validated on every change.

9. How do I handle product variants?

Use one of three approaches: (a) one Product schema per variant, with distinct sku and mpn; (b) one Product schema with an additionalProperty array listing the variants; (c) one Product schema with an offers array containing one Offer per variant. The 2026 best practice is approach (c) — one Product, multiple Offer entries — because it consolidates the reviews and aggregate rating.

10. What's the single highest-ROI schema to implement first?

Organization schema, on the home page, with a full sameAs array of 8–10 verified external profiles. This single block, done correctly, will lift the AI citation rate for the entire site within 30 days. After Organization, the next priorities are Article + FAQPage on the top 5 articles by traffic, then Product on the top 5 products, then the rest.

About Kangdi Medical Devices

Henan Kangdi Medical Devices Co., Ltd. is an OEM/ODM manufacturer of pain patch, heat patch, cooling gel patch, and herbal patch products, with 18+ years of formulation and production experience serving 412 B2B accounts across 47 countries. Our facility is ISO 13485 certified, FDA Establishment Registered, and CE marked under MDR. We process 200+ RFQs per month with a median 9-hour quote turnaround, and we ship to 47 countries through three logistics hubs (Shanghai, Shenzhen, Hamburg). Every page on kangdimedical.com implements the 6 minimum viable schema types, validated quarterly.

Want a copy of our schema template library? Email /kangdi.php?s=message/message and we'll send you the JSON-LD templates for Organization, MedicalBusiness, Product, Article, FAQPage, BreadcrumbList, and AggregateRating, plus the validation scripts we run quarterly.

For more GEO and AI search guidance, see:

• What Is GEO 2026: How AI Search Engines Cite Pain Patch Suppliers — the foundational explainer
• AI Search Visibility for B2B Manufacturers 2026: 7 Signals That Get You Cited — the 7-signal framework
• Pain Patch OEM Audit Readiness 2026: 10 Documents Inspectors Ask For — the documentation side of the same compliance work

Henan Kangdi Medical Devices Co., Ltd. — 18+ years OEM/ODM pain patch manufacturing. Henan, China. ISO 13485 / FDA / CE MDR. Home · Contact · News & articles