Using an XML document as a content provider and XSL is ingenious - however, do you reckon there is a chance that at some point Google might classify this as grey hat since the bot is indexing something which doesn’t really appear on the page.

For the majority of my clients we usually end up grabbing the data from some kind of CMS (either XML or a database) and creating a simple HTML microsite which either redirects to the Flash (also a little dangerous from a blacklisting perspective) or has links to the real site.

I’m sure I heard a rumour that Adobe had some kind of big and cunning plan for improving this in the next generation of Flash Player, but hey, they’ve been saying that for a while

Dave
http://www.actionscriptfreelancer.com

Josh - My idea was not to have search engines try to understand the SWF format any deeper. Rather to simply give them a channel to listen to. And to perhaps provide a method that would optionally allow for differentiation of states.

Andrew - Most definitely would have to be internal to Flash Player.

John - We have numerous clients, some have some pretty high relevancy on the web. Just pulling one off the top of my head, Home Media Magazine ranks 4th for the following keywords: “Blu-Ray format war over”.

So there is validity to our desire to improve indexing results.

To see an example, go to http://directory.onflex.org/ and you’ll see a Flex UI. Now, view the HTML source in the browser, and you’ll see an XML page that does *not* embed any SWF. Instead, it holds all the data. This is what the search engines will see, and as you can see it is highly indexable. This page also supplies the data for the SWF, so it performs double duty.

Now look at the XSL for the above page at http://directory.onflex.org/template003.xsl and you’ll see that the XML is transformed into a simple HTML page that uses JavaScript to embed the SWF. This supplies what the user sees in his browser - the Flex-built SWF. The SWF, in turn, loads its data from the above XML.

So, really, it isn’t any more work than standard Flash, it’s just a slightly different twist: Rather than using a plain-Jane HTML file to embed the SWF and a separate XML file to supply the data to the SWF, you let the XML file double as a search-engine-friendly page and use an XSL file to transform it into HTML that embeds the SWF.

The best solution that I’ve seen so far is the one that Ted Patrick used for Flex Directory. He uses XSL to transform a simple, semantic XML/HTML document by replacing it with SWF embed code. The SWF then reloads the page without the XSL transform, and it displays the data as part of an RIA.

Ted’s solution is a good first step. I’d like to see it brought to a finished product’s level of quality, though. If JavaScript is disabled, the embed code fails. I’d like to see decent error handling such that if the content cannot be embedded, the raw data will be formatted nicely as a regular webpage (probably with CSS too). Basically, have it fail gracefully such that the user may not even notice that the preferred Flash Player view didn’t work.

On the search engine front, I think Google/Yahoo!/others should have better handling of pure XML and other non-HTML text data formats. Ted found that he had to change his page’s content from XML to HTML because the search engines would completely ignore the page’s content if they didn’t understand the tags being used. The web is moving beyond HTML. We have other XML-based formats like RSS, ATOM, JSON, and others that could provide all sorts of new information to search engines. Even better, these formats could be very useful in the crawling of RIAs created with technologies like Flash, Silverlight, and others.