How Flash Can Be Search Engine Friendly

For a long time there has been a tug of war between developers and designers who love to use Flash and SEOs who know how bad Flash can be from a search engine crawler perspective. The designer wants the beauty of an all Flash site. The SEO wants to bring the site traffic. It’s a tough situation, but there are ways to implement Flash and still provide something for the crawlers to chew on.

Scalable Inman Flash Replacement (sIFR)
sIFR is a technique that uses Javascript to read in HTML text and render it in Flash instead. The essential fact to focus on here is that the method guarantees that the HTML content and the Flash content are identical. The intended use for this is to render text in an anti-aliased font. This can provide a great improvement in the presentation of your site.

Don’t make too extensive use of the technique. According to sIFR’s creator, Mike Davidson, you shouldn’t try to redo your whole page with sIFR. He says that “sIFR is for heacdlines, pull quotes, and other small swaths of text.” Overuse the technique and suddenly your page will take a long time to load.

How do search engines view this? In July of 2007, Google’s Dan Crow went to a Search Engine Marketing New England (SEMNE) event. Dan, who is head of Google’s crawl team, said that as long as this technique is used as it is intended, that Google was fine with it.

The key thing that drives this statement is that the HTML version of the text is the input used by sIFR to create its output. It is not possible for them to be different. For this reason, this technique is not susceptible to spamming, and there is no reason for a search engine to worry about its implementation.

SWFObject
The basic underlying concept with SWFObject is similar, but the implementation is noticeably different. SWFObject starts by detecting if a user agent (a browser or crawler) is capable of executing Flash. If they are not, then the pure HTML version of the given block of content is shown. However, if the user agent is capable of executing Flash, the Flash version of the content is shown instead.

Unlike sIFR, this method does not guarantee that the HTML and the content in the Flash are the same. SWFObject does not reference the text in the HTML at all. It simply runs a pre-compiled Flash movie in place of the HTML.

This technique could conceivably be used by spammers to show one type of content in Flash and another in HTML. In the extreme case, you could have information on travel to a Caribbean island in HTML replaced by a Viagra ad in Flash. This is, of course, not its intended purpose.

At the same SEMNE event, Dan Crow indicated that this technique was “dangerous.” Even though this technique could be used for entirely legitimate reasons (e.g., the same purpose as outlined for sIFR above), there is no way for Google to detect that.

In talking with other search engine representatives, I have also heard it suggested that their concept of a clean implementation of SWFObject would depend on the content in the Flash and the HTML being identical.

In practice, it is really difficult for a search engine to ban or punish a site for using such a technique without human review. I am not saying that sites don’t get hurt by the use of this technique, but there is no way that the search engines could simply punish sites based on the degree of use of SWFObject without creating a great outcry.

Simply put, it’s a legitimate technique for providing accessibility for those with poor eyesight, and providing content to users who have Flash disabled. I think one of the bigger challenges is that you end up with the obligation to craft well thought out implementations in two different mediums at the same time, one in Flash, and one in HTML.

Since the mediums are quite different, you would be tempted to do things quite differently. As noted above, the search engines indicate that they want your HTML content and Flash content to be identical. However, Flash will sometimes lead you down a path to do things quite differently.

This is a good thing, in terms of creating the best user experience with such a site. Search engine comments aside, my own opinion is that a search engine would be hard pressed to justify implementing a penalty on a site if the content of the HTML and the content of the Flash were substantially similar (as opposed to identical).

Note, however, that my opinion notwithstanding, Google has not come out in support of implementing similar but not identical content, and in fact warns that if sites present text in the HTML that is not present in the Flash, the site could risk violating the Google webmaster guidelines.

No Need For A Flash War After All

For a long time SEOs have stood against Flash as a technique. With sIFR and SWFObject, you can implement Flash on your site and still be search engine friendly. Certainly, this brings some additional challenges due to the need to implement the content twice when you use SWFObject, and a certain amount of search engine risk.

Even with SWFObject, I think your risk is low if your implementation is truly clean, but the risk is not zero. The best thing to do to minimize that risk is make your HTML implementation as close to the Flash implementation as possible.

Eric Enge is the president of Stone Temple Consulting, an SEO consultancy outside of Boston. Eric is also co-founder of Moving Traffic Inc., the publisher of Custom Search Guide