The Structured Data Brouhaha At SMX East: Clarifying Contentious Issues
If you attended the Structured Data Superstars session at SMX East earlier this month, you probably witnessed a very brief interchange between myself and Googler Pierre Far at the end of the session. Pierre woke everyone up by stating that some of the semantic markup recommendations I’d presented would be considered “spam” by Google. It was […]
If you attended the Structured Data Superstars session at SMX East earlier this month, you probably witnessed a very brief interchange between myself and Googler Pierre Far at the end of the session. Pierre woke everyone up by stating that some of the semantic markup recommendations I’d presented would be considered “spam” by Google.
It was quite a gut-clencher for me, particularly because it was so completely unexpected — and because I’ve long considered myself a fairly conservative, white-hat sort of search marketer. Not the reception I was aiming for by a long shot!
I asked for specifics, and he stated that there were two areas of recommendation involving reviews and ratings that Google would have considered against their guidelines; he also went on to state that my recommendations around logo markup optimization were erroneous.
There wasn’t much time for context or specifics, and the session was soon over, so I chatted with him afterward and got more clarification. We’ve subsequently emailed as well, so I wanted to post an update outlining directly what uses of structured data can get you into trouble with Google so you don’t innocently stray into dicey implementations.
Using Reviews/Ratings Markup For Testimonials On Small Business Websites
During my presentation, I showed an example of a business that had quoted a review from Yelp on their company’s homepage. They had marked the review up using Review and Rating Schema. Doing this gave their homepage a five-star rating in Google’s search results:
I knew that Google Maps guidelines had at one point stated that doing this was okay (see Internet Archive for this in 2010):
Now, this is where I really should’ve known better. Mike Blumenthal later warned that Google had changed this guideline, and his interpretation was that they were now calling this tactic “spam.” Here was the later text:
Mike did a better job of channeling Google’s intentions than I did. It was still confusing, however, because despite the language above which suggests a ranking penalty for “reviews markup intended to game search results,” the same FAQ states elsewhere that structured markup will not impact rankings, negatively or positively:
To add more confusion, the FAQ page from which the above excerpts were taken is no longer available (it errors out), despite being linked to from the Webmaster Tools help page on Reviews. It’s nearly enough to make you feel that adding structured markup is just too risky — if you can’t keep up with the changing landscape, parse Google’s language and psychically glean what they like, then perhaps you shouldn’t do it at all since you could get dinged if they don’t like it.
What I’d assumed was that the obvious problem with small businesses using Reviews markup was that their reviews might not be real — though that’s been deemed illegal by the U.S. government and state attorneys general. However, the wording of Google’s updated guideline made it sound like it was okay to use reviews on your site as long as they came “from an independent source.” In the example I posted above, the business had quoted the review from someone on Yelp.
Pierre told me later that there were two problems with that from Google’s perspective. First, they don’t want any syndicated content marked up — it should only be your original content (although they never mentioned the word “syndicated” in the guidelines). Second, a business homepage isn’t a page of reviews, so it shouldn’t be presented as such. Quoting him directly:
There are two aspects to this, both stated in our guidelines. We want structured data markup to:
1. Describe and summarize the page’s main content as a user would see it.
2. Be of original content that you and your users have generated and is fully contained on your page.
The first point is that if a user sees a review rich snippet, they will expect a page that’s a review. In the scenario you described, you suggested webmasters add the reviews on the homepage, which is usually not seen as a review page. I’ve yet to see a business homepage that a user would expect to function as a review page.
The second point is about syndicating reviews. By definition, syndicated reviews are not original content your users generated on your site. Marking up third-party reviews like this is outside our guidelines and is considered spam.
So, it’s now clear that what I presented was wrong from Google’s perspective, though their guidelines are still not really telling people that in a very direct manner. From what Pierre has said, I’m sort of assuming it would still be fine to mark up testimonials on your site if they’re sent to you directly by your customers (as so many are), and if you have them only on a page specifically devoted to testimonials — not the homepage or a locations page.
However, considering how these guidelines have changed around this one point over time, I would advise just leaving that markup out entirely.
Rolling Multiple Reviews Up For Aggregate Rating/Reviews Presentation
The second problematic tactic I’d presented was around Aggregate Reviews. I’d suggested that if you were an online retailer, you could use Aggregate Reviews markup for your category-level pages, to enable them to display reviews and rating stars in the search results.
For instance, if you had a category of “Big Screen TVs,” you could average the rating value to display the rating in a rich snippet. Or, if you were an hotelier, you could perhaps roll up a page of all your hotels within a particular country or state and enable that listings page to display an average rating.
Pierre said that was a violation of their quality guidelines. He further expanded:
This, incidentally, is another example of the markup needing to describe the main content of the page as a user would see it. Pages that list multiple products are not what users would expect to see if the snippet suggests it’s a review page. If a page lists (say) cars, I would expect a listing of cars. Showing rich snippets aggregating reviews across all cars is confusing and misleading because the listing page doesn’t function as a review page.
I was particularly tripped up by the webmaster guidelines on this one — totally unaware that this was not acceptable. Here’s what they say:
I understand now that they meant “singular” or “individual” when they said “specific.”
The second part of that first guideline had also added to the trip-up — “not supported” suggests if you use the code incorrectly, it just won’t show up. When I found examples of this sort of code in use, I’d assumed it must therefore be “supported.” In online and software terms, “not supported” just usually means that functionality isn’t there or isn’t guaranteed. What Google really means in these guidelines is “it’s prohibited.”
I still think there’s a problem with the way these obvious implementations are not spelled out as prohibited.
For instance, some online retailers will list out separate product pages according to options — like “white,” “black,” and “gold” color. But, they’re all the same product — so, it’s apparently not okay for those sites to use aggregate markup for a page that lists out separate pages with separate reviews of the same type of product that differs by an option; whereas, the sites that do display the product only on a single product page will get to use the aggregate markup for the main product page.
Finally, on the point about my preso being erroneous about Logo Optimization, apparently it wasn’t. In both my earlier article on using logos for SEO, and in the presentation, I’d based my example code on Google’s blog post on the subject, only I’d used a sub-type of organization instead of the more general organization schema. Pierre had thought that the subtypes weren’t supported, but they are. So, my advice around that was fine after all.
Google’s guidelines around using structured data to elicit rich snippets tell us not to “parse” their rules, but to be honest and straightforward when implementing. I didn’t really parse it until after I tripped-up and felt somewhat stung. I don’t think the webmasters, from examples I presented, intended to do wrong, either — I think that in some specific implementation cases, it is difficult to understand precisely what is allowed and what isn’t.
I really wish that Google would address some of the more common issues that are likely to arise, and use blunter language in the guidelines so that people will not stray into implementing in ways that can get them into hot water.
Pierre told me that Google can take manual actions on sites that abuse structured markup — at least one action is that their ability to invoke rich snippets can be completely suspended.
I appreciate Pierre attending and communicating with us at SMX — I think this is helpful all the way around in enabling us as marketers to do a good job in helping companies to optimize themselves. I think it’s also good to have the dialogue so Google might be able to clarify their guidelines if and when they appear a bit mystifying.
Opinions expressed in this article are those of the guest author and not necessarily Search Engine Land. Staff authors are listed here.