Steve Jobs was recently quoted as saying “No one will be using Flash. The world is moving to HTML5″ igniting interest in HTML5 and sparking numerous debates online in blogs and forums.

Jobs’ prediction that flash is dead invokes memories of the famous Mark Twain quote “reports of my death are greatly exaggerated”. While the debate rages on over the future of Flash, HTML5′s destiny is assured.

It’s not just Apple pointing to HTML5 as an internet revolution, Microsoft, Google, Opera, Mozilla, W3C and even Adobe themselves agree. In fact HTML5 may become historic for that very reason. It is arguably the only time Google, Microsoft and Apple have ever agreed on anything.

How HTML5 evolved was largely due to a disagreement with the W3C over Error Handling and the failure to embrace modern Internet applications. In 1997, W3C announced it would no longer extend HTML4 and saw XML and XHTML as the future. Draconian Error Handling, (Draco was the Greek leader that issued death penalties for minor offences), instructed that browsers were to treat all errors in XML as fatal. With 99% of web pages showing minor errors, and the lack of new features in XML, many webmasters ignored the new standard or continued to serve their websites as HTML, even when adopting XHTML.

In 2004, a group of developers and browser vendors including Apple, Opera and Mozilla gave a presentation to the W3C on evolving HTML4 to include new features for modern web applications. The W3C rejected their proposal of extending HTML and CSS. Those interested in evolving HTML4 rebelled and broke away from the W3C, forming their own working group called WHATWG (Web Hypertext Applications Technology Working Group). At the core of the WHATWG beliefs was backwards compatibility and forgiving error handling. WHATWG’s vision was to extend HTML features including form handling while ensuring that it would degrade gracefully in older browsers. While the W3C wanted the world to move to a new standard XML, WHATWG planned to evolve existing HTML to support a modern Internet.

In 2006, Tim Berners-Lee, the founder of the W3C, recognized that the rebels at WHATWG had gained momentum and announced that the W3C would work together with WHATWG to evolve HTML. The W3C HTML Working Group was formed, working with HTML in conjunction with XHTML. HTML5 was officially born. In October 2009, W3C shut down XHTML2 making HTML5 the future of the Internet. The pirates had taken over the ship.

HTML5 marks a change in attitude from the W3C and seeks to support the diversity of HTML rather than just enforcement of web standards. It is an incredible achievement that HTML5 is backward compatible, meaning most of HTML5 can be used straight away albeit with some JavaScript hacks on semantics for IE. Ideas from W3C, Apple, Microsoft, Google, Mozilla, Opera and many other experts combine to pull the best bits out of HTML and browsers past into an exciting upgrade of the HTML language that promotes inclusion not exclusion.

In many ways HTML5 simplifies web pages, taking laborious tasks such as form validation away from web authoring and into the browser. The idea of making the browser do the work probably stems back to IE3, where Microsoft provided the first browser to build in CSS support. HTML5 introduces new tags for page structure and semantics of documents.

New markets in Typography are opening up with the implementation of “@font-face”, meaning designers at last can transfer the visual appeal of print to the web thanks to advances in CSS and HTML5. Large JavaScript libraries such as MooTools and JQuery can be slimmed down as HTML5 transfers many common tasks directly into the browser. Client side storage, session storage and client side posting are set to change how we communicate on the web. Web applications such as video are embedded by HTML without the need of JavaScript. Sites will begin to move away from Flash to deliver their video and onto HTML5, especially when current codec concerns with Mozilla Firefox are resolved.

New HTML5 API’s, such as drag and drop, are reverse engineered from Microsoft, ensuring that they are supported from the start by IE. What developers of HTML5 such as Ian Hickson (Opera) have done is to view the modern web and say, “OK that’s what people are trying to do, how can HTML5 support that”.

Unlike previous web standards based releases such as XHTML 1.1 and the never finished XHTML 2.0, HTML5 is backward compatible and is here to stay. With the involvement of people that have been critical of the W3C, HTML5 brings a standard based upgrade of HTML that is fully supported throughout the industry. HTML5 will genuinely future proof your site without the danger of your markup depreciating in a couple of years.

