Remember when Google started including images, videos, local shops, PDF documents and Youtube videos right in search results back in 2007? Well now that’s happening again with structured forms of content like HTML tables.
Tables were originally meant to present sets of information, just like spreadsheets. But back in the early days of the web, designers found that they could stretch them to encompass the entirety of a web page and use columns and rows to lay content out the way they wanted. Today this technique is considered archaic as CSS provides far superior layout capabilities, but a significant quantity of sites that rely on tables for their design remain.
It took time, some trail-and-error and a lot of machine learning, but Google’s deciphered a way to reliably isolate good tables that contain data from the vast sea of “bad” tables that contain layout. This was no small feat, considering bad tables outnumber the good a hundred fold—and Google had a colossal 10 billion+ tables in its index.
In this article we’ll examine some of the particulars behind what makes a good table. This way when you publish sets of data, you’ll have another traffic source from Google’s table search, better semantic preparedness (more on this later) and potentially better search results for certain queries in the future, when table search takes a more integrated role in Google SERPs.
Google’s a machine (that’s getting gradually more unsupervised). So the trick to creating tables that Google will love is making it easy for machines to understand your tables and categorize the data within them. When creating tables remember this cardinal rule: the more easily the semantic structure of a table can be discovered, the more likely it is to contain high quality data.
When creating tables remember this cardinal rule: the more easily the semantic structure of a table can be discovered, the more likely it is to contain high quality data.
Good tabular data almost always has a row that acts as a header (except for, perhaps in the case of vertical tables, which we will explore as well). Just as headers describe columns, a candidate for a strong table has a primary column which describes rows. This column often features entities that the table is about, which is why it’s called the subject column. Unlike table headers, subject columns aren’t declared in code: Google figures out what these are on its own.
The biggest indicator of a table that contains high quality data is a subject column whose contents remain consistent across a theme.
Below you’ll find a list of factors that serve as indicators of a good table, ranked from highest to lowest on a speculative basis. Note that some of these factors are also slightly speculative, but likely. Others have either been explicitly described in Google’s research papers or strongly suggested.
Not all good tables fit neatly into the box defined by the above-mentioned factors however, the major exception being vertical tables. These are frequently found on, but certainly not limited to sites like Wikipedia and consist of two columns. Interestingly, such a small quantity of columns often negates the need for table headers, as each of the two cells in a row form a subject:value pair.
Take a look at the long vertical table (right) detailing all sorts of data on Jupiter’s largest moon. It may not follow the 12 rules above, but it certainly does contain structured and useful information. Wikipedia uses an interesting format for vertical tables where headers act as captions that span a two column width, and designate a subsection of the table.
Tables are used in Google web search today, but as of 2015 they seldom make appearances, although it’s likely that the breadth of search results that use tables is going to increase.
Tables will appear in search if the following two conditions are met:
Tables will only boost your ranking if the query is highly informational and if you rank second or third already. In other words, the state of table integration into blended search is conservative at best and in a beta phase right now.
The vertical tables mentioned earlier are a great candidate for rich snippets. Remember Ganymede from before? Here’s that SERP result featuring the tabular data as a rich snippet.
Vertical tables, especially those found on Wikipedia, are prime candidates for this sort of snippet enrichment despite the lack of traditional semantic markup. What’s really cool about this is that information may be attached to a snippet that isn’t part of any semantic vocabulary yet.
In a word, yes. Tables afford three advantages. First, your data will be indexed in table search, which means those who use Fusion Tables or the Research Tools within Google Docs will come across them. Furthermore, using tables can potentially enrich your result in SERPs by adding structured data, even if no classes exist yet for the sort of data being structured. This can serve as a sort of semantic preparedness and bypass, to some extent, the need for constantly checking Schema.org for new vocabulary. Lastly, on occasion, your tables could appear in search and give you a minor ranking boost—this places it in a class with other standalone ranking boosters like Google Authorship (formerly), mobile-friendly sites, SSL, etc.
Most of the tables I’ve cited so far suggest little to no commercial intent, so as a closing thought I’ll leave you with the table below and its corresponding search result.
Filed under: SEO , User Experience || Tagged under: blended search, Google research, integrated seo, latent semantic indexing, ontology, search predictions, semantic web, seo, structured data, table search, universal search
Author: Orun Bhuiyan