HTML Table Elements and SEO – Part 2


In the first part of the article we’ve looked at how search engine bots read pages built with HTML tables, at why it’s important to know how they do that and then briefly explained the “table trick“. In the second part I’ll list the rest of HTML table tags.

Mostly, when it comes to the table elements it is web designers and the programmers who will be more involved with them, rather than copywriters or SEOs. The copywriter shouldn’t worry about how the page is built at the backend, he will need to just focus on the content of the page. The SEO guy has to look at the page when it’s done by the designer/programmer and see how it’s cached in search engines and then provide feedback to make required changes, so pages are cached properly. Let’s start.


<TABLE> tag

Table defines an HTML table and this tag itself can’t contribute to better search engine rankings.

One of the table’s tag optional attributes which can have a minimal effect on your rankings is summary. The summary‘s attribute content doesn’t get cached as text in Google and it’s very likely that Google will use it for rankings purposes, however it might be used for getting the page’s theme, that is equally important in SEO.

One could say, if <TABLE> tag can’t influence rankings, why bother? But, aren’t websites supposed to be built for users in the first place and then, search engines? Accessibility should be an important thing SEOs should to consider too. Providing a good summary offers insight to visually impaired user who might use screen readers, so go ahead, add a summary to the tables that need one (excel like tables).

A very frequent question I hear is, what to use, <TABLE> or <DIV> to improve my search visibility? The answer is, It Doesn’t Matter. Many SEO “experts” won’t agree with me, but here’s the cruel truth for them: search engines don’t care about how you build web pages, tableless or divs-only, php or aspx, they only look at the final output, by stripping html markup and analyzing the pure text content they can and want to read. However, from other points of view, I would recommend a combination of predominantly CSS and lightly tables, or, if you can build entirely with CSS easily, go tableless.

The use of DIVs and CSS can allow reducing the size of your HTML significantly, depending on how nested your tables would be. TABLE tags require TR, TD, TH, THEAD, TBODY, and TFOOT. This adds quite a few tags that can all be condensed into a few DIVs.

If you choose to stay with your current tabular structure, that should be fine in terms of SEO, as long as you don’t screw up your code badly (improper nesting, unclosed tags, etc). But at least you should semantically markup your tables. David Calhoun wrote a good piece of article on how to create the perfect semantic html. Here’s how the table looks like:

Sample of a perfect semantic table

The Perfect Semantic Table

Read the article, then go and make changes where appropriate.

So, how do you know if your tables are screwing you up?

A good indicator that your code is ok and will be properly crawled by search engine bots is if you get no errors (or very few) when you run an html validation over it. The number of html errors can be related up to a certain extent, to the difficulties search engine bots will encounter while trying to crawl your web pages.

Another way to check if your pages are well structured is by looking at the text-only version of the Google cached pages. Take a look at how the paragraphs are flowing. Are there any words that are concatenated, without the appropriate spacing? Does your content contain mainly navigation/menus or other irrelevant data at the top? Going a bit further, do you link to the same page with thematically different anchor texts?

The cached version of the page should provide a good indication of your page status, designed tableless or not.



This tag has been discussed in detail on the CAPTION tag and SEO article.

Before going further with the SEO analysis of the other html tags, let’s talk a bit about html attributes. You can find the complete list of this W3C page.

There are optional, standard and event attributes that you can attach to almost any html element. Of the aforementioned, event attributes won’t influence the search engine algorithms since these attributes are used to trigger actions in a browser, like starting a JavaScript when a user clicks on an element.

Some of the optional and standard attributes are however used by search engines bots. They are getting cached and taken into consideration when ranking a web document. A great example is the alt attribute attached to IMG tags.

There are different types of attributes but the types read by search engines are %Text; and some other CDATA. One of the widely supported attribute is the title attribute which can be attached to almost all other elements but BASE, BASEFONT, HEAD, HTML, META, PARAM, SCRIPT and TITLE.

While search engines won’t cache the title attribute for any html elements, the attribute should be used for good usability and accessibility. Don’t abuse, provide succinct and good information and eventually include one of your keywords. Don’t add titles attribute to every html elements in your pages or on the <body> tag – this will cause the title tooltip to display on each pixel of the screen.

<THEAD> tag

The HTML thead element is used to group header content in an HTML table. The element isn’t required. However, any data that deserves to be in a table deserves to have headings, right? So semantically, you should use it. Also, an empty <thead> is invalid and it must contain a <tr> and the same number of data cells as the body of table.

The <thead> tag supports the title attribute, where you can provide user agents more information about the heading of the tabular data:

<thead title=”here goes the description of the table head” >







<TFOOT> tag

Similarly with <thead> the <tfoot> tag is not required, and it’s invalid if it’s empty. <tfoot> has to come before the <tbody> element (this is a bit strange, from what I read it has to do with rendering the table footer before showing a possible very long tabular data).

<tfoot title=”some human-oriented information about the data presented in the table“>







<TBODY> tag

If you use this tag within your tables you can provide additional descriptive information to users using the title attribute.

