Fixing 5 common SEO problems with HTML5... today!

HTML5 Superhero

For sometime now you’ve probably been hearing conversations about how some problem or another would be much easier solved with HTML5, but because X percent of users are still on IE we can’t “move to HTML5”.

However, in reality, HTML5 isn’t something you need to ‘switch on’ - it isn’t one big thing. Think of HTML5 not as a tool but as a toolset; a collection of new features, in many cases independent of one another. This post deals with the SEO benefit of HTML5, and so our focus is on what Google and co. can interpret and not with browser compatibility. It is not necessary for a browser to recognise all the tags on a page, as long we do not disrupt its ability to render that page (and if the browser gets some benefit too, then even better). However, we will touch on what browsers do and don’t support and how this relates to SEO; there are plenty of bits in the HTML5 toolset that the browsers have absolutely no problem with, and where they do we can often help them out.

We are going to look at some common problems encountered with SEO, and discuss how HTML5 could help to address them. I’m sure there are many other situations where HTML5 could help us out, but I’ve picked 5 to get going with. Note that not all of these are open and shut scenarios, but I think they are all scenarios where there HTML5 can provide a measure of assistance, be it now or in the very near future.

Problem 1: Pagination

Issues: duplicate content, crawl budget, juice flow

Pagination on an eCommerce siteYou have a tonne of pages, e.g listing products in a particular category, which are completely identical asides from which subset of your products are listed on them. Now you want to ensure that you rank, but you also do not want to run into duplicate content issues, or waste your crawl budget letting Google crawl hundreds of pages which add no value. However, maybe you do want them to be crawled to ensure the content is indexed? Maybe you want them crawled but are aware these same products are listed in different groups and sequences in varying categories and you are worried about the implications of this. If only you could just tell Google: “Hey! These pages are paginated listings, so please treat them accordingly!”.

This is a common scenario for many sites, especially eCommerce sites; however, whilst a common problem, it is still something we see many clients struggling with. Furthermore, often clients will have some specific site quirk or preference which makes this less straightforward than it should be.

Unfortunately Googlebot is not yet sentient and so we can’t chat with the little guy just yet, so we have to find another way. Enter HTML5 and sequential links:

A sequence of documents is one where each document can have a previous sibling and a next sibling. A document with no previous sibling is the start of its sequence, a document with no next sibling is the end of its sequence.

A document may be part of multiple sequences.

Source: W3 HTML5 Spec

That pretty accurately details our problem! So how do ‘sequential links’ work? Well, of course, via our old friend the rel attribute. Previously your previous page and next page buttons might have looked like:

<a href=’products.php?page=3’>Previous Page</a>
<a href=’products.php?page=5’>Next Page</a>

We simply add the rel attributes accordingly:

<a href=’products.php?page=3’ rel=’prev’>Previous Page</a>
<a href=’products.php?page=5’ rel=’next’>Next Page</a>

This sends a clear signal that these pages are a sequence that belong together, and obviously this semantic information is a clean way for letting Google, Bing and the other engines know about this relationship.

Now, this isn’t a silver-bullet and I would not yet recommend that you do just this and nothing else, but I’d absolutely recommend that you do add these attributes to your pagination links. It isn’t the complete solution because there are ‘sequences of documents’ that are not product listing style pages (e.g sections in a tutorial) and we do not yet have a complete picture of how much Google will trust these attributes. However, the more you can tell Google about your content the better you help her (is Google a girl?) understand and index your content, and these attributes are a fantastic indicator to Google and a good place to start.

Actions: Deploy rel prev/next on pagination links.

Problem 2: Page structure

Issues: accurate indexing, crawl budget, SERP CTR, juice flow

For years now we have been reminded over and over to focus on semantic HTML. Originally the focus on this was that it makes rendering content across devices and formats far easier when it is neatly categorised: HTML for content and meaning, CSS for presentation and style, and Javascript for additional behaviour. Removing anything in your HTML that was just there for presentation was not too difficult, but managing to fully define the meaning of the content with HTML was pretty much impossible - HTML simply wasn’t a rich enough language. Microformats started flooding in trying to fill some of the gaps, but the fact is that HTML remained ill equipped for the task.

Once again, HTML5 swoops in to save the day! It doesn’t provide all the answers, but it does go a long way towards helping by providing a whole raft of new tags we can use to organise the web’s content and give Google and the engines a lot more help in interpreting our sites. Some of these tags include:


