Tag: local search

As Google continues to affirm its support for more detailed types of schema markup when crawling sites, it seems that there is an increased level of general interest in the concept and implementation of schema. I know that across our office, there are constant enraptured whispers about the ethereal mystery and beauty of this particular variety of microdata. At least, that’s what I imagine. In any case, I am quite certain that people across departments in the Search Influence office, and presumably others, are talking about schema more than they used to.

If you are already thoroughly comfortable understanding and implementing schema, this is not a blog post for you. Take a long pull on your cigar, another sip of fine brandy, ease the seat back and return to your Baudelaire. As for everyone else, I’m writing this because Google’s documentation on the subject – though extremely helpful and somewhat surprisingly transparent – is probably still a bit dense for those not familiar with microdata as a concept or without some experience coding a web page. I’m hoping to help bridge this gap for anyone seeking a schema primer without the time or inclination to sign up for a night school web design course.

So What Is Schema Anyway?

Schema is a type of microdata that is standardized and structured in a way that can help search engines parse pertinent information from web content. The official description can be found here, but let’s keep this simple.

Many of us went to school at a time where we had to carry around these huge, heavy things called “books” that contained all sorts of crucial knowledge within words printed on bound “paper.” In the course of trying to learn the material contained in the books, many students found it helpful to highlight really pertinent passages in obnoxious neon colors. Highlighting made it a lot easier to go back and see what passages to focus on when studying later for an exam or putting together an essay.

Well, schema is a lot like highlighting for a search engine. We mark up certain key pieces of information that may provide a clearer concept of what is most important for a search engine to pull from a larger body of content. It’s not saying that the entirety of that content isn’t important in any way; rather, it’s streamlining the presentation of content so that Google or Bing can get a clear picture of what the page is about even before parsing the full scope of what is contained on a page. Accordingly, there is a vast array of different schema types available for different content topics or functions. Whether the topic of your page involves a bus trip or a volcanic eruption, there is probably a schema type that can help further break down your content.

OK Cool, But Why Bother If Google Is Going To Read Everything Anyway?

Yes, Google will find a way to establish a general concept of what is on your page for presentation in search results with or without the use of schema. But, well, the Internet is kind of huge, and search engines tend to get kind of busy dealing with that a lot of the time. I think anyone interested in schema understands that Google and Bing use extremely intricate and elaborate algorithms to assess content for use within search results. Even with all of Google’s bears, birds, and mythical beasts on the job, however, it is still possible for information to be misconstrued within Google’s results. It is less a matter of keeping a search engine from getting things wrong than it is of helping a search engine get things more accurate.

For a hypothetical example, let’s look at this – as I do most things – in David Bowie terms. As you may or may not be aware, David Bowie actually briefly changed into an apocalyptic half-dog monster in 1974. This is a fact. Had you been unaware of this rather unusual moment in human evolution and overheard it discussed in an elevator (which is certainly where most of us first hear about otherworldly metaphysical transformations), you might be tempted to Google it. Well, if you were to Google “david bowie changes into dog monster,” you’ll eventually find some things about dog monsterdom, to be sure, but you also get an awful lot of results related to the classic 1971 song “Changes,” the compilation album “Changesbowie,” and the 1980 album “Scary Monsters.”

Well, in this example, Google isn’t doing anything wrong really. It gave you perfectly logical results related to the primary subject of your search and based on the many of the keywords entered, but it still wouldn’t be quite what you were looking for. This is where schema would come into play. If an obviously extant news article on the completely 100% factual occurrence of David Bowie turning into an apocalyptic dog monster had been marked up with, say, Article schema breaking down the subject matter and providing a summary of the content, Google would likely have better understood to serve you the content that directly matched your search query. Likewise, were album and song writeups for “Changes,” “Changesbowie” and “Scary Monsters” marked up with MusicRecording schema or MusicAlbum schema, Google would be better able to differentiate these types of results from articles more pertinent to this search.

I realize that it’s cheating to hold Google accountable for not being able to perfectly assess my intent in searching for viable news on an event that didn’t actually happen, but this example still hopefully illustrates how schema can be employed to help Google get from “logical and related” to “absolutely on point” in its serving up of search results.

There is, of course, a less tangible, but equally (if not more) enticing motivation for using schema. Imagine you are trying to settle on your order at a restaurant, and you ask your server if there are any vegetarian options. You’re probably going to leave a bigger tip for a server who specifies and describes the vegetarian options available, versus a server who simply says, “yeah, read the menu” and walks away. In the same way, there is a mentality when using schema that making it easier for Google to see what it needs to take away from a page might result in a better ranking in search results. I will not say in any definitive terms that adding schema markup boosts a site’s search ranking, but – if used correctly and responsibly – it sure isn’t likely to hurt, is it?

So that’s all it does? What’s all the fuss?

