When someone asks a question, they expect an answer. Naturally,…
What’s Wrong with HTML 5, Microdata and Schema.org?
After reading the article, here are the main points Keery Dean makes against HTML 5 microdata tags using Schema.org vocabulary on your website. People can simply go overboard and tag every possible thing on a webpage. This would cause code bloat and eventually nullify the effectiveness granted by search engines due to overuse.
Well, here’s the thing. Overusing any type of tag is basically SPAM.
As website SEO professionals, we have to be sensible, practical and strategic. Every SEO consultant should be able to spout off the known types of on-page SEO SPAM. The oldest forms of SPAM mainly boil down to excessive use of keywords, A.K.A keyword stuffing. The goal of over optimization of a website, being to game the search engine algorithm, tends to create poor user experience. This is contrary to the search engine goal, which is to provide high quality user experience search results. With the emergence of new technology, it is in our best interest to apply the principles of SEO best practices. Microdata is a tool. Use it when it makes sense. Use it strategically, when needed. Otherwise, as Kerry Dean points out, it becomes useless code bloat.
Strategic Use of Microdata and Schema.org for SEO
So far, my use of schema.org for website SEO and development has only been two fold:
- an effort to label and specify something that I can’t get into Google otherwise
- to create rich snippets based on what Google already includes in its Webmaster Guidelines
I made an attempt to get about a couple dozen Caribbean resorts accurately located in Google maps. The problem is you can’t verify them, because Google doesn’t support business owner verification in those countries yet. None of the feed providers like Localeze or Acxiom support these countries either. For the most part, the resorts in the Caribbean don’t even have street addresses. They just have PO boxes. Based on PO boxes, Google Maps tends to place the locations on the post office – which is generally inland, not on the beach where the resort is located. So I set up unverified locations where you can recognize the buildings and resort logos in the pools from satellite view. However, other Google map users would edit things and change what I put in, even though I know my information is correct because it came straight from the owner (or rather corporate or hotel managers on location). The funny thing is, after fighting a little with the tide of other Google users moving things around, I noticed that Google Maps takes its cues for the location more from other online resources than from where Google Map Maker users place it. Moving forward, my strategy is to use microdata tags with schema.org vocabulary, including longitude and latitude coordinates to indicate the resort location on the homepage for each resort.
Example of microdata marked up organization location that might appear in a footer under the copyright:
Valpak of Atlanta | 5887 Glenridge Drive, Suite 420, Atlanta, Georgia 30328 | (800) 550-5025
My other use of schema.org vocabulary purely overlaps with what Google already was supporting in the way of rich snippets. Except now, if Google guidelines give a choice between microformats, search monkey, Hcard, etc and microdata… I go with microdata. My goal for this is purely conversion. Make the existing listing and big and full as possible. It stands to reason, if you take up more visual space with your listing on the Google result page, you’ll get more clicks. Just because it’s bigger. I’m also in the process of experimenting with getting bullet point lists inserted in Google SERPs.