These mostly relate to what you’d expect and I’m not going to describe them each in detail here; if you’d like to read a bit more about them then check out w3schools’ excellent HTML5 Tag Reference.

I’ll just give a couple of examples...

Previously the constituent parts of most pages were separated with the overworked div tag:

<div id="myarticle">
<div id="extrafacts">

However, in HTML5 we have a much wider array of tags to assign semantic meaning to these elements, so the same example may look like so:


You should immediately see the difference - the tags themselves now transmit some information about what it is they contain. For any search engine trying to interpret the page and catalogue the information on that page having these indicators provides a massive benefit.

As another example, we can now break pages up far more neatly; consider the traditional H1 tag problem, and look at this example:

Google News Top Stories

What is the appropriate H1 on this page?? The fact is that not all pages lend themselves to being divided up with one main title. HTML5 uses a more sensible approach an allows us to have multiple

elements and multiple H1s on a page:

<section id="finance">

... <footer> </footer> </section> <section id="entertainment"> <header> <h1></h1> </header>

... <footer> </footer> </section>

HTML5 is intelligent enough to understand that these

elements are the headers and footers for their parent tags.

For an SEO this makes structuring a page significantly easier, and for a search engine it makes pages significantly easier to interpret and that helps with accurate indexing.

It isn’t completely clear how well Google handles all this new found awesomeness, so I’d advise a pragmatic approach at the moment. If you are uncomfortable with multiple H1 elements, then you can still employ the other elements. You’ll probably find that with most projects there are elements of these you can include already.

Whoa there... one last thing before you dive in!

With Firefox, Chrome of Safari you’ll be able to apply CSS to these new tags right out of the gate, but for a certain other browser this is not the case... In IE these tags will be inaccessible to CSS without a bit of help. Luckily enough, there is a solution out there in the form of the free and open source html5shiv. Download this smart bit of Javascript and install it and you’ll find you are good to go. Take that IE!

Actions: Gradually begin refactoring your page designs to slowly integrate these new elements. Begin replacing or supplementing generic div tags with these new tags.

Problem 3: Internal search pages

Issues: accurate indexing, duplicate content, crawl budget

What happens if you Google Bing’s results page for Googling Bing? Well, nothing actually because they block it with robots.txt, but my point is when a search engine starts crawling another search engine’s results pages the universe gets uneasy.

Now if you have an internal search feature on your site, the standard answer would be to block it with robots.txt and stop the hellish nightmare that can otherwise ensue. However, some sites actually blend the search feature with weird navigation systems or even use the search results as a way to list certain product categories that they then link to. The best solution is to fix the site IA and make this a non-issue but it isn’t always as easy as it should be.

Furthermore, you may find a lot of people linking to search results pages, and in some cases you may want them indexed.

Well, HTML5 provides a quick and easy way to let Google know what is going on...

<a href=’/search.php’ rel=’search’>Search the site</a>

This lets the search engines know that the target page is a search engine, and not to sound repetitive but that is a really helpful signal you can be providing the search engines and will take all of 20 seconds to add to each necessary link. Whilst you are there you may want check out which allows for some seriously cool stuff - including letting browsers discover your search feature and incorporate it directly into the browsers search bar.

Actions: Add rel search to all links to any on site search features.

Problem 4: Microformats !=

Issues: social sharing, SERP CTR, rich snippets

Microformats and RDFa are two forms of embedding machine readable meta data into our web page that are both quite well known in the SEO community. Microformats and RDFa have seen a marked uptake in use since Google introduced rich snippets in 2009, allowing SEOs to add some bling to their SERP listings:

rich snippet example

Microdata is another such format, and is part of the HTML5 spec, but has remained somewhat in the shadows and hasn’t seen the widespread adoption of the others.

More recently there was the announcement of from Google, Bing and Yahoo. Along with plenty of excitement this seems to have caused some confusion with many SEOs thinking this to be a new format. is not a format or a language in itself, but it actually a vocabulary which the search engines have all agreed to understand and respect. It lays out what types of entities and attributes you can insert into the metadata on your web pages and guarantees that all the engines will understand these.

BUT, and here’s the rub....

The vocabulary is only available to those speaking in the microdata format.

You cannot use it with Microformats or the RDFa format currently. The engines say this will change in time, but in the meantime if you want to take advantage of the vocabulary you need to use HTML5’s microdata.

