English Español Deutsch Français Italiano Português (Brasil) Русский 中文 日本語

Structured Data For Ecommerce


Martha's slides ↓

Jono's slides ↓



Paul: Right then, we're live. I can see there's a few people in the chat already and there's a few more, there's Anton. In this one, we're going to be going through e-commerce, structured data and what we can leverage and how to leverage it. I know you two guys have got some really good presentations for us. 

I believe, Martha, you're going to go first. Well, actually, I'll let you introduce yourself. I know everyone knows who you already are but please do divulge more a bit more, I think.

Martha: Sure. My name is Martha. I'm the CEO here at Schema App. I'm coming to you live from Guelph, Ontario, Canada. I'm actually in my office. I'll share a little bit more about my knowledge graph as we jump in but I'm really excited to be a part here and contributing to the SEMrush Webinar Series.

Paul: That's it. Jono, I'll let you introduce yourself.

Jono: Thank you very much. I'm Jono. I work for a company called Yoast which I'm sure many of you have heard about. If you're lucky enough to be a WordPress person, then hopefully you use our plugin. I run what's loosely known as our Special Ops team, which is all of our research and development SEO stuff and the delightful treat that is doing webinars like this as well as being the brains and muscle behind a lot of our Schema implementations. This is really my very, very favorite thing in the world of SEO to be talking about so it's delightful to be back here again.

Martha: And we get to nerd out together, I love it.

Jono: Yes, it is the best. All these SEO conferences talking about links and content, it's all boring stuff, Schema is where it's really at.

Paul: That's it, enough about links. Right then, Martha, I'll let you kick off with the first presentation.

The Latest News in Structured Data

Martha: Today, I've captured a couple of pieces of news because I do think it's important as we do these on a regular basis to just talk about what's changing because there's a lot changing. Jono is going to build on a lot of what's changing in the vocabulary. 

Let's jump in. We all had a cry, I think over this summer when Google announced that they are officially going to be retiring structured data testing tool and that the Rich Result Testing Tool is moving to GA. 

This is good news in that Google is going to actually keep the Rich Result Testing Tool up to date with documentation. They're also doing some more advanced things like being able to show, you can see here it's recipe snippets, showing different types of snippets. 

If you are doing more advanced markup, let's say recipes with video and FAQ and others, that you actually will be able to see those results within this tool.

The drawbacks are, for those of us that like to see entities and nested entities with a lot less clicks, then that's less ideal. But the good news is, Google is responding to all of our feedback on what we want to see the tool evolve to, to get back to that really simplistic, clear vision that we saw within the structured data testing tool. 

We also have had a really rocky couple of months with some of the Google algorithm changes, but when I look at it from a Schema Markup standpoint, we've been seeing a lot of impact on FAQ rich results. It primarily starts on July 15th. We're seeing, I'll say, a mix of results.

Somewhere we're seeing, what I call, a drop on the 15th but it maintains just a lower performance level. Primarily, where we see that is in the financial sector. Where we see a drop on the 15th and then almost a loss, really low is in e-commerce. 

I'd love to say I know exactly why that's happening. The team is just digging into that right now and then we'll be announcing that to our customers as well as sharing some of those insights with the market. 

And then the third area where we're seeing lots of fluctuation where we see a drop and then I'll say bouncing performance is primarily in the healthcare sector. At Schema App, we're trying to dig into not just what are we seeing but is it actually because of how they've put in the FAQ Schema Markup, where they've nested it, et cetera. 

Now, with regards to e-commerce, there's also been a change where Google has done a lot of clarification. One of the clarifications that they've done specifically around products is around the product rich result being specific for a product and not for a category or a list of products. For example, shoes in our shop is not a specific product, it would be a product model or a group of things that fall under one model, which is what I'm going to talk about.

And then the last piece of news I want to highlight is, Jono and I are really, really passionate about nested and proper Schema Markup, on July 8th, they made an update to the documentation that basically said make sure you're linking things together.

In the example they give here it's about a recipe and a video so if the page is primarily about a recipe and it has a video, make sure that you're actually nesting that video under the recipe and using @id for both.

Jono: Do you mind if I chip in on this because this is the thing? This is the biggest thing. I know we pitched this as an advanced webinar and I think this is the difference between basic Schema and advanced Schema. Every SEO in the world can copy and paste or use Google Tag Manager or write their own basic Schema to say, “this is a video or this is a recipe”. 

The step to advanced is using ids to link and build connections between those entities. This is what it's all about. If this sounds alien to you, if you haven't got to this level, this is where you need to be looking. You need to be describing network relationships and things. It's so delightful that Google have finally said, oh, by the way, this is the thing. Just wonderful. 

