By now you probably know Google indexes text content within Flash thanks to Google's new Algorithm for Flash. In case you missed it, Google recently updated their original announcement to include additional details about how Google handles Flash files.

SWFObject - Google confirms that Googlebot did not execute JavaScript such as the type used with SWFObject as of the July 1st launch of the new algorithm.

SWFObject - Google confirms "now" rolling out an update that enables the execution of JavaScript in order to support sites using SWFObject and SWFObject 2.

According to Google, "If the Flash file is embedded in HTML (as many of the Flash files we find are), its content is associated with the parent URL and indexed as single entity." I found this isn't the case using a variation of the example used by Google. The following query finds the same content indexed at three URLs 2 SWF and 1 HTML:,+...


Deep Linking - Google doesn't support deep linking. "In the case of Flash, the ability to deep link will require additional functionality in Flash with which we integrate."

Non-Malicious Duplicate content - Flash sites containing "alternative" content in HTML might be detected as having duplicate content.

Googlebot, it seems still ignores #anchors but will soon crawl SWFObject. Given that Googlebot can or will soon crawl SWFObject sites, major reworks should be considered for "deep linking" sites where correlating "alternative" HTML content pages contain the same Flash file and are accessible via multiple URLs.

ActionScript - Google confirms indexing ActionScript 1, ActionScript 2 and ActionScript 3 while at the same time Google shouldn't expose ActionScript to users.

External Text (XML) - Google confirms, content loaded dynamically into Flash from external resources isn't associated with the parent URL.

While this is a great development for Flash Developers moving forward, lots of education may be required.

As an SEO I'm always looking for ways to help Flash developers make Flash sites more "search engine friendly". I recently came across an article on the Adobe Developer Connection that sounded interesting at first. As I kept reading, I was surprised by what they call a "solution" for the "one URL per page" issue as it relates to sites in Flash. To solve this deep-linking issue, Adobe proposes a method for directly linking to content that's "buried". The technique they suggest uses a variation of RESTful URLs in Flash. REST or "representational state transfer", basically uses one or more distinct URL/s linking directly to different content or different states of content within web-based applications.

The technique uses a "frame anchor" located in the URL to specify one specific frame in the main timeline. As a result, the playhead jumps to that specific frame in Flash and users with Flash enabled see content associated therein by the Flash developer.

"The syntax for writing a URL to point to a particular anchor location in HTML is to use the pound sign (#) followed by the designated name for the anchor, as in the following examples:

* #section1: a URL that points to the anchor named "section1" in the current HTML page

* some_html_page.html#appendix: a URL that opens the URL some_html_page.html and then scrolls to the anchor named "appendix""

from: "Deep-linking to frames in Flash Websites"

This solution may work for "deep linking" in Flash but it's yet another nightmare when it comes to making Flash sites search engine friendly. Bottom line, Googlebot ignores #anchors but browsers do not. So when users link to "any URL dot com" /home.html#/about.html from their blog, PageRank, "link juice" and/or relevancy intended for about.html is instead given to home.html.