Shopify Schema Markup Builder

Schema markup is structured data that states explicitly what a page contains. Without it, a search engine or language model has to infer meaning from headings, layout, prose and context — which usually works and sometimes produces the wrong answer.

The difference matters most where ambiguity is expensive. A number on a page could be a price, a rating, a model number or a date. A name could be an author, a brand or a person mentioned in passing. Schema removes the ambiguity by labelling each one.

JSON-LD is the format to use. It lives in a script tag, typically in the head, and does not require changes to your visible HTML. That separation is why it has become the standard rather than microdata or RDFa.

The highest-value markup on most sites and frequently missing. It establishes who publishes the content — name, URL, logo, social profiles, contact details. Without it, a model reading your page may struggle to identify the entity behind it, and models are cautious about citing sources they cannot identify.

Use LocalBusiness instead where you have a physical location, since it supports address, opening hours and geographic data.

Essential for ecommerce. Covers name, description, images, price, currency, availability, SKU and reviews. It powers product rich results and gives AI assistants precise data to quote when someone asks about price or availability.

For editorial content. Headline, author, publish and modified dates, publisher. The author and date fields carry weight for expertise and freshness signals, both of which affect whether content is treated as authoritative.

Labels question-and-answer content explicitly. Google restricted FAQ rich results in 2023, so expect no visual treatment on most sites — the value now is machine readability for answer engines.

Describes where a page sits in the site hierarchy. Simple to implement, appears in search results, and helps establish structural context.

The rule that breaks most implementations. Everything in your structured data must appear in the visible page content. Marking up prices, reviews or answers that a visitor cannot see is a violation and can trigger a manual action.

Prices in the markup must match prices on the page. Availability must reflect actual stock. Ratings must come from real reviews. Inaccurate structured data is worse than none, because it produces confident wrong answers with your name attached.

Choosing an approximately correct type is a common error. A single support question is QAPage, not FAQPage. A product listing page is not a Product. A guide is Article, not WebPage. Precision here costs nothing and prevents misinterpretation.

Each type has required and recommended properties. Missing required ones means the markup may be ignored entirely. A validator will tell you immediately which are absent.

1. Generate the markup for your page type using the tool above.
2. Paste it into a script tag with the type set to application/ld+json, ideally in the head.
3. Validate with Google's Rich Results Test and the Schema.org validator. Both catch syntax errors and missing properties instantly.
4. Check the rendered page, not just the source, if your site uses JavaScript to inject markup.
5. Monitor Search Console for structured data errors after deployment.

Most broken structured data comes from two syntax problems: unescaped quotation marks inside text values, and a trailing comma after the final item in an array. Both are invisible on the page and obvious in a validator.

Structured data has become more important as answer engines have grown, for a reason that has nothing to do with rich results.

When a model assembles an answer, it needs to decide whether a source is trustworthy and identifiable. Schema answers both questions directly: this is an article, published by this organisation, written by this person, on this date, about this subject. A page without it requires the model to infer all of that, and inference introduces uncertainty.

Uncertainty makes citation less likely. This is why entity markup — Organization, Person, LocalBusiness — punches above its weight relative to the more glamorous types.

• Marking up content that is not on the page. The most serious and most frequent error.
• Prices or stock that contradict the page. Creates confident misinformation attributed to you.
• Self-serving review markup. Aggregate ratings must come from genuine reviews, not from your own assessment of yourself.
• Duplicating markup across templates so the same Product appears on multiple URLs.
• Never validating. Structured data fails silently, so untested markup frequently does nothing at all.

Schema is rarely a single block. On a well-marked-up page several types coexist, each answering a different machine question, and the combination is what produces clarity.

On a product page that might be Organization for the publisher, Product for the item, BreadcrumbList for the position in the hierarchy, and FAQPage for the questions underneath. Each is separate and valid on its own; together they describe the page completely.

Rather than several disconnected script blocks, you can place multiple types in one JSON-LD block using an @graph array and link them with @id references. That lets you state explicitly that this Product is offered by this Organization, rather than leaving the relationship implied.

This matters for entity recognition. A model reading connected markup understands the relationship; reading two separate blocks it has to assume one.

Organization markup belongs in your theme layout so it appears on every page. Page-type markup — Product, Article, FAQPage — belongs in the relevant templates. Mixing the two levels is a common source of duplication, where the same Product ends up declared on several URLs.

• Most themes include basic Product markup, often incomplete. Check what yours outputs before adding your own, or you will end up with two conflicting Product blocks.
• Availability frequently goes stale if the markup is hardcoded rather than pulled from inventory. Inaccurate availability is worse than none.
• Variant pricing needs care. A price range requires different properties from a single price, and getting it wrong produces a validation error.
• Review apps often inject their own markup, which can duplicate or conflict with the theme's. Validate the rendered page rather than the template.