Welcome to Part 2 of The Beginner's Guide to Structured Data: How to Implement Structured Data for SEO. In Part 1, we focused on gaining a high-level understanding of what structured data is and how it can be used to support SEO efforts.
(If you missed Part 1, you can go check it out here).
In Part 2, we'll be looking at the steps to identify opportunities and implement structured data for SEO on your website. Since this is an introductory guide, I'll be focusing on the most basic types of markup you can add and the most common use cases, and providing resources with additional detail for the more technical aspects of implementation.
Is structured data right for you?Generally speaking, implementing structured data for SEO is worthwhile for most people. However, it does require a certain level of effort and resources, and you may be asking yourself whether it's worth prioritizing.
Here are some signs that it's a good time to prioritize structured data for SEO:
*What is considered significant volume may vary according to how niche your market is.
If you said yes to any of these statements, then implementing structured data is particularly relevant to you! And if these criteria don't currently apply to you, of course you can still go ahead and implement; you might have great results. The above are just a few of the most common indicators that it's a worthwhile investment.
Implementing structured data on your siteIn this guide, we will be looking solely at opportunities to implement Schema.org markup, as this is the most extensive vocabulary for our purposes. Also, because it was developed by the search engine companies themselves, it aligns with what they support now and should continue to be the most supported framework going forward.
How is Schema.org data structured?The way that the Schema.org vocabulary is structured is with different "types" (Recipe, Product, Article, Person, Organization, etc.) that represent entities, kinds of data, and/or content types.
Each Type has its own set of "properties" that you can use to identify the attributes of that item. For example, a "Recipe" Type includes properties like "image," "cookTime," "nutritionInformation," etc. When you mark up a recipe on your site with these properties, Google is able to present those details visually in the SERP, like this:
Image source
In order to mark up your content with Schema.org vocabulary, you'll need to define the specific properties for the Type you're indicating.
For example:
If you're marking up a recipe page, you need to include the title and at least two other attributes. These could be properties like:
Each Type has different "required" properties in order to work correctly, as well as additional properties you can include if relevant. (You can view a full list of the Recipe properties at Schema.org/Recipe, or check out Google's overview of Recipe markup.)
Once you know what Types, properties and data need to be included in your markup, you can generate the code.
The code: Microdata vs JSON-LDThere are two common approaches to adding Schema.org markup to your pages: Microdata (in-line annotations added directly to the relevant HTML) and JSON-LD (which uses a Javascript script tag to insert the markup into the head of the page).
JSON-LD is Google's recommended approach, and in general is a cleaner, simpler implementation... but it is worth noting that Bing does not yet officially support JSON-LD. Also, if you have a Wordpress site, you may be able to use a plugin (although be aware that not all of Wordpress' plugins work they way they're supposed to, so it's especially important to choose one with good reviews, and test thoroughly after implementation).
Whatever option you choose to use, always test your implementation to make sure Google is seeing it show up correctly.
What does this code look like?Let's look at an example of marking up a very simple news article (Schema.org/NewsArticle).
Here's the article content (excluding body copy), with my notes about what each element is:
[posted by publisher 'Google'] [headline]Article Headline [author byline]By John Doe [date published] Feb 5, 2015 [description] A most wonderful article [image] [company logo]And here's the basic HTML version of that article:
<div> <h2>Article headline</h2> <h3>By John Doe</h3> <div> <img src="https://google.com/thumbnai1.jpg"/> </div> <div> <img src="https://google.com/logo.jpg"/> </div>If you use Microdata, you'll nest your content inside the relevant meta tags for each piece of data. For this article example, your Microdata code might look like this (within the <body> of the page):
<div itemscope itemtype="http://schema.org/NewsArticle"> <meta itemscope itemprop="mainEntityOfPage" itemType="https://schema.org/WebPage" itemid="https://google.com/article"/> <h2 itemprop="headline">Article headline</h2> <h3 itemprop="author" itemscope itemtype="https://schema.org/Person"> By <span itemprop="name">John Doe</span> </h3> <span itemprop="description">A most wonderful article</span> <div itemprop="image" itemscope itemtype="https://schema.org/ImageObject"> <img src="https://google.com/thumbnail1.jpg"/> <meta itemprop="url" content="https://google.com/thumbnail1.jpg"> <meta itemprop="width" content="800"> <meta itemprop="height" content="800"> </div> <div itemprop="publisher" itemscope itemtype="https://schema.org/Organization"> <div itemprop="logo" itemscope itemtype="https://schema.org/ImageObject"> <img src="https://google.com/logo.jpg"/> <meta itemprop="url" content="https://google.com/logo.jpg"> <meta itemprop="width" content="600"> <meta itemprop="height" content="60"> </div> <meta itemprop="name" content="Google"> </div> <meta itemprop="datePublished" content="2015-02-05T08:00:00+08:00"/> <meta itemprop="dateModified" content="2015-02-05T09:20:00+08:00"/> </div>The JSON-LD version would usually be added to the <head> of the page, rather than integrated with the <body> content (although adding it in the <body> is still valid).
JSON-LD code for this same article would look like this:
<script type="application/ld+json"> { "@context": "http://schema.org", "@type": "NewsArticle", "mainEntityOfPage": { "@type": "WebPage", "@id": "https://google.com/article" }, "headline": "Article headline", "image": { "@type": "ImageObject", "url": "https://google.com/thumbnail1.jpg", "height": 800, "width": 800 }, "datePublished": "2015-02-05T08:00:00+08:00", "dateModified": "2015-02-05T09:20:00+08:00", "author": { "@type": "Person", "name": "John Doe" }, "publisher": { "@type": "Organization", "name": "Google", "logo": { "@type": "ImageObject", "url": "https://google.com/logo.jpg", "width": 600, "height": 60 } }, "description": "A most wonderful article" } </script>This is the general style for Microdata and JSON-LD code (for Schema.org/Article). The Schema.org website has a full list of every supported Type and its Properties, and Google has created "feature guides" with example code for the most common structured data use cases, which you can use as a reference for your own code.
How to identify structured data opportunities (and issues)If structured data has previously been added to your site (or if you're not sure whether it has), the first place to check is the Structured Data Report in Google Search Console.
This report will tell you not only how many pages have been identified as containing structured data (and how many of these have errors), but may also be able to identify where and/or why the error is occurring. You can also use the Structured Data Testing Tool for debugging any flagged errors: as you edit the code in the tool interface, it will flag any errors or warnings.
If you don't have structured data implemented yet, or want to overhaul your setup from scratch, the best way to identify opportunities is with a quick content audit of your site, based on the kind of business you have.
A note on keeping it simpleThere are lots of options when it comes to Schema.org markup, and it can be tempting to go crazy marking up everything you possibly can. But best practice is to keep focused and generally use a single top-level Type on a given page. In other words, you might include review data on your product page, but the primary Type you'd be using is Schema.org/Product. The goal is to tell search engines what this page is about.
Structured data must be representative of the main content of the page, and marked up content should not be hidden from the user. Google will penalize sites which they believe are using structured data markup in scammy ways.
There are some other general guidelines from Google, including:
So how do you know which Schema.org Types are relevant for your site? That depends on the type of business and website you run.
Schema.org for websites in generalThere are certain types of Schema.org markup which almost any business can benefit from, and there are also more specific use cases for certain types of business.
General opportunities to be aware of are:
Image source
Image source
You'll often see recommendations about "marking up your reviews" to get star ratings in the SERP results. "Reviews" have their own type, Schema.org/Review, with properties that you'll need to include; but they can also be embedded into other types using that type's "review" property.
You can see an example of this above, in the Recipes image, where some of the recipes in the SERP display a star rating. This is because they have included the aggregate user rating for that recipe in the "review" property within the Schema.org/Recipe type.
You'll see a similar implementation for other properties which have their own type, such as Schema.org/Duration, Schema.org/Date, and Schema.org/Person. It can feel really complicated, but it's actually just about organizing your information in terms of category > subcategory > discrete object.
If this feels a little confusing, it might help to think about it in terms of how we define a physical thing, like an ingredient in a recipe. Chicken broth is a dish that you can make, and each food item that goes into making the chicken broth would be classified as an ingredient. But you could also have a recipe that calls for chicken broth as an ingredient. So depending on whether you're writing out a recipe for chicken broth, or a recipe that includes chicken broth, you'll classify it differently.
In the same way, attributes like "Review," "Date," and "Duration" can be their own thing (Type), or a property of another Type. This is just something to be aware of when you start implementing this kind of markup. So when it comes to "markup for reviews," unless the page itself is primarily a review of something, you'll usually want to implement Review markup as a property of the primary Type for the page.
In addition to this generally applicable markup, there are certain Schema.org Types which are particularly helpful for specific kinds of businesses:
If you have an e-commerce site, you'll want to check out:
For sites that publish a lot of recipe content, Recipe markup is a fantastic way to add additional context to your recipe pages and get a lot of visual impact in the SERPs.
If you're implementing Recipe Rich Cards, you'll want to be aware of some extra guidelines:
If you have an publisher site, you'll want to check out the following:
Image source
Image source
Things to watch out for... Schema.org for events/ticketing sitesIf your business hosts or lists events, and/or sells tickets, you can use:
If your site offers job listings, you can use Schema.org/JobPosting markup to appear in Google's new Jobs listing feature:
Note that this is a Google aggregator feature, rather than a rich snippet enhancement of your own result (like Google Flights).
Things to watch out for...If you have a local business or a store with a brick-and-mortar location (or locations), you can use structured data markup on your homepage and contact page to help flag your location for Maps data as well as note your "local" status:
You should also get set up with GoogleMyBusiness.
☆ Additional resources for local business markupHere's an article from Whitespark specifically about using Schema.org markup and JSON-LD for local businesses, and another from Phil Rozek about choosing the right Schema.org Type. For further advice on local optimization, check out the local SEO learning center and this recent post about common pitfalls.
Schema.org for specific industriesThere are certain industries and/or types of organization which get specific Schema.org types, because they have a very individual set of data that they need to specify. You can implement these Types on the homepage of your website, along with your Brand Information.
These include LocalBusiness Types:
And a few larger organizations, such as:
Things to watch out for…If you create a product or type of content which could be considered a "creative work" (e.g. content produced for reading, viewing, listening, or other consumption), you can use CreativeWork markup.
More specific types within CreativeWork include:
Schema.org new features (limited availability)Google is always developing new SERP features to test, and you can participate in the testing for some of these. For some, the feature is an addition to an existing Type; for others, it is only being offered as part of a limited test group. At the time of this writing, these are some of the new features being tested:
Structured data beyond SEOAs mentioned in Part 1 of this guide, structured data can be useful for other marketing channels as well, including:
For more detail on this, see the section in Part 1 titled: "Common Uses for Structured Data."
How to generate and test your structured data implementationOnce you've decided which Schema.org Types are relevant to you, you'll want to add the markup to your site. If you need help generating the code, you may find Google's Data Highlighter tool useful. You can also try this tool from Joe Hall. Note that these tools are limited to a handful of Schema.org Types.
After you generate the markup, you'll want to test it at two stages of the implementation using the Structured Data Testing Tool from Google — first, before you add it to the site, and then again once it's live. In that pre-implementation test, you'll be able to see any errors or issues with the code and correct before adding it to the site. Afterwards, you'll want to test again to make sure that nothing went wrong in the implementation.
In addition to the Google tools listed above, you should also test your implementation with Bing's Markup Validator tool and (if applicable) the Yandex structured data validator tool. Bing's tool can only be used with a URL, but Yandex's tool will validate a URL or a code snippet, like Google's SDT tool.
You can also check out Aaron Bradley's roundup of Structured Data Markup Visualization, Validation, and Testing Tools for more options.
Once you have live structured data on your site, you'll also want to regularly check the Structured Data Report in Google Search Console, to ensure that your implementation is still working correctly.
Common mistakes in Schema.org structured data implementationWhen implementing Schema.org on your site, there are a few things you'll want to be extra careful about. Marking up content with irrelevant or incorrect Schema.org Types looks spammy, and can result in a "spammy structured markup" penalty from Google. Here are a few of the most common mistakes people make with their Schema.org markup implementation:
Mishandling multiple entities Marking up categories or lists of items (Products, Recipes, etc) or anything that isn't a specific item with markup for a single entitySo there you have it — a beginner's guide to understanding and implementing structured data for SEO! There's so much to learn around this topic that a single article or guide can't cover everything, but if you've made it to the end of this series you should have a pretty good understanding of how structured data can help you with SEO and other marketing efforts. Happy implementing!
Source: The Beginner's Guide to Structured Data for SEO: How to Implement Structured Data
No comments:
Post a Comment