The site itself has plenty of details on how to use microdata and put it on your webpages, so get over there and get reading.

Luckily, you aren’t forced to decide between these formats, and Google have confirmed that it is ok to have these different formats on the same web page marking up the same metadata. So even if you have Microformats or RDFa you can still employ Microdata with, and I encourage you to do that. I do imagine, though, that Google are going to start showing a preference to metadata using the vocabulary.

Actions: Include Microdata alongside Microformats and RDFa you already have. Look for further opportunities to use these formats.

Problem 5: AJAX and URLs

Issues: accurate indexing, social sharing, juice flow

This one is well known and disliked by pretty much every SEO that there ever was. AJAX sites are really nice for users and improve the user experience greatly.... right up to the moment the user tries to bookmark the page they are on, or email it someone, or share it via social media, or use the back button, or find the page in their history the next day.

AJAX and SEO simply were never designed to mix, and now we are in a world where people want both. If you have somehow managed to avoid this problem and aren’t aware of is then I’ll briefly outline it... AJAX allows a webpage to, via the use of javascript, update the contents of a page without actually reloading the page; a new HTTP request will be sent and the new content will probably replace some old content on the page but because the page does not reload the URL does not change.

The traditional method to address this to ensure the Googlebot can spider the content is simply to ensure the AJAX calls are hooked to traditional <a> tags so you can include an href to a version of that same content which Google will pick up (and far too often even this hasn’t been done - meaning the content is stranded and will never get indexed). This is fine for the crawling aspect of SEO, but nowadays we need to consider the fact that social shares are an important aspect of SEO too and if the user can’t copy and paste the correct URL then you are already handicapped.

So, you guessed it, HTML5 comes to the rescue by providing some new DOM features that we can use with javascript to dynamically change the URL in the address bar without reloading the page. This is in the form of history.pushState() and its associated methods (replaceState() & popState()):

var stateObj = { foo: "bar" };
history.pushState(stateObj, "page 2", "bar.html");

Not only does history.pushState() allow us to update the URL on the fly, but it pushes these new URLs to the browsers history, so the user can use the back button as expected and find the page in their history later on.

Check out this demo of demo of HTML5 pushState.

Unfortunately, IE does not yet support pushState even with IE9 and so you cannot completely forget about using horribly workarounds that use the #, but luckily there is a pre-built solution that does the fallback for IE for you. You shouldn’t let the fact that this cannot work on IE put you off integrating it for the other browsers though; it is better to allow these improved features for some users than none at all.

Actions: The next time you are involved with the design stage of an AJAX site integrate PushState into the solution. Also consider refactoring the AJAX content you already have.

Wrap up

HTML5 hero and IE menace fightingHTML5 and the related technologies are incredibly exciting for SEO, users and the web as a whole. However, it is still going to be quite a while before there can be widespread rollout of many of the features mostly thanks to the fact that even the latest version of Internet Explorer doesn’t even attempt to support some features.

However in the meantime, there are certainly parts that can be used for SEO and parts that can be used for user features, and I encourage everyone to adopt these where possible. If there are certain features you want to roll out for those users who have modern browsers, whilst still supporting those using versions that lack that feature you should check out this extensive collection of cross-browser HTML5 fallbacks.

Where next?

For my part, I’m wondering what extensions the search engines themselves might offer once HTML5 sees wider adoption. Now that Google+ posts are showing in the SERPs, likes Tweets before them, we are seeing a migration away from ‘web search’ meaning searching web pages, and more towards it meaning searching web information. Maybe we will soon see a day when we can use rel canonical on the
<section> and
<article> type tags, which would truly allow us some flexibility without being niggled with doubts about duplicate content.

Then there is WAI-ARIA, a separate specification dealing with web applications, but which is accounted for in HTML5. With it’s ‘role’ attribute we are taking the first steps towards being able to tell crawlers about our web pages’ behaviour and not just their content.

The thing I do know is that HTML5 is coming, and every SEO needs to get up to speed. If you can start not only learning HTML5 now, but already deploying aspects of it then you are going to be well placed when the full force of HTML5 hits the web. See you on the other side!

Tom Anthony

Tom Anthony

Joining Distilled as an SEO, Tom comes from a background in freelance web development. With a degree in Computer Science, a PhD in Artificial Intelligence (almost – he is still writing his thesis!) and having taught himself to program on a BBC...   read more

