There is no doubt that Flash creates many issues when it comes to search engine optimization.  As you probably know, Flash files are similar to interactive movie files.  Even when there is textual content inside of Flash files, the text probably will not be indexed by the engines.

A webmaster may or may not know about the various tactics that can be used to compensate for the SEO issues that are created when Flash is used.  They may be more likely to know best practices for graceful degradation from a user interface perspective than from a SEO perspective.  These user interface best practices can help with SEO issues as well, as long as they are implemented correctly.

SWFObject

The SWFObject is essentially a small JavaScript file that detects whether a users browser has Flash installed.  If the user has Flash, then the Flash file will load and the user will be able to engage in the rich Flash experience.  However, if the user does not have the Flash player installed, the SWFObject can be set up to show HTML content in place of the Flash file.

This type of graceful degradation is important to search engines as well as to humans.  Because search engines are not effective at indexing Flash, and since they will not execute JavaScript, the SWFObject allows replacement HTML content to be shown not only to human users, but to search engines as well.  Google has come out and said that use of the SWFObject is an SEO best practice, as long as the replacement content mirrors exactly the content in the Flash file.

Low Speed Pages

Sometimes, Flash developers may use what are called low speed pages as a way to provide graceful degradation for non-Flash users.  What are low speed pages?  Very simply, they are pages designed to be smaller in file size, and thus, load faster.  Generally, low speed pages are HTML versions of their Flash counterparts.  Low speed pages originated back before broadband was widespread.  This way, users with Flash could view the larger and bulkier Flash pages, while users who didn’t have Flash or who couldn’t load it quickly enough could use the low speed pages.

Wait a second, you are surly saying.  Why are developers using low speed pages if they can just use SWFObject?  The reason is because the original intent of low speed pages was, and to a increasingly smaller percentage of internet users still is, to provide a page that is quicker to load than a larger Flash file.  But now that high-bandwidth broadband access is available to more and more users, the need for a low speed page is decreasing.

Still, that doesn’t mean that developers have stopped using low speed pages.  After all, there are still users out there that do not have broadband access, or may be visiting your site from a mobile device, and the low speed pages work well for those users.

If you are doing search engine optimization on a site that has Flash as well as low speed pages that mirror the Flash pages, you need to check to see which page, the Flash version or the low speed version, has the better chance of ranking in the SERPs.

For a smaller site, the low speed version may have an easier time ranking, because there is little external link equity which means the search engines have to rely more heavily on internal factors to determine what a page is about.  In this case, you will want to add a meta noindex tag to the Flash version of the page.

On the other hand, for a larger enterprise level site, there may be much more external link equity for your Flash pages.  This is not always the case, so make sure to do a backlink report before you start making changes.  If you do determine that the Flash pages have significant link equity, while the low speed pages do not have as much link equity, you may make the decision to put a noindex tag on the low speed pages, despite the fact that they have better on-page optimization.  The low speed pages will still be entirely available to the user, but will not be indexed by the major search engines.

The Best of Both Worlds

In the end, you can use both Flash pages that use the SWFObject as a graceful degradation method, as well as low speed pages.  The content can be the same in both the Flash version, the HTML SWFObject backup, and the low speed pages, as long as the low speed page has the noindex tag.  However, if you want the low speed page to be the page that ranks, then you will need to take steps to make sure that the content is different enough to not create duplicate content issues with the Flash page’s SWFObject backup content.

Still, the situations where you would want the low speed pages to rank are increasingly rare.  With the SWFObject, and by putting your JavaScript and Flash in external files, you can effectively minimize the file size of your primary Flash page and deliver HTML content to users that do not have Flash installed and to the search engines.

I really like the use of tabs to present content to users.  I think it’s a great way to take advantage of limited screen real estate on a web page.  However, there are some important things you need to consider for SEO if you are going to use tabs to present content to a visitor.

How Focused is your Content?

That is the first very important question you need to ask yourself.  In most cases, if you are considering using tabs, each tab will likely be presenting content that is substantially unique.  If each tab is presenting content that really has the ability to stand on it’s own with regard to search engine ranking, then you want to make sure that you design the architecture of the page so that search engines can rank each instance of content individually.  Otherwise, you run the risk of diluting your ability to rank for anything if you don’t present the content to the search engines individually.

On the other hand, perhaps the content within each tab is focused on one specific topic.  In a case like this, you will want to present the content so that the search engines read all of the content as a singular source.

Presenting Each Tab Individually

In the majority of cases, this will be how you will need to present tabbed content.  Otherwise, you will run the risk of diluting your page to the point that you won’t have a strong chance of ranking for your targeted phrases.

Individual Pages

There are a couple of ways to present the content in this case.  Perhaps the easiest way is to program individual pages, where each page shows the selected “tab” as being on top and displaying content.

This method allows the content to exist on individual URLs, meaning that the search engines can index, and rank, each page individually.  It also means that each page of “tabbed” content can be deep linked to.

There are a lot of negative implications that need to be considered with this method.  The first is that when a tab is clicked, an entire new page must load, potentially making the user experience worse.  Also, as is often the case, you may have content on the pages that are identical outside of the tabbed content, such as an introductory paragraph.  Remember that if your tabbed content is relatively minimal, the search engines may index your pages and identify them as being duplicate content.

Javascript and URL Parameters

