Your Peptide Product Schema Says 'Dietary Supplement' — Your Label Says 'Not for Human Consumption'
A client came to us after a Merchant Center suspension notice for "misrepresentation of product category." Their BPC-157 page had a research-use disclaimer in 14-point type, an age gate, and copy that said "not for human consumption" four separate times. The product itself was never marketed as a supplement anywhere a human would read. But Google's policy bot didn't read the page the way a human does. It read the schema. And the schema, generated automatically by a Shopify app the team installed eighteen months earlier, had tagged every peptide SKU as Health & Beauty > Vitamins & Supplements, with a Product type and an offers block that priced it like a bottle of fish oil.
The visible page said research chemical. The invisible page — the one search engines and shopping feeds actually parse — said supplement. Google believed the invisible one.
The Contradiction Lives in a Layer Your Team Never Looks At
Most peptide operators spend real time on the parts of the page a visitor sees: the disclaimer banner, the affirmation gate, the COA download link. That's the right instinct — it's also incomplete. Underneath that visible layer is a block of JSON-LD structured data that tells search engines, shopping feeds, and AI crawlers what the page actually is, in machine-readable terms. Platforms like Shopify, WooCommerce, and most page builders generate this schema automatically based on a generic e-commerce taxonomy. That taxonomy has no concept of "research use only." It has categories like Health, Beauty, Supplements, and Sports Nutrition, because that's what 95% of stores selling powders and capsules are.
So the plugin does what plugins do: it maps your BPC-157 5mg vial to the nearest category in its dictionary. That's "Vitamins & Supplements." It assigns Product schema with pricing, availability, and often a star rating block, because that's the default for anything sold through an /products/ URL. None of this is malicious. It's just generic automation applied to a non-generic product category, and nobody on the compliance side ever audited it because compliance reviews read the page, not the markup.
The result is two documents at the same URL that disagree with each other. One is written for your customer and your legal counsel. The other is written for Googlebot, Google Shopping's policy crawler, and increasingly, the language models powering AI search — and it was never written by anyone who understood what "research use only" is supposed to mean, legally or operationally.
Why This Isn't a Cosmetic Bug — It's Two Separate Systems Reading Two Different Truths
Here's the mechanism, and it's worth understanding because it explains why this keeps happening even to brands that think they've covered compliance.
Google runs structured data through two largely separate pipelines. The first is Merchant Center's policy enforcement layer, which scans schema and feed data for restricted-category violations — supplements making health claims, drugs without proper licensing disclosures, anything that looks like an unapproved medical product. This system is mechanical. It doesn't weigh your disclaimer copy against your schema category; it flags the mismatch between "sold as a supplement" and "making claims no supplement is allowed to make," and suspends the listing or the whole feed.
The second pipeline is the one that matters even more right now: entity extraction for AI-powered search. When an answer engine like Google's AI Overviews, Perplexity, or a ChatGPT browsing session needs to describe what your product is, it doesn't read your disclaimer banner and weigh it against your marketing copy the way a human would. It pulls structured, labeled data first, because structured data is treated as higher-confidence ground truth than prose. If your JSON-LD says "category": "Vitamins & Supplements", that's the label the AI inherits — even if three paragraphs below it, in plain HTML, your copy says the opposite. You end up with an answer engine citing your BPC-157 page as a supplement, which is the exact classification your legal strategy was built to avoid, and the exact classification that invites the regulatory attention research-use positioning exists to sidestep.
This is the part most peptide operators miss: the compliance-first language on your page isn't protecting you if the schema underneath contradicts it. You've built a legal position in HTML and let a plugin quietly undermine it in JSON. Google Shopping enforces the literal reading. AI search engines cite the literal reading. Your actual intent is irrelevant to both systems if the markup says something else.
What a Schema Layer That Actually Matches Your Compliance Position Looks Like
Fixing this isn't a settings toggle. It requires treating structured data as a compliance artifact, not a technical afterthought, which means hand-coding it per product type instead of trusting what a commerce platform auto-generates.
A corrected build does a few specific things. It drops the generic Product schema's inherited category mapping and replaces it with a custom additionalType and category field that accurately reflects research-use status — not forced into "supplement" or "drug" buckets that don't exist for your actual product. It strips aggregateRating and review schema blocks entirely from research compounds, because star ratings on a research chemical are themselves a category-confusing signal that invites the exact policy flag you're trying to avoid. It embeds the research-use disclaimer inside the schema object itself — as a disclaimer or additionalProperty field — so the machine-readable layer carries the same legal position as the human-readable one, instead of contradicting it. And it links the COA not as a decorative PDF buried in a tab, but as a structured url property tied to the specific batch number on that product variant, so the compliance trail is machine-visible, not just visually present.
This is also where the broader site architecture matters, not just the per-product markup. A site built on a templated commerce platform will keep re-generating the wrong schema every time a plugin updates, every time a new SKU gets added by someone who isn't thinking about Merchant Center policy. A custom-coded peptide site built on a framework like Astro or Next.js gives you control over every JSON-LD block at the template level — meaning the correct, compliance-accurate schema gets applied automatically to every new product, not re-audited by hand each time, and not silently overwritten by an app update six months from now.
Separately, if you run Google Shopping ads, the feed needs its own exclusion logic — research compounds routed out of Shopping entirely where the category has no honest mapping, rather than forced into a bucket that trips enforcement. Organic indexation and paid shopping feeds don't have to carry identical data; treating them as one feed is usually where the suspension starts.
The Page You Approved Isn't the Page Google Reads
Most compliance reviews stop at the visible layer because that's what humans can see and sign off on. But the machines deciding whether you rank, whether you get cited, and whether your Merchant Center account stays active are reading a different document entirely — one nobody on your team wrote on purpose. If your legal position is "research use only," that position needs to exist in the markup, not just the copy. Anything less is a brand that thinks it's compliant and a crawler that's already decided it isn't.
If you want a second set of eyes on what your current schema is actually telling Google and AI search about your products, that's a conversation worth having before the next suspension notice, not after.