Question

A client of mine has a full-Flash site and an HTML site (wordpress). Currently, the HTML site lives at http://www.domain.com, while the Flash site lives at http://www.domain.com/flash (swfobject detection at http://www.domain.com redirects flash users to the flash URL). The client isn’t entirely pleased with this arrangement in terms of SEO, as links to their site sometimes point to http://www.domain.com and sometimes to http://www.domain.com/flash.

In a few weeks, the client will be rolling out a new version of their Flash site, which features deeplinking, among other things. Instead of living in its own folder off of the domain, the full-Flash site will be a “progressively enhanced” version of the HTML site, so if a user supports Flash, all HTML content will be replaced by Flash content.

Once the new site is launched, each page/URL in the Flash site will have a corresponding HTML page/URL; for example, the Flash content at http://www.domain.com/#/about/clients corresponds to the HTML content at http://www.domain.com/about/clients.

We’re going to implement a 301 redirect so the old /flash path points to the domain itself, but we’re not sure how to proceed in terms of redirects between the HTML and Flash versions of the site. One possibility would be to simply do client-side detection of capabilities and redirect the user to the appropriate version; under that scenario, a non-Flash-capable client that attempts to visit http://www.domain.com/#/about/clients would be JS-redirected to http://www.domain.com/about/clients, and a Flash-capable client visiting http://www.domain.com/about/clients would be JS-redirected to http://www.domain.com/#/about/clients.

Is this a reasonable approach? Are there any potential SEO red flags that we should be aware of before proceeding?

Thanks for your consideration!

Answer 1

The redirect from /#/about/clients to /about/clients sounds reasonable, but applying the reverse could cause problems – if your Flash detection doesn’t work correctly (perhaps Flash is blocked etc.) then you may send the user into an infinite redirect loop.

Personally, I would recommend that non-hash links always load their content as expected, in a static manner. If the user then navigates, you may either end up with a URL like /about/clients#/ (if they went to the home page) (this shouldn’t be an issue as crawlers will never end up visiting them this way) or you can have them redirect to / next time they navigate.

IMHO, I’d say that a pure JavaScript solution to the hash problem would be easier to manage as there are already many good examples of this.

Also consider using #! instead of # – this ‘hash-bang’ technique is being pushed by Google as a way of identifying to search engines that your hash is important and that its contents differ from what you would see without the hash part. Google can already point to specific parts of a page using # and if you follow the hash-bang technique on the client and server-side, it will be able to index your AJAX/Flash links just like regular links (see the implementation details and the requirements you need to fulfill).