Another solution that can be faster from a user experience perspective is to use unobtrusive JavaScript to show and hide each tab.  In this scenario, the HTML content is contained within the page source code, while the JavaScript is called in from an external file.  This means that the JavaScript can execute for the user to enhance the site functionality, while users without JavaScript (including search engines) will still be able to see the HTML content.  You will also want to call the JavaScript function so that it offers a static link that passes a URL parameter (i.e. www.ericpender.com/blog/example?foo=2) as opposed to a URL fragment (i.e. www.ericpender.com/blog/example#foo=2).  This is because search engines typically ignore anything after the #, but will follow anything after a ?.  By using a URL parameter, the search engines will see each instance of tabbed content as a new page, even though from a user perspective the entire page will not be reloading.

Presenting Each Tab Collectively

Although not as likely, you may come across a situation where you want to present information in tabs, but you want all of the content in the tabs to be presented as one singular document to the search engines.

JavaScript with Fragments

This method is identical with the JavaScript method listed above except for one very important component.  Instead of using a static link when calling the JavaScript, you will use the URL fragment instead.  The user experience is the same, but the search engines will truncate anything after the # in the URL, so that it will view all of the tabbed content as existing on a single page.

Link rel=”canonical”

So far, we have covered different ways to present tabbed content to users, ways for that tabbed content to be deep linked to from other pages, and ways for the content to be viewed as a different pages within the search engines as well as being a singular page.  However, that still leaves us with one scenario.

Let’s say you want to use JavaScript to present tabbed content to a user.  You also want the search engines to spider the tabbed content as a single document (not as many individual pages).  Your programmers used the URL ? parameter instead of the # fragment so that the tabs could be deep linked.  The problem, however, is that because of the ? parameter, the each URL will be recognized as a new page.

The solution in this case is to use the link rel=”canonical” element.  This allows for the ability of the tabs to be deep linked, while telling the search engines that each of the URLs are actually duplicates of the URL without the parameter.

Tabbed content is a great way to present content to users, and can be very effective for SEO when done correctly.  Remember to ask yourself if each instance of tabbed content can stand on it’s own, and then employ the correct method of programming depending on the answer.

Additional resources:

• AJAX and Non-JavaScript Experiences for SEO friendly websites
• A spider’s view of Web 2.0
• Hijax: Progressive Enhancement with Ajax

I just finished watching a video from Matt Cutts about the new canonical link element, and in the video he ran through a checklist of how to fix/avoid duplicate content issues.  All of these come from the video, so I really have to give all the credit here to Matt, but I felt these were worth mentioning.

Before we talk about the ways to fix duplicate content issues, let’s talk about why duplicate content is bad for search engines.  At a very high level, search engines look at duplicate content as a form of web plagiarism.  If two sites have pages with exactly the same content, the search engine will try to figure out which page has the most authority and trust with regard to the topic.  This is because they only want to serve one version of the content in the search results, since users really only need to see one version of the exact same content.

Duplicate content, however, is often a serious site architecture issue within a single site.  Duplicate content can exist within a site for a variety of reasons, sometimes as the result of using session IDs, tracking parameters, breadcrumb trails, etc.  In these types of cases, we are really just cannibalizing our own success with these duplicate content issues.

In his video, Matt Cutts described a variety of ways to fix duplicate content issues.

1. Customize CMS systems or sites in the beginning – By customizing a CMS system to only produce the URLs that you want, you can prevent a lot of duplicate content issues before they even start.
2. Link only to one version of a page – Google finds new pages and new sites by scanning existing web pages, identifying links to other pages, and then spidering those pages.  If you only link to one version of a page, a search engine can (theoretically) only identify that page from that singular URL.  Of course, in practice this is incredibly difficult, since you cannot control how other sites will choose to link to your site.
3. Use 301 redirects – Most of the time, this is probably going to be the most likely method to realistically fix duplicate content issues.  Using a 301 redirect tells Google that a given web page has been moved to a different URL.  The user, search engines included, will be redirected to your specified URL, thereby not seeing the duplicate content.
4. Webmaster Tools – Webmasters can use Google’s Webmaster Tools to specify which version of the top level domain you wish to show to users.  While this allows you to specify either a www or non-www preference, thereby solving duplicate content issues at the domain level, it does not really solve duplicate content issues at deeper levels (for example, if the duplicate content is the result of tracking parameters).
5. Use site map to list preferred URLs – Webmasters can submit an XML site map to Google to show the search engine which URLs are the preferred URLs on the site.
6. Use the canonical link element – Much like a 301 redirect, the canonical link element allows webmasters to specify to the search engines which page is the preferred page and which page contains duplicate content at a page-by-page level.  To use the canonical link element, place the element in the head section of the page code for the non-preferred page.  Then, use the element to specify the URL for the preferred page displaying the content.

So what’s the difference between using a 301 redirect and using a canonical link element?  The 301 redirect will actually redirect the user to the preferred page on your site, bypassing the non-preferred page and resulting in the preferred page’s URL resolving in the users browser.  The canonical link element will not redirect the user, but will simply tell the search engines that this specific page is the non-preferred page with very similar or identical content that can be found on another page on the site.

Let’s say you are a widget maker, and you just came out with your shiny new 2009 widgets.  Since the 2009 widget is pretty much the same as the 2008 widget, and you completely sold out of your stock of 2008 widgets, you have decided to simply replicate your marketing copy from the 2008 widgets page to a 2009 widgets page.  Your site is not dynamically creating the page, and you aren’t using session IDs or tracking parameters.  In this case, you will probably be best using a 301 redirect from the old 2008 widgets URL to the new 2009 widgets URL.

However, if you were dynamically using tracking parameters to create the landing page, or needed to pass through some session IDs in order to track the user, you would probably want to use the canonical link element.  This is because you still want to maintain the tracking through the site, while still letting the search engines know that the session IDs are creating duplicate content.

Hopefully this helps to offer some insight on how to fix duplicate content issues, as well as to clear up any confusion on when to use the new canonical link element versus a 301 redirect.  Remember, if you can take some steps to reduce the possibility of duplicate content issues early on, you’ll be helping yourself out tremendously.  But if you can’t, there are a handful of different ways to make the fix.