10 Things You Don’t Know About Structured Data

When I introduce myself, I like to do so with a knowledge graph. I explain that I’m an alumni of Cisco; I spent 14 years there doing online support strategy as well as product management. I’m an alumni of Queens University and MIT,  I have a very technical background in mathematics and engineering, as well as strategy and innovation. I’m Canadian, the co-founder of Schema App, and I used to own this awesome car that was an Austin Healey Sprite. My actual car was in the movie Losing Chase, which was directed by Kevin Bacon. Kevin Bacon used to drive my car.

The reason I share that is that you have now inferred that you are three degrees from Kevin Bacon since I’m two degrees from Kevin Bacon. The same inference that you just made for Kevin Bacon is the same type of inferencing that Google does when trying to figure out how to provide searchers with the best answers to their questions.

In this article, we’re going to talk about schema markup and structured data. I’ll use those terms interchangeably, although I do prefer schema markup because it’s actually meant to disambiguate the definition of things, whereas structured data can be lots of different things.

If you’re not familiar with it, it’s what helps search engines truly understand the content so that it can best match things with the searcher’s intent and also reward you with rich results.

1. ROI Beyond Rich Results

Schema markup provides ROI (return on investment) beyond just rich results. Google’s John Mueller stated that it’s not just about rich results, but really promoting understanding, which provides great value. In our work with customers, from small/medium business all the way up through large enterprise, but specifically focused on enterprise clients, we’re seeing outstanding results.

Not just in impressions and click-through rates, but all the way through to customer journey including impact to rank, more interaction with the content, more time spent on sites, and eventually even higher revenue.

In May 2019, Google announced that they had a specific motivation for continuing to invest in structured data.

It was during Google IO that they talked about how users are trying to reach out at different moments and through different services, so different times of their day and through different devices or surfaces (think of your phone, your car). This is a great opportunity for content creators, despite building and maintaining those customer experiences being hard work.

They said this is why they’re doing structured data: if we focus on building amazing content and translating it into structured data, Google will then help reach those users across those different surfaces and those different experiences. What this means is that when you’ve optimized with structured data, you’ve actually optimized not only for search but also for voice. 

2. Errors, Warnings and Content Strategy

The schema markup process starts with strategy, and then moves into authoring where the JSON-LD or schema markup is created. You then have to get it on to the site through deployment. Over time you’ll need to maintain it, either if you get new results, new content, or changes to the layout of your page. You then report and analyze it and then go back to strategy – it’s an iterative process. 

When you get Google errors and warnings, it doesn’t always mean that there’s anything wrong with your structured data. It just means that the required and recommended fields that Google is looking for in order to qualify for those rich results and present the content appropriately aren’t being met.

When you get a warning or an error, it’s just a matter of addressing the fact that the content isn’t visible on the page. Once that is understood, you can add the content, optimize it, and eliminate the errors and warnings.

While Google errors and warnings mean that your rich results eligibility could be at risk, it doesn’t actually mean that the way you’ve written your structured data is wrong.

One example is that we at Schema App don’t put a salary on our job postings. That’s a choice we make for the business not to include that information. But because of this omission, we receive an error or warning that that content is missing for JobPosting rich result eligibility, but we just dismiss it because it’s not appropriate to our content.

3. Schema.org Extensions and Actions

Schema.org extensions are entire vocabularies that have been written for specific areas of the industry. There’s one for Automotive, one for Health and Life Science, one that’s just started around the Internet of Things, a bibliographics one around Library Sciences, and then Finance (sometimes referred to as FIBO).

The finance extension has actually been merged into the overall schema.org vocabulary. This allows for an even more specific language that you can use to describe things within these other industries. If ever you’re trying to describe a business, but it’s a medical business, or an article that is a medical article, you can look at schema.org for specific examples or specific classes that describe those things within those industries. 

The other piece that is hugely underutilized is ‘actions’. There are roughly 14 specific actions that you can use.  Here’s a list of some of them:

• CreateAction
• FindAction
• PlayAction
• SearchAction

