On 12/19/06, Kevin Newman <[EMAIL PROTECTED]> wrote:
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.
I dont think you need to use the hash based URL for the indexing thing. The reason is that I dont think you need to use visible URLs to do this. The only place these URLs would appear is in the sitemap, because all we are concerned about is indexing. So you use a regular url using ?foo=bar. When the bot calls the URL, the server recognizes it and sends the additonal data in the html wrapper, *and* the swf also gets the URL in the application object so that the flex app can navigate to the appropriate screen and dataset, possibly making a remoting call. I know this works because not including the sitemap and the hiding of data in the html, I do this in my current app. I am depending on Claus for the hiding of the data in the html :). 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).
This seems way too complex to me. I think, as you suggest, it is questionable whether one could make it work. 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).
I think your basic thought here is right, and not too bad. For indexing you use ?foo=bar. The user never needs to see this except in google as the link, though if he did, and he used it, it would work no problem. #foo=bar would be used for internal linking and what you see in the nav bar when you navigate around the app. This doesnt seem too bad to me. This is a tough nut. :-) Aw come on... its not that bad - I think we are making good progress here! Hank