Well, actually there are a number of other things we can do using schema beyond making Google’s life easier and hoping for some vague benefit in rankings. With many types of schema, we can make really cool things happen in search result snippets for specific types of pages with specific types of content.

Review Schema

One thing clients tend to like is having a really pretty star rating value appear in listings of their site in search snippets, which is something that can be accomplished using Review schema.

By marking up a number of details within the content of this testimonials page, we are able to communicate enough information to Google about the ratings contained on this page that it presents the rating and review values right there in the search snippet. This is obviously pretty enticing for a user unsure of which result to click on in a long list of unfamiliar names and businesses.

It is important to remember, though, that the reviews contained in review schema must contain actual ratings associated with said reviews in order to facilitate the addition of the pretty stars to the results. It is also good practice to include some portion of each reviewer’s name in order to establish legitimacy for the content being marked up. Also, in a case like the above example, where there are multiple reviews with multiple rating values, it is necessary for some cumulative review value totals to actually appear on the page. This is known as a review set’s aggregate rating, and it is required in order for the list of ratings to be compiled into a single rating value to be displayed as a star value.

Video Schema

Anyone who has used Google (so anyone reading this) has seen the potential results of video schema in action every time the inevitable Youtube video links comes up somewhere in your search results list. When YouTube links appear in search results, they are generally accompanied by a thumbnail of the video, which is also a direct link to play the video and the duration of the video being linked. See below:

Effective use of video schema can lead to a similar thumbnail, play icon, and duration display within your site’s search snippets. This can be accomplished using self-hosted videos displayed with custom players or through embedded videos hosted on YouTube, Vimeo, or any other video engine. It is important to remain realistic about this though. Remember that Google owns YouTube, so it’s kind of unlikely that the page containing your embedded YouTube video is going to rank higher or be featured more prominently than the source video’s listing actually on YouTube.

MusicRecording Schema

Much like video schema, MusicRecording schema can display player icons with track, title, and duration details right there in the search snippet. This type of schema obviously only applies to a fairly niche segment of sites and/or clients, but it is another good example of how search snippets can be enhanced through schema. The example below displays a Google Play search result, which, as with fellow Google property YouTube, almost always displays the player info in the search snippet. Similar results can be accomplished in organic results with effective use of schema, however:

OK, I Get It. So How Do You Do It?

I’m not going to get into incredibly great detail here, because I promised a relatively simple primer and not a code-heavy breakdown that would scare away newcomers. Perhaps a more thorough explanation of the actual implementation of schema within HTML can be addressed in a future post. For now, I just want to explain schema implementation in terms of properly reading and understanding schema properties in the context of the schema.org item breakdowns.

The most important thing to understand is that schema markup, like the HTML markup it is integrated into, is hierarchical in nature. This means that there are often numerous schema subproperties, within another schema subproperty, within a schema property, within the top level declared scope of a specific schema type, and so on. And once you go a next level deep in the hierarchy (or change the scope of your markup), the set of available properties is different and only applies to this new scope of the schema.

As an example, let’s look at a section from the page for the always useful Mountain schema*:

So we’re going to start with Mountain schema as the scope of what we’re marking up in our content. As you can see, there is a list of available Properties for use within this schema on the left. With a nod back to the much earlier comparison in this post, these are all the different types of information we can “highlight” for a search engine. The Description on the right is a pretty self-explanatory explanation of what the property should reference. So far, so good.

Now, where things get a little tricky is in the Expected Type column in the center. Take a look at the bottom most property “faxNumber,” which is obviously very important. We all know how difficult it can be to send a fax to a mountain, right? Well, you can see that the faxNumber property has an expected type “Text.” This means that whatever text content you list as the value for the faxNumber property is what will be directly communicated to a crawler or search engine as the fax number for your mountain. Simple enough.

Well, you’ll notice that all the properties above it have more vague and mysterious extended types associated with them. In fact, these types are entirely new hierarchical scopes for the schema being added to the page. So for the “address” property, for instance, instead of just dumping your mountain’s entire street address in as the value, as you can with “faxNumber,” you’re going to have to change the scope of this schema and fill in any address information according to the next level of properties contained in the PostalAddress schema type. Once you change scopes in schema, the deeper level schema type does not know what is going on in the outer levels. So in this example, your PostalAddress does not know or see your mountain’s fax number.

OK, This Is Getting Ugly. Just Stop.

Good call. This is probably a good place to cut off an intro level crash course in schema, since anything much more detailed would involve some actual HTML knowledge or experience. Hopefully, this will have helped a non-web developer understand a little bit more about what schema is and how it can be employed to better communicate with search engines. There is such a vast expanse of available schema types for use marking up web content, a fundamental grasp of its structure and function can be extraordinarily useful in pointing your content more directly to the right readers.

* This is where the Game Of Thrones meme would have gone if I weren’t such a snob.