Get blog posts via email


  1. Your comment on WAI-ARIA is interesting - since its main purpose is to increase accessibility of dynamic content and controls for disabled users (who frequently use methods of browsing the internet that just aren't compatible with such websites - voice browsers, sight impaired browsing, etc); rather than using it for telling bots and crawlers what a page does.

    Are there any live examples of crawlers using ARIA attributes to determine the behaviour/meaning of web content (dynamic or not)?

    reply >
    • Hi Graeme,

      I'm not aware of any examples of crawlers using ARIA attributes currently; it is more a prediction of what may happen in the future.

      Remember that the alt attribute was originally for screen readers, and then became a key indicator for the crawlers. I imagine that the same thing may happen ARIA attributes.

  2. Hi Tom!

    Nice post! I really hope search engines start taking into account more and more HTML 5 and the standard, specially in the page structure definition and the pagination issues (I cannot find a really clear solution to this problem :/)

    Regarding the problem number 4 (microformats and, I have some questions:

    I understand you recommend to use both microformats/rdf and the new microdata from, and mention that Google said that it is ok to have both in the same webpage, but in the post they used to announce, they don't recommend to do this:
    3) We’ll continue to support our existing rich snippets markup formats.
    If you’ve already done markup on your pages using microformats or RDFa, we’ll continue to support it. One caveat to watch out for: while it’s OK to use the new markup or continue to use existing microformats or RDFa markup, you should avoid mixing the formats together on the same web page, as this can confuse our parsers.

    Do you have another resource of information where they state that it is ok to use both? If you do, that would be fantastic! :)

    Do you have examples of sites with reviewswhich already implemented the standard in their pages and that are showing up the starts in the SERPs (only with

    Thanks in advance!

    reply >
    • Hi Christian!

      You are absolutely right - when they initially announced they did state that you shouldn't be including the different formats on the page.

      However, there was a bit of a backlash and they later retracted that - you can read this discussion from SemTech 2011 where Kavi Goel, a product manager at Google, responds to a question regarding this and says it was a mistake and they are fixing it. :)

      I'm glad they saw sense on this front, as it would have really sucked if they had shut people into one format when everything is still so up in the air.

  3. Thanks for the quick answer, Tom!

    That's really good news, so we can test/use microformats/rdf and on the same page. Anyway, I hope they announce this officially on their blogs, too.

    Regarding my other question, I'm trying to find examples of webpages using the new sintaxis for reviews and ratings which are showing the stars on the SERPs and showing them on the validator too. I've found an example of a site using for that, the validator detects all the data but in the validator's preview the stars don't appear (and neither do they on the SERPs.) Do you know any example of this?

    reply >
  4. This is a great post! I hope that html5 will help to eliminate pagination issues!


    reply >
    • Thanks Paul. I'm hoping it eliminates all sorts of problems! Even if it doesn't solve all the problems I wish it would, which it won't, it will help to organise the web's growing mass of information a bit more.

      I'm really hoping that those sites that do employ it see a good boost in the search engines, so that it drives further adoption. I think HTML5 provides a lot of value other than SEO, and widespread adoption would be a really good thing for the web.

  5. Myles

    Hi Anthony,

    Quick question regarding the use of there an example of Google using this data in the SERPs? I have a wealth of data I need to put into a microformat but doesn't appeal at the moment as I haven't seen Google use it. I appreciate this might change but as far as I know only other microformats are proven to be used by Google.

    reply >
    • Hi Myles,

      I'm not aware and couldn't find any example of Google using in the SERPs - only Bing in the example I pointed to in the comment above.

      However, I think it is a pretty safe bet that Google will start using this data in the SERPs pretty soon. My suggestion is to use microdata along with Microformats and/or RDFa.

  6. Hi Tom,

    Interesting post!

    On a scale of 1-10 how important would you say these 5 items are to a great ranking on Google and having a site that converts well?

    Thanks Doug

    reply >
    • Hi Doug,

      Oh- that is a tough question! Not least because this is very new stuff so we don't have much data on how Google are using it, and because they are also likely still deciding themselves and changing stuff fairly often, trying stuff out.

      In terms of getting great ranking in Google currently, there should be a lot of things on your SEO todo list before worrying about most of these things.

      Furthermore, most of what I've suggested here won't cause you rank, it'll just remove some of the hurdles that might prevent you from ranking so well because of crawling issues.

      So provided you're doing SEO on your site, and want to streamline the ease of crawling, I'd suggest the following order for HTML5 oriented updates:

      1) The rel attributes for Pagination and Search pages are super quick and easy to do, so are a no brainer.

      2) If you have microformats on your pages already, it shouldn't be overly complicated to include microdata using the stuff.

      3) If you have AJAX content with different sections that each have canonical URLs, I'm an advocate for pushState making it a much nicer user experience and for making it easier to share.

      4) Unless you are having known issues with segmenting your page content, I'd put this as your last item to do. It will take a fair bit of time and planning to refactor pages, and they all need doing.

      Make sense? Thoughts?

  7. Thanks for the info, Tom.

    Unfortunately none of those examples are showing the rating stars on the Google SERPs nor on the Webmasters Tools Validator.

    Anyway, as long as it is ok to use both microformats/rdf and we can test and wait until google starts using to show more information on the serps.

    reply >
    • Hi Christian,

      Yeah - Google don't seem to be using it yet. However, with rich snippets already widespread I cannot imagine it'll be long before they are.

      As you say, because you can us microformats/rdf too you lose nothing by also including microdata on the same pages, and you'll be ready when Google do start using it more actively.

      It's a real shame they haven't got their tools up to speed though. Very frustrating when they lay out stuff like and then don't bother having their tools ready.

  8. Tom, thanks for the excellent post. You've raised up some great advice.

    reply >
  9. Steve

    Very intereting and useful information.
    Good to hear someone advocating use of HTML 5 now and not complaining because of lack of support from IE-just saying this is how to fix it.
    It's far better I feel to have these new schemas, HTML elements etc understood and in place before they are fully used by the search engines, it puts you ahead of your competitors who may not be as fast as you to take on the new technology.

    reply >
  10. Hiya Tom. What do you think of the Ajax crawling scheme (see following Google URL) as a solution to Ajax URL issues?:

    reply >
    • Hi Mark,

      Good question. To be honest, I'm not a fan at all of the #! style AJAX URLs. It is fraught with problems for both the user (the back button, history etc.), and also for SEO (canonical URLs). What I think is good about it is that Google want to find a solution to this and were helping to provide a solution that people could use.

      In summary, I think the #! URLs are a well intentioned hack which provided a half solution that was available in the interim, whereas pushState() provides a far more comprehensive solution. I think pushState() will start to see far more uptake in the coming months, because the SEO and User Experience benefits are numerous and the fallback for IE means there aren't much in the way of downsides.

  11. Thanks Tom

    I haven't used either pushstate or #! crawling scheme. So I can only theorise and look at the examples available. And theory and practise are different things, of course.

    I'm amused by the Heath Robinsonish way Google's #! scheme works. It's almost like it uses pullies and ropes. More seriously it's clearly a bit of work to set-up. But (if you read them all) G's docs give a detailed write up and we can see it working well on this demo:!CwBasicButton

    Back button and history work fine, btw. So apart from its clunkiness back-end, what's it not doing?

    Not sure about Twitter's implementation of #!. I don't get why they are using it when no new URL appears. I'm sure they have a good reason. See:

    Pushstate is elegant compared to #!. But I haven't read a clear and detailed write up and the demo you link to doesn't work for me on FF/OSX!

    reply >
    • Hi Mark,

      Thanks for sharing those links, and examples! :)

      The # example you link to doesn't work for my browser history (Safari) - thought it did work when I just checked it in Chrome and FF.

      I also just checked the HTML5 pushState in FF/OSX and true enough it doesn't work right. However, our very own Rob @ Distilled has an example site also:

      And that does work for me in FF/OSX.

      I really like that Google are indexing # URLs and trying, but I detest them for many reasons. I'll add to the list problems I've seen in analytics with them, and the fact that the # portion of the URL is inaccessible to server side scripts and resources (i.e your server logs...). The mess with the Twitter URLs is enough to convince me that nobody is quite sure what to do with them.

      Given that you can easily fall back to the #! feature, I cannot really see any reason not to use pushState() where possible.

  12. Rob's URLs work well but his video reloads for me in FF/OSX. Works in Safari.

    I cannot really see any reason not to use pushState() where possible.

    I have 3 reasons:

    • I haven't yet seen enough evidence that it works consistently for users across browsers?

    • Example implementations by those showcasing it are inconsistent.

    • Nobody has yet clearly explained how to implement (those trying are lost in tech-speak and assumptions).

    reply >
    • Mark,

      Weird - Rob's video works for me in FF 5 in OS X, and FF 3.5 and 4 on Windows, and in Chrome. However 5.0.0 on Windows does seem borked.

      However, I still advocate its use. Your first 2 bullet points apply equally to me for # implementations - which have had a lot more time to be perfected!

      But , as with all these things you have to be comfortable with the solution you roll out. If you are more comfortable with the # solution are find you are getting indexed properly and users are happy then you have no impetus to change. However, I've not used an # based Ajax site that fits that bill for me as a user.

      Do you have a specific app you want to create / change over?

  13. Your first 2 bullet points apply equally to me for # implementations – which have had a lot more time to be perfected!


    And we certainly shouldn't take Twitter as our lead. I just found this lovely description by Vanessa Fox of the mess that is Twitter's URLs:

    Do you have a specific app you want to create / change over?

    No, but I like to be, if not future-proof, then future-braced :-)

    reply >
  14. Rob Ousbey

    Hi Mark, I built the pushState demo, so I thought I'd chime in.

    You're totally right: it doesn't work properly in all browser (and will not: there will always be some old browsers still installed, some people won't have JavaScript, etc.)

    However, the huge advantage that this brings with it - as you've already noticed - is that if the feature isn't available, it can easily fall back to navigating around the site as if no Ajax had ever been added. Most '#' or '#!' implementations fail for users without JS support.

    (For a production application, there's actually a possibility to do a hybrid of more than one AJAX mechanism, to cover more bases.)

    Regarding implementation: I'm not a coder or a developer at all... so the implementation really isn't too difficult. Take a look in the head of my demo, and you'll see the front-end javascript with comments. To summarize: the function
    history.pushState('', '', '/newurl'); will change the URL.

    That's the only new bit of JS that you need to get this working. I hope that helps! (In the code you'll see 'window.onpopstate' as well; as noted, this just makes sure that the 'back' button behaves as expected.)

    For technical advice, the Mozilla Deverlopers site was helpful, and there were some useful threads on Stack Overflow. Let me know if you have any other questions.

    reply >
  15. Hiya Rob

    Definitely helpful, thanks. These two points are good:.

    • it can fall back to navigating around the site as if no Ajax had ever been added
    • a hybrid of more than one AJAX mechanism is possible.

    By the way, I think I still own the domain name if you're interested.

    reply >
  16. I'm new to HTML5 but I found a cool site that has lots of HTML5 video tutorials that I found useful and others may too -

    reply >
  17. Sebastiaan

    Great post, but is it factually correct with regards to pagination using rel="prev/next"?

    Google just posted something on the same subject and doesn't mention anything about using the rel attribute on the actual <a> links in the , but advises to add an extra tag in the section instead.

    reply >
    • Yes, they recommend using <link> in the <head> section instead; which makes sense given a page should only have one prior and one following page in a sequence. I recommend you follow Google's way of doing it. :)

      When I wrote the post, I had to try to work out how Google might implement it. I am guessing they will still use my suggested method as an indicator, but I believe their suggestion is better.

  18. Wow this is great. Now if we can only get all of the IE6 people to upgrade...

    reply >
  19. Matt

    Just a heads up. Your code examples are not displaying in Chrome. Also, you may want to update the article to note Googles new rel="next" and rel="prev".

    Thanks for writing this article. I'm going to implement some of these techniques into a site I'm building.

    reply >
  20. Tks a lot for this great article ..

    Semantic, html 5, all those opaque terms are much more easy to understand now !

    reply >
  21. This is unique! Thank you for this tips. Now i can optimize my webdesgin studio :). You are great

    Best regards,

    reply >
  22. Hi Tom,

    It took me awhile but I am back. I really appreciate the time and thought that went into your answer to my question about ranking and to-do priorities.

    As far as I am concerned you are spot on. I was thinking along the same lines, but I like to get the ideas and thoughts of others. I find that for me anyway, it easy to latch onto and follow an idea and/or concepts down the wrong paths on occasion.

    As result I like to touch base with colleagues whom I respect to make sure I am not heading off into no mans land.

    Again thank you, and keep up the awesome work!


    reply >
  23. Bing Webmaster Central will show warnings for documents that have multiple h1 elements as a high impact.

    reply >
  24. Excellent article. Cleared up a lot of questions I had about HTML 5.

    reply >

Leave a Reply

Your email address will not be published. Required fields are marked *


You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>