Structured Data
Machine-readable markup such as JSON-LD that explicitly describes visible entities and facts.
Structured data is not an SEO spell. It is a machine-readable description of page facts, usually delivered as JSON-LD, that helps systems identify entities and relationships. If the markup contradicts the storefront, duplicates another graph, or invents evidence, technical validity does not make it trustworthy.
The operating model is simple: assign one owner, publish one canonical entity graph, map exact catalog facts, validate meaning as well as syntax, and monitor every theme, app, and product change. Structured data can improve machine understanding; it cannot command rankings, rich results, AI citations, or recommendations.
What is structured data, and what does it not do?
Structured data is machine-readable annotation attached to a page’s content, often as JSON-LD. It names things such as a product, organization, offer, or breadcrumb and connects them with properties. It is not visible sales copy, and it never guarantees ranking, a rich result, an AI citation, or a recommendation.
The JSON-LD 1.1 specification defines the serialization model, while Schema.org supplies the shared vocabulary. Valid JSON merely follows RFC 8259; it says nothing about whether the values are current, supported, or useful.
| Test | Question |
|---|---|
| Syntax | Does the JSON parse? |
| Vocabulary | Are types and properties defined? |
| Semantics | Do relationships describe the right entities? |
| Evidence | Does visible page content support every value? |
Which schema types matter most for Shopify and ecommerce?
Most Shopify stores should prioritize Product, Offer, Organization, and BreadcrumbList because those types map directly to product identity, commercial terms, the selling entity, and navigation context. Add only properties the page and catalog can support. FAQPage belongs only on pages with real, visible questions and answers.
| Type | Map it to | Never invent |
|---|---|---|
| Product | Exact identity, attributes, images, identifiers | Reviews, ratings, unsupported claims |
| Offer | Current price, currency, availability, seller | Invented price or stock |
| Organization | Canonical business identity, name, logo, URL | A Person or unsupported credentials |
| BreadcrumbList | Visible navigation hierarchy | Hidden category paths |
Google’s product guidance and organization guidance add search-specific expectations. Schema.org defines vocabulary; each consumer decides eligibility and presentation.
Google states that FAQ rich results stopped appearing on May 7, 2026; its FAQPage documentation remains useful for markup rules, while the Shopify FAQ schema guide helps map visible answers—not a rich-result promise.
How should variants and offers be mapped?
Model the product family once, then connect each real variant and its current offer without collapsing distinct identifiers, options, prices, currencies, or availability. The exact graph shape depends on the page and supported vocabulary, but every node should resolve to a stable identity and agree with what shoppers can see.
Use a canonical @id for the Organization and stable page-level identifiers for products and offers. Link nodes instead of emitting disconnected copies. Review Product and Offer definitions, then follow Google’s merchant listing guidance for properties its product experiences consume.
- Compare selected variant, URL, SKU or GTIN, image, and options.
- Verify displayed price and currency against the structured Offer.
- Remove
aggregateRatingorreviewunless genuine visible evidence supports them.
Where should JSON-LD appear on a Shopify page?
JSON-LD may be present in the initial HTML or added to the rendered DOM, but auditors should inspect both because tools, crawlers, and timing differ. The reliable target is accessible, parseable markup that consistently matches the final visible page—not a script that appears only after fragile client-side behavior.
Shopify themes commonly generate JSON-LD with Liquid. Use Shopify’s json filter to serialize values safely instead of hand-escaping strings, then confirm the output remains valid for quotes, line breaks, and empty data. Initial source proves delivery; rendered inspection reveals later app additions or replacements.
How do themes and apps create duplicate structured data?
Duplicates appear when a theme, SEO app, review app, and custom snippet each believe they own the same entity. Two valid Product blocks can still disagree about identity, price, availability, or ratings. Assign ownership by entity type, remove redundant emitters, and preserve one connected graph with stable identifiers.
Map each source: theme file, app embed, app block, or custom integration. Private app ownership may be invisible publicly, so compare output before and after controlled changes. Never delete a block solely because a validator calls both syntactically valid.
| Entity | Preferred owner | Conflict signal |
|---|---|---|
| Organization | Theme or one SEO layer | Different @id, logo, or URL |
| Product and Offer | Product template or one catalog app | Conflicting variant, price, or availability |
| Reviews | Verified review provider | Unsupported totals or duplicate aggregates |
What is a safe Shopify implementation workflow?
A safe implementation starts with a fact inventory and ends with monitored deployment, not a generator pasted blindly into a theme. Work on one template and representative product set first, define ownership, serialize catalog values safely, compare visible output, and expand only after syntax and meaning both pass.
- Inventory visible page facts, current emitters, and responsible owners.
- Define canonical entities, stable
@idvalues, and required relationships. - Map Product, Offer, Organization, and breadcrumbs from source fields.
- Serialize safely; omit unknown values rather than guessing defaults.
- Test representative simple, variant-heavy, sold-out, and discounted products.
- Compare initial HTML, rendered DOM, visible content, and catalog records.
- Deploy gradually, record the change, and schedule regression checks.
The product schema generator can provide a starting shape, and Shopify product-schema instructions can guide placement. Neither replaces field mapping or ownership review.
How should structured data be validated and audited?
Validation has three separate jobs: confirm JSON syntax, confirm vocabulary and relationships, and confirm every value against visible content and current catalog truth. A green validator covers only part of the problem. Audit representative templates and edge cases, then rerun checks after theme, app, price, inventory, or catalog changes.
- Parse with the Schema.org validator and schema checker.
- Inspect Search Console structured-data reports for supported features.
- Compare source HTML and rendered DOM.
- Match names, identifiers, images, variants, prices, currency, and availability.
- Trace every node to one owner and stable
@id. - Confirm visible FAQs support any FAQPage node.
- Reject invented reviews, ratings, claims, authors, and credentials.
- Recheck after deployments, app updates, and bulk catalog edits.
Also test Google’s general policies, not just its structured-data introduction. Syntax failure is obvious; semantic drift is quieter and often more damaging.
What can StoreCited verify, and where does it stop?
StoreCited can inspect publicly accessible storefront markup and report point-in-time readiness findings, including missing, conflicting, or unsupported signals it can observe. It cannot edit Shopify, identify every private app owner, inspect private catalog systems, continuously monitor live AI citations, or guarantee rankings, rich results, citations, or recommendations.
Treat the scan as evidence for a remediation queue, not as proof of platform behavior. StoreCited is an Organization entity, never a fabricated Person author. Run the free StoreCited readiness scan, fix the public facts you control, and verify changes in the systems that consume them.