Martha: They've made me an honest woman, frankly, because people I think thought I was full of it for the last five years when I talked about this. But this is where the semantic piece comes in. By actually having @ids, you're actually starting to reference entities on the site and make sure that you understand where something is managed.

Again, as a semantic technology company, at Schema App, this is foundational to how we think about markup. But good evidence from Google that, that is indeed what they want to see happen. Also, John Mueller, there was a great quote from him in January where he said, "It's only going to get more complicated." I think this is real good evidence of that.

Jono: And as you are saying just now, the difference between the structured data testing tool and the rich results is increasing as it gets more complicated. You don't just have a recipe, you have a recipe with a video by a person with snippets that references another thing that's published by a different company, et cetera, et cetera. You can't just have those things referenced on the page, you have to describe the relationships. This is very early days but it's going to get much more intertwined.

Schema e-Commerce Product Models

Martha: Let's jump into product model definitions and product models in e-commerce. I wanted to touch on this because this is actually based on a blog we wrote originally in 2016 as we were working with some big e-commerce vendors. 

But we like to start with how do WooCommerce and Shopify talk about variable products or variants, just so we're all on the same page so you know what I'm talking about when I talk about variations. WooCommerce talks about it being a product type that lets you offer a set of variations such as price, stock, size, and more. For example, the combinations could be a large purple t-shirt or a medium red shirt, and we're just actually using variables. 

My math background loves thinking about all the options there. And then Shopify describes it as being products that come with more than an option and then it's the combination of those options that create that product set. 

That's what we're going to talk about today. We're going to talk about all the different ways you can do Schema Markup, I'll say the basic one, at least get this piece or nail this piece but what would be the ideal markup? 

Product markup would be just the properties that are shared across the variants. And you might end up in this and that, you only can do the most basic markup if some of the other data isn't available or it's not consistent across all your product base. 

What you can see here is, we've called out the product the names Clarks Falalala Shoes for Men, where the image is, what the description is. You can see we have one basic offer, we're saying it's €45.99 and it's in stock.

Well, that's great, you have one product but perhaps there's different sizes of products. And again, there's, I'll say, more ideal markup. We would include all that information about the sizes, but if you don't have access to that, at least use an aggregate offer to show that there's a price range. 

Additional properties, again, a more advanced thing that you can do where you basically get to make up your own properties, but because of unit code, there's actually references in unit codes like two different things such as memory et cetera. 

Ideally, you would actually define, I'll say, the product group and what's common on there, and I'll say properties that tie to it such as that aggregate price range, but then you would use the property model and then basically the type product model to then go at it and define every single thing that you know. 

If you think of a product learning page, so often there's a table that has all the information about that product. Why aren't you marking that up to help make sure that it's understood so that it can then match it appropriately to where it is?

The key takeaway here is, ideally, your product models are defined with all the information that you have available and that you're using, I'll say, the product type at the top to group them together on things that are similar. On a cellphone page, there might be like, hey, look at our cool iPhone 400, and then you have listed below the three different types. Those would be the product models with their offers. 

This goes back to what Jono and I were just talking about, you're nesting it and defining the relationship. Again, something we're really adamant about at Schema App is, being as specific as possible about what it is that you're describing. Calling the product with an offer range is not specific when we actually know that there's versions of that product and variations that go with it.

Jono: Every site and every type of product will have differences in those differences and the key is to go and really pour over what kind of definitions does Schema support and what's the closest fit. You end up with these incredibly complex trees with variant products. If you've got five different colors and five different sizes and five different logos, that is a lot of variants and everybody is going to need to work out what the right architecture should be.

Martha: Well, there's a big difference between a full polyester shirt and one made out of bamboo, and I say that as a picky buyer that likes to buy bamboo dresses and t-shirts and so forth. Wouldn't it be nice then if you actually get results that talk about the fact that they're made with bamboo versus 100% polyester? 

How Structured Data Helps e-Commerce Analytics

Let's talk a bit about analytics. Why I like doing product models and getting into all the nerdy stuff is because, once you define those, that data is structured and you can reuse that structure in analytics to ask questions and get insights. Again, one of our principles at Schema App is, doing the structured data is step one but then we actually want see how we can leverage that to get insights for the business.

This is actually Schema App from a while ago where we were saying which author drives the most sessions on our website from a content perspective? We took the Schema Markup property of author and added it into analytics using a custom dimension and we do this programmatically at scale.

