Thanks for the comments. In this case, I’m more of the notion that it’s the results that matter, however you achieve it. When implemented, all my clients care about is that they have a beautiful flash site with complete SEO.

Looking at the display list in a running Flash site is not anything near looking at the DOM of a HTML page. Sure, you can see if a textfield or shape is visible, but you will not see any of the semantics or structure that you will for a HTML page. In Flash a textfield is just a textfield, never a “h1″, “em” or “small” and there is no way to determine the relation between two display objects. They may appear as siblings in the display list, but on opposite sides of the screen, or vice versa.

Semantics, context and hierarchy is the kind of information that takes indexing from the dumb Altavista version (”this word appeared on that page”) to the intelligent, useful Google version (”this word is an important word on that page, because it’s in a header”). A running Flash site doesn’t provide that kind of information, so even if the indexing can be done, it will be inferior to a HTML rendering of the same data.

As far as I can tell the two websites you link to use progressive enhancement to make them indexable, but I wouldn’t call it “Flash SEO”, because it has little to do with Flash as such, what you have is a HTML website that is replaced by a Flash website which displays the same data. The same technique can be used with Silverlight, Ajax or even Java applets, if you would want to.

The discussion above is about “Flash SEO” as in indexing the actual Flash website. Not the HTML on the embedding page, but the running SWF.

However, I’m completely with you, I think that progressive enhancement is the best way to make Flash websites indexable. Poking around inside a running SWF will never come near looking at the semantic, structured data of an HTML page.

They both give you the benefits from Flash design and complete visibility and index-ability by all search engines.

Take a look at FlexSpy for a visual demonstration of the DOM in a Flash display list. Just like a browser’s DOM, it should be pretty easy to determine what’s visible and what objects are likely candidates for user interaction.

So where’s the big technical barrier here? A search engine bot doesn’t have to intercept or even care about your externally loaded content (and it shouldn’t, since the goal should be to recreate a user experience). It only has to be able to observe changes to the DOM in response to user interaction, and then determine how those changes affect visible (and I guess we’re only talking about text here) content.

As far as understanding the semantic context of text content, you can determine quite a bit just by looking at a node’s object type (similar to element type in HTML) and it’s position in the hierarchy.

So I think this is indeed a game-changing development and something all Flash/Flex developers should try to learn more about.

You’re right in that they actually do execute the code, that was badly argued by me.

But as pointed out by several here - the real difficulty is figuring what part of the loaded text that is relevant. Google have some merit here, but there’s no standard way to index a SWF with dynamic content.

J