5 Common Schema Problems and What You Can Do about Them

This post is going to go over five common problems you might come across when you start to dig into and actually apply schema.  

Structured data looks is starting to look like the future of the web. It’s been around for awhile now and is slowly becoming more common. Search engines like Google and Bing are driving the adoption and are providing the primary benefits for us, as marketers, to implement.

There’s been a lot of great content already written on structured data, Google’s own documentation has got substantially better over the past few months as well.

If you’ve never come across structured data before, then you should go and watch this video, as it’s an excellent place to start. I’ve also provided a short explanation structured data below, in case you just need a brief recap.

Brief Note: Any terms in italics are schema objects or properties. Except this sentence…

What is schema?  

There are two parts to providing structured data on a webpage:

  1. Describing data on the webpage in a “key : value” format

  2. Using a language to describe this data.

The three most common ways to describe the structured data in a key value format are: JSON-LD, Microdata and RDF.

Microdata and RDF both live in the HTML where the data appears. JSON-LD, appears in a script tag at the head of the document separate from the data it’s describing.

Schema is the most popular standardized language for describing this data (data vocabulary is another). It’s obviously important to have a standardized language, so everyone knows what they’re talking about.

Schema can be hard to get to grips with.

1. If you provide more than one date in schema, which one will Google pick?

There are several possible pieces of date markup, that you can apply to Articles. The most common two being:

  1. datePublished

  2. dateModified

It’s completely reasonable to have both of these on page, but it isn’t obvious which one Google will choose.

Answer

Google will use the datePublished by default, which if you keep your content up to date and relevant isn’t ideal. You could have an article published in 2012, updated in 2015, but which which only shows 2012 in the SERPs.

Example markup on page:

<div itemprop=”datePublished” content=”2012-03-09T05:40:51+01:00″>Published: 9 Mar 15</div>

<div itemprop=”dateModified” content=”2015-02-22T14:55:06+00:00″>Last Updated: 22 Feb 15</div>

At the moment, Google will only show date markup if the date actually exists in HTML on the page, so the solution is to remove the date published from your article (you can leave the schema as a metatag) and leave only the modified date.

<meta itemprop=”datePublished” content=”2012-03-09T05:40:51+01:00″>

<div itemprop=”dateModified” content=”2015-02-22T14:55:06+00:00″>Last Updated: 22 Feb 15</time>

2. Should you use more than one kind of machine readable language?

I.e. Can you put JSON-LD, Microdata and RDF all on the same page?

Answer

In short, no. Stick to one in case it confuses the crawler. The answer is tucked away in Google’s documentation here.

3. How do you markup multiple objects on the same page in JSON-LD?

Marking up multiple objects with microdata on a single page is pretty self explanatory, after all microdata sits around the objects it’s marking up.

JSON-LD however sits separately from the markup and people can often get confused about how to markup multiple items. For example, if you have a search results page with 10 products on it, what would the JSON-LD array look like?

Answer

It functions actually exactly as you’d expect, one listed after the other. I found just seeing a single example clarified it for me. This github project is an example of marking up multiple locations on a page with a map:

<script type=”application/ld+json”>

{

 “@context”: “http://schema.org&#8221;,

 “@graph”: [

{

  “name”: “Google Inc.”,

  “@type”: “LocalBusiness”,

  “address”: {

    “@type”: “PostalAddress”,

    “addressCountry”: “United States”,

    “streetAddress”: “1600 Amphitheatre Parkway”,

    “addressLocality”: “Mountain View”,

    “addressRegion”: “CA”,

    “postOfficeBoxNumber”: null,

    “postalCode”: “94043”,

    “telephone”: “+1 650-253-0000”,

    “faxNumber”: “+1 650-253-0001”

  }

},

{

  “name”: “Google Ann Arbor”,

  “@type”: “LocalBusiness”,

  “address”: {

    “@type”: “PostalAddress”,

    “addressCountry”: “United States”,

    “streetAddress”: “201 S. Division St. Suite 500”,

    “addressLocality”: “Ann Arbor”,

    “addressRegion”: “MI”,

    “postOfficeBoxNumber”: null,

    “postalCode”: “48104”,

    “telephone”: “+1 734-332-6500”,

    “faxNumber”: “+1 734-332-6501”

  }

}

 ]

}

</script>

4. What should you do about multiple instances of the same object?

This point is less of a common question, but rather something that I think is really underused at the moment and will end up becoming important. It’s question people should be asking and they’re not.

It’s likely that you’ll end up with multiple references to an object across a website.

Suppose you’re an online shop, you might end up with the same author bio for a shop owner across multiple products. Is there a good way to tell a search engine each of these bios is talking about the same person?

Answer

The Thing object in schema has the two following properties which are ideal for this:

  1. url – URL of the item.

  2. sameAs – URL of a reference Web page that unambiguously indicates the item’s identity. E.g. the URL of the item’s Wikipedia page, Freebase page, or official website.

Properties are inherited in Schema and so any Thing object or the many categories under it (full hierarchy here), like Organisation or Person, can use these properties.

In our above example to indicate all instances of the author bio are talking about the same person, you’d markup the bio snippet with a link to their dedicated author page and perhaps even an official website if they had one. Particularly on websites which might refer to a single person or organisation in multiple places, this is a good way to make explicit the relationship between pages.

Example:

<div itemscope itemtype=”http://ift.tt/pQ5oHU”&gt;

<div class=”author-name” itemprop=”name”>

<a itemprop=”url” href=”http://ift.tt/1InQkIC”>Mr Author</a>

<meta itemprop=”sameAs” content=”www.mrauthor.com”>

</div>

<div class=”author-bio” itemprop=”description”>

Mr Author is truly a wordclass author with articles published in Author Magazine, Author Weekly, Author’s Digest and many others.

 </div>

</div>

5. Which rich snippets are very hard to get with schema?

Not all snippets are created equal and while you might see these snippets mentioned in older articles about schema, some of them either have become, or always have been, very hard to get.

Answer

  • Indepth articles

  • Video snippets

You’ll probably still see both of these, but getting either of them for your website is very hard. Video snippets are now almost all associated with Youtube while in-depth articles are typically associated with a small set of particularly high authority publications. That’s not to say you shouldn’t still be using this sort of markup, but just be aware that if you’re putting in the markup just to get these results, you’ll likely be disappointed.

A DistilledLive episode appearing as a video snippet in the SERPs.

Wrapping up…

Schema is a fiddly thing. The benefits aren’t always immediately obvious, the documentation can gloss over basic points, and just putting the schema on your page isn’t a guarantee to getting rich snippets.

Hopefully these questions help clear up some of the common problems. If you want to learn more, here are three very useful schema resources I find myself continually referring back to:

via Distilled http://ift.tt/1Dy5zqS

Tagged with: ,
Posted in News

Leave a comment