HTML5 timetable for completion is in 2022, which has left many webmasters confused as to its relevance now. However, any website can begin using the new specification immediately by simply changing the doc type to “< !DOCTYPE html>“, the lowest number of characters required to trigger standards mode in IE. Currently, only beta versions of browsers IE9, Chrome, Safari, Firefox and Opera support advanced HTML5 elements. However, typography “@font-face” is fully supported in current browsers. For more information have a look at Ethan Dunham’s “FontSquirrel.com” and Jeffrey Veen’s “Typekit.com”. Other HTML5 features such as “Drag and Drop” and “ContentEditable” are also currently supported. You can follow the implementation of HTML5 in modern browsers at “HTML5Readiness.com” and “Caniuse.com”.

Further information:

http://www.whatwg.org

http://diveintohtml5.org

http://dev.w3.org/html5/spec/Overview.html

Author: Jennifer Robinson

You have a beautiful website with great products, great guarantees, many comprehensive pages and great customer service. Unfortunately, Google and other search engines won’t give your website high rankings.

There are several reasons why search engines do not list websites although they look great and offer quality content:

1. Your web pages are meaningless to search engine spiders

Search engines use simple software programs to visit your web pages. In general, search engine spiders won’t see anything that is displayed in images, Flash elements, JavaScript (except for a few exceptions) and other multimedia formats.

If the main content of your website is displayed in images or Flash then your website can be totally meaningless to search engines. If your website navigation is pure JavaScript then chances are that search engines won’t find the pages of your website.

Your website will look like a single page site although it consists of many different pages.

Solution: Check your website with IBP’s search engine spider simulator to find out how search engine spiders see your website.

2. The HTML code of your web page contains major errors

Most web pages have minor errors in their HTML code. While most search engine spiders can handle minor HTML code errors, some errors can prevent search engine spiders from indexing your web pages.

For example, a tag at the top of your web pages could tell search engine spiders that they have reached the end of the page although the main content of the page has not been indexed yet.

Solution: Verify the HTML code of your web pages with an HTML validator tool. You can find an HTML validator in the free IBP demo version (IBP main window > Tools > HTML Validator).

3. The HTML code of your web pages doesn’t contain the right elements

If you want to get high rankings for certain keywords then these keywords must appear in the right places on your web page. For example, it usually helps to use the keyword in the web page title.

There are many other elements that are important if you want to have high rankings. All of them should be in place if you want to get high rankings.

Solution: Analyze your web pages with IBP’s Top 10 Optimizer. The optimizer will tell you in detail how to edit your web pages so that they will get top 10 rankings on Google and other major search engines for the keywords of your choice.

4. Your web server sends the wrong status codes

Some web servers send wrong status codes to search engine spiders and visitors. When a search engine spider requests a web page from your site then your server sends a response code. This should be the “200 OK” code.

Some servers send a “302 moved” or even a “404 not found” response code to the search engine spiders although the web page can be displayed in a normal web browser.

If your web server sends the wrong response code, search engine spiders will think that the web page doesn’t exist and they won’t index the page.

Solution: Use the search engine spider simulator mentioned above to find out which response code your web server returns to search engines. If the response code is not “200 OK”, the spider simulator will return a warning message.

5. Your robots.txt file rejects all search engine spiders

If your robots.txt file does not allow search engine spiders to visit your web pages then your website won’t be included in the search results. Some robots.txt file contain errors and search engine spiders are blocked by mistake.

Solution: Check the contents of your robots.txt file. In general, it is not necessary to use a robots.txt file if you don’t want to block certain areas of your website.

Search engine spiders must be able to understand your web pages if you want to get high rankings on Google, Bing and other search engines. The tips above help you to make sure that search engine spiders see what you want them to see.

At the end of the year, many businesses start to think about redesigning their tired old website to breathe some new life into it. You may even be in the midst of a website redesign right now. If so, the first thing is to make sure you hire a design and development company that knows how to build the infrastructure of the website in a search engine crawler–friendly manner.

Beyond that, you need to address a number of additional SEO tactics before you get too deep into your redesign. The reason you need to keep SEO front and center during this time is twofold: so that you do not lose your previous traffic, but also so that you can gain additional targeted search engine visitors when the new site goes live.

Here are 6 SEO redesign secrets your developer may not know…ignore them at your peril!

1. Creating Your SEO’d Site Architecture

