SEO Guide to Schema.org – An Introduction
If you’ve been following events in the web development and SEO world, you’ve probably heard that there is a new standard for marking up data so that search engines can display rich data. It’s called schema.org.
We’ve already seen this sort of thing with the Microformats that are around at the moment, but this standard will be normalised across the main search engines. The plan is to also allow a standard format for other tools to read as well – allowing a much easier flow of data between websites, web services and even more exotic tools such as mobile apps.
In this post I won’t be going into specific examples of code (that’s all listed over at the schema.org website, so there’s no point duplicating it here), but I will be addressing some of the questions that I think you might have about it.
Schema.org – who are these guys anyway and why should I listen to them?
Schema.org is rather unique, in that it is a collaboration between the three biggest players on the search engine market – Google, Yahoo! and Bing. This kind of thing hasn’t really been seen since 2006, when they came together to provide a common standard for sitemaps.
That in itself should also answer the second part of the question – you should listen to them because they are giving us, as web content writers and SEOs, the perfect opportunity to mark up our web copy and data in a way that is effectively guaranteed to be read properly (i.e. optimised) for almost every search happening today.
What is wrong with Microformats – and why do we need this?
One problem with Microformats and the other ways of getting meaningful data straight onto the SERPs is that they are not standard; what works for Google might not work for Bing, and vice versa. Using the schema.org scheme will work across all search engines. There is a good argument that using these will eventually be essential for getting the best SEO performance from a website, just reading the FAQ drops some pretty strong hints at this: “using on-page mark-up [will] help you to surface your content more clearly or more prominently in search results”.
As you might already know, Google Microformats can be inconsistent. Different sites (and even different pages on the same domain) will sometimes show up with rich snippets, and sometimes they won’t – even if they use identical mark-up. Schema.org mark-up should be more easily trusted (and hence displayed more consistently) by the search engines than current formats, such as hProduct and GoodRelations.
On top of all that, webmasters will now have an “SEF mark-up bible” to refer to – i.e. it will have all the information they need in one place, and with much less ambiguity than patching together bits from here and there.
How will schema.org change SEO?
The change won’t be fast, but once this standard is widely adopted, we can expect to see a lot more rich data on SERPs. Plus, this rich data will be more accurate and relevant than what we have at the moment.
Sites that do not have any structured mark-up are already less effective in SEO terms, but this is likely to become even more pronounced as more and more sites begin to offer this rich data to the search engines in the way that they “like”.
On the flip side, it will become easier than ever to “scrape” very rich content from sites that are using schema.org data structures. Because of this we might see a rise in automated content aggregation sites and the wholesale lifting of data from one site to be copied by another – effectively reducing the percentage of the web that is good quality, original content. That said, we can only wait and see how effective the search engines are at detecting spam (my money is on them being pretty good at using the new structure to accurately decide if the content on a page is legit).
What will stay the same?
This won’t change any of the underlying SEO methods you currently use. If you have a tried and tested method for improving the SEO performance of a website, then it will still be effective.
Pigeonholing data – what if my data doesn’t fit?
Schema.org covers most of the data types you might come across, but if you need to you can extend the vocabulary. There is no guarantee that this will appear in SERPs but it is fully endorsed by schema.org. For example, you can extend a class with a / character, such as: “Person/Engineer”. Over time, it is possible that these extensions will be moved into the core schema.org vocabulary, if they get used widely enough.
How will it affect the SEO community?
Schema.org is likely to become a natty buzzword amongst anyone with a website who wants to be on the top of SERPs. It should be quite marketable, and widespread coverage in the web world should help to underline the importance of search engine friendliness in general. It will no doubt soon appear on the “what we do” lists of countless SEO agencies, under the “on page SEO” section.
A lot of SEOs might be quite defensive of the methods they currently use to provide rich data (and those methods will continue to be effective), but in the end you can’t fail to adopt a standard that has got the backing of all the main search engines.
My client heard about all of this and wants it right away. What should I do?
There is nothing wrong with implementing this now – even though the schema is only in draft form, and won’t be finalised until later on this year. The FAQ at schema.org assures us that as the schema evolves over time, everything currently listed will continue to be fully supported by the major search engines.
If you don’t have any sort of structured mark-up to your copy, it’s probably logical to implement the schema.org structures rather than any of the others that are floating about – it’s not going to go away anytime soon!
On the other hand, the FAQ also says that all current data formats which “work” and are read properly by Google, Bing and Yahoo! will continue to be supported – so if you already have your data marked up properly and the search engines like it, there is no official sign that they will perform any worse than competing sites that use schema.org data formatting. Of course the acid test for this is in the SERPs – we can only wait and see what happens next, but personally I wouldn’t go rewriting great swathes of copy just yet: if you have any other SEO related work to do on a site, it should probably take priority over implementing schema.org formatting.
You haven’t answered my question! I don’t agree with what you say!
If there is something I haven’t covered in this SEO guide for schema.org, or something you don’t like the sound of, just leave a comment and I’ll see what I can do. I’ll be responding to every comment!