hank williams wrote: > > I do know that the various search engines explicitly warn against > "cloaking" (redirecting search results to different content), but for > understandable reasons they don't go into much detail on their > implementations. > > > I am not suggesting this. I am just suggesting that when a url is sent > to the server that describes a particular content set, for example a > particular myspace page like www.myspace.com/hank > <http://www.myspace.com/hank> that the server sends along invisible > html data that exactly matches what the swf is going to show once it > gets up and running. I think the problem is that Flex or any single page web app doesn't use that style of url (which actually goes to the server and fetches another page). They tend to use hash based urls (#) to avoid page refreshes. So how to you reconcile the two url types - you don't want the Flex/Flash/etc. app refreshing every time the url changes, that's not cool. (more on this below).
> The sitemap thing solves an important half the problem. It identifies > the URLs that the spider should search. But then you need the server > to actually send indexable data/html when the given URLs are hit. And > what I am saying is that when one of these URLs are hit, that the > server needs to provide both the swf, and the invisible html that > contains the indexable data that you will see in the swf. This means > the content will be accessible in the swf, and accessible to the > search engines in html. This is the thrust of my earlier described > content. That's correct, but how do you make sure to send the data back when your server recieves a hit for something like http://www.unfocus.com/#Contact - I'm not sure the hash portion of that url makes it to the server (I would be ecstatic to learn I'm wrong here) - or even that indexers (spiders) would use that part of the hash if it was in a link. If spider bots are willing to run web apps (using whatever technology) and those apps are screen accessible, I guess it would be possible to actually index the content from within the app, but I'm just not sure how feasible such a setup would be (I have heard that google is playing with search tech that would load a copy of firefox and actually index based on what it's really displaying). The other way is to just use two different link types, and Content views - one hash based (#foo=bar) for the client app (Flash/Flex/etc.), and one query string based (?foo=bar) for the html files that are indexed. And if we should avoid automatically forwarding the user from the query url to the hash url, then we are stuck presenting search engine users with html content, or loading the application, and refreshing the url at some point to main url (..com/?foo=bar#someother=location would just be wrong) and the app along with it (no seemless transition from a search engine link - which honestly, might not be the end of the world). This is a tough nut. :-) Kevin N.
