But what if you've got an extremely complex site, with many sections, pages and drill downs that you want to make accessible? One option is to simply spit out all the content, no matter how long, into that same div. Yes, that will get indexed by search engines, but not only does it make the page you're loading very large, it also doesn't link users directly to the content they searched for.
That's where SWFAddress and mod_rewrite come in. Full deets after the jump.
Let's look at our tools:
mod_rewrite is an apache module that basically lets you parse out elements of a url as variables instead of the folder structure that they appear to be.
So let's put them together.
Let's say you've got a flash application set up for selling music. There is conceivably a huge amount of information that you would want to make available to search engines, but there's no way you could output all the information on one page.
Instead, you set up a "fake" directory structure using mod_rewrite that might look like this:
yourmusicapp.com/alternative/wolf_parade/apologies_to_the_queen_mary/
So everything after the first "/" is parsed and used to return an html page with the track listing and album info for Wolf Parade's album "Apologies To The Queen Mary".
Similarly, if you went to "/alternative/work_parade/", you would get html of links to all of Wolf Parade's albums and a description for the band. Go futher down to just "/alternative/" and you'd get links to all the alternative artists and if you just went to "/" you'd get a links to all the genres.
So now we've set up a structure that can easily be indexed. But now how does that allow us to get into the flash?
If we call the above links "hard urls", then "soft urls" would be urls that you pass into SWFAddress for deep linking -- basically anything that occurs after the "#". So the soft url of the example above would be:
yourmusicapp.com/#/alternative/wolf_parade/apologies_to_the_queen_mary/
The flash is then set up as such that when it receives the value above from SWFAddress that it automatically goes to the album view for "Apologies To The Queen Mary".
Now the final step: using javascript, you can automatically forward users with flash who are led to the "hard urls" to the the "soft urls". So someone who searches for "Wolf Parade" in google would get back:
yourmusicapp.com/aternative/wolf_parade/
If the viewer is a search engine, they'll be stopped here and just index the information about wolf parade. But if its a viewer with flash installed, they'll be seamlessly redirected to the flash application:
yourmusicapp.com/#/alternative/wolf_parade/
Conclusion
Our next step is to get a public example of this for people to take a gander through. SEO solutions of this caliber for flash are great for both developers and agencies as it lets us alleviate some fears that clients may put up to going with flash. It's not for every project -- you'll probably need control of the back end development as well as the front end -- but when you find the right one, you'll know it.
Also, keep in mind that you don't actually need mod_rewrite to pursue a solution like this - you could generate the hard urls as actual html files instead of generating them on the fly, which, if your music store was getting a ton of traffic, might be a better plan anyway. The important thing is coming up with a url structure that is mirrored in the both the hard urls and the soft urls.
Finally: if you haven't heard "Apologies To The Queen Mary", do yourself a favor and get it. I'm not going to say that if you listen to it backwards while reading this post, you'll find a super secret message... but you never know.
Buenos dias!
we are juggling with the same issue in a big project at the moment. We are using typo3 for all the content management and url generation. We are thinking about a solution to display and overall using the hardlink and rewriting it to a softlink for swfaddressing in background. But would that effect the client-side js? mod_rewrite stays behind the server-side ...
solution: disabling request for flash user using the hardlink and retreiving it with "document.location" instead of a "hash" by listening to changes on the location.
How does it work for u guys? Our goal is to use only one url shema for both clients (bot, flash and html).
Cheers
Florian