On June 30th, Google announced that it was working with Adobe in order to index flash content and thousands of flash developers around the globe rejoiced! Having developed countless flash applications, I fully know the impact of making sure flash content is crawlable for SEO. Until now, many developers were faced with a big question from marketers (and that question typically came at the end of the project), “How do I make sure our flash content can be indexed by Google?” This was never a comfortable situation for flash developers… Needless to say, the news that Google will index flash content is a big step forward for content providers, marketers, and for the engines. That said, I did have some serious questions and concerns after I heard the news. I understand flash development extremely well and I’m neck deep in SEO, so it was natural for me to start thinking about this from both perspectives.
Over the past few days, I’ve been testing several flash movies and applications across my sites to see how Google has indexed them. Below, I have listed some concerns and questions, based on my experience with flash, SEO, and my research and testing over the past few days. Keep in mind, this is by no means final…I plan to write more about how the search engines index flash content over the next few months. I know this is a dynamic area for search engine optimization.
Questions, Concerns, and Findings About Google Indexing Flash Content:
1. Indexing the Core SWF File (the parent swf)
Based on what Google explained in their communication, it will index the core swf file on the page, but not associate dynamically loaded files (other swfs, xml, etc.) with the original flash file. Now, there are many reasons to load content dynamically and most professional flash developers are using these techniques to keep their content fresh and to maintain a small file size. In addition, Google said that it won’t index FLV files (which are typically loaded on demand into a parent swf), because they don’t contain any text content.
My concern is that best practices may not be used so marketers can get all of their text content into one swf. In addition, loading xml data to keep your content up to date (such as pulling the latest product information from a database) won’t be associated with the parent swf (from an SEO standpoint). So, if developers start to add more and more content into the parent SWF file, then file size can become a real issue. I know bandwidth isn’t as big of a problem as in the past, but the proper way to code multi-section flash applications is to load additional SWF files into the parent SWF. So, get ready for more, “Loading Site” animations. :) I can only hope that Google and the other engines decide to associate externally loaded content with the parent SWF file.
2. Black Hat SEO’s Must Be Chomping at the Bit!
OK, this one hit me right away and concerns me greatly. As a flash developer, you typically display text content on the fly, based on how the user is interacting with your flash movie. For example, you might have movieclips in Flash that only display when someone triggers that feature in your application (i.e. to view the latest products you have). These movieclips aren’t visible until needed. I think you can see where I am going with this… In my tests, Google indexed all of the text content in the parent SWF, including text in movieclips that may never be triggered.
Now, the fact that Google indexed all of the text content is great for white hat SEO’s, but could be extremely dangerous in the hands of a black hat SEO. I fear that some may include dozens of movieclips stuffed with keywords in order to get those terms indexed by Google. In flash, you can basically add code to any object at your disposal. So how will Google decipher what’s real text content versus text content that’s there to game their algorithm? In HTML, you pretty much know if something is hidden. In flash, how do you know if something is really hidden? For example, let’s say you had a product image and some text show up when someone rolled over a small button in the corner of the screen. Let’s say 2% of users realize it’s a button and trigger it. Is that wrong? Is that against the rules? Take that example to the nth degree and you can see why I’m concerned. I’m eager to see how Google combats black hat tactics now that flash is being indexed. And more importantly, will you (as a white hat SEO) become collateral damage if they tweak the algorithm to handle this??
3. Obfuscation and SWFEncrypt
Many flash developers use tools like SWFEncrypt to obfuscate their code. I know, horrible word, right? Try saying that 5 times really fast. :) Obfuscation encrypts your code so other programmers can’t steal it. It bumps up your file size somewhat, but helps you protect what you’ve spent hours writing! My initial concern was that if Google decompiles your flash movies to find text content, what will it do with the your obfuscated code? But I’ll stop there, as Google explained that it won’t be decompiling flash movies. I was happy to hear this… So, programmers of the world, keep obfuscating! ;-)
4. Flash Publishing, Choose your method wisely…
There are several ways to output your flash movie (SWF) in your HTML code. In a nutshell, you can use standard object and embed tags, you can use JavaScript to write out your flash movie, or you can use SWFObject to elegantly provide flash content while providing alternative HTML content. SWFObject has a few different versions that you can use, and one relies on JavaScript and the other is a standards-compliant version that doesn’t rely on JavaScript. So, how will all of these publishing methods impact your flash indexation? I definitely recommend testing each of these methods out on your own sites to gauge their effectiveness. However, Google has already said that it won’t execute some types of JavaScript. So, as you can guess, using JavaScript to publish your flash content probably isn’t the best way to go at this stage. :) That would include SWFObject 1.0 and 1.5 (for now). Google said that it is working on an update for SWFObject, but does that include 1.0 and 1.5? That said, SWFObject 2.0 using static publishing (standards-compliant) doesn’t rely on JavaScript and I’ve noticed some strong results indexation-wise.
This is such a fluid situation, that you should test out your own flash content on your own sites to see how they get indexed. In addition, keep up to date on the latest changes Google is making regarding indexing flash content. My guess is that the changes will be relatively frequent as Google learns more.
My Flash SEO Advice
So there you have it, 4 concerns and observations that I’ve had since the news hit that Google will be indexing flash content. I have listed some quick advice below:
* Don’t assume Google will automatically index all of your flash content. That would be a big mistake, as there are numerous factors involved with how you code and publish your flash movies.
* Don’t run and create an all-flash site! Please don’t do this for numerous reasons… ;-)
* Test your flash content on several sites that you control, using various publishing methods. This is the best way to gauge how your flash content is being indexed.
* Keep up to speed on how Google changes its algorithm with regard to flash content. The techniques that you use today may need to be tweaked tomorrow. That’s the just the nature of SEO.
Quick Summary
As I wrap up this post, I wanted to reemphasize that this is a big step forward for Google and the other engines, Adobe, and countless content producers across the world. I’ve been waiting for this day for a long time and I’m excited to track the progress of flash indexation. If you have discovered any interesting results, please feel free to include them here as a comment. I know I’ll be writing new posts about this topic as time goes on, based on my own testing. Now off to code and test some more flash movies! :)
GG