The more users start interacting through these different services, the more relevant they will become. You won’t always be looking at content with your eyes on a browser on your computer. You might be interacting with it through a voice channel or while you’re driving in your car. The actions that you can take, or that your assistant will give you options for, can actually be defined in the structured data so that interaction can take place.

This is an important area to understand, as it allows the user to take that clickbait into action and ensures the content is relevant across any surface.

4. “Proper” Connected Schema Markup

At Schema App, we love to talk about connected schema markup. It’s very common for people when doing structured data to exclusively seeking rich results, but there is so much more to it. In order to get that understanding piece that John Mueller was talking about, you actually have to connect the dots in order for search engines to understand the context of how things are connected on your pages.

For example, from my introduction, you know how I’m connected to MIT, Schema App and Kevin Bacon. You can do the same thing with your content.

Here are some tips and tools for you to figure out how to ensure that you’re fully optimizing on not only rich results, but how your information is connected: 

Don’t Put the Same Schema Markup on Every Page

We’re talking about plugins or other things that put Organization markup on every page. The reason this isn’t ideal is because if the same markup describing exactly the same thing is on every page, then search engines don’t actually know which page is really talking about that thing. You want to be really specific so that you can bring clarity on what it is you do.

Don’t Create Islands of Schema Markup

An example of this would be creating your locations, your organization and your products, but not describing how they’re connected.

Here are some tips on how to do that appropriately:

Ensure You are Telling the Story

The most important thing you can do with your schema markup is make sure that you’re telling the story; you’re explaining how these things are all connected. This is really what then yields a knowledge graph. It’s not just doing schema markup but doing proper schema markup where it’s really well connected.

Here is an example of ensuring the connections on your page are explained appropriately:

We’re going to look at a food establishment with an amazing marketing video on it. How do we actually say how those things are connected? We don’t want to have two entities where we have just a video and just a food establishment – we want to make sure they’re embedded. 

If you go to Schema App, we have a free tool that helps you figure out how to connect them.

Schema Paths Tool

Go to Resources > Tools > Schema Paths. 

Schema Paths was developed by my co-founder Mark when he got tired of going to schema.org to figure out how he was going to relate two different things. Within Schema Paths, you can simply just pick the two different classes. In this case, you would choose a food establishment and a video object and it will tell you how you can relate those two things.

For example, ‘subjectOf’ is the appropriate way to connect the food establishment as the subject of the video. This would be a really clean way of applying it so that the primary entity on the page is around the food establishment. It highlights that it is a page about the restaurant, and then embedded within that would be subjectOf, then you would link to the data item or link to the video object.

You can also relate it the other way: if the page was primarily about the video object then you might use about and say that it’s primarily about this video. The video is then about the food establishment and that way I’m being very clear as to which one is the primary entity of the page.

Use Strong Connectors

The other suggestion we have is to use very strong connectors. As you’re looking at linking things, use fields such as About, Mentions, subjectOf and hasPart.

For example, say you’re writing a news article and you want to be very clear that it’s about ‘Jack Ward the Cowboy’. You ideally want to use a Wikipedia entry in order to define who Jack Ward is. In this news article you could say that it mentions interstate 10 and also avocados. Again, starting to link key topics that were within the article to authoritative sources that clearly define those topics. In this news article you could say it’s the subjectOf the video object ‘The Bees’.

Now, a more advanced option is this example:

You have a very long web page that talks about a specific service that is being delivered. On the page are many FAQs about that service, as well as blogs related to the service. We would opt to classify it as a Collection Page because it contains many different things. We would use a very strong connector (About) to specify it’s about the service, and then hasPart FAQ. The FAQ then hasPart Questions and AcceptedAnswers and then it mentions BlogPostings.

As you can see the strong connector is the About field, and then the less strong ones are hasPart and mentions. This allows us to make sure that we’re still getting that rich result for the FAQ but that it’s all nicely connected so Google really understands how this information is related.

5. Main Entity of Page

The main entity of a page is really identifying the primary topic of the page. This often comes out if there’s different schema markup data items on a page. You could have a news article, a video that haven’t been embedded, and it leaves you wondering “what is this about?”

