Shopify Schema for Roasters: Theme and App Options
A roaster selling beans through Shopify asked me what schema their store needs and whether an app is worth paying for. Short answer: check what your theme already outputs before you add anything else, because the most common problem I see on a roaster's Shopify store is not missing schema, it is two sources both writing overlapping markup at the same time.
A theme with correct Product markup on your product pages, plus a short Organization block describing your business, is usually enough for a roaster site. The question is not whether you need schema in the abstract. It is whether what you already have is clean, and whether anything you add on top of it duplicates what is already there, since a store can genuinely have too much markup, not just too little.
This is a Shopify specific how to guide: how to check your own store's defaults, how to decide between leaving the theme alone, using an app, or editing the theme yourself, and how to test the result. It is not a ranking of themes or apps, and it will not tell you a particular app is the best one. That is a judgment your own store's setup should drive, not a recommendation I can make generically.
This post also is not the place for a full explainer on Product schema fields or common errors in general, since that ground is covered elsewhere on this site, and it is not a repeat of the platform comparison study that looks at how shops on each platform score in the wider census. This one stays narrow: the Shopify specific route, for a roaster specifically, from checking what you have to deciding what, if anything, to change.
Defaults
The first step, before installing anything, is to look at what your current theme is already outputting. Open a product page on your live store, view the page source in your browser, and search for the text application/ld+json. Each block you find between those script tags is a piece of structured data your theme is already generating on its own, without any app involved.
Most current Shopify themes generate Product structured data automatically on product pages, covering fields like the product name, price, and availability. Whether your specific theme does this, and how completely, is something you have to confirm on your own store, because themes differ and Shopify's default theme changes over time. Do not assume; check your own product page directly and record what you actually find.
The homepage and collection pages are a different story. Many themes output little or no structured data on these page types by default, focusing their automatic markup on individual product pages instead. If you view source on your homepage and find no JSON LD blocks at all, that is a common, unremarkable default, not evidence that something is broken.
Collection pages, the ones listing several products together like a page for all your single origin coffees or all your subscription options, tend to follow the same pattern as the homepage rather than the individual product page pattern. If your theme is not generating markup here, that is worth knowing but is usually a lower priority than confirming your individual product pages are correct, since a shopper and a search system alike are more likely to land on and evaluate a specific product page than a broad collection listing.
Once you know what your theme already generates, you have a baseline. Everything else in this post is about deciding what, if anything, to add on top of that baseline, and the single most useful thing you can do before adding anything is to have already looked.
It is worth checking more than one product page while you are at it, since some themes handle a simple single variant product differently from a product with multiple variants, like different bag sizes or grind options. A product page for a twelve ounce bag with three grind choices may carry more or less complete markup than a page for a single, unvariant item, and it is worth confirming both rather than assuming one page represents your whole catalog.
It also helps to check whether your theme's markup includes the fields that actually matter for a roaster specifically. A generic Product block might carry a name and a price without carrying availability, or without distinguishing between variants at all. None of this means the theme is broken. It means you now know exactly what is there, which is the starting point for every decision in the rest of this post, and it saves you from guessing later when a validator flags something you could have already known about.
Custom
There are three broad routes once you know your baseline: leave the theme alone, add a schema app, or edit the theme's code directly. Each has a real trade off, and none of them is automatically correct for every store.
Leaving the theme alone is the right call when your product pages already carry clean Product markup and your main gap is something small, like an Organization block describing your business as a whole, that does not require touching the theme's product template at all. This is often the lowest risk option, since it does not touch anything the theme is already handling correctly. Many roasters will find, after checking their own baseline, that this is genuinely the right answer for most of their site, and the only remaining decision is where a short Organization block should live.
A schema app adds markup through the app's own code, usually without you needing to edit theme files directly. This can be a reasonable route for filling a genuine gap, like adding Organization or breadcrumb markup a theme does not generate on its own. The real risk with this route is the one this post opened with: if the app adds Product markup to the same pages where the theme already generates its own Product markup, you can end up with two separate JSON LD blocks describing the same product, which is a duplication problem rather than an improvement.
Editing the theme's code directly gives the most control, letting you write exactly the markup you want without an app's assumptions layered on top. This is the most technical route and the easiest to get wrong if you are not comfortable working in a theme's code editor, since a broken edit can affect how the whole page renders, not just the structured data. It is worth considering when you have a specific gap an app cannot cleanly fill, or when you have already found a duplication problem from an app and need to remove it at the source.
One category worth naming separately from all three routes above is metafields, a Shopify feature that lets you attach structured information to a product, like an origin, a processing method, or a roast date, beyond what a standard product listing holds. Metafields themselves are not automatically turned into schema markup; whether they show up in your JSON LD depends on your theme or an app reading them and outputting them as part of the markup. If your theme or app supports pulling metafield values into structured data, this can be a useful way to represent roaster specific details, like origin or process, that a generic Product block does not cover on its own.
Before choosing a route, it helps to write down, in plain language, exactly what gap you are trying to fill. Is it a missing Organization block. Is it duplicated Product markup you already found and need to remove. Is it a roaster specific field like origin that nothing currently outputs. Naming the actual gap first keeps you from installing an app to solve a problem you do not have, or editing code to fix something an app could have handled more simply.
Testing
Whichever route you choose, test the actual result rather than assuming it worked. View source on the page again after any change, and count how many application/ld+json blocks appear. If you added an app and now see two Product blocks where you previously saw one, that is the duplication problem, and it needs to be resolved by either removing the app's Product markup or disabling the theme's, not by leaving both in place.
From there, run the page through Google's Rich Results Test and through the general schema markup validator at validator.schema.org. These two tools check different things. The Rich Results Test focuses on what Google's own systems can parse for specific result types, while the general validator checks whether your markup is structurally valid schema.org data regardless of any particular search feature. Reading both outputs, rather than just one, gives you a fuller picture of whether the markup is clean.
Here is a short worked example. Picture a roaster with a product page for a single origin coffee bag. Before any changes, viewing source shows one JSON LD block with Product type, including name, price, and availability, generated by the theme. After installing a schema app aimed at adding review markup, viewing source now shows two blocks: the original Product block from the theme, and a second Product block from the app that duplicates the name and price fields while adding a review section the theme did not have. The fix in this case is not to remove the app, since the review markup is a genuine addition, but to check the app's settings for an option to suppress its own Product level fields and let the theme's existing Product block stand alone.
Keep a simple record of what you tested and when. Note the theme name, the date you viewed source, and what you found, since themes update and an app can change its own output over time. A test done once and never revisited is only accurate for as long as nothing else changes, which for a live store is rarely very long.
Testing is not a one time gate you pass and forget. Any time you switch themes, install a new app that touches product pages, or make a manual edit to a template, the responsible move is to repeat the same check: view source, count the blocks, run both validators, and update your notes. This does not need to be elaborate. A simple dated line in a document, noting the theme, the app if any, and what the validators reported, is enough to catch a duplication problem early rather than months later. This small habit is far less work than untangling a duplication problem that has been sitting unnoticed on a live product page for months.
It is also worth testing more than the homepage and one product page once you make a change. If you edited the theme's product template directly, check a second and third product page to confirm the edit applied consistently across different product types, especially if your catalog includes both simple listings and multi variant bags. A fix that works on the one page you tested but was never confirmed on the rest of the catalog is not really a finished fix yet.
Related Reading
More from Hillcane on this topic, plus the pages on the site that sit next to the work.
Frequently Asked Questions
Does Shopify include schema?
Most current Shopify themes automatically generate Product structured data on product pages, covering fields like name, price and availability, though this varies by theme and changes over time. Homepages and collection pages often carry little or no automatic markup by default. Always confirm your own theme's output by viewing page source directly rather than assuming based on what another store shows.
How do I check what schema my Shopify theme already outputs?
Open a live product page on your store, view the page source in your browser, and search for application/ld+json. Each script block you find between those tags is structured data your theme is generating. Record what types you find, such as Product, and whether fields like price and availability are present, before deciding whether to add anything on top of it.
What is the most common schema problem on a roaster's Shopify store?
Duplication, not absence. When a schema app adds its own Product markup to a page where the theme already generates Product markup, the page ends up with two overlapping JSON LD blocks describing the same product. This is a more common problem than having no schema at all, and it is worth checking for specifically after installing any schema related app.
Should a roaster use a schema app or edit the theme directly?
It depends on the gap you are trying to fill. An app is often simpler for adding something the theme does not generate at all, like Organization or breadcrumb markup. Editing the theme directly gives more control and is worth considering when an app has caused a duplication problem, or when you need markup an app cannot cleanly provide. Neither route is automatically right for every store.
What schema does a roaster's homepage typically need?
Usually a short Organization block describing the business as a whole. Many Shopify themes output little or no structured data on the homepage, so viewing source and finding zero application/ld+json blocks there is a common default, not a fault. Adding Organization markup is lower risk than touching product pages, since it does not overlap the Product block the theme already writes. Afterward, confirm it in the Rich Results Test and at validator.schema.org.
How do I test whether my Shopify schema is working correctly?
View source on the page and count how many application/ld+json blocks appear, checking for duplication first. Then run the page through Google's Rich Results Test and the general validator at validator.schema.org, which check different things: one focuses on what Google's systems can parse for specific result types, the other checks general schema.org validity. Read both outputs rather than relying on just one.
Is one schema app better than another for a Shopify roaster store?
This post does not rank apps, because the right choice depends on what your theme already outputs and which gap you are filling. What matters more is testing afterward: view source, count the application/ld+json blocks, and run the page through Google's Rich Results Test and validator.schema.org. If an app adds a second Product block beside the theme's own, look in its settings for an option to suppress its Product fields.
What does the census say about Shopify stores and schema?
Across the six regional files checked September 15, 2026, 318 of 1,109 shops in the census run on Shopify. This is context on how common the platform is among the shops studied, not an explanation of cause, and it should not be read as a statement about why any individual store's schema looks the way it does.
Does adding more schema guarantee a rich result in search?
No. Adding more schema on its own is not a guarantee. Testing tools like the Rich Results Test and validator.schema.org can confirm whether your markup is structurally valid and parseable for a given type. Whether a specific rich result displays is a separate decision made by Google's own systems and is not something correct markup alone guarantees.
How often should a roaster recheck their Shopify schema?
Recheck after any theme update, any new app install or removal, and periodically otherwise, since themes and apps both change their own output over time. Keep a simple record of the theme name, the date you viewed source, and what you found, so a test done once does not get treated as permanently accurate on a store that keeps changing.
Work with Hillcane
A roaster on Shopify wants to know what schema they need. The real question is what their theme already outputs, because the most common problem is two sources overlapping, not one missing.
If you want a second set of eyes on your Shopify store's structured data, reach Hillcane at hillcane.co/contact or call (256) 384-2449.
Comments