JSON-LD

JSON-LD stands for JavaScript Object Notation for Linked Data. It is ordinary JSON with two extra keys that do all the work:

• @context — which vocabulary the field names come from. For product pages, that is https://schema.org.
• @type — what kind of thing this object is: Product, Offer, Brand, Organization.

Without those, {"name": "hex cap screw", "sku": "HCS-38162"} is just text a parser can load. It cannot tell whether name means the product's name, the brand's name, or the author of the page. Add the context and the type, and every key points at a public definition anyone can look up.

The markup lives in a script tag in the page source:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "3/8-16 x 2 in. Grade 8 Hex Cap Screw, Yellow Zinc",
  "sku": "HCS-38162-G8-YZ",
  "mpn": "38162G8YZ",
  "gtin13": "0012345678905"
}
</script>

A browser renders none of it. It is invisible to the person shopping. It exists so a crawler does not have to work out that 0012345678905 is a GTIN and not a model number, or dig the $12.40 out of a sentence.

All three express the same schema.org vocabulary. The difference is where the markup lives — and that difference is operational, not semantic.

Dimension	JSON-LD	Microdata	RDFa
Lives where	One script block, separate from the page	itemprop attributes on visible HTML	property attributes on visible HTML
Coupled to design	No	Yes	Yes
Injectable via tag manager	Yes, natively	Only by rewriting the rendered DOM, which is impractical at catalog scale	Only by rewriting the rendered DOM, which is impractical at catalog scale
Google support	Supported, and the format Google recommends	Supported	Supported
Typical failure mode	Block drifts out of sync with the rendered page	A template refactor drops the itemprop attributes and the markup silently vanishes	A template refactor drops the property attributes and the markup silently vanishes

The practical case for JSON-LD is that your front-end team can rebuild the PDP without touching the structured data, and your data team can change the structured data without touching the PDP.

The practical risk is the flip side of the same coin: nothing forces the block to agree with what the page shows. Microdata is welded to the visible price. JSON-LD is not, so it can lie by accident.

Google's Product rich result documentation defines what is required and what is merely recommended. For a B2B catalog, the useful shape looks like this:

Field	Required?	Example value	Why it's there
@type	Required	Product	Tells the parser what to expect
name	Required	3/8-16 x 2 in. Grade 8 Hex Cap Screw, Yellow Zinc	The title in a rich result
offers	Required	{"@type": "Offer", ...}	No offer, no price treatment
sku	Recommended	HCS-38162-G8-YZ	Your identifier
mpn	Recommended	38162G8YZ	Matches you to the manufacturer's record
gtin13	Recommended	0012345678905	The global identifier that lets engines merge listings
brand	Recommended	{"@type": "Brand", "name": "..."}	Nested object, not a string
offers.price	Required	12.40	No currency symbol and no thousands separator: "12.40", never "$12.40"
offers.priceCurrency	Required	USD	ISO 4217
offers.availability	Recommended	https://schema.org/InStock	Full URL, not the word "in stock"
additionalProperty	Optional	{"@type": "PropertyValue", "name": "Thread Pitch", "value": "16 TPI"}	Where specs go when schema.org has no dedicated field

That last row is where most technical catalogs actually live. Schema.org has no voltageRating and no threadPitch. A UL-listed 600V wire connector expresses those through repeated additionalProperty entries, which engines read even though they rarely surface them as a rich result on their own.

A crawler reading your PDP as prose has to guess. Is "600V" a rating, a model number, or part of a marketing line? JSON-LD removes the guess and replaces it with an assertion.

That matters in three places:

• Rich results. Price, availability, and review stars in the SERP come from parsed markup, not from a language model reading your copy.
• Merging. A GTIN in the markup lets an engine recognize that your listing and four competitors' listings are the same physical part.
• Answer engines. LLM-backed search grounds answers in whatever it can extract cheaply and confidently. A structured block is cheaper and more confident than a paragraph.

None of this is a ranking bonus for having markup. It is a retrievability change, and the difference is worth being precise about. Ranking is a contest among pages already eligible for a surface. Retrievability decides which contests you are entered in at all.

A PDP with no parsable price is not ranked lower in the price box; it is not in the price box. With no GTIN it is not a candidate for a merged listing. An answer engine asked who stocks a Grade 8 hex cap screw in yellow zinc has nothing cheap to lift from it. Markup does not move you up a list. It puts you on lists you were never on.

The markup is the easy part. Any modern PDP template can emit a JSON-LD block in an afternoon. What breaks is upstream.

• Empty fields. You cannot emit gtin13 for 40,000 SKUs if 40,000 SKUs have no GTIN. Omitting the key is valid and functionally useless: the block parses, and the identifier an engine needs to merge your listing is simply absent. Emitting "gtin13": null is worse, because null is not a valid value and Search Console will flag it as an error.
• Wrong nesting. "brand": "Acme" instead of a Brand object. Common, and quietly costs you the brand association.
• Drift. Price changes in the ERP, the page updates from a live call, the JSON-LD comes from a nightly cache. Now they disagree, and mismatched markup is worse than none.
• Spec fields with nowhere to go. Thread pitch, amperage, listing agency — all real, all sitting in a PDF datasheet, none in a field the template can read.

Your PIM stores the values; the template serializes them. JSON-LD cannot serialize data you do not have.