Epic #SEOisAEO series: More than you thought you needed to know about Schema Markup
- Can we map Schema Markup to Knowledge Graphs? Where types in Schema are entities? Properties are attributes. Nested types become relationships
- What are some groovy ideas for sameAs for companies, people, and products?
- A quick description of what @id unique Unique Resource Identifiers are, and what the best practices are
- If Schema's feeding action and events, can we just use Schema Markup and not bother creating actions and skills?
- Voice Schema is good fun to play with. But what about for businesses in real life?
- When designing your site, you should think about the Schema
- How does JobPosting markup work, and when is it coming to Europe?
- Does Schema help rankings, directly or indirectly?
- We are now building the #SEOisAEO position zero profile
Jason: This is a subject I'm incredibly interested in. I've got seven questions. With a super special eighth, which is the ongoing position zero question. So stick around for that. Now, Schema Markup is cool. There's no doubt about that. Gary Illyes said, "I want to live in a world where Schema Markup is not that important, but we currently need it." And in my little trio theory of relevancy, understanding, and credibility, we are looking at understanding - the need to communicate with Google in a language that it can easily understand and digest. And that is Schema Markup.
Here we have the main basis of Schema Markup. Things: CreativeWork, Event, Organization, Person, Place, Product, Intangible, and Action.
To quote the Schema.org website - “These vocabularies cover entities, relationships between entities and actions.” That made me think because I'm a little bit obsessed about Knowledge Graphs...
Can we map Schema Markup to Knowledge Graphs? Where types in Schema are entities? Properties are attributes. Nested types become relationships
Gennaro, does that equal flip, flop, or fly?
Gennaro: Well, that's a tricky one. But that simple mapping to the Knowledge Graph alone doesn't fly. But through Schema, we are allowing the main search engines to look at the relationships that we're building up. For instance, the case of an entity that I created in the Knowledge Graph to answer the query "Who is Gennaro Cuofano”. So how did I do that? A few months before, I created a page where I indicated a set of relationships - I connected all my social accounts to the website property using sameAs. I was allowing Google to cross-reference my information. The power of the Knowledge Graph is not just the existence of the Knowledge Graph itself, but also the way it allows information to be cross-referenced across several touch points - that's what makes the Knowledge Graph fly.I like to think as the Knowledge Graph as a modern version of an advanced sitemap.
To expand on that: the sitemap is for allowing the search engine to understand what pages are important and what not. Instead, with Schema and the Knowledge Graph, we might be able to specify what the website is about. Thus, it is the "sitemap for meanings." As we're moving from search to voice, the sitemap which is the most basic tool for websites might be replaced by the knowledge graph, which might become the most basic, yet a must-have tool for voice interfaces. Thus, something that seems advanced today might become the standard in the next decade.
Schema is something that every website is going to need in the future, just to communicate. In the context of the Knowledge Graph, you want the search engine to understand the meaning of the site. The real meaning for you. So it's a way to tell your story so Google can understand.
Jason: What I really loved about that “It allows you to tell your story to Google”. And this idea of telling a story is … explaining, educating. Educate Google like you would a child - reliable information from reliable sources, confirmed multiple times. And Google needs you to join the dots up, and that's what Schema Markup enables you to do. Next up - using additionalType to be specific when a type doesn’t exist. If you want to say that your shop sells only beer, there isn't a Schema type for a beer store, but you can use Store and add additional type using ProductOntology. That’s cool. But perhaps more interesting is sameAs.
Here's an example from one of my clients who've joined the dots with their social accounts using sameAs. That's fine. I think that's a little bit limited. Dave...
Can you give us some groovy ideas for sameAs for companies, people, and products?
Dave: Sure. With sameAs, like anything with Structured Data, you have a 1-1 relationship and it is for information that is presented on the page. sameAs for people and companies, that is usually the social media accounts With my clients I look beyond that - we can have other associations. For example: if you have people in the medical field or the law field, there are other associations or other organizations that person or company is a part of. Ideally, they are strong organizations. You would like to connect that through sameAs in Schema. But also, because we have to have a 1-1 relationship with what is on the page, it gives you an opportunity to make a choice. “Do I put this additional content, which is a link of American Medical Association that my doctor or my practice is connected with?” It allows you to not only let Google understand through Structured Data, but gives you the chance to say, "Let me put this piece of content on there to make it more relevant when someone looks at that site." So the visitor thinks, "Okay, wow. They're part of that organization." That starts to build a little trust for that product, that person, that company.
Jason: Yeah. And by linking yourself to associations, organizations, memberships that make you more credible, you're kinda piggybacking off their credibility?
Dave: Right. But the key is that it is a strong association - something that is worthy of a connection. A company or a person can have tons of connections out there and, beyond the social media, you want to choose the strong ones. You want to pick and choose, as opposed to let's just jam everything in there. It is comparable to keyword stuffing. “Let's jam everything into sameAs”... but that's not what Google wants. Google wants the relevancy. They want connections that stand out, that means something. So that's why cherry-picking those possibilities is what I do for my clients.
Jason: So, be a little bit careful about sameAs. I've been overdoing it, getting a bit overenthusiastic. I think I will reign in my enthusiasm a little bit and be more reasonable. Thank you very much, Dave.
Now, a website homepage can either be the page, the company, or the domain name. In an article last year I said that @id identifies the entity we are referring to, and suggested we can choose it ourselves. Am I right? Am I wrong? Have I gone too far?
Could you give us a quick description of @id unique Unique Resource Identifiers are, and what the best practices are?
Ashley: Sure. I think there's a tendency to both make it more complex than it is or oversimplify what it can be. So if you're looking at JSON-LD, the @id is really just a node - it's really just the notification of, "Hey, here's a node, here's a resource." And it can be as simple as a URI - an internal resource. It could be a URI, or it could be the URL. The biggest mistake I see with SEO is that developers are actually using this appropriately, calling out the separate nodes, but SEOs don't understand what it is. So for instance, if we were talking about SEMrush and we're talking specifically about you, I might use the hash sign from your main domain to you that's mentioned on the page. I see a lot of SEOs go out and tell their clients this is not an appropriate URL. But it’s not a URL, it's an entity. So you are right in that it can identify the thing on the webpage. It can identify the webpage. It can identify just the URL. It can identify the domain. There are lots of separate ways to use it. And you'll hear it called @id for JSON-LD, but for anyone that uses microdata, it's the item id. Or if you're using RDFa, it's known as, I believe, resource. So, the same thing is used across the various different languages. Entities are the backbone of what we're doing here. It's almost like a full circle from XML back to where we are today, where we're trying to make those different relationships easy to define, and indicate how we all relate to each other. So this, to me, is a building block. As an SEO, I recommend you talk to the developers on how they're using it, and how they understand it, and that you brush up a little bit on your knowledge as well. I think @id is commonly misunderstood.
Jason: Yeah, great stuff. I’m wondering, in the example I just showed mailjet.com hashtag corporation. I find the hashtag is confusing because it can be an anchor. Is that a useful point? Or is that just me overdoing it, and getting a bit stressed out about something that isn't so important?
Ashley: I don't think you need to stress about this because in this case, it's not like our usual understood practice of creating anchors on a URL. It's really just saying this is the page, but we're talking about something else. It's literally just defining the entity and what that page is referring to, that node. You might have a page that has several different nodes and you might want to use those ids across your website and even point back to the identifier from different websites. So if I'm putting content on your blog, I'd use my @id to point back to a biography page I have on my own site. But that's not actually a link to an anchored page. It's just recognizing me as the entity.
Jason: And the vital thing is to be consistent.
Ashley: Yes. Ideally, consistency is good.
Jason: And a quick question for Dave - in sameAs is it useful linking back to your Freebase or your Wikidata reference?
Dave: No. That would be additionalType.
Jason: Great stuff! I heard a few months ago that Alexa was using Schema Markup as default Skills. That if the Skill doesn't exist for something, but they can achieve the task from Schema Markup, they will do so. And then Google said that they were doing the same thing. So I'm wondering...
If Schema's feeding action and events, can we just use Schema Markup and not bother creating actions and skills?
Gennaro: We have to make a distinction here. Of course, when it comes to Schema actions, we're moving toward the phase in which those become critical to allow a website to speak to several devices. But, this step is not immediate. For instance, let's think of Google. Your first step is Structured Data, then you can claim your Google directory page, and then the next step is going to be a Google Action (and in the case of Alexa, a Skill).
So the step from Schema to action is not immediate, but it's critical because the Schema action is what will allow us to move to that phase in which the JSON-LD explains what the website is about, and communicate through those devices. It's still underutilized, but it's something that I think is critical.
Let's take your case. You have a song on your website. You want your listeners to listen to the song. With Schema Action you can actually allow the user to take that action from the search results. It's not going to be automatic, of course, the Schema is just the first step. The web is not just a place where you find information anymore, it’s a place where you want users to take actions, even commercial ones. Definitely, the Schema actions allow us to move forward in that kind of direction. So I think it's critical.
Jason: So, Schema Markup is a means of communication, but it's only one step. To have the machines then communicate our content to their users is another step on top of that. But we can't have that communication to the users if we don't communicate through Schema to start with.
Gennaro: Exactly. That's the foundation, yeah. Plus, communication is going to be way more fragmented in the future. We can imagine just how much with all the devices that we're going to have, especially with voice. And Schema is going to be the foundation. Then we can expect other vocabularies on top of Schema - more ontologies. As you said, Alexa also uses a Schema ontology. So that's the foundation - the first step toward an action.
Jason: I read an article today, talking about knowledge graphs within enterprises - that is, companies building their own internal knowledge graph. And that seems to me phenomenally interesting because that then allows them to leverage all this information into formats that Google can digest.
Gennaro: Well, that's what we do with WordLift. We automate the process of creating a knowledge graph within your site. So we inject the Schema, but that is just the first step. The main aim is to have a site which has a knowledge graph which is independent from Google. Because, we know that Google might take your information for their Knowledge Graph, but then you are locked in by Google ... There's an issue with giving total control to the search engine, especially as we don't know how it is going to end up. Google is going to give us a business model, which is going to be mainly defined by Google.
And with an internal knowledge graph, we have an option. In the future, who knows? Perhaps we can connect these internal knowledge graphs to a blockchain, or other ways to monetize the knowledge graphs. But importantly, it is a way out, to avoid getting locked in by Google.
Jason: That was brilliant. In fact, that wasn't a plug. I didn't know that's what WordLift did. The article was actually completely unconnected, but it was a nice plug without wanting to be a plug. For me, that's phenomenal, and I do like the idea that maybe perhaps we can relieve ourselves a little bit of our entire dependency on Google. As an aside, I saw Alexis talk at BrightonSEO in April. She did a talk about advanced and practical Structured Data. It was really, really, really interesting. If this episode is missing anything, it's probably in her presentation, so I recommend taking a look. She talked about SpeakableSpecification, which has not been validated by Schema yet, and yet Google is already saying, "Yes, we do support this. We will use it." Same thing for using cssSelector and hashtag anchors to reference content blocks rather than putting the Speakable content in the Schema. Why is Google doing that? I suspect they are too impatient, to push this out for the Google Home. Beyond that on that topic, let’s look at voice related Schema Markup. HowTo, HowToDirection, HowToSection, HowtoStep, comments, answers, questions, reaction etc. All these Actions and Reactions, are things I would assume voice assistants can use - they're actions that can be taken by these machines.
Voice Schema is good fun to play with. But what about for businesses in real life?
Ashley: I don’t think that voice is everything to most businesses yet. And I think that it is premature to put a lot of stock into it unless you have a very specific business plan, and you have support and finances for both your dev team and your marketing team. I think everyone wants to touch it, but most are not sure what to do with it yet. There are some really specific use cases that are interesting now, for example, if you're a content person and you have this marked up, you can be read back. That's fantastic.
If you're in eCom it gets a little bit more complex. It’s easy to markup the product description, but it's difficult to browse in voice. That's where a lot of these actions can make a lot of sense. If eCom want to do anything in voice, it's going to be initiating sending a package back, or asking for a refund, or a call to customer service, or leave a review on a product. Users are getting more into that.
So, in general, businesses just need to have a great site. That's the best way to prepare. But if you do want to start testing, these type of speakable identifiers and Schema are a great way to get started. I think one cool test would be a deal of the week page on an eCom site. If you can go and mark that up, and then be able to test on a voice, "What is the Dillards.com deal of the week." And I can go and look at the products, or it can read to me the description and the price.
So that would be a fun way for a business to start getting involved, with a very low-cost overhead, just to see how it pans out, and how people are using it. I also think that Skills and Actions are wicked cool, but tough to develop. Structured Data can really bridge the gap there - all different types of browsers support it, which is not the case for Actions and Skills. For accessibility, Schema is the way to go. If you are going to play with that, the cool thing about voice assisted Schema is that you can do it with the CSS, or the id values, referencing a specific part of the page, which is brilliant. But you can also do it with XPath - you can write in XPath, which is similar to Regex, to just say, "Hey, these are the parts that are speakable". With all these techniques, Google can cherry pick from a whole repertoire of information.
Jason: Wow. I didn't know most of that. I really, really love that answer. What comes out of it for me, is that right now in terms of actually making money, the speakable markup isn't particularly useful. However, on the path to learning about a product, or in interacting with the company, either before or after the purchase, it is potentially very useful. Perhaps not something that companies should be investing immense amounts of money in. We'll see how all that develops.
Next - I have clients who come to me and say, "Oh, we've just built this site, what about the SEO?" And I say to them that you should've thought about the SEO before you started building the site.
When designing your site, you should think about the Schema
Dave, can you give us some pointers, because what you told us before the webinar was incredibly interesting?
Dave: Yes, when you're doing a site for the first time, you're building that foundation, your architecture. It’s a great opportunity to build in your SEO. But also an opportunity to look through the lens of Schema - understanding where the connections are and what the relationships are. Schema forces you to think where is content should be. For instance, an example I had recently was a service page. It should've just been a simple list of services, but it was talking about their main service, then spilling out into other services. When we thought "How do I describe this in Schema?" it became very obvious that was really confusing - for us, for Google and for users too! So we said, "Well, why don't we separate it out, and make it purely an offer catalog of services”, and then from there have dedicated pages for the other services. So it gave us an opportunity to enhance the site, the connections, and its SEO. A lot of people think, "I have to add some Schema”, but we're talking about is the reverse. Start that process in the planning stages. And when you're looking at a site, look at how that connectivity can help to enhance not only Schema but also the site in terms of the layout and the content. Same thing with the sameAs - an opportunity to look at your site and ask yourself, "am I representing everything on the site that I should?” Is there another great organization or profile somewhere that will help conversions, as well as joining the dots for Google concerning the organization or person.
Jason: Yeah. Great stuff. The more we talk about it the keener I am about Schema ... Gennaro talking about communication, you talking about the architecture. It really makes sense to me that this is now a fundamental building block of the websites that we're building today for tomorrow.
Next up is something that Ashley wanted to talk about a little bit, which I'm actually incredibly interested
How does JobPosting markup work, and when is it coming to Europe?
Ashley: The job posting markup is something I'm really excited about because Google is trying a few different things. I know earlier this year we saw Google Employee and a lot of the rich features around Job Posting come into the US. It is my understanding that they were aiming to be available in hundreds of countries at the end of this year, or early next year. JobPosting takes the rich results to the next level - it not only allows users to go and see this aggregated job search data but also filter it. They can save jobs that they're interested in. They can get alerts. There are a lot of cool things that you can do with it directly in the search, which relates nicely to AEO that you talked about for the single result. And there are a few ways that businesses could take advantage of it.
So if you are a business and you're hiring, you should be interested in this, since Google can do a really good job of extracting different pieces of information for the posting - the employer, the position, occupation, where to apply, even employer ratings too. I think a lot of businesses were upset about Google pulling this data and showing it in SERPs. Talking about how Google might steal rankings from them. But specific to jobs, Google is working hard to prioritize the owners of those jobs and get the companies that are hiring up higher than LinkedIn, or Monster.com, or any of your regional job postings. Which I think is a really good show of goodwill by Google, because it's easy for them algorithmically to just bypass that.
Jason: One thing you mentioned is employee reviews. I know that's something that a lot of employers are worried about. First, they said, "Customer reviews, how frightening." But then realize that if they’ve got a good service, there's no reason to get bad customer reviews. Maybe the same for Employee reviews? Employers will be in a situation where they need to treat their employees with respect in order to maintain their credibility to potential employees. Would you agree with that?
Ashley: Absolutely. We need to do the right thing by people. I had one more feature that's unique to the Jobs Posting that I hope expands to other areas - with their indexing API, Google allows you to submit directly to API to tell when a job posting is expired. So they can remove it from those rich snippets directly. It's really fantastic. It's really sexy if you're into Structured Data to be able to ping them directly and say to remove something is awesome.
Jason: Great! Simon Cox just wrote in here. He says, "Schema Markup isn't cool, it's essential.
Ashley: I think that's fair. Well, we're all here because we do boring things. But we love it. We're a special audience.
Jason: So, the big question that's going to be hopefully a little bit of a debate. John Mueller said, “We don't use Schema.org as a quality factor”. Alexis Sanders said, "Featured snippets appear when Google has high confidence in the usefulness of a response Structured Data can support confidence." And Dawn Anderson said in one of the previous episodes, "Then they fill the gaps from web pages and presumably the more structured, the better."
So, officially, Schema is not a quality factor. But here on the right-hand side, two experts are saying we're looking at confidence, and credibility, and the more structured, the better.
Does Schema help rankings, directly or indirectly?
Gennaro: Well, I would like to say “only in your dreams” but in truth, I think there are several ways that the Schema affects rankings. Directly - if you get into the Knowledge Vault, you know that you're going to get right away a knowledge panel. Some of it will be a no-click search, but in other cases, it's going to be qualified traffic. Indirectly - when you implement Schema, you get more space on the search results pages. For instance, with Schema, you can push more information about an event into the SERP, which might improve the click-through rate.
But there's a third one, which is I think very, very interesting. In an article in June about augmentation queries, Bill Slawski highlighted a patent that involves giving quality scores to queries. Aside from giving an answer in a search result, Google also wants to understand what is the best synthetic query (machine generated) - a query that Google creates, that matches the best result that it could give to the user. To identify some of those synthetic queries, based on this patent, Google mines Structured Data on the web (among other things). The reference is this.
When you have Structured Data you're not only improving the search results because you're giving more information to Google, but you're also creating demand. You're creating queries. For example, I created the query, "Who is Gennaro Cuofano”. Who cares, but Google now has it and that might be because there is Structured Data behind. So that's interesting.
So yeah, three ways. Directly, if you get inside the knowledge vault. Indirectly, through the click-through rate. And the third aspect, you may be creating demand through the Structured Data, through Schema.
Jason: Super duper. Wonderful stuff. Wow. We'll move onto Dave, who hasn't said anything for a little while. Directly, indirectly, or in my dreams?
Dave: I agree on all the points that Gennaro made. My answer is “directly and indirectly”. Directly, being the whole issue of rich results, all of that will help in terms of click-through rate. But also indirectly, if Structured Data helps Google understand what that page is about, then Schema, will help the algorithm when it comes to deciding who's going to be position zero. There's a positive benefit there. Indirect, and we can't track it, but I think it's there. And they've made mention before, a couple different times within the last year, about how Structured Data helps Google to understand.
But be careful - aggregate rating, that's probably one of the biggest things that's being spammed at this time. And that’s something I think Google is going to get a handle on in the near future, get everyone into line, and bring it out of the wild wild west.
Jason: So, manual penalties for spammy Schema Markup. I had a client come to me asking why they'd got this penalty, and it was all down to marking up reviews on articles that were not real reviews and that were obviously cheated. So from what I've seen, Google has already started to wag the finger, and this may become 'penguin-esque'. So, I would've thought penalties for spammy Schema Markup are definitely on the horizon. And lastly on to Ashley for the question. Directly, indirectly, or in my dreams?
Ashley: Sure. I think it maybe helps gently, but I don't put a lot of stock into it affecting ranking, because Schema won't compensate for stuff that you're doing in your site that isn't right. Or if you don't have authority. Or if you're not answering specific questions. And conversely, Google will show rich snippets for sites that don't have any Schema on them at all, if they know that they're an authority and Google can parse and understand the information on the page, just from good architecture.
Ashley: Schema is something you should be doing, both in terms of readability and exposure. Good Schema can help your stuff show up in a variety of places, versus just the web. It is something you should be doing well, and doing honestly.
Jason: That's wonderful. Great answers. My personal opinion is maybe not for ranking, but certainly in credibility, and in understanding. Next is our last question, which is rolling on from the second episode where Dawn and Eric came up with some great theories about position zero.
We are now building the #SEOisAEO position zero profile
Jason: So far we have four points. 1) Knowledge Graph first, then the best of the top 10 results 2) Google is building an answer algorithm on top of its original search algorithm 3) Google is looking to identify the ultimate source of truth for each question 4) User signals are crucially important. Gennaro, in terms of position zero, what does Schema bring to the table that we can add to this list?
Gennaro: Well, from a few experiments we've done, it's clear that Schema can really be a great help, especially when you're trying to answer a specific long-tail keyword. For it’s Knowledge Graph, Google is looking for information from several perspectives. So what we do with Schema and with the Schema properties is to refer to information and data sources that Google can cross-reference before adding information to its Knowledge Vault. In our strategies, Schema is the foundation.
Jason: Yes, indeed. Words that stand out for me in this webinar are: cross-referencing, communicating, digesting, educating, and explaining. So, Dave, for position zero, anything that Schema can bring to the table?
Dave: I agree on the long-tail because I've seen it in experiments I'm doing with the clients, that Schema and Structured Data markup for long-tail are beneficial. But as Ashley was saying, good content, good architecture within your site is currently the foundation. Structured Data adds a reinforcement, and that is just a small component... but something I think will grow in the future.
Jason: Wonderful stuff. Absolutely perfect. Ashley?
Ashley: I think Dave and Gennaro captured it. So I won't wax on about that. I was looking at the comments, and trying to figure out the best way to make sure that we're responding to folks who are taking the time to add chat to the video because there are some really great comments.
Jason: I've seen you've answered a few questions directly in the chat. That's great. That's really kind of you. I would do it, but a) I don't know the answers, and b) I'm desperately trying to juggle the three computers here. I've been overwhelmed with information, and I'm thinking, "Oh, I'm going to have to watch this back now to digest all that information." Thank you, Ashley. Thank you Gennaro, and thank you, Dave. Have a lovely afternoon. Next week we will look at sexy semantic HTML5, interesting information architecture, and ace accessibility. See you then.
This is the 4th episode of Epic Series by Jason.