An example I often give is a scenario where there was an event site that had five different events on five different days. But, what is the primary event that we’re talking about? If there are different items on the page, ideally you would have embedded them and linked them like we just talked about. But if you don’t, it’s unclear which one of these is actually the main entity of the page.

The primary thing that is the primary topic of the page? In order to identify that, what you can do is use the property mainEntityOfPage and add in the URL of the page it’s on. Now, you would only pick one of these to do it on and then that would actually indicate to Google that this is the main topic of that page.

6. Multi-Type Entity

This is where you can actually merge two different schema.org classes and use properties across both of them. Where we see this really commonly used are situations like a house for sale or a house for rent. As you saw my previous example, it’s both a product and a single-family home. Or a comedy event on-air is both a comedy event and a broadcast event. A book for sale is both a product and a book. A hotel for rent is a product and a hotel room. You really want to do this only when it adds more clarity. Multi-type entities are where you merge those two. I believe Schema App is one of the only tools out there that allows you to do this both within our Editor as well as in our Highlighter, either one page at a time or across many.

7. Additional Type

Additional type also adds clarity to a schema.org type that maybe isn’t in the vocabulary. I always joke that there’s no local business class for a marketing agency even though digital marketing agencies make up a large portion of the people doing schema markup.

In this example we’re going to look at an orthodontist, hence the smiling face.  You would identify the type, which in this case it would be a dentist. Then for additional type I would use a Wikipedia entry to define more clearly what type of dentist I want. Think of this as a way to further clarify the type that you’re using within schema.org.

Now I was in Texas when I first presented this, and this is Texas Longhorn. So it’s not just a Thing, but there’s no animal class in schema.org. What I could do is use additionalType and use the Wikidata entry to further define what this is. The Wikidata is even more specific than Wikipedia since Wikipedia is often localized for different languages. When you see a number like this it means it’s identifying the entity in the Wikidata database, which then populates Wikipedia’s.  In this case I’m saying it’s not just a Thing; it is very much a Texas Longhorn as defined by that Wikidata entry.

8. Additional Property

All right, additionalProperty. AdditionalProperty allows you basically to use free variables to further describe something within a Product or so forth. As an example, let’s consider a camera. You might want to call out some specific features, such as the number of megapixels.

In this case you would use additionalProperty and you would create a data item using propertyValue. PropertyValue is really a property value pair where you define relationships between a variable and what its actual number or quantity is.

There are some things already set in here, like a max value measurement type, min value, name, etc. You always want to include name and then value; those would be the minimum. If you can find a unit code, such as a UNC fact code for megapixels, you can go above and beyond and also use that.

9. Lists: Item List, Collection, Offer Catalog

There are the basic kind of lists like a BreadcrumbList and a HowToSection and a HowToStep and an OfferCatalog. I decided to clarify when to use these lists. An item list is a list of any type of Thing. An OfferCatalog is a list of offerings, which could be a list of Products.

So, if you had a landing page on your store you would have an OfferCatalog. A CollectionPage is really interesting because it can kind of put a container around a list and then allow you to connect it. You saw this example when I showed this previously where this CollectionPage allows us to have lists within it, but then also use strong features or properties such as About and Mentions.

10. Analytics

Structured data really goes beyond search – it can also help you structure other things like your analytics. Schema App recently released a Trend Report for all our clients and this replaces the Google Structured Data Report that used to be in Search Console. It allows you to track your schema markup over time. We also have an offering called Enhanced Analytics which allows you to take the schema markup that you’ve built and add any property into Google Analytics and soon into Adobe Analytics.

In this example we wanted to ask the question “Which author gets the best results?” We’ve taken the schema markup out of our WordPress plugin, loaded it programmatically into Google Analytics, and lo and behold Martha and Schema (who Mark says is him in his Admin mode).

What this tells me is that I should continue to write the content because my posts drive the most sessions. You can imagine there are a lot of insights that you can start getting now from your search data if you reuse that structured data.

Get in Touch

If you’re interested in learning more, feel free to reach out to us at Schema App. We’re happy to show you more about Enhanced Analytics.

 

If you need a hand getting started with your structured data strategy, we’ve helped customers such as SAP and Keen Footwear drive more quality search traffic to their websites.