You can imagine, if you're looking at all those product model variations, we could ask a question of like, which color of t-shirt drives the most conversion or revenue? Now, you might have that because you have a really great invoicing system and you can track it all down, but you can ask questions of like, the actual number of ratings on my product, does that actually affect conversion rate? 

You can start asking really interesting questions of the data once you actually do really proper complex Schema Markup that might then allow your SEO team to influence other parts of the business.

Jono: This is huge. If you're a bit of an analytics nerd and if you've got some basic Google Tag Manager skills, it is really easy to take Schema Markup and transform it into data layer stuff for Google Tag Manager and then it's trivial to pull that into Google Analytics site. You can just go, give me everything in my Schema graph in Google Analytics and start playing with it. 

We do loads of this on yoast.com. It is awesome. It's really transformed the way we think about analytics and page-level metrics. Really cool.

Martha: The last thing I have just before I hand it off to my colleague is, we are really passionate about training, teaching and enablement so our website is full of all kinds of interesting articles. We also have a whole support area and knowledge base. With that, I'm going to hand it over to Jono.

Going In-Depth into Schema Product Options

Jono: I'm going to look at some of what might be coming next and some interesting odds and ends and then hopefully we'll have some time for some Q&A. I've seen some interesting stuff already so I'll blitz through my stuff and then we can get some of the audience questions.

I thought we might pull up the schema.org page for products and just eyeball it and see what's interesting. Because I know that's a page that nobody even looks up. 

You still want to describe your iPhone has 32 gigs of Ram or however much an iPhone has, I'm an Android guy. But there's just stuff in here that nobody ever really looks at. 

Audience is a really interesting Schema property for a product. Many products are targeted to the specific audience, whether that's gender or demographic or age, and you can define all of these types of things. Now, you might just do a bit of work to put that into place, whether it's through the CMS or something like a Schema App, but this sort of stuff is really valuable.

If you're already describing this in the content or you know it, this is really, really cool. I think it's worth looking at briefly the relationship between brands and products as well. I know in a lot of cases the relationship is as simple as this is an e-commerce store selling shoes made by this brand. 

But quite often, you'll find that the products are manufactured or retailed or branded by a different organization than the ones selling them and you want to be describing those relationships as well. You don't want to accidentally say that these Nike shoes that my site sells are manufactured by me. That's a different type of relationship, it's really important to get that right.

Martha: It's also really interesting if the e-commerce store focuses on specific brands and that you have a brand landing page that talks about that brand and why you sell it and so forth. When we talk about nesting and linking, the brand is good, especially if you're wanting to define that brand. 

But maybe you're also trying to get that brand page to perform itself so how do you think about linking both the products to it but then also thinking about what else you can do in that brand page. Here, if you link it appropriately, then it's really beautiful and nested and can also help drive traffic perhaps back to your brand page.

Jono: There is definitely value in going deeper and describing the nuance, not only because Google might reward and support it in the future but because there are ways in which they pass and process this that they don't explicitly showcase in the search results that help them understand the relationships between things. 

There are other things than Google out there, I want to come onto it briefly. But Facebook uses Schema, bits of Amazon use Schema bizarrely, Bing uses Schema better than it used to, there are other consumers out there. Look at what can be done and described and factor that into your strategy and don't start from what does Google reward and work back because you'll never get ahead of the competitors.

Martha: Take it back to your customer. What are your customers asking for about your products or what do they love about your products or why are they buying your products or why do they buy from you as a store? Those things are the things you want to describe.

Jono: One of the things that Martha entered into when she was talking about pushing data into analytics as custom dimensions is that, there's a whole other side to Schema which is, thinking about how you structure your business data, your inventory and your operational information using these kinds of properties and then feeding that data in both directions.

You might find that you already have internal types of descriptions and ways of structuring data that might be easy to expose on your website. But the opposite might be true; you might have really robust Schema that describes all the relationships between your product and an absolute minefield of an internal inventory system.

You can use this kind of structure in the other direction, which is really, really useful. This isn't just for markup on the web for Google, this can be the single way that you describe all of your stuff so this kind of stuff is really, really powerful. 

Martha: We're already building this type of thing into the user experience because we know it helps increase the shopping cart size, it helps increase conversion. This is just how you can use in Schema to do that. We do this for our e-commerce clients without a blink because you've already built that into your experience.

Jono: It's not hard to imagine that Google might turn around next week and say, oh, we're building a related product recommendation engine and they're using this kind of data. That would be really easy for them to do. 