<TBODY title=”you can describe here what’s in the table body”>

<TR> …first row of block one data…

<TR> …second row of block one data…


If you can, use the <thead>, <tbody> and <tfoot> to build more robust tables (i.e. sortable tables). This might provide some useful semantic information to search engines. Don’t abuse the title attribute on this one as you may get into spam penalties.


The difference between the two is the semantic meaning. The <COL> tag does not group columns together structurally while <COLGROUP> provides a more semantic meaning by grouping them with meanings. In other words, COL is used just for styling the tables while COLGROUP has a relational meaning.

They both support the title attribute where you can provide user agents (if appropriate) more information about the group of columns created with these tags.


<TR> <TH> and <TD>

The TR element acts as a container for a row of table cells. <TH> and <TD> are table cell elements and may contain two types of information: header information (TH) and data (TD). This distinction enables user agents (browsers and search bots) to render header and data cells distinctly, even in the absence of style sheets. For example, visual user agents may present header cell text with a bold font and speech synthesizers may render header information with a distinct voice inflection, while search engine bots may draw semantic meaning from TH and attach it with the data followed into TDs.

<TH> will communicate richer hierarchy to search engine bots and could be a good place to add your keywords, where relevant.

All three tags support the title attribute, which can be used to provide more information to users.

None of them have the means to alter your website rankings in search engines, but the way you lay data inside these tags may affect how search bots will read the data. The “table trick” described in the first part of the article, can be used to move content at the top of the source code.

As usual, if any of you have ideas or experience on altering html tag with the purpose of providing better experience to search engine bots :) and users, please comment.

Pitstop Media offers ROI focused SEO services. If you need a SEO company to help you rank #1 please contact us for a free, no obligation quote. We’ve helped companies rank first on Google in short periods of time, for highly competitive terms.

VN:F [1.9.22_1171]
Rating: 10.0/10 (7 votes cast)
VN:F [1.9.22_1171]
Rating: +4 (from 4 votes)
HTML Table Elements and SEO - Part 2, 10.0 out of 10 based on 7 ratings


Traian is Director of Search Marketing at Pitstop Media Inc. He has more than 11 years experience in helping small and medium businesses generate and convert organic traffic from search engines. Connect with Traian on Google+. He is also the author of the Ecommerce SEO book.


5 Responses to “HTML Table Elements and SEO – Part 2”

  1. Anonymous said:

    Sep 28, 11 at 12:08 pm

    The post is actually the freshest on HTML Table Elements and SEO. I harmonize with your conclusions and will thirstily look forward to see your approaching updates.


    VA:F [1.9.22_1171]
    Rating: 0.0/5 (0 votes cast)
    VA:F [1.9.22_1171]
    Rating: 0 (from 0 votes)
  2. Karl Kelman said:

    Feb 13, 12 at 3:16 pm

    “by stripping html markup and analyzing the pure text content they can and want to read”

    Are you sure? Don’t bots need to look at markup for page segmentation, font size, etc.

    Without looking at the html, how could they place more value on big headers at the top of the page, and less value on fine print in a footer 10 pages “below the fold.”

    VA:F [1.9.22_1171]
    Rating: 0.0/5 (0 votes cast)
    VA:F [1.9.22_1171]
    Rating: 0 (from 0 votes)
  3. TraiaN said:

    Feb 13, 12 at 4:34 pm

    Karl, you are right; there are even patents for that kind of analysis too. Most likely SE bots will read the HTML and CSS code just as any modern browser would. Heck, they will take that even further and will analyze how the layout looks like visually. However, what I meant is that search engines strip that info to analyze the text context in terms of relationships between words, shingles and semantics and won’t assign more weight if you design with tables and less weight if designed with CSS. I hope it helps. I appreciate your contribution.

    VN:F [1.9.22_1171]
    Rating: 0.0/5 (0 votes cast)
    VN:F [1.9.22_1171]
    Rating: 0 (from 0 votes)
  4. Karl Kelman said:

    Apr 23, 12 at 4:02 pm

    I largely agree with your clarification, but… …isn’t SEO always about “skating to where the puck is going, not where it is” to borrow a hockey phrase.

    I’ve always suspected that as SEO professionals figure out how to “game” other variables, search engines will start to look at modern, clean code as essentially a “freshness” variable.

    Do 10-year-old tabular Dreamweaver pages signal a stale site? Not sure, but why not play it safe.

    VA:F [1.9.22_1171]
    Rating: 0.0/5 (0 votes cast)
    VA:F [1.9.22_1171]
    Rating: 0 (from 0 votes)
  5. TraiaN said:

    Apr 23, 12 at 4:34 pm

    I don’t think that tabular design means older or not fresh. However rich user experience, which seems to increase time on site, page views and CTRs (which are all feedback metrics for Google nowadays) seems to happen mostly on CSS designed sites. One must design for the user, and then for search engines.

    VN:F [1.9.22_1171]
    Rating: 0.0/5 (0 votes cast)
    VN:F [1.9.22_1171]
    Rating: 0 (from 0 votes)