Rich Cards and Google's Structured Data Restructuring
On 17 May 2016 Google rolled out a number of changes to how the search engine handles structured data on the web. Among the most important of these changes are the introduction of a new rich results type, Rich Cards; the complete restructuring of its documentation about structured data; and the addition of a new report in Google Search Console, the Rich Cards report.
This follows closely on the heels of changes made to Google’s Structured Data Testing Tool just a few days earlier.
Let’s take a closer look at some of the more significant of these changes, and what their implications might be for a site owner’s search visibility and search engine optimization efforts.
Rich results and user intent
In a new page on search features, Google introduced the term “rich results”, a catch-all phrase for instances where attributes about some thing represented on a website “can be featured in a visually compelling way.”
These “rich results” are facilitated by the addition of structured data markup to web pages, either in the form of content items (“such as articles, recipes, or movies”) or lists of items (“such as recipes and events).
This is the first time Google has made the differentiation between “content items” and “lists of items”, and it relates to another concept introduced by Google in their revamped documentation, that of a user’s search intent driving presentation.
When you prepare your content for inclusion in Search, it can appear in a variety of visual forms, because it’s the user’s search intent that determines how Google Search displays information. A user’s search intent is a concept describing how our algorithms understand what the user really wants with a specific query within a specific context.
For example, if a user queries for “turkey,” the search intent is ambiguous, so our results will display a mix of items, including a Knowledge Graph card about the country of Turkey, news items on Turkey, and turkey as a kind of fowl.
However, if the query changes to “turkey recipes,” the search intent narrows to a list query, so a carousel of recipes helps to cluster related recipes together, including a summary carousel for recipes from various providers and a host carousel for recipes from a specific host.
“Cluster” is the key concept here. Google has now explicitly stated that it will make efforts to group results together when it ascertains that the search intent is for a “list query.” And this is a good segue to the concept of a “card”, and the environment that gave birth to it – the mobile web.
Cards, rich cards and mobile
A card, Google now tells us, “is the fundamental presentation unit for Search results. It appears in the organic results for Google Search either as a single element or a list of elements.”
Note here we’re talking about cards, not rich cards. Like everything else in the new search guides, the nomenclature here draws heavily from the language of mobile. These, for example, are cards returned for the query “red wine.”
In other words – as far as I can judge – “cards” are search result items in mobile, which we used to call a search snippet. On desktop, indeed, one might still call these “search snippets”, but its revised documentation and examples for structured data Google has essentially banished the concept of desktop results.
Or will we still be talking of “search snippets” in a week’s or a month’s time?
There have very recently been multiple sightings of mobile-style cards appearing in the desktop results, such as those you can see in this screenshot provided by Jennifer Slegg in an article on the SEM Post.
If indeed a card is “the fundamental presentation unit for Search results” then this may be less of a test than a preliminary rollout. And while I may have been premature in tweeting “Rich snippets RIP” (they are still mentioned tangentially in the documentation, and the rich cards announcement FAQ gleefully provides the answer “Yes, you can!” to the question “Can I keep my existing rich snippets markup?”), rich snippets themselves may soon be a thing of the past – if only in name, as conceptually this type of rich result lives on in the form of rich cards.
Which brings us to Google’s main announcement about these changes, the introduction of rich cards – “a new Search result building on the success of rich snippets.” And, in essence, rich cards (as evidenced by Google’s “evolution” graphic in their post) are rich snippets re-imagined for the mobile web.
Google’s has now started showing two types of rich cards: movies and recipes. Here’s a current recipe rich card.
It’s actually more accurate to say “here are current recipe rich cards” as what’s pictured are multiple cards shown in a carousel. And in some ways, thinking of the “list query intent” discussed above, one might be tempted to say that a rich card is “a rich result that can be displayed in a carousel.” But rich cards can also be displayed as single items.
When it comes to movies, however, color me confused. At present every single movie I search for returns ye olde Knowledge Panel (now a “Knowledge Graph card”), and no result bears any resemblance to the movie rich card previews provided by the Structured Data Testing Tool, as we’ll see later.
As per the use cases listed the TV and movies data type page, one of the benefits of adding structured data to a movie item is to facilitate its inclusion in a Knowledge Graph card’s streaming options, but this isn’t a “movie rich card.” And in both the announcement post and in the structured data documentation there’s no movie rich card to be found.
However, movie rich cards will, apparently, one day appear in a host-specific list carousel (currently in “experiment mode” where you can test your markup for errors, but where the cards themselves aren’t yet available in the search results). Which brings us to the next new feature Google announced, host-specific lists.
UPDATE: A few hours after this post was published Google’s Richard Gingras, in his I/O talk on “Search and the mobile content ecosystem“, shared an example of a movie host-specific list on screen.
Host-specific lists
A host-specific list, as the lists specification page explains in reference to recipes, displays “cards from a single site within a specific category.” Here, for example, is host-specific recipe list for curry recipes on the Food Network’s website.
As you can see, these results are returned a carousel. Host-specific lists for events are provided in a more traditional “list” format.
As already noted, movie host-specific lists aren’t yet available but are coming sometime soon.
And I expect we’ll see more types of host-specific lists in the future. Mobile has really opened up opportunities here for Google to innovate with the presentation of search results, as the availability of carousels and lists within rich cards mean they’re no longer faced with the conundrum of sacrificing host diversity by presenting a SERP with results all from a single site: those single-site results can be relegated to a carousel, with more diverse listings below.
Rich card and rich snippet reporting Search Console
Announced in concert with rich cards is the addition of new rich cards report within Google Search Console. The new report (which complements rather than supersedes the structured data report) displays errors that render a page ineligible for a rich card (“invalid cards”), cards that are “fully enhanced”, and “enhanceable cards” – cards that “can be enhanced by marking up additional fields.”
Google also promises that a new “rich results” filter in the search analytics report “will help you track how your rich cards and rich snippets are doing in search: you’ll be able to drill down and see clicks and impressions for both.” This feature is currently being tested in a closed beta.
As per a post from Google Webmasters on Google+, AMP reporting has been added to the search analytics report on Search Console, but this doesn’t pertain to structured data usage specifically. More important in that regard is the 4 May 2016 update announced by John Mueller, in which AMP error information is now aggregated – and this error reporting includes structured data usage.
JSON-LD, JSON-LD and more JSON-LD
As noted in these pages, Google has slowly but surely making improvements for their support for JSON-LD. With these latest changes they’re all-in when it comes to favoring JSON-LD for the markup that uses the schema.org vocabulary.
The announcement post states that “[w]e strongly recommend using JSON-LD in your implementation”, and the new introduction to structured data page reiterates this recommendation, noting (correctly) that “[s]tructured data markup is most easily represented in JSON-LD format.” A table on that page shows that JSON-LD is now supported by Google for “[a]ll public data types except for Breadcrumbs.”
However, it’s worth noting that, despite this recommendation, microdata and RDFa are still supported for all data types, and there’s no suggestion that support for these syntaxes will be deprecated.
A revamped Structured Data Testing Tool and new previews
As noted above, the Google Structured Data Testing Tool was revamped just prior to the rich cards announcement and redesign of the structured data document changes. I wrote about those changes in some detail, so won’t repeat the information I already provided in that post.
One thing I didn’t notice, however, is that there is limited rich card preview functionality in the revamped Tool. The announcement notes that you can now see a preview “of how the rich card might appear in Search (currently available for recipes and movies).” Rich snippet previews were available in the first version of the Rich Snippets Testing Tool, but haven’t been provided since the tool was redesigned in January 2015.
You can trigger a “preview” button by running the first data type example code for recipes or movies through the Testing Tool.
And here’s what a recipe rich card preview looks like.
Okay, almost like that: I must confess that I overlaid the image on that screenshot. The actual preview, even though I’ve declared the image you (which is available at a Googlebot-accessible UR) looks like this.
This is because, as the new help article on the Google Search Preview Tool explains, “you can see your actual image in the preview if we confirm, or verify, that the image URL is in our index”, and the asset I’ve used here hasn’t yet been indexed by Google.
It’s possible that this restriction is in place because the preview actually runs on google.com (and the help page also includes instructions on how to override regional Google domains using /ncr in order to facilitate the preview), and so might be restricted to returning only indexed images. The preview URL looks like this:
http://bit.ly/1X5gOVx]
Based on that, and the help page’s note that “[i]t helps you preview your structured data markup for web or mobile app URL as it would appear in the Google Search results page” (emphasis mine) It’s likely that we’ll see the functionality of this tool expand in the future.
For the record here’s a preview of a movie item (with, as with my recipe preview, a manually added image). Pretty underwhelming “rich result” in my opinion, but perhaps isn’t as lackluster as it appears when you think of these rich cards in the context of a host-specific list of movies. (Updated since publication: see the image of a host-specific movie list that’s been added to the host-specific list section above.)
New structured data documentation and examples
Google has completely reorganized how they provide information about structured data use, specifications for specific types, and examples of structured data markup.
Previously, all information was provided from a single hub page on Google Developers. Now all things related to structured data appear on the Google Search site. The most notable change is that informational pages are now separated from pages about specific item types. Here are the most notable pages in the reorganized presentation.
- Guides
Guides and usage specifications for structured data, indexing and page creation. Includes the new search features page, which gives an overview of rich results type, and the new search gallery, which provides images and code examples for a handful of rich results types (four at time of writing: recipes, events, products and reviews). - Data types
The hub for individual data types that are eligible for rich results, such as reviews, events and recipes. These were previously served from the single documentation hub on Google Developers, under the heading “Enable Rich Snippets.” The new way of organizing these items is much more extensible. - Pilot features
A new holding area for data types that are being piloted “with a small set of initial providers.” Currently the features listed there are live blogs and software apps. - The Google Search Preview Tool
Information on the Search Preview Tool, as mentioned above. Worth calling out in this list because, as far as I can tell, the link to this page is exposed only after you click the “preview” button in the Structured Data Testing Tool for a type that’s eligible for preview.
For articles it’s worth noting that the prior pages for “Top Stories with AMP” and article rich snippets have been combined into a single articles page, reflecting the move to organize structured data documentation around data types rather than rich snippet types.
The way in which example code is provided has changed too. Previously code was provided on each specifications page inline. As per the image above, code examples are now linked by a “see markup” button, which opens the code example directly in the Structured Data Testing Tool (though there is still some inline code provided for the local businesses data type).
This doubtlessly makes example management easier for Google, and certainly now relieves users of the burden of copying and pasting code into the Structured Data Testing Tool. And, unlike before, the examples provided mostly come back as error-free in the Structured Data Testing Tool. Current exceptions are an aggregateRating example that, bizarrely, declares something named “Super Book” as a Thing rather than some more specific class (declared as such in examples for all three supported syntaxes), a VideoObject example where the thumbnail URL provided is not valid, and a MusicGroup example where the content declared by and event property is a URL, rather than the Event type that is expected.
One vocabulary to rule them all
Finally, while this isn’t new, it’s worth noting that all of Google’s structured data guidelines and documentation reference schema.org, and only schema.org. Google has gone all-in with the vocabulary as the basis for structured data markup they support, just as schema.org’s fifth anniversary approaches.
Dr. IT - Data recovery,it support,computer & laptop repair in Kingston upon Thames
http://bit.ly/22GDYBq