You can go into a huge amount of depth on this and you can really go overboard. You could give every single one of the shoes that you sell a height property. Technically, yes. I don't think there's necessarily a huge amount of value unless you're specifically marketing to people who care about how tall their shoes are.

What’s Coming Next in Schema?

Let's change gear because we have some other little bits I just wanted to touch on, which we're worth exploring because that is all based on what you can do now. There's some interesting stuff coming in the pipeline and we should save some time for some questions. What is coming next?

Have a look at these properties like the distinction between types of refunds and how many days you expect it to take to turn that around, have all these things ready. You can mark this up now, it might achieve a huge amount. You can have it in place and ready so that's pretty cool. 

These are the kinds of things that a consumer wants to be able to see and understand at a glance when they're comparing products and services and offers. This is the kind of thing that Google wants to extract and showcase in rich results and snippets and that kind of environment. If you have this sort of stuff, it's worth looking at.

They're not just throwing this out here because it's a wishlist idea of something they're dreaming about, to have got to this stage of definition and conversation, work and conversations have happened to get it this far. 

The flip side is that this isn't finalized yet and there is still debate and discussion around the specifics of how this will work, the mechanisms, the specific naming conventions of tags, the relationships, and other things. 

The big existential thing that's happening that I just wanted to touch on outside of specific Schema properties is what's happening in the world of marketplaces and particular in Google Shopping and Facebook Marketplace, where they are moving increasingly to, what I'm calling, Schema-first inventory data, which is not a great way of describing it.

Let me explain. Google Merchant Center is where you sell your products through Google. It's the evolution of Google Shopping, it's all of the product results in Google. And what they're saying is that, increasingly, rather than you having to generate an XML feed or upload a spreadsheet and do that every morning, or build complex systems to synchronize that, they will just read your Schema. 

When Google comes along and scripts your pages, as it does probably many times per day or per week depending on your throughput, they update their understanding of your availability and product details and your inventory and price in particular based on your markup on your page. I think this is huge.

Martha: The piece though that I love about this, again, I'll call it existential or the strategic nature of it, is, I always talk about structured data almost being that data feed for your entire marketing website. 

Jono: Historically, you would have a marketing website, a blog on a subdomain, a data warehouse, a CRM, a database, an app and an integration for a smartwatch. Now, all of these things are your website, whether that's through a combination of progressive web apps and other stuff integrating, but it's really interesting. Your website is a presentation layer on top of the data and this is the single source of truth. 

It's not a huge stretch to say that we need to stop thinking about websites as marketing collateral for our potential visitors and audiences and start thinking about them as things which are consumed by different entities, people, types of technology in different ways.

That's all I have. I skipped through that and I've left plenty of time for questions. Hopefully, there's some interesting ones that we've missed whilst that has been ticking along.

Schema Entities and IDs In Separate Pages

Paul: Jose mentioned at the beginning, it would be awesome if you guys could explain the entities and ids in separate pages, for example, a product linking a related product, which I know you went over in your slides. You mentioned ids, Martha, and you've mentioned the related products as well, Jono.

Jono: I think there was a related question which was about ids that span multiple pages. I think this is something we touched on last time we talked. It's really frustrating that Google does not support or do a good job of matching up relationships between entities with ids on different pages. 

If you have a product page in this example, all of these relationships need to be defined on this product page including the address of the U.S. office and the description of the FAQ, et cetera. You have to build out all of those entities on each page where you want to describe them. 

You can't say this blog post was written by this author over on that URL because it won't match those relationships. So you have to describe the author in full with an id in context.

Martha: I've seen them doing a better job of that so I actually disagree with you. I think you have to describe enough to describe what that entity is but you can relate back to the URL and they're smart enough to understand that, oh, that whole piece is there. 

Now, the structured data testing tool used to be really crappy though at reporting on this where, for example, we'll only go three hops deep within our markup. If your organization has five people on it and then those five people have these FAQs, you're like, at some point go to that organization page and find out all that information about it. 

I am seeing Google do a better job of that. I would say from the nesting and purest approach, you have to relate some of that information, but as long as again that @id or in a technical term, the URI, is defined and is unique, Google is smart enough to figure that out.

Jono: Yeah, and even if they don't explicitly connect to those cost pages, they consume each page and they can imply it in the background. 

Martha: We have to be specific. That's where it's important.

Avoid Marketing in Your Schema Markup

Paul: Andrea Molin has asked the question, in product markup you can add some generic keywords such as category for the name field, example XYZ is the product name of sneakers of men and the product's name XYZ Sneakers of Men. 