Search engines look explicitly at how all your pages are linked together in order to determine their place within the site. Pages that are linked from every other page will be given more weight than those that are only linked from a few others. This is all considered a form of internal link popularity, or in Google language, internal PageRank.

Recommendation: During your redesign, don’t bury too deeply within the site any content that was previously bringing targeted search engine traffic. Ensure that any informational content that will be focused on the more competitive keyword phrases (for example, product and service pages) is high up in your site hierarchy.

In addition, all content contained in a specific category should be cross-linked via some sort of sub-navigation within that section.

2. Categorization and Avoiding Duplicate Content

When people are seeking information from a search engine, they usually have a question, a problem, or a need for specific information. The search queries they use at Google and the other engines reflect this. The more ways you can categorize your content for the various target markets you serve, the better.

Recommendation: Be sure that all top-level pages answer the potential searcher’s (your potential customers’) questions, and that it’s clear that your products and services can solve their problem. In addition, you also have to ensure that regardless of how someone found any piece of content on your site, they always end up at the same URL to avoid PageRank splitting and duplicate content issues.

For example, if a specific product can be classified as both a product and a service, it makes sense that it might be listed under both categories. However, the page (URL) that the potential customer eventually lands on, regardless of which category they started in, should always be the same.

3. New Content Management System and Changing URLS

If URLs must change in the redesign due to a new content management system or back-end coding, search engines may take some time to index the new URLs as well as give them the same weighting they gave the previous URLs due to URL age factors.

Recommendation: It’s critical to 301-redirect all old URLs to their relative counterpart within the newly designed website. This will pass the link popularity of the old URLs to the new ones quickly, as well as ensure that site visitors don’t receive 404-not-found errors.

This will be easier if the new URL naming is similar to the old one, because you can use automated methods. If URLs must change completely with no correlation to the names of the old URLs, and hand-redirects are required, you’ll want to at least redirect all the top-level pages, as well as those that you’re sure receive keyword traffic from search engines. But, ideally, every URL should be redirected if at all possible.

4. Coding of Navigation Menus

Links contained within the navigation of your website should be coded in a search engine–friendly manner so that they are visible and crawlable. Some DHTML and Flash menus are invisible to search engines, which causes the pages linked within them to not receive the internal link popularity they should receive.

Recommendation: Make sure all navigational menus are coded with CSS that is visible to search engines. In addition, avoid drop-down box links as the main form of navigation (CSS mouseovers are fine). You’ll also want to ensure that all content can be reached by hard-coded links – don’t force the user to go through any kind of search box menu because those are traditionally search engine unfriendly.

5. Custom HTML Elements

While some level of automation for titles, metas, headers, URLs, and alt attributes for images can be helpful, it’s critical that your new website’s content management system allow you to create custom descriptions for these as well.

Recommendation: Make sure the content management system has fields for custom title tags, meta descriptions, heading tags, etc. There should be no limit to the number of characters allowed in these fields either, because every page may need a different number of words and characters.

6. Session IDs and Other Tracking Links

It’s best not to use session IDs to track visitors, but if your system must use them, you’ll only need to feed the “clean” URLs to the search engine spiders – otherwise, they may get caught in an infinite loop, indexing the same content under multiple URLs.

You’ll also want to avoid any sort of campaign tracking links appended to URLs because these can split your link popularity by causing your content to be indexed under multiple URLs.

Recommendation: If this type of tracking is inherent in your system, use the canonical link element to maintain one URL for every page of content.

Don’t be surprised if your developer isn’t happy to receive some of these “secrets.” He or she may feel that their authority is being usurped or their creativity is being hindered. Just remember that it’s your website that you’re paying them to create in a way that will make you the most money possible. Let your developer know up-front that these things are non-negotiable. If they tell you that they can’t do any of the above, start looking around for a new developer – ASAP!

While there will always be a few unexpected bugs to work out when your site goes live, you won’t have to be afraid of losing your search engine visitors as long as you know what you’re doing. We’ve successfully helped many companies through this transition without any glitches. At the end of the process, there’s nothing like the feeling of having your beautiful new website launched. But more than that, there’s great comfort in knowing that the people looking for what you provide will continue to be able to easily find you in the search engines.

Author
Jill Whalen