Structured Data for Peptide and Research-Supply Websites

What structured data does, and what it does not

Structured data is a machine-readable description of a page, written in the schema.org vocabulary. It tells a search engine or assistant that this page is a product, that one is an article with a publication date, and that the business behind both is a particular organization with a particular website and contact point.

It can make a page eligible for some rich results in Google, and it reduces guesswork for any system that reads it. It does not raise rankings on its own, it does not guarantee a rich result or an AI citation, and Google decides case by case whether to show any enhancement. Treat it as accurate labelling, not as a lever.

For a research-supply site there is a second reason to get it right. Markup is read by machines that also feed ad reviews, payment underwriting tools and AI answers. A claim in markup is still a claim, and it is held to the same research-use-only rules as the visible copy.

JSON-LD basics and stable IDs

Use JSON-LD: a script block of type application/ld+json in the page, separate from the visible HTML. It is the format Google recommends and the easiest to generate from the same data that builds the page.

Give the main entities a stable @id, usually the page URL with a fragment, such as the site URL followed by #organization. Other blocks can then point to that @id instead of repeating the details, which keeps the organization's name and contact details defined once. This site defines its Organization and WebSite once, with @id values ending in #organization and #website, and every Article, Service and page block refers back to them.

• Generate markup from the same data source as the page, never by hand in a separate file.
• Use absolute URLs in markup.
• One subject per block; link blocks with @id rather than nesting the same entity twice.
• Leave a property out rather than filling it with a guess.

Organization and WebSite

Organization markup states who runs the site: name, URL, logo, contact email or phone, and links to profiles elsewhere through sameAs. It is the anchor for entity consistency, so its values must match the footer and contact page exactly. A short example: {"@type": "Organization", "@id": "https://example.com/#organization", "name": "Example Research Supply", "url": "https://example.com", "email": "support@example.com"}.

WebSite markup names the site and points its publisher at the Organization. Keep it simple: name, url, publisher and inLanguage. Add a SearchAction only if the site has a working search page at the URL pattern you declare.

Do not add certifications, awards, ratings or registrations to Organization markup unless the business has documented them and shows them on the page. This site's Organization lists the services it offers in an OfferCatalog with no prices, because every service is quoted.

Navigation markup: BreadcrumbList, CollectionPage and ItemList

BreadcrumbList describes where a page sits: home, catalog, category, product. It matches a breadcrumb trail shown on the page, and Google can use it in place of the raw URL in results. Each item needs a position, a name and the URL of that level.

Catalog, category and hub pages are collections. CollectionPage says what the page is; ItemList says what is on it, in order, with a URL for each entry. Example: {"@type": "ItemList", "itemListElement": [{"@type": "ListItem", "position": 1, "name": "BPC-157", "url": "https://example.com/catalog/bpc-157"}]}. List only items that appear on the page, in the order they appear.

Product, and why there is no Offer when there is no price

Product markup describes a catalog item: name, description, image, category, brand, and properties such as vial size as PropertyValue entries. In research supply, the description must stay within what the product page says, which means identity and documentation, never usage or effects.

Offer is the part of Product that carries a price, currency and availability. If the page does not show a price, because wholesale pricing is sent on inquiry, the markup must not show one either. Inventing a placeholder price, a price of zero or a price range to satisfy a validator puts a claim in the markup that the page contradicts. This site's product markup omits offers for exactly that reason, and adds a purity property only when a published report matching the product and size prints one, with the report number in the property's description.

The trade-off is real: Google's product rich results expect an offer, a review or a rating, so a Product without any of them is unlikely to show price or star enhancements. It is still valid markup that identifies the product accurately, and that is the honest option when prices are quoted.

• Product names exactly as on the page and the label, compound names only.
• One PropertyValue per size, matching the sizes listed on the page.
• Purity or test values only if printed on a published report for that product and size, with the report referenced.
• No Review or AggregateRating unless real, permissioned reviews are shown on the page.
• No offers when there is no visible price.

FAQPage

FAQPage marks up questions and answers that appear on the page, with each Question's acceptedAnswer holding the visible answer text. Example: {"@type": "FAQPage", "mainEntity": [{"@type": "Question", "name": "Do wholesale lots come with reports?", "acceptedAnswer": {"@type": "Answer", "text": "Yes. Each quote names the lot and its report."}}]}.

