BEFORE READING: If you’re unfamiliar with JSON-LD, check out this article to learn more about the structured data format and why we prefer it. Overall, JSON-LD is much more flexible and scalable in comparison to microdata. Rather than having to add and edit microdata spread throughout the HTML of a page, you can add and edit JSON-LD in one place, wherever it’s pasted in the HTML.
While compiling recommendations for structured data for a client, many questions came up. After looking through countless articles on schema markup for e-commerce and going knee-deep into Schema.org, I still came up short when trying to find answers to my questions. Whether you’re working on implementing structured data for your own e-commerce site or a client’s site, here are 7 things that will help you along your journey.
If you’re unsure whether your structured data is valid or is free from errors, use Google’s Structured Data Testing Tool. It can confirm whether Google sees the markup on a page. If you’re missing any recommended (displayed as “warnings”) or required values (displayed as “errors”) as part of the structured data type, Google will tell you so. Additionally, the tool will report any syntax errors in your code.
Another great aspect of the testing tool is the ability to view the structured data used on competitor sites. This can be great if you’re unsure where to start or what schema types are relevant for your e-commerce pages. You can even learn from their errors and warnings.
Whether you’re the one adding structured data to your e-commerce site or the one making recommendations, it can be overwhelming to think about all the schema markup needed across the many pages of your site. Rather than thinking about this page by page, approach it from a template level: product categories, products, contact, about, and so on. Also include a universal template, that is, structured data that would appear on all pages (such as BreadcrumbList).
Delivering templated structured data to a client or your team can also aid in communication with developers and make it easier to implement changes.
We often come across clients that use third-party apps to collect and display product reviews. We get a lot of questions about review markup and whether to include it as part of their product markup. Review markup should always be included in your product markup as it is a recommended field. But do you need to add it yourself? Here’s a visual to help answer that question.
When taking a look at the examples included at the bottom of Schema.org’s Review schema, one example review markup uses “description” and the other uses “reviewBody”. They both appear to be review text. So, which one should you use?
I would recommend using “reviewBody” for review text as it is a property of Review, whereas “description” is a property of Thing. The description for “reviewBody” (“The actual body of the review”) seems to fit review text more closely than “description” (“A description of the item”). Furthermore, when comparing with Google Developers’ guide on review snippets, they used “reviewBody” for the body of a review.
Category pages can include products, yet it’s not quite a product page. About two years ago, Distilled, using an SEO split test conducted on our ODN platform, experienced positive results when including Product schema on e-commerce category pages. Unlike product schema on a product page, we omitted links to individual product pages when including the markup on category pages. This is in line with Google’s structured data policy on multiple elements on a page:
See the next tip on how to include markup for multiple products on a category page.
Are you using multiple structured data types on a single page? Instead of using numerous