Jono: I would be very careful about trying to market in your data. This is not what it's for. It's not how Google wants to use it. A whole bunch of their guidelines actually have some really great examples saying, you should not do this.

Martha: That's where I was going. I was like, I think this may be an example of that should not be in the name of it. Just be careful. I guess part of it is, structured data should be used to articulate what it is and not necessarily to, I'll say, keyword stuff or market within it. They give usually some pretty good examples of how to talk about a product not an offer, for example, or what to put in there.

Jono: There other fields for that sort of thing. If they're sneakers for men, describe the fact that they're sneakers and use the audience attributes to say, men.

Martha: That's why there's all those properties there. You could actually describe everything, think beyond the documentation.

Jono: The Google Rich Results, Schema documentation has some great examples of very contained things you can do, but it's not a great way of thinking about Schema. The schema.org documentation is where you should be really putting your brainpower in.

Martha: Yeah, and there's 42 properties and 840 classes.

Errors in Google's Structured Data Testing Tool

Paul: Exactly. Our friend, Jason Barnard has asked the question. How much of a problem are the errors in Google reports in the structured data testing tool?

Martha: I have a strong opinion. I dislike how Google says that your markup has an error in it if you choose not to include a property that they have as a required property within their documentation.

For example, job postings is one of my favorites. I don't post a salary range on my job postings, I choose from a business perspective that you need to have a conversation with me about that. I'm not going to put it on my job posting and Google is like “error”. 

There's no errors and my Schema App generates a Schema Markup, thank you very much. By the way, it's actually okay if I don't include that required field because it's a business decision or that information doesn't exist. 

I actually think it should be a warning like, “hey, you're not going to get this rich result because it has this required property, you should really consider looking at that as part of your content strategy or looking at adding that”. And then the warnings are basically just like you're missing a recommended property. 

I actually think, for an area of search that's about being specific and clear, their warnings and errors are misguided, however, they are to tell you that you will not be eligible for that rich result.

From that standpoint, they should not be ignored. You should take them as input into your content strategy or for that page and highly consider including the required properties so that you have the opportunity to get that rich result. But it doesn't mean that there's commas missing or quotes missing or that you've done a wrong Schema.

Jono: And the other thought was, if there are legitimate errors in the schema, yes, that's an issue.

Martha: Correct.

Jono: If it's saying this is duplicated or this is erroneous or this is a closing bracket that shouldn't be here, then do not ignore that, go and fix it in the same way that you wouldn't leave broken code on a page

Does Schema Markup Reveal Info to Competitors?

Paul: Perfect. I like your view on the errors. Tony McCreath has asked the question, some people are getting concerned about structured data makes it easy for competitors to find out what they're doing or worse comparing, what do you think?

Jono: Yeah, and if you're competing on price or the color of your t-shirts, then you have a bigger strategic problem and either Google or Amazon are going to eat your lunch in the next week or so anyway. 

There is one exception that I think about which ties back to the things you might push to analytics et cetera, there are some categories of information which are critical business providings like, you would never want to expose your returns rate in your Schema Markup. 

While it might be useful for analytics, it might be useful for conditional tagging and page behavior, that sort of information is quite valuable. But anything where you're just describing what's on the page in Schema, that's not competitive advantage, surely.

Paul: And the other thing you need to realize is, if your competitors are looking at your prices, like you said, they can go on your website and see that anyway. If they are half-educated, they're not going to be looking at it manually, they're going to be looking at automated.

Services and Schema Markup

So there's going to be other ways that you're going to be able to stop them from getting that information quite easily. I've blocked many a site from doing that so there's other ways that you can stop them from getting that information rather than worrying about what you're putting in your structured data. Will Schema for service ever come back? 

Martha: Service isn't gone. Services in Schema Markup just like the other 820 ignored types within schema.org, is alive and well. I think what you have to think about is, and this is a principle we work really hard with our customers on that, if you can't get the rich result you want for it, get creative with regards to, if you're talking about services, talk about FAQ about that services which can get a rich result, talk about how to and how that works.

A service isn't a product so, for me, I still think that again, get creative, use other types of rich results to embed a nest under your service saying like, it's a subject of a video, has part FAQ page, or do a multitype entity and make sure you're clear that it's both. 

The thing I'm also really sad about is, just that they took away, I always call it, the ratings rich result but it's the review snippet for blogs. 

Jono: I should echo multiple typing is so powerful. Actually, Google is surprisingly good at handling it. 

Paul: That's it. It's been great. Thank you for you guys sharing all the information around e-commerce and structured data.

Jono: Thank you.

Martha: Thank you.


Check out other webinars from this series