The Knowledge Panel Course: The Powerful Geeky Way to Join the Dots
Script from the lesson The Knowledge Panel Course
Jason Barnard speaking: Hi there. This lesson is all about joining the dots using Schema.org Markup. This is the geeky way to join the dots. It is very powerful. So if you can do it this way, you will definitely have an advantage over using just a great description and links in the page. It also allows you to add additional information and corroboration that you can’t practically do otherwise. So even if you aren’t a geek, stick with it and remember that we have an easy-to-use free tool on Kalicube Pro that will do the geeky part for you.
Jason Barnard speaking: So, once you identified your Entity Home, added a clear description, and you’ve made sure that multiple first, second, and third party sources corroborate, you need to indicate to the child the places it should be looking. The non geeky method is using hyperlinks on the Entity Home. Schema Markup is the geeky and more powerful way of joining the dots for Google and bringing all of this together.
Jason Barnard speaking: You can think about Schema.org as Google’s native language. You use it to re-explain to Google everything you’ve applied in the previous lessons to Google in a language it can digest natively. This explicit repetition is supportive of what you’ve explained with the Entity Home, the entity description, and the corroboration. And it’s a support that Google greatly appreciates, and it’s a huge help in building its confidence in its understanding.
Jason Barnard speaking: Firstly, a quick word about what you are building. You need to choose the correct Schema.org type: person, corporation, podcast series, book, et cetera. You are then building your Schema Markup to describe this entity to Google in a way I call its native language. You can use the entity type as the root of your Schema like this.
Jason Barnard speaking: Kalicube Pro integrates the entity’s Schema into the Schema type About page. We find this to be highly effective, and it allows us more flexibility and scope in what we can communicate to Google. Your Schema Markup should be showing information that you already have in the page with some exceptions. Those exceptions are links in the form of sameAs and subjectOf that don’t help the user experience. An example here would be the Wikipedia page, the Crunchbase page, or a ZoomInfo profile.
Jason Barnard speaking: Examples of other additional information that you would include in the Schema Markup, but probably won’t include in the Entity Home would be the date and place of birth of the person, maybe their parents or their siblings, or for a company, perhaps the founding date or an exhaustive list of the C-level employees.
Jason Barnard speaking: This additional information should be relevant and help Google in one of three aims: to disambiguate between the entities with the same name, date and place of birth is great for identifying a specific Jason Barnard, for example, to provide information that can be used as attributes for the Knowledge Panel, awards and qualifications, for example, or to indicate relationships that Google can use to better link you to other entities in its Knowledge Graph, subsidiaries, siblings, parents, for example.
Jason Barnard speaking: And a quick word about the difference between the sameAs and the URL properties in Schema. Historically, there was an important distinction between them, however, as with many things, because people use them in very different manners, that distinction has become very blurred. At Kalicube, we follow one simple rule. The URL property is for the Entity Home and the sameAs is for all corroborative sources.
Jason Barnard speaking: Additionally, only add corroborative sources to sameAs or subjectOf if that page is 80% or more about the entity. Google has trouble distinguishing reliably between multiple entities on the same page, so you really need to only use pages that are truly only about that specific entity, or you are throwing a curveball to Google.
Now, sameAs is for profile pages. Examples for sameAs would be the Twitter profile for the entity, the Facebook profile, LinkedIn profile, Crunchbase profile, or Muck Rack if the entity is a writer.
Jason Barnard speaking: subjectOf is for second and third party articles and videos that are dedicated to the entity. Examples for subjectOf for a company would be an article about the company in Inc.com, a video report about the company on YouTube or on a TV channel website. Examples for a person would be an interview on Entrepreneur.com, a biographical piece by a blogger or a journalist, or an interview with the person on a YouTube video.
Jason Barnard speaking: Importantly, do not add sameAs or subjectOf to unclear or contradictory information about the entity. This will confuse Google and reduce its confidence and make the Knowledge Panel harder to get, rather than easier.
Jason Barnard speaking: More is better is not the approach. More consistent corroboration on relevant sources is the correct approach. Just a few incredibly authoritative, relevant, and accurate sameAs will be far more effective than dozens of unclear descriptions on irrelevant or non-authoritative sources. If you have a doubt about the relevancy, authoritativeness, trustworthiness, or accuracy of a page, don’t include it.
Jason Barnard speaking: Always bear in mind that first party sources have the least influence, other than the Entity Home. Second party sources have more influence, but third party sources are really the ones you need. Also, first party sites will have a very fast rate of diminishing returns in terms of building confidence, second party websites will have a slower rate of diminishing returns, and third party sites will tend to have a low rate of diminishing returns, maybe none at all. So, you want to build those third party references over time.
Jason Barnard speaking: One very powerful trick that I will go into in more detail in a future lesson is to find relevant and authoritative media sites willing to publish an interview with you. Many journalists will simply send you a list of questions, and you write the answers. If you write them well, and the answers are helpful, clear, relatively neutral, i.e. not too self-congratulatory and not sales-y, then the journalist will generally change very little, then publish it under their own name. And that is delightful because even though you are the person who actually wrote the texts, the third party is putting their name and their reputation behind those words, and it becomes third party corroboration.
Jason Barnard speaking: One small but important point is that generally, it’s better not to overload your Schema Markup with additional information until Google has understood the basics and is at least a little bit confident in those. The more information you throw at it too soon, the more likely you are to confuse it. The web evolves constantly, so you will always be able to get more ambitious and add more information in the future.
Jason Barnard speaking: Also remember that just because a property exists in Schema.org, it doesn’t mean Google’s knowledge algorithms can necessarily use that property in any meaningful way today. Beyond the obvious, we don’t know for sure which properties Google’s knowledge algorithms actually understand and can use in the context of Knowledge Panels.
Jason Barnard speaking: The basics that you need to start with for a company include company name, alternate names, legal name, parent organisation, sub organisations, founding date, founding place, founders, contact points, tax ID, logo. You would then build up with other information such as awards, C-level employees, images, and so on and so forth.
Jason Barnard speaking: The basics that you need to start with for a person include first name, family name, middle name, birth date, birth place, gender, nationality, alumni of, i.e. the university, job title, employer, and a photo. You would then build up with other information such as parents, siblings, member of, awards, additional photos, and so on and so forth.
Jason Barnard speaking: For an event series, film, podcast, or other artistic work, you’d want to include properties such as name, alternate names, production date, production company, director, screenwriters, actors, producers, and so on.
Jason Barnard speaking: Alternate name is incredibly important in all these cases. This is because we are all inconsistent and use different names for the same thing. For example, I use Jason Barnard and Jason M Barnard. Kalicube uses Kalicube and Kalicube SAS. Alternate name allows Google to see that these different strings of characters refer to the same entity. So, take a good look around the web and make a list, and you will almost always be using the alternateName field in your Schema Markup.
Jason Barnard speaking: For the specific properties that make most sense for your entity, spend some time looking at Schema.org and use your good judgment. As a general rule, you need to include the foundational information that will help Google to disambiguate, information that it can use as attributes in the Knowledge Panel, and explicit relationships with entities it already recognises.
Jason Barnard speaking: To find the properties it is likely to use as attributes in the Knowledge Panel for your type of entity, take a look at what it shows for Entity Equivalents. That is the same entity type, the same geo region, and the same industry. To decide which relationships to include, start with the most famous ones and focus on those that are the strongest, the longest, and the closest.
Jason Barnard speaking: In the Kalicube Pro SaaS platform, we generate the Schema Markup and limit ourselves to the properties that we know are the most important for each entity type. If you aren’t using the Kalicube platform, don’t worry. We maintain a publicly available, up-to-date, free example of the Schema Markup that Kalicube Pro platform generates for each entity type. Just look in additional materials underneath the lesson.
Jason Barnard speaking: Once you have your Schema Markup, check in the Schema checker at https://validator.schema.org to make sure that there are no errors, then add the Schema to the Entity Home. Generally, it is best to add the Schema to the head section of the HTML. However, adding in the page works fine. For WordPress, for example, you can create an HTML Gutenberg block in the middle of the page and copy and paste it there.
Jason Barnard speaking: If you already have Schema Markup in your page for the entity, if you are using Yoast or Rank Math or WordLift, they might have Schema about the publisher or the author. You can merge your Schema into theirs by adding the @id property for the person or organisation in their Schema to your Schema Markup. Find the @id property for the entity in the existing Schema and add the value to your Schema as the @id, and the two will merge.
Jason Barnard speaking: Here’s an example. I used Yoast on my website and added the @id from Yoast to my handwritten Schema. And the two merge neatly, making this very clear and simple for Google.
Jason Barnard speaking: Use the @id that you use on the Entity Home wherever you can around the web. The @id is supposed to be a unique identifier, but different sites create their own ID and that is confusing. That said, you cannot always do this. But the more it sees the @id from your Entity Home around the web, the more it will see that as the dominant ID and recognise your Entity Home as the authoritative source about your entity.
Jason Barnard speaking: Ideally, Google would have just one unique reference to each named entity, but that isn’t practically possible. The most stable references for Google are, in this order: the Entity Home URL, the Google kgmid, and the ID for your entity on your Entity Home. For other engines, obviously only the first and third apply.
Jason Barnard speaking: To dig deeper into Schema Markup, the reference site is https://schema.org. I strongly recommend that you take a good look around the Schema.org website and read the articles you’ll find in the additional materials of this lesson. I also recommend using their Schema validator rather than Google’s, since Google’s tool is designed to tell you whether your Schema Markup is valid for Rich Elements and features on their SERP. And that means they will declare a warning or an error because your Schema will not trigger a feature in their SERP, rather than because it is not written correctly.
Jason Barnard speaking: Since we are trying to communicate facts to Google’s knowledge algorithms and educate them over a long period of time about who we are, what we do, and which audience we serve, and thus get in the Knowledge Graph and trigger a Knowledge Panel, the bells and whistles of prices and stars in the SERPs is not part of our equation.
Jason Barnard speaking: One last point, add this code only to the Entity Home. Adding it sitewide would suggest to Google that every page on the website talks 80% or more about this one entity, which is obviously not the case. Stick to the Entity Home. This ensures you focus Google’s attention, and Google’s attention, well-focused, is going to win you the game.
Jason Barnard speaking: Thank you very much, and I’ll see you soon.
