Flash Sites and the Google Index

Mark Cook of ZoomZoom Ltd in the UK wrote in to let us know that Google is indexing flash pages. Mark references this article about the topic. Based on this e-mail, I ran some tests, and the results are illuminating.

Query: cooking schools filetype:swf

Cooking Schools Flash Results

Query: red wine filetype:swf

Red Wine Flash Results

As you can see, Google is indexing flash. In fact, Google has been indexing flash for years (since 2004 or so). Yet Google still recommends against this practice. If you check out the Google Webmaster Guidelines, you will see the following recommendation:

Use a text browser such as Lynx to examine your site, because most search engine spiders see your site much as Lynx would. If fancy features such as Javascript, cookies, session IDs, frames, DHTML, or Flash keep you from seeing all of your site in a text browser, then search engine spiders may have trouble crawling your site.

So Google still recommends against this practice, and there is a reason why. Shari Thurow provides an excellent analysis as to why in her article from October of 2004. Here are two basic reasons:

  1. Many sites that use flash implement one flash movie for the whole site. The crawler is definitely not following that trail because it will only link one set of content to a given URL
  2. Flash pages tend to be thin on text, and do not index as well. This is because the medium seems to call for sites that use less text.

So you can build a flash site, provided that you build a different move for each page, and are pursuing non-competitive keywords. But it’s very difficult to have a flash site that ranks well for highly competitive terms. These sites need every possible advantage and require an authoritative approach to content to succeed. There is a reason you don’t see Flash ranking for highly competitive terms. It can’t compete with a well structured text site.


  1. Dmitriy says

    I am a flash developer and I am amazed by the number of sites that say how you should not build a what appears to be a 100% flash site, because it would be a death to your search engine optimization. To make a long story short, all you need to do is use a system like sIFR that would display your flash content over html, xml or xhtml layout. That means that if a user or a bot visits your site without javascript or flash they will see your html-style layout (that’s what google’s or any other search engine’s bot would see). There you go problem solved, you can have a 100% looking flash site to all those that have flash and a 100% html or xml-based site to all your visitors that cannot see flash(like search engine bots).

    So, you would have to develop a flash application that would parse and display the contents of a for example, xhtml page that would be displayed behind the 100% flash site and not visible to usual browsers like Firefox or IE.

    Problem solved! Use as much flash as you want on your site, this will not hurt you SEO as long as you set up your site properly.

    Don’t listen to people that say you’d pretty much be stupid to build your site using tons of flash. 90% of those people base their knowledge on articles only confuse people by focusing their attention on flash instead of web development.

  2. says

    Dmitriy – You might want to check out this later article I wrote on Flash:


    In addition, you may want to look at this post from Mike Davidson (co-creator of sIFR):


    Here is what he has to say:

    “sIFR is a powerful tool. So powerful, in fact, that you can completely ruin a web page with it if you get overzealous and don’t exercise restraint. Early on in development, a dude in Texas e-mailed me and asked me why his sIFR-ized page took 30 seconds to load. I looked at the page and he had replaced every single word with sIFR text… even complete paragraphs and 300-word passages. Do not do this please! sIFR is for headlines, pull quotes, and other small swaths of text. In other words, it is for display type — type which accents the rest of the page. Body copy should remain browser text. Additionally, we recommend not replacing over about 10 blocks of text per page. A few more is fine, but once you get into the 50s or so, you’ll notice a processor and speed hit.”

Leave a Reply

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