Google limits FAQ rich results to a small set of well-known authoritative government and health sites, so most research-supply sites will not see the expanded FAQ display in Google results. The markup is still a clear question-and-answer structure that other systems can read, and it costs nothing if it is generated from the visible FAQ.

The text in the markup must match the page word for word. Answers must follow the same rules as the copy: no dosing, usage, outcome or medical language, which in an FAQ is the most common place for it to slip in. Strip links and formatting from the markup text, as this site does, so the answer reads as plain text.

Article and speakable

Guides and long pages take Article markup: headline, description, datePublished, dateModified, author or publisher, and mainEntityOfPage pointing at the page. Keep dateModified equal to the updated date shown on the page, and change both only when the content changes.

speakable marks the part of a page best suited to being read aloud, through CSS selectors or XPath. Google documents it as a beta feature aimed at news content, so it should not be expected to produce a visible result. It is still a precise way to say which passage is the summary. This site marks each guide's short answer with a data attribute and points the speakable selector at it, alongside the word count and section of the Article.

Dataset for publication statistics

If a page publishes data, such as counts of indexed publications per compound, Dataset markup describes it: name, description, url, creator, dateModified, temporalCoverage for the period covered, and license. Google Dataset Search reads this type, and it requires at least a name and description.

Describe the data honestly. Name the source and the query in the description or on the page, give the retrieval date, and do not call a count of publications evidence of an effect. This site's research statistics page carries Dataset markup with its retrieval date, the years covered and a Creative Commons licence, and shows the queries on the page.

DefinedTermSet for glossaries

A glossary is a set of terms with definitions, and schema.org has a type for exactly that. DefinedTermSet names the glossary; each entry is a DefinedTerm with a name and description and an inDefinedTermSet link back. Example: {"@type": "DefinedTerm", "name": "Certificate of analysis", "description": "A laboratory report on a specific lot.", "inDefinedTermSet": "https://example.com/glossary"}.

Glossaries are useful to assistants because they pin down what a business means by a term. Keep definitions factual and short, and keep compound-related entries to identity and documentation. This site's glossary uses DefinedTermSet for its payments, search and supply terms.

Languages: hreflang and inLanguage

Translated pages need two things that are easy to confuse. hreflang is not schema.org: it lives in link elements in the page head, in HTTP headers or in the sitemap, and tells search engines which URL serves which language, including an x-default. inLanguage is the schema.org property on WebSite, Article or Dataset that states the language of that content.

Use both, and keep them consistent: the Spanish page declares es in its markup and lists the English page and itself in its hreflang set, and the English page lists both in return. This site's Spanish pages set a canonical on the /es URL with hreflang for en-US, es and x-default, and pass the language into the Article markup.

Validating before and after release

Use two tools, because they answer different questions. Google's Rich Results Test shows whether a page is eligible for the rich results Google supports, and renders the page as Googlebot would, so it catches markup injected by scripts that fails to load. The Schema Markup Validator at validator.schema.org checks the markup against the whole schema.org vocabulary, including types Google does not use, such as DefinedTermSet.

Test one URL per template, not only the home page: a product, a category, a guide, the glossary, a translated page. After release, the enhancement reports in Google Search Console show errors across the site as Google crawls it. Re-test whenever a template or its data source changes, and add markup checks to whatever pre-release script the site runs.

Mistakes that cause problems

Most structured-data problems come from markup written once by hand and never updated, which is why we generate it from the catalog and documentation on every research-supply site we deliver, as part of SEO for research-supply websites. How to get a research-supply website read and cited by AI search covers the rest of the work around it. The mistakes we see most often:

• Markup that does not match the page. A price, rating, FAQ or claim in markup that visitors cannot see is against Google's guidelines and can lead to a manual action.
• Review markup without real reviews. Self-written reviews, invented ratings or ratings copied from elsewhere break search guidelines and this category's rules on social proof.
• Medical or usage claims in markup. A description, FAQ answer or property that implies an effect or a use is still a claim, even if few people see it.
• Undocumented certifications. GMP, ISO or similar statements in markup need the same documentation as on the page.
• Placeholder values. Zero prices, default availability or template text left in production.
• Stale dates. dateModified that changes on every build, or never changes at all.
• Duplicate entities. The organization defined differently on different pages, instead of once with an @id.