Re: [flexcoders] Re: SEO Compatibility
On 12/28/06, Kevin Newman [EMAIL PROTECTED] wrote: What you have described is basic deep linking, but does not solve the problem I have been attempting to articulate. Regardless of what goes on on the server, if you enter some path info after the .com part of the url, the server thinks it is getting its data from that location (foo.com/bar/ for example). Not quite true. You can use mod_rewrite (on Apache) to chop up the URL - everything after the foo.com/ can be altered internally to be a request to something else entirely, without affecting the browser. e.g. the client enters foo.com/bar/monkey internally, mod_rewrite alters it to foo.com/index.php?page=bar/monkey, but the user still sees foo.com/bar/monkey in his browser. I've done it lots, I know it works. :-) You can then enter your application at any point you like based on a complete URL - e.g. passing it through to Flash as flashvars via PHP. But as you say, unless we then update the browser's location bar when we move through the app, it doesn't help much. :-) Cheers, Ian
Re: [flexcoders] Re: SEO Compatibility
i see what you are saying in your words. when we go to a new state, say foo.com/bar/ you want the url to change to foo.com/bar/monkey not foo.com/bar/#monkey correct? have a look at www.neave.tv. as you move the app the browser's location bar is updated. are we changing topics again or are we moving to another piece of the puzzle? ie, jd summarized the current topic issue as this: I'd like Adobe to provide examples on how to expose user-entered text, stored within my database and displayed and entered through a Flex SWF's UI, so that any search engine could search for that user text and return the address of the interface. and then we discussed some solutions to this. On 12/28/06, Ian Thomas [EMAIL PROTECTED] wrote: On 12/28/06, Kevin Newman [EMAIL PROTECTED] wrote: What you have described is basic deep linking, but does not solve the problem I have been attempting to articulate. Regardless of what goes on on the server, if you enter some path info after the .com part of the url, the server thinks it is getting its data from that location (foo.com/bar/ for example). Not quite true. You can use mod_rewrite (on Apache) to chop up the URL - everything after the foo.com/ can be altered internally to be a request to something else entirely, without affecting the browser. e.g. the client enters foo.com/bar/monkey internally, mod_rewrite alters it to foo.com/index.php?page=bar/monkey, but the user still sees foo.com/bar/monkey in his browser. I've done it lots, I know it works. :-) You can then enter your application at any point you like based on a complete URL - e.g. passing it through to Flash as flashvars via PHP. But as you say, unless we then update the browser's location bar when we move through the app, it doesn't help much. :-) Cheers, Ian
Re: [flexcoders] Re: SEO Compatibility
Perhaps the easiest way to think about this is stuff before the hash, is server side stuff, and after the hash is client side stuff. The client portion can be changed on the client without reloading the client app, but the stuff before the hash will cause the app to be reloaded if altered by javascript (mod_rewrite only affects the server side - it doesn't update the user's location info). More within: dorkie dork from dorktown wrote: i see what you are saying in your words. when we go to a new state, say foo.com/bar/ http://foo.com/bar/ you want the url to change to foo.com/bar/monkey http://foo.com/bar/monkey not foo.com/bar/#monkey http://foo.com/bar/#monkey It's not that I want the url to change to that, it's that the search bots only (to my knowledge) use the stuff before the hash (#). So it's more of a necessity to have those standard urls in some kind of link structure for the bots to follow. In other words, if you want SEO compatibility in your client side app, you are required to maintain and integrate the two different URL types - one for the user, and one for the search bots (and that one is a server side app). correct? have a look at www.neave.tv http://www.neave.tv. as you move the app the browser's location bar is updated. This site demonstrates what I've been saying - only the stuff after the hash changes (and it's using unFocus.History, which was written by yours truly :-D - *shameless*). are we changing topics again or are we moving to another piece of the puzzle? ie, jd summarized the current topic issue as this: I'd like Adobe to provide examples on how to expose user-entered text, stored within my database and displayed and entered through a Flex SWF's UI, so that any search engine could search for that user text and return the address of the interface. and then we discussed some solutions to this. I guess this is a different discussion - we are discussing why this is so hard to do, and the specific road blocks, and then some possible solutions. I'd be happy to start another thread, but I don't watch the list as closely as I'd like, which is why I keep coming back to this old huge one. The more I think about this particular problem, the more I am starting to see which tools may be right for which jobs. If you have a lot of content in your site, then each piece of content should probably be contained in some kind of document container (like html). It's these documents that would be indexed by search engines. So maybe then the problem is that we need a standard way to get from the indexed document into the Rich app more fluidly, if not automatically? This whole problem is also difficult, because it is not solely a technical problem, nor is it entirely an architectural problem - there are also possible user experience considerations, as well as work flow issues. Kevin N.
Re: [flexcoders] Re: SEO Compatibility
What you have described is basic deep linking, but does not solve the problem I have been attempting to articulate. Regardless of what goes on on the server, if you enter some path info after the .com part of the url, the server thinks it is getting its data from that location (foo.com/bar/ for example). The problem occurs after the initial page is loaded in whatever app you are running on the client. Let's say for example that you want to move the user from foo.com/bar/ to foo.com/foo - there is no way to update the browser without causing the full page to reload. This is why we rely on the hash portion of the url. That part does not cause the page to reload, since it is generally meant to refer to a named anchor with in the html. This fact makes the current method of deep linking and history manipulation a huge hack BTW - which IMO means that the browser vendors aught to figure out some kind of extension to make history management and deep linking more robust for client runtimes (a simple javascript API would work - maybe something plugins could interact with directly also). We could just move them in the app, and update the url client side, but we'd end up with foo.com/bar/#foo which is just terrible (though again, its not the end of the world - I guess). Thanks! Kevin N. dorkie dork from dorktown wrote: First, this structure already works for these content management / blog sites. They have a single index page that shows content based on the url. There is only one file. So we know it works. #1 - yes. i am thinking at its most basic level, on that single catch all index page, we have a function that gets called when the page loads. that function is passed the broken down url information, ie, a object similar to the location object (contains the pathname, protocol, etc - or we define a set of global variables). these are set when the mod rewrite or referrer. i'd have to check how they do it. back to the function - then your function can parse and use logic you set up to deliver the content that you want to make available to the search engines based on the url the user or search bot requested. in your logic you may be going to the database and pulling information based on the page they request. we store that information in a variable that will eventually get written to the page underneath the swf in xml hidden inside of a script tag. #2 - the search engine does not know it is getting redirected to the index.php, index.asp, index.jsp page. all it knows is that when it asks for animals.com/carnivors/bears http://animals.com/carnivors/bears it is getting the page on bears. #3 - yes. thats right. this is described in #1. i really think some variables would be better than an object. #4 - that is not necessary. remember, the user (and their browser) and the search bot only believe in the url. they don't care or know if its a single page or a different page that gets served up. One more thing we would have to do that I did not mention in #1 was to pass a list of links to the page to be written out. These can be in a display none tag or in the no script section. And finally that url path and variables should be passed to the flash swf in the flash vars section. Dang. I think this can be done rather quickly. This would be basic. A front end / front end manager could be created for this later on top of this. On 12/22/06, * Kevin Newman* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: dorkie dork from dorktown wrote: One of the open source solutions I occasionaly use *cough* *cough* *drupal* *cough* has a mod redirect / mod rewrite htaccess file (i'm combining words). Any url that is entered into the site gets rewritten or redirected. It is a dynamic system that allows you to dynamically redirect to the content you want without hard coding paths or directories. So you would create a dynamic page (doesn't really exist - only in the database) and then an alias to reach it. For example, www.test.com/myalias http://www.test.com/myalias http://www.test.com/myalias. Actually a lot of systems use this (wordpress, etc). All urls entered in to the site would be redirected to index.php. At this point you could with the super awesome power of server side code, deliver page links dynamically and content dynamically. I recently did a project with FXT and did exactly that. You pass the data as an xml model into a script tag under the body tag. Search engines pick this up. My Flex app pulled this xml in and then used it as a dataprovider for numerous controls. I've asked in the wish list for Macromedia at the time before it was Adobe to let us specify the type of extension for the published html wrapper. Right now if you click publish or run it creates a HTML
Re: [flexcoders] Re: SEO Compatibility
dorkie dork from dorktown wrote: One of the open source solutions I occasionaly use *cough* *cough* *drupal* *cough* has a mod redirect / mod rewrite htaccess file (i'm combining words). Any url that is entered into the site gets rewritten or redirected. It is a dynamic system that allows you to dynamically redirect to the content you want without hard coding paths or directories. So you would create a dynamic page (doesn't really exist - only in the database) and then an alias to reach it. For example, www.test.com/myalias http://www.test.com/myalias. Actually a lot of systems use this (wordpress, etc). All urls entered in to the site would be redirected to index.php. At this point you could with the super awesome power of server side code, deliver page links dynamically and content dynamically. I recently did a project with FXT and did exactly that. You pass the data as an xml model into a script tag under the body tag. Search engines pick this up. My Flex app pulled this xml in and then used it as a dataprovider for numerous controls. I've asked in the wish list for Macromedia at the time before it was Adobe to let us specify the type of extension for the published html wrapper. Right now if you click publish or run it creates a HTML page. So somewhere in the options it would be nice to choose the page extension type (php, asp, jsp, etc) of the page we are publishing. I've also investigated and requested a way to pick my template page that Flex finds and then replaces the tokens which it is looking for inside of it. This may all be possible already. I've been mostly only learning the API, mostly. Now that I've had a chance to think about it a default Adobe Page and Link Management admin site might be the solution. It would be created and deployed to bin or bin-admin with every project. Then you would upload that to the server along with the contents of your bin directory. A developer could login to it on the server. The Adobe Page Manager would use an xml file or database to create the aliases. The alias would be for different states in a Flex app. When you create an alias there would be a place where you could call the services or page associated with that state and alias. It would then wrap that content in a xml tag like in FXT for indexing. You could also pass any links back to the page. The content and links would be in the noscript / script / area of the page and not be visible to the user but it would be visible to the search bots. Because it uses a single page index.php and .htaccess mod rewrite it would redirect all traffic to the single index page (php, asp, java). That page would take that url alias, search the xml file or database and serve up the appropriate content (in the background hidden to users). I hope that makes sense. It would manage aliases, content for that alias, links for the alias and state to pass to the embedded flash swf. I can actually imagine how it would work. Hmm.. I'm not sure I understand exactly what you are talking about, but let's see if this is close: 1. Set up the homepage to pull dcontent from the database using whatever server side technology (php/asp.net, etc, over WebServices/FMS, etc.) - front loader style (design pattern). 2. Set up a 404 handler (using .htaccess or iisadmin) to detect what url was passed in - say domain.com/section/contentid, and redirect to homepage. (How would the search engine deal with something like that - would it just keep replacing the index information for the home page. Can a spider or bot store multiple versions of a webpage? Maybe the Vary header would help here?). 3. Redirect the user (or bot/spider) to the homepage, display the information based on the section/contentid part of the url. I'm not sure how you would do that. Is there a server var that can be relied upon that you can check to know where the user or bot was redirected from. 4. Use client side technology and location.replace to fix up the url so the user ends in the right place in the app, and has the standard one link type (with the #). Would something like that actually work? I'm sure I could make it work for a web browser, but I'm not sure what would work with search engine spider bots. Kevin N.
Re: [flexcoders] Re: SEO Compatibility
First, this structure already works for these content management / blog sites. They have a single index page that shows content based on the url. There is only one file. So we know it works. #1 - yes. i am thinking at its most basic level, on that single catch all index page, we have a function that gets called when the page loads. that function is passed the broken down url information, ie, a object similar to the location object (contains the pathname, protocol, etc - or we define a set of global variables). these are set when the mod rewrite or referrer. i'd have to check how they do it. back to the function - then your function can parse and use logic you set up to deliver the content that you want to make available to the search engines based on the url the user or search bot requested. in your logic you may be going to the database and pulling information based on the page they request. we store that information in a variable that will eventually get written to the page underneath the swf in xml hidden inside of a script tag. #2 - the search engine does not know it is getting redirected to the index.php, index.asp, index.jsp page. all it knows is that when it asks for animals.com/carnivors/bears it is getting the page on bears. #3 - yes. thats right. this is described in #1. i really think some variables would be better than an object. #4 - that is not necessary. remember, the user (and their browser) and the search bot only believe in the url. they don't care or know if its a single page or a different page that gets served up. One more thing we would have to do that I did not mention in #1 was to pass a list of links to the page to be written out. These can be in a display none tag or in the no script section. And finally that url path and variables should be passed to the flash swf in the flash vars section. Dang. I think this can be done rather quickly. This would be basic. A front end / front end manager could be created for this later on top of this. On 12/22/06, Kevin Newman [EMAIL PROTECTED] wrote: dorkie dork from dorktown wrote: One of the open source solutions I occasionaly use *cough* *cough* *drupal* *cough* has a mod redirect / mod rewrite htaccess file (i'm combining words). Any url that is entered into the site gets rewritten or redirected. It is a dynamic system that allows you to dynamically redirect to the content you want without hard coding paths or directories. So you would create a dynamic page (doesn't really exist - only in the database) and then an alias to reach it. For example, www.test.com/myalias http://www.test.com/myalias. Actually a lot of systems use this (wordpress, etc). All urls entered in to the site would be redirected to index.php. At this point you could with the super awesome power of server side code, deliver page links dynamically and content dynamically. I recently did a project with FXT and did exactly that. You pass the data as an xml model into a script tag under the body tag. Search engines pick this up. My Flex app pulled this xml in and then used it as a dataprovider for numerous controls. I've asked in the wish list for Macromedia at the time before it was Adobe to let us specify the type of extension for the published html wrapper. Right now if you click publish or run it creates a HTML page. So somewhere in the options it would be nice to choose the page extension type (php, asp, jsp, etc) of the page we are publishing. I've also investigated and requested a way to pick my template page that Flex finds and then replaces the tokens which it is looking for inside of it. This may all be possible already. I've been mostly only learning the API, mostly. Now that I've had a chance to think about it a default Adobe Page and Link Management admin site might be the solution. It would be created and deployed to bin or bin-admin with every project. Then you would upload that to the server along with the contents of your bin directory. A developer could login to it on the server. The Adobe Page Manager would use an xml file or database to create the aliases. The alias would be for different states in a Flex app. When you create an alias there would be a place where you could call the services or page associated with that state and alias. It would then wrap that content in a xml tag like in FXT for indexing. You could also pass any links back to the page. The content and links would be in the noscript / script / area of the page and not be visible to the user but it would be visible to the search bots. Because it uses a single page index.php and .htaccess mod rewrite it would redirect all traffic to the single index page (php, asp, java). That page would take that url alias, search the xml file or database and serve up the appropriate content (in the background hidden to users). I hope that makes sense. It would manage aliases, content for that alias, links for the alias and state to pass to the
Re: [flexcoders] Re: SEO Compatibility
I guess it isn't as large a problem as maybe I've been suggesting, after having talked about it in this thread. My whole problem is that I don't like urls that look like this: http//domain.com/some/path/#other/path - which in all the examples, is what you could end up with, if you try to combine a regular indexable set of html files (or a server side app or whatever), with an self updating deep link solution that uses the hash portion of the url (like all current flash based deep link systems do). At the end of the day the problem is largely cosmetic I suppose, but it's still a problem I'd like to find a solution for. :-) The optimal solution, imo, would be some way to have the pages get indexed by search engines, then kick you into the app, at the app level, rather than shoe horning the app in at the index level. Kevin N. hank williams wrote: Either way, it's reconciling the two urltypes that's the crux of the problem as I see it. Kevin, You keep saying this, and maybe I am missing the big picture here, but I am not clear why it is necessary to reconcile these two url types, or how they relate to each other at all. It seems to me you can use them both, they exist for different purposes and there is no problem. You seem to think that that is not right, and below categorize it as so large a problem. What am I not understanding? Regards, Hank
Re: [flexcoders] Re: SEO Compatibility
One of the open source solutions I occasionaly use *cough* *cough* *drupal* *cough* has a mod redirect / mod rewrite htaccess file (i'm combining words). Any url that is entered into the site gets rewritten or redirected. It is a dynamic system that allows you to dynamically redirect to the content you want without hard coding paths or directories. So you would create a dynamic page (doesn't really exist - only in the database) and then an alias to reach it. For example, www.test.com/myalias. Actually a lot of systems use this (wordpress, etc). All urls entered in to the site would be redirected to index.php. At this point you could with the super awesome power of server side code, deliver page links dynamically and content dynamically. I recently did a project with FXT and did exactly that. You pass the data as an xml model into a script tag under the body tag. Search engines pick this up. My Flex app pulled this xml in and then used it as a dataprovider for numerous controls. I've asked in the wish list for Macromedia at the time before it was Adobe to let us specify the type of extension for the published html wrapper. Right now if you click publish or run it creates a HTML page. So somewhere in the options it would be nice to choose the page extension type (php, asp, jsp, etc) of the page we are publishing. I've also investigated and requested a way to pick my template page that Flex finds and then replaces the tokens which it is looking for inside of it. This may all be possible already. I've been mostly only learning the API, mostly. Now that I've had a chance to think about it a default Adobe Page and Link Management admin site might be the solution. It would be created and deployed to bin or bin-admin with every project. Then you would upload that to the server along with the contents of your bin directory. A developer could login to it on the server. The Adobe Page Manager would use an xml file or database to create the aliases. The alias would be for different states in a Flex app. When you create an alias there would be a place where you could call the services or page associated with that state and alias. It would then wrap that content in a xml tag like in FXT for indexing. You could also pass any links back to the page. The content and links would be in the noscript / script / area of the page and not be visible to the user but it would be visible to the search bots. Because it uses a single page index.php and .htaccess mod rewrite it would redirect all traffic to the single index page (php, asp, java). That page would take that url alias, search the xml file or database and serve up the appropriate content (in the background hidden to users). I hope that makes sense. It would manage aliases, content for that alias, links for the alias and state to pass to the embedded flash swf. I can actually imagine how it would work. On 12/21/06, Kevin Newman [EMAIL PROTECTED] wrote: I guess it isn't as large a problem as maybe I've been suggesting, after having talked about it in this thread. My whole problem is that I don't like urls that look like this: http//domain.com/some/path/#other/path - which in all the examples, is what you could end up with, if you try to combine a regular indexable set of html files (or a server side app or whatever), with an self updating deep link solution that uses the hash portion of the url (like all current flash based deep link systems do). At the end of the day the problem is largely cosmetic I suppose, but it's still a problem I'd like to find a solution for. :-) The optimal solution, imo, would be some way to have the pages get indexed by search engines, then kick you into the app, at the app level, rather than shoe horning the app in at the index level. Kevin N. hank williams wrote: Either way, it's reconciling the two urltypes that's the crux of the problem as I see it. Kevin, You keep saying this, and maybe I am missing the big picture here, but I am not clear why it is necessary to reconcile these two url types, or how they relate to each other at all. It seems to me you can use them both, they exist for different purposes and there is no problem. You seem to think that that is not right, and below categorize it as so large a problem. What am I not understanding? Regards, Hank -- Flexcoders Mailing List FAQ: http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txt Search Archives: http://www.mail-archive.com/flexcoders%40yahoogroups.com Yahoo! Groups Links
Re: [flexcoders] Re: SEO Compatibility
Thank Claus, I wah hoping you would pipe in on this! Hank On 12/20/06, Claus Wahlers [EMAIL PROTECTED] wrote: I dont think google needs to do much here. If we can get the server product to easily allow XML to enhance the HTML response then googles indexing will just work. I'd love to see this work in a concrete example. ;-) Again, I am not an HTML expert, (Claus is really the guy that has the expertise to be saying this) but this is really just the kind of stuff that he has been talking about. I am just putting a little more specific meat on the bone. I think Claus pointed to a flash website that does this that he mentioned earlier in this thread. I don't know if i have any more expertise than you ;) But let me just say that XHTML *is* XML, and XHTML is all about semantics, ie. you *could* use XHTML both as the (perfect) format you use to feed to search engine bots *and* as the datasource for your Flash application/site. Of course you don't *need* to do the latter, you can also pipe the (same) data to Flash via remoting or whatever, but for any of your site's URLs the content a search engine bot sees and the content a human with JS/Flash enabled browser sees must be the same. The Flash website was http://guipaganini.com.br/ It supports deep linking, eg. http://guipaganini.com.br/12/75 View source (or switch off JS) to get the idea. The XHTML is loaded as is into Flash. I'm using the Symfony PHP5 framework on the server side. (Disclaimer: don't look too close at the Flash site, it's been a low budget project and i still need to finetune it) Cheers, Claus. -- claus wahlers côdeazur brasil http://codeazur.com.br/ http://wahlers.com.br/claus/blog/ -- Flexcoders Mailing List FAQ: http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txt Search Archives: http://www.mail-archive.com/flexcoders%40yahoogroups.com Yahoo! Groups Links
Re: [flexcoders] Re: SEO Compatibility
Claus Wahlers wrote: The Flash website was http://guipaganini.com.br/ It supports deep linking, eg. http://guipaganini.com.br/12/75 View source (or switch off JS) to get the idea. The XHTML is loaded as is into Flash. I'm using the Symfony PHP5 framework on the server side. (Disclaimer: don't look too close at the Flash site, it's been a low budget project and i still need to finetune it) That site highlights the problem I see with this solution. It does work as it is, but try adding a live updating deep link support (such as Flex has, or unFocus.History can do, or urlKit, which I haven't checked out yet). You'd end up with odd urls like http://guipaganini.com.br/12/75#13/76 instead of having consistent urls such as http://guipaganini.com.br/#13/76 or the other. I suppose for an information rich site, it might make sense to initially serve up the content as html, and then offer a manual path back into your application, after they have read the content. Either way, it's reconciling the two urltypes that's the crux of the problem as I see it. Honestly, this problem is so large, maybe this is a problem for the browser makers and thos The Web Standards Project http://www.webstandards.org/ guys. Since this is a problem for more than just Flash based Web Apps, they could come up with a standard or something (and hopefully not get ignored like the w3c does). Just a thought. Kevin N.
Re: [flexcoders] Re: SEO Compatibility
Either way, it's reconciling the two urltypes that's the crux of the problem as I see it. Kevin, You keep saying this, and maybe I am missing the big picture here, but I am not clear why it is necessary to reconcile these two url types, or how they relate to each other at all. It seems to me you can use them both, they exist for different purposes and there is no problem. You seem to think that that is not right, and below categorize it as so large a problem. What am I not understanding? Regards, Hank
Re: [flexcoders] Re: SEO Compatibility
hank williams wrote: Kevin, I had a few inline comments on some of what you wrote since I had a few differences of opinion. On 12/18/06, *Kevin Newman* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: I think that's great and don't necessarily think Adobe needs to fix the problem, since I don't think it's Adobe's problem - I like the flexibility. I think its definitely adobe's problem to the extent that they offer products that are client/server systems instead of just client tools. FDS and Cold Fusion should offer a way to facilitate this most important of issues. Adobe has defined a significant part of its business as building servers in the flash ecosystem. I dont think solving this issue would limit any flexibility. You are right about FDS and Cold Fusion servers - it should be possible for Adobe to create some kind of tools or solutions, even if it isn't hands off - but for the rest of us, and overview or best practices document would be nice. This is a problem for Google and others, to fix, or perhaps one that there is already a solution for. I dont see why this would be googles issue really at all. More on this below. The problem with Flex/Flash/AJAX/Expression Blend apps, is that they are not documents, they are applications. Actually, many such apps are *both* apps and documents and that is where the problem is. For example a discussion board is an app that manages and displays document type data that deserves to be indexed. I guess it could be, but mixing it like that seems odd to me. How would Google or anyone else index something like Microsoft Word, or Adobe Photoshop. You correctly point out that these do not make sense for indexing, but these are not the kinds of apps that we are talking about for user generated content or webapps that have significant indexable data. I guess I see Flex/Ajax/Flash/etc. apps more like extension to the browser, than as web sites or content. To me they just extend the way the browser app access and displays information. To me the answer is as Claus suggests - to build an alternative, server side web app, that serves the documents to spiders and bots (BTW, this can be produced before or after the UI - it's up to the developer ;-) ). The interesting question, and the place that needs focus, is what is the right way to direct traffic from those search pages back into the web app. This it seems is not that interesting a question because it is the easy part. Flash/Flex apps can easily read data in the URL and go to the right place in the app which can then use remoting to get the data in the right format for the app. Yeah, but it has to run to do that, and then the displayed data has to be interpretable by the bot - if that can be standardized enough for a spider to understand what it's got back from the server (maybe an event system that says hey I'm ready to be indexed, or read me now - screen readers have to be able to do this, so I guess it might be possible), that's great, but I don't know if spiders will be that smart, or if companies like google would be willing to build such a bot that can run apps like that. I suppose it would be more ideal than two different types of links into the app (hash # and query ?). Of course the bot would still need to know how to crawl the site (where to get urls) - I guess sitemaps.org could come in handy here. A smart enough bot wouldn't even have to reload the app (if the app don't break at least). I think the easiest way to do that would be with a small snippet of JavaScript that would detect for Flash Player (or whatever the app requires) then location.replace you into the appropriate location within the application (which would need deep linking support, and there many ways to do that now). This, it seems to me is more complicated than necessary. I do this in my current app without any javascript snippet (cuz I dont know jack abou js!). I just read the parameter from the application object go to the right place in my app and load the appropriate data from the server. Do you do this after the page loads, or when the app is requested? What's needed now is a concrete example to follow, or a set of patterns or standards, or whatever, that will ease the development of this second view of your app's content. I think the server side code to do this is more than just a standard. I think we need an entry point on the current adobe remoting products for adding XML to the HTML response of a url with addition field or query information. For Adobe's products, a tool that would help developers build something like that into their content systems, would be useful. It would be nice if Google and Adobe (and whoever else) could get together and figure out what
Re: [flexcoders] Re: SEO Compatibility
This it seems is not that interesting a question because it is the easy part. Flash/Flex apps can easily read data in the URL and go to the right place in the app which can then use remoting to get the data in the right format for the app. Yeah, but it has to run to do that, and then the displayed data has to be interpretable by the bot - if that can be standardized enough for a spider to understand what it's got back from the server (maybe an event system that says hey I'm ready to be indexed, or read me now - screen readers have to be able to do this, so I guess it might be possible), that's great, but I don't know if spiders will be that smart, or if companies like google would be willing to build such a bot that can run apps like that. I suppose it would be more ideal than two different types of links into the app (hash # and query ?). Of course the bot would still need to know how to crawl the site (where to get urls) - I guess sitemaps.org could come in handy here. A smart enough bot wouldn't even have to reload the app (if the app don't break at least). The html can definitely be formatted in such a way that bots can read it. I am not at all an HTML, XHTML, or JS expert, but as I understand it from lots of other folks this is no big deal. I think the easiest way to do that would be with a small snippet of JavaScript that would detect for Flash Player (or whatever the app requires) then location.replace you into the appropriate location within the application (which would need deep linking support, and there many ways to do that now). This, it seems to me is more complicated than necessary. I do this in my current app without any javascript snippet (cuz I dont know jack abou js!). I just read the parameter from the application object go to the right place in my app and load the appropriate data from the server. Do you do this after the page loads, or when the app is requested? Well, I guess I dont know when it happens. In flex, when an app loads, you can get the URL parameters in an object that is part of the applications object. I guess that happens when the page loads and then the page loads the swf. What's needed now is a concrete example to follow, or a set of patterns or standards, or whatever, that will ease the development of this second view of your app's content. I think the server side code to do this is more than just a standard. I think we need an entry point on the current adobe remoting products for adding XML to the HTML response of a url with addition field or query information. For Adobe's products, a tool that would help developers build something like that into their content systems, would be useful. It would be nice if Google and Adobe (and whoever else) could get together and figure out what these standards/patterns should look like, but there's no reason the development community can't get this figured out. :-) I dont think google needs to do much here. If we can get the server product to easily allow XML to enhance the HTML response then googles indexing will just work. I'd love to see this work in a concrete example. ;-) Again, I am not an HTML expert, (Claus is really the guy that has the expertise to be saying this) but this is really just the kind of stuff that he has been talking about. I am just putting a little more specific meat on the bone. I think Claus pointed to a flash website that does this that he mentioned earlier in this thread. Regards, Hank
Re: [flexcoders] Re: SEO Compatibility
I dont think google needs to do much here. If we can get the server product to easily allow XML to enhance the HTML response then googles indexing will just work. I'd love to see this work in a concrete example. ;-) Again, I am not an HTML expert, (Claus is really the guy that has the expertise to be saying this) but this is really just the kind of stuff that he has been talking about. I am just putting a little more specific meat on the bone. I think Claus pointed to a flash website that does this that he mentioned earlier in this thread. I don't know if i have any more expertise than you ;) But let me just say that XHTML *is* XML, and XHTML is all about semantics, ie. you *could* use XHTML both as the (perfect) format you use to feed to search engine bots *and* as the datasource for your Flash application/site. Of course you don't *need* to do the latter, you can also pipe the (same) data to Flash via remoting or whatever, but for any of your site's URLs the content a search engine bot sees and the content a human with JS/Flash enabled browser sees must be the same. The Flash website was http://guipaganini.com.br/ It supports deep linking, eg. http://guipaganini.com.br/12/75 View source (or switch off JS) to get the idea. The XHTML is loaded as is into Flash. I'm using the Symfony PHP5 framework on the server side. (Disclaimer: don't look too close at the Flash site, it's been a low budget project and i still need to finetune it) Cheers, Claus. -- claus wahlers côdeazur brasil http://codeazur.com.br/ http://wahlers.com.br/claus/blog/
Re: [flexcoders] Re: SEO Compatibility
Admin: Threads like that make a good start for a flexcoders wiki. This would also free JD from having to watch flexcoders during the night and at the weekend :) Any chance we get one? Cheers, Ralf. On 12/17/06, Mike Weiland [EMAIL PROTECTED] wrote: I was told this same information a couple months ago by a Google VP and engineer. Just keep the user experience in mind, that's not to say there are those out there google bombing and trying to beat the system. Mike Weiland - Mike Weiland Aspen Tree Media (877)659-1652 | FAX: (512)828-7105 http://www.AspenTreeMedia.com http://www.CertificateCreator.com - Create Print Awards and Certificates On 12/17/06 12:24 AM, Rich Rodecker [EMAIL PROTECTED] wrote: AND, re: the potential problem that Google punishes websites which in whatever way tweak the display of the indexed data (for example by adding a Flex UI layer on top), it would be TREMENDOUSLY helpful if Adobe would approach Google and once and for all clarifies what's allowed and what's not. If that's ever possible, that is. actually, google does not penalize for that. As long as as users can see the same content that the googlebot indexes, that's ok, it's not cloaking. I actually use detection on the server side and serve up text from the database rather than a swf if i detect a bot. I used to have a link to where google says that was acceptable, but I can't locate it at the moment, searching for it. On 12/16/06, dorkie dork from dorktown [EMAIL PROTECTED] mailto:dorkiedorkfromdorktown%40gmail.comdorkiedorkfromdorktown%40gmail.com wrote: I have had a few emails that were misunderstood to the point they really upset someone when it was not my intent at all. I think due to the frustration of the issue things might be taken out of hand. I'm going to one up all you guys and say JD AND Hank are both really nice guys. I've been on the list with both of them for the last 3 years. Anyway, back to the point. We need JD to present this to Adobe as issue that needs attention. We also need to be actively sending feature requests to the wish list and Google wish list (is there one?). The way features make it into next releases is mostly by majority vote and plausability (budget and other factors etc but still mainly majority rule). While I know google will eventually get to it because Flex apps will become more and more prevalent we can have them start addressing it now. The other thing we can do is make it known to google that we are creating Flex apps. There are no if ands or buts about it. They are coming. And if Google wants to index them they are going to have to work with Adobe to figure out a way to index dynamic content. --- The problem - Flex apps that have dynamic content are not searchable by search engines. Example, a Flex forum. The Scenario - Current search engines follow links, index content and keywords and rank based based on that and other criteria (trackback links etc) The Players - Developers, Clients, Adobe, Google, Yahoo, etc - Users The Solution: - Something developers could figure out. - Something Adobe, Google or both together could figure out -- best in my opinion ADOBE PULL RANK - Technically, it could be anything that works. Could be a completely new approach. Maybe Google can call public API's in the swf to get dynamic content. Whatever it is it, the ball needs to start moving in this direction. - All we need is something simple that works and doesn't interfere with our work In the mean time: - http://www.adobe.com/cfusion/mmform/index.cfm?name=wishform - [PLACE LINK TO GOOGLE WISH LIST HERE - no, i don't have it] - blog on it - continue to work through the issues in this thread. - send flowers to JD. come back JD we love you!!! you had us at hello?!?!? On 12/16/06, Cortlandt Winters [EMAIL PROTECTED] mailto:cortrah%40gmail.com cortrah%40gmail.com wrote: I would like to say that I feel strongly that jd has been poorly treated and wrongly insulted a number of times in this thread. I'd also like to suggest that allowing link spidering to dictate the future of content indexing may be shortsighted. It's convienient, but it gets worse every year as a way of finding information. Ten years ago Alta Vista was the stuff, today it's Google, but the nature of search engines is such that any year Google could find itself replaced by something else, rss being a perfect example for a specific kind of info. Also, as a side note, as advertisers and marketers optimize the hell out of their information, it gets harder to find real information on Google (and not have the first 5 pages of a simple query return only links to products). The natural progression is that that will continue until something else takes over the role. I realize that in many cases it makes sense to go with the flow for either marketing or technical reasons and that google is a useful tool, but it's far from the
Re: [flexcoders] Re: SEO Compatibility
I just wanted to chime in with some ideas, and to suggest that Claus's answer is the right one. First, this is a problem of standards. Adobe with Flex and Flash, try to keep things as open ended as possible, and so you can build your Flex/Flash apps in many ways to draw the data from some data source (SOAP/XML-RPC/Remoting from Flash, or using AJAX with a bridge connector, etc.). I think that's great and don't necessarily think Adobe needs to fix the problem, since I don't think it's Adobe's problem - I like the flexibility. This is a problem for Google and others, to fix, or perhaps one that there is already a solution for. What these search engines index is the content contained within structured _documents_, not web apps. Most current server side web apps will generate and serve structured documents to the web browser - and to the indexing spiders, but what Google and others are indexing is not the actual web app itself or it's business logic. They are indexing only the documents returned over http in (x)html format (or pdf, or other document formats). The problem with Flex/Flash/AJAX/Expression Blend apps, is that they are not documents, they are applications. How would Google or anyone else index something like Microsoft Word, or Adobe Photoshop. This is the appropriate way to look at these client side web apps, in my opinion. So I think the appropriate question to ask, is how can I, as an application/content provider, take advantage of Google, and others' indexing services. To me the answer is as Claus suggests - to build an alternative, server side web app, that serves the documents to spiders and bots (BTW, this can be produced before or after the UI - it's up to the developer ;-) ). The interesting question, and the place that needs focus, is what is the right way to direct traffic from those search pages back into the web app. I think the easiest way to do that would be with a small snippet of JavaScript that would detect for Flash Player (or whatever the app requires) then location.replace you into the appropriate location within the application (which would need deep linking support, and there many ways to do that now). What's needed now is a concrete example to follow, or a set of patterns or standards, or whatever, that will ease the development of this second view of your app's content. It would be nice if Google and Adobe (and whoever else) could get together and figure out what these standards/patterns should look like, but there's no reason the development community can't get this figured out. :-) Kevin N. Claus Wahlers wrote: AND, re: the potential problem that Google punishes websites which in whatever way tweak the display of the indexed data (for example by adding a Flex UI layer on top), it would be TREMENDOUSLY helpful if Adobe would approach Google and once and for all clarifies what's allowed and what's not. If that's ever possible, that is. PLUS.. ;) I'd be interested in how Ajax applications handle SEO, as they likely face the same, or similar problems. Cheers, Claus.
Re: [flexcoders] Re: SEO Compatibility
Kevin, I had a few inline comments on some of what you wrote since I had a few differences of opinion. On 12/18/06, Kevin Newman [EMAIL PROTECTED] wrote: I think that's great and don't necessarily think Adobe needs to fix the problem, since I don't think it's Adobe's problem - I like the flexibility. I think its definitely adobe's problem to the extent that they offer products that are client/server systems instead of just client tools. FDS and Cold Fusion should offer a way to facilitate this most important of issues. Adobe has defined a significant part of its business as building servers in the flash ecosystem. I dont think solving this issue would limit any flexibility. This is a problem for Google and others, to fix, or perhaps one that there is already a solution for. I dont see why this would be googles issue really at all. More on this below. The problem with Flex/Flash/AJAX/Expression Blend apps, is that they are not documents, they are applications. Actually, many such apps are *both* apps and documents and that is where the problem is. For example a discussion board is an app that manages and displays document type data that deserves to be indexed. How would Google or anyone else index something like Microsoft Word, or Adobe Photoshop. You correctly point out that these do not make sense for indexing, but these are not the kinds of apps that we are talking about for user generated content or webapps that have significant indexable data. To me the answer is as Claus suggests - to build an alternative, server side web app, that serves the documents to spiders and bots (BTW, this can be produced before or after the UI - it's up to the developer ;-) ). The interesting question, and the place that needs focus, is what is the right way to direct traffic from those search pages back into the web app. This it seems is not that interesting a question because it is the easy part. Flash/Flex apps can easily read data in the URL and go to the right place in the app which can then use remoting to get the data in the right format for the app. I think the easiest way to do that would be with a small snippet of JavaScript that would detect for Flash Player (or whatever the app requires) then location.replace you into the appropriate location within the application (which would need deep linking support, and there many ways to do that now). This, it seems to me is more complicated than necessary. I do this in my current app without any javascript snippet (cuz I dont know jack abou js!). I just read the parameter from the application object go to the right place in my app and load the appropriate data from the server. What's needed now is a concrete example to follow, or a set of patterns or standards, or whatever, that will ease the development of this second view of your app's content. I think the server side code to do this is more than just a standard. I think we need an entry point on the current adobe remoting products for adding XML to the HTML response of a url with addition field or query information. It would be nice if Google and Adobe (and whoever else) could get together and figure out what these standards/patterns should look like, but there's no reason the development community can't get this figured out. :-) I dont think google needs to do much here. If we can get the server product to easily allow XML to enhance the HTML response then googles indexing will just work. Regards, Hank
Re: Re: [flexcoders] Re: SEO Compatibility
AND, re: the potential problem that Google punishes websites which in whatever way tweak the display of the indexed data (for example by adding a Flex UI layer on top), it would be TREMENDOUSLY helpful if Adobe would approach Google and once and for all clarifies what's allowed and what's not. If that's ever possible, that is. actually, google does not penalize for that. As long as as users can see the same content that the googlebot indexes, that's ok, it's not cloaking. I actually use detection on the server side and serve up text from the database rather than a swf if i detect a bot. I used to have a link to where google says that was acceptable, but I can't locate it at the moment, searching for it. On 12/16/06, dorkie dork from dorktown [EMAIL PROTECTED] wrote: I have had a few emails that were misunderstood to the point they really upset someone when it was not my intent at all. I think due to the frustration of the issue things might be taken out of hand. I'm going to one up all you guys and say JD AND Hank are both really nice guys. I've been on the list with both of them for the last 3 years. Anyway, back to the point. We need JD to present this to Adobe as issue that needs attention. We also need to be actively sending feature requests to the wish list and Google wish list (is there one?). The way features make it into next releases is mostly by majority vote and plausability (budget and other factors etc but still mainly majority rule). While I know google will eventually get to it because Flex apps will become more and more prevalent we can have them start addressing it now. The other thing we can do is make it known to google that we are creating Flex apps. There are no if ands or buts about it. They are coming. And if Google wants to index them they are going to have to work with Adobe to figure out a way to index dynamic content. --- The problem - Flex apps that have dynamic content are not searchable by search engines. Example, a Flex forum. The Scenario - Current search engines follow links, index content and keywords and rank based based on that and other criteria (trackback links etc) The Players - Developers, Clients, Adobe, Google, Yahoo, etc - Users The Solution: - Something developers could figure out. - Something Adobe, Google or both together could figure out -- best in my opinion ADOBE PULL RANK - Technically, it could be anything that works. Could be a completely new approach. Maybe Google can call public API's in the swf to get dynamic content. Whatever it is it, the ball needs to start moving in this direction. - All we need is something simple that works and doesn't interfere with our work In the mean time: - http://www.adobe.com/cfusion/mmform/index.cfm?name=wishform - [PLACE LINK TO GOOGLE WISH LIST HERE - no, i don't have it] - blog on it - continue to work through the issues in this thread. - send flowers to JD. come back JD we love you!!! you had us at hello?!?!? On 12/16/06, Cortlandt Winters [EMAIL PROTECTED] wrote: I would like to say that I feel strongly that jd has been poorly treated and wrongly insulted a number of times in this thread. I'd also like to suggest that allowing link spidering to dictate the future of content indexing may be shortsighted. It's convienient, but it gets worse every year as a way of finding information. Ten years ago Alta Vista was the stuff, today it's Google, but the nature of search engines is such that any year Google could find itself replaced by something else, rss being a perfect example for a specific kind of info. Also, as a side note, as advertisers and marketers optimize the hell out of their information, it gets harder to find real information on Google (and not have the first 5 pages of a simple query return only links to products). The natural progression is that that will continue until something else takes over the role. I realize that in many cases it makes sense to go with the flow for either marketing or technical reasons and that google is a useful tool, but it's far from the endgame on indexing information. I do agree that it would be in Adobe's interest to make publishing well tagged information easier with built in components, tools, examples and specs, but it's really going to be hard for them to do something like that by themselves. They are probably better off waiting for developers to articulate the problems and brainstorm solutions until it's clear what they could do to help. Just my thoughts, not to be taken to seriously, but my real purpose of commenting here is that I don't think jd was well treated and I wanted to mention that.
Re: [flexcoders] Re: SEO Compatibility
I was told this same information a couple months ago by a Google VP and engineer. Just keep the user experience in mind, that¹s not to say there are those out there google bombing and trying to beat the system. Mike Weiland - Mike Weiland Aspen Tree Media (877)659-1652 | FAX: (512)828-7105 http://www.AspenTreeMedia.com http://www.CertificateCreator.com - Create Print Awards and Certificates On 12/17/06 12:24 AM, Rich Rodecker [EMAIL PROTECTED] wrote: AND, re: the potential problem that Google punishes websites which in whatever way tweak the display of the indexed data (for example by adding a Flex UI layer on top), it would be TREMENDOUSLY helpful if Adobe would approach Google and once and for all clarifies what's allowed and what's not. If that's ever possible, that is. actually, google does not penalize for that. As long as as users can see the same content that the googlebot indexes, that's ok, it's not cloaking. I actually use detection on the server side and serve up text from the database rather than a swf if i detect a bot. I used to have a link to where google says that was acceptable, but I can't locate it at the moment, searching for it. On 12/16/06, dorkie dork from dorktown [EMAIL PROTECTED] mailto:dorkiedorkfromdorktown%40gmail.com wrote: I have had a few emails that were misunderstood to the point they really upset someone when it was not my intent at all. I think due to the frustration of the issue things might be taken out of hand. I'm going to one up all you guys and say JD AND Hank are both really nice guys. I've been on the list with both of them for the last 3 years. Anyway, back to the point. We need JD to present this to Adobe as issue that needs attention. We also need to be actively sending feature requests to the wish list and Google wish list (is there one?). The way features make it into next releases is mostly by majority vote and plausability (budget and other factors etc but still mainly majority rule). While I know google will eventually get to it because Flex apps will become more and more prevalent we can have them start addressing it now. The other thing we can do is make it known to google that we are creating Flex apps. There are no if ands or buts about it. They are coming. And if Google wants to index them they are going to have to work with Adobe to figure out a way to index dynamic content. --- The problem - Flex apps that have dynamic content are not searchable by search engines. Example, a Flex forum. The Scenario - Current search engines follow links, index content and keywords and rank based based on that and other criteria (trackback links etc) The Players - Developers, Clients, Adobe, Google, Yahoo, etc - Users The Solution: - Something developers could figure out. - Something Adobe, Google or both together could figure out -- best in my opinion ADOBE PULL RANK - Technically, it could be anything that works. Could be a completely new approach. Maybe Google can call public API's in the swf to get dynamic content. Whatever it is it, the ball needs to start moving in this direction. - All we need is something simple that works and doesn't interfere with our work In the mean time: - http://www.adobe.com/cfusion/mmform/index.cfm?name=wishform - [PLACE LINK TO GOOGLE WISH LIST HERE - no, i don't have it] - blog on it - continue to work through the issues in this thread. - send flowers to JD. come back JD we love you!!! you had us at hello?!?!? On 12/16/06, Cortlandt Winters [EMAIL PROTECTED] mailto:cortrah%40gmail.com wrote: I would like to say that I feel strongly that jd has been poorly treated and wrongly insulted a number of times in this thread. I'd also like to suggest that allowing link spidering to dictate the future of content indexing may be shortsighted. It's convienient, but it gets worse every year as a way of finding information. Ten years ago Alta Vista was the stuff, today it's Google, but the nature of search engines is such that any year Google could find itself replaced by something else, rss being a perfect example for a specific kind of info. Also, as a side note, as advertisers and marketers optimize the hell out of their information, it gets harder to find real information on Google (and not have the first 5 pages of a simple query return only links to products). The natural progression is that that will continue until something else takes over the role. I realize that in many cases it makes sense to go with the flow for either marketing or technical reasons and that google is a useful tool, but it's far from the endgame on indexing information. I do agree that it would be in Adobe's interest to make publishing well tagged information easier with built in components, tools, examples and specs, but it's
Re: [flexcoders] Re: SEO Compatibility
Adobe: Yes google will index your Flex app. It reads the text in the file and keywords in the html page (basically etc). Flex is SEO friendly. Doug: Sure, google will show your link to your site for resturant review but it does not index the dynamic data in that site. So if someone is searching for Casa Bonita (sings melody) and not resturant review the site will not be listed because google does not know that resturant review.com contains information about Casa Bonita. At least not without unnatural restructuring of the application and application wrapper. Me: I do not know if search engines can find and index this information. A concrete example that a Flex app with dynamic data is being index would suffice that it is not an issue. If it is an issue, referring specifically about dynamic data, not static, then a distinction should be made to clarify this conversation. Flex = SEO friendly Dynamic data in Flex = Impossible without modifications(?) Right? So putting everything else aside... we could say that some people want more support in this area or at least a better answer (or recommend solution) to this specific issue. /end of message /start of suggested solution We all know how a search engine works. It finds a site, indexes the content on the home page and then crawls through the rest of it *by following links*. Each page it finds it indexes the content on those pages. So lets say we have a comic book forum created in flex. Our flex app has 3 main states, forum index, forum posts (newest ten shown) and forum message thread. In an HTML site the search engine would follow the each forum link and then read in the forum posts page and follow those links and read in each message thread. Right now Flex apps have no links to follow because they do not deal with pages they deal with states. So what if on each state we wrote out html anchors to the browser dynamically? Using something like URLKit you can go to different states in your Flex app by url. So in your comic book forum your page loads, the flex app writes links to the page after content is received from the server. Google comes along finds page, finds the content, indexes it, finds the links and recursively goes through the site. It is unknown how google indexes so this may not be possible of course but I'm saying, if we build it they will come - and adopt it or rewrite it. -er, this also works, if we want it they will build it. dorkie cant sleep dork from dorktown I think we can come up with a solution. the problem you are saying is how to index dynamic data. On 12/15/06, Doug McCune [EMAIL PROTECTED] wrote: OK, right, we were talking about two different things. Sorry if this has caused confusion. I was talking about dynamic data being indexable by search engines. You were talking about search engine optimization for static content (sorry again if I'm still misunderstanding). I guess I never think about search engine optimization in terms other than how to get your dynamic content indexed by search engines. If I have a restaurant review website I want google to index every review that my users write. I don't know what you call this is if doesn't count as search engine optimization, but I guess that's not what the term means. If I run a restaurant review website I don't want to show up for someone searching restaurant reviews. I want to show up for someone searching El Farolito burritos. And there's no way I can optimize static content with restaurant names or with what users are going to write. But I guess that's not SEO, my bad. John Dowdell wrote: I'm out of this conversation, sorry... if I say start with the search terms you're trying to be found on and don't get acknowledgment, I'll just bow out now. (That restaurant sample applet, I have no idea if it's data-fed text or internal text, and don't see mentions of E Coli myself, and that's not the common type of things people are looking for with search engine optimization. Undefined terms make the convo go 'round.) Recap: Work in Adobe Flex produces SWF files. Text within SWF files can be found and used by the search engines (contrary to widespread myth). Example: http://www.google.com/search?q=%22contrary+evidence%22+filetype%3Aswf If your content includes material fed in via database, then the search engine would not usually see that you use those words. As with all SEO tasks, you'd first figure what search terms you have a chance to compete on (eg, you will never appear on the first page of results for search terms like buy flowers online). Then set up your HTML hosting page with TITLE, URL, metadata and reinforcement of the targeted text terms. Then make sure you get plenty of inbound links from authoritative sources, preferably with your targeted search terms as anchor text. jd -- John Dowdell . Adobe Developer Support . San Francisco CA USA Weblog: http://weblogs.macromedia.com/jd Aggregator: http://weblogs.macromedia.com/mxna Technotes:
RE: [flexcoders] Re: SEO Compatibility
Google, Yahoo, and Microsoft already agreed on what they feel is the best solution for indexing dynamic data. Le the site owners do it. Soon all you will need to do is make an xml file with entries containing a link, a description and the keywords. Their engines will read your xml file and then your dynamic content will be indexed. This way it will be easy for content management systems to make SEO automated. --Kelly http://blog.searchenginewatch.com/blog/061116-01 http://www.sitemaps.org/ What are Sitemaps? Sitemaps are an easy way for webmasters to inform search engines about pages on their sites that are available for crawling. In its simplest form, a Sitemap is an XML file that lists URLs for a site along with additional metadata about each URL (when it was last updated, how often it usually changes, and how important it is, relative to other URLs in the site) so that search engines can more intelligently crawl the site. Web crawlers usually discover pages from links within the site and from other sites. Sitemaps supplement this data to allow crawlers that support Sitemaps to pick up all URLs in the Sitemap and learn about those URLs using the associated metadata. Using the Sitemap protocol http://www.sitemaps.org/protocol.html does not guarantee that web pages are included in search engines, but provides hints for web crawlers to do a better job of crawling your site. Sitemap 0.90 is offered under the terms of the Attribution-ShareAlike http://creativecommons.org/licenses/by-sa/2.5/ Creative Commons License and has wide adoption, including support from Google, Yahoo!, and Microsoft. _ From: flexcoders@yahoogroups.com [mailto:[EMAIL PROTECTED] On Behalf Of dorkie dork from dorktown Sent: Saturday, December 16, 2006 2:01 AM To: flexcoders@yahoogroups.com Subject: Re: [flexcoders] Re: SEO Compatibility Adobe: Yes google will index your Flex app. It reads the text in the file and keywords in the html page (basically etc). Flex is SEO friendly. Doug: Sure, google will show your link to your site for resturant review but it does not index the dynamic data in that site. So if someone is searching for Casa Bonita (sings melody) and not resturant review the site will not be listed because google does not know that resturant review.com contains information about Casa Bonita. At least not without unnatural restructuring of the application and application wrapper. Me: I do not know if search engines can find and index this information. A concrete example that a Flex app with dynamic data is being index would suffice that it is not an issue. If it is an issue, referring specifically about dynamic data, not static, then a distinction should be made to clarify this conversation. Flex = SEO friendly Dynamic data in Flex = Impossible without modifications(?) Right? So putting everything else aside... we could say that some people want more support in this area or at least a better answer (or recommend solution) to this specific issue. /end of message /start of suggested solution We all know how a search engine works. It finds a site, indexes the content on the home page and then crawls through the rest of it *by following links*. Each page it finds it indexes the content on those pages. So lets say we have a comic book forum created in flex. Our flex app has 3 main states, forum index, forum posts (newest ten shown) and forum message thread. In an HTML site the search engine would follow the each forum link and then read in the forum posts page and follow those links and read in each message thread. Right now Flex apps have no links to follow because they do not deal with pages they deal with states. So what if on each state we wrote out html anchors to the browser dynamically? Using something like URLKit you can go to different states in your Flex app by url. So in your comic book forum your page loads, the flex app writes links to the page after content is received from the server. Google comes along finds page, finds the content, indexes it, finds the links and recursively goes through the site. It is unknown how google indexes so this may not be possible of course but I'm saying, if we build it they will come - and adopt it or rewrite it. -er, this also works, if we want it they will build it. dorkie cant sleep dork from dorktown I think we can come up with a solution. the problem you are saying is how to index dynamic data. On 12/15/06, Doug McCune [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] edu wrote: OK, right, we were talking about two different things. Sorry if this has caused confusion. I was talking about dynamic data being indexable by search engines. You were talking about search engine optimization for static content (sorry again if I'm still misunderstanding). I guess I never think about search engine optimization in terms other than how to get your dynamic content indexed
Re: [flexcoders] Re: SEO Compatibility
On 12/15/06, John Dowdell [EMAIL PROTECTED] wrote: I'm out of this conversation, sorry... if I say start with the search terms you're trying to be found on and don't get acknowledgment, I'll just bow out now. Real problem, no solution. As the adobe rep... how arrogant. Hank
Re: [flexcoders] Re: SEO Compatibility
On 12/15/06, John Dowdell [EMAIL PROTECTED] wrote: I'm out of this conversation, sorry... if I say start with the search terms you're trying to be found on and don't get acknowledgment, I'll just bow out now. of E Coli myself, and that's not the common type of things people are looking for with search engine optimization. By the way the concept that E Coli is not a word that would be relevant for SEO is one of the most ridiculous things I have heard from someone that purports some level of expertise. The idea of being search friendly in the context that was being discussed is obviously that people should be able to use google to find things on postings or user generated content. I am sure that Mr Dowdell understands this and must be trying to play some kind of word games. The issue that is being brought forth here does not require a phd to understand, so the fact that he feigns not understanding so that he can claim the conversation invalid because its going round and round is just amazing. Hank Recap: Work in Adobe Flex produces SWF files. Text within SWF files can be found and used by the search engines (contrary to widespread myth). Example: http://www.google.com/search?q=%22contrary+evidence%22+filetype%3Aswf If your content includes material fed in via database, then the search engine would not usually see that you use those words. As with all SEO tasks, you'd first figure what search terms you have a chance to compete on (eg, you will never appear on the first page of results for search terms like buy flowers online). Then set up your HTML hosting page with TITLE, URL, metadata and reinforcement of the targeted text terms. Then make sure you get plenty of inbound links from authoritative sources, preferably with your targeted search terms as anchor text. jd -- John Dowdell . Adobe Developer Support . San Francisco CA USA Weblog: http://weblogs.macromedia.com/jd Aggregator: http://weblogs.macromedia.com/mxna Technotes: http://www.macromedia.com/support/ Spam killed my private email -- public record is best, thanks. -- Flexcoders Mailing List FAQ: http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txt Search Archives: http://www.mail-archive.com/flexcoders%40yahoogroups.com Yahoo! Groups Links
Re: [flexcoders] Re: SEO Compatibility
On 12/15/06, Doug McCune [EMAIL PROTECTED] wrote: OK, right, we were talking about two different things. Sorry if this has caused confusion. I was talking about dynamic data being indexable by search engines. You were talking about search engine optimization for static content (sorry again if I'm still misunderstanding). I guess I never think about search engine optimization in terms other than how to get your dynamic content indexed by search engines. If I have a restaurant review website I want google to index every review that my users write. I don't know what you call this is if doesn't count as search engine optimization, but I guess that's not what the term means. If I run a restaurant review website I don't want to show up for someone searching restaurant reviews. I want to show up for someone searching El Farolito burritos. And there's no way I can optimize static content with restaurant names or with what users are going to write. But I guess that's not SEO, my bad. Doug, Whether you were using the word SEO in exactly the right way is not the point. The irony is that SEO means search engine *optimization*. If certain types of data are not searchable at all, then optimization is clearly not possible. Your examples were clear and everyone except Mr. Dowdell knew what you were talking about because we probably unlike him) spend lots of time trying to figure out how to deal with it. And the issue you are raising is a real one that is an important one to address. It would indeed be much better for adobe to say that they understand the issue and build something that would be of assistance, the same way that they did with the history manager. It is indeed frustrating to watch them play cute word games with the issue instead of just saying yes it is a problem we realize, and at some point we are going to put some resources on it. In short, its not your bad and you have no reason to apologize. Mr. Dowdell's response to you was inappropriate. Regards, Hank John Dowdell wrote: I'm out of this conversation, sorry... if I say start with the search terms you're trying to be found on and don't get acknowledgment, I'll just bow out now. (That restaurant sample applet, I have no idea if it's data-fed text or internal text, and don't see mentions of E Coli myself, and that's not the common type of things people are looking for with search engine optimization. Undefined terms make the convo go 'round.) Recap: Work in Adobe Flex produces SWF files. Text within SWF files can be found and used by the search engines (contrary to widespread myth). Example: http://www.google.com/search?q=%22contrary+evidence%22+filetype%3Aswf If your content includes material fed in via database, then the search engine would not usually see that you use those words. As with all SEO tasks, you'd first figure what search terms you have a chance to compete on (eg, you will never appear on the first page of results for search terms like buy flowers online). Then set up your HTML hosting page with TITLE, URL, metadata and reinforcement of the targeted text terms. Then make sure you get plenty of inbound links from authoritative sources, preferably with your targeted search terms as anchor text. jd -- John Dowdell . Adobe Developer Support . San Francisco CA USA Weblog: http://weblogs.macromedia.com/jd Aggregator: http://weblogs.macromedia.com/mxna Technotes: http://www.macromedia.com/support/ Spam killed my private email -- public record is best, thanks.
Re: [flexcoders] Re: SEO Compatibility
This discussions hits the mailinglists and forums since forever. It seems to me that Adobe still is five or more generations behind their own technology with respect to SEO. A while back i wrote an article about that very topic: http://wahlers.com.br/claus/blog/seffs-to-flash-or-not-to-flash/ You can see this method in action in this (Flash-)website: http://guipaganini.com.br/ Hope this helps a bit. Cheers, Claus. -- claus wahlers côdeazur brasil http://codeazur.com.br/ http://wahlers.com.br/claus/blog/
Re: [flexcoders] Re: SEO Compatibility
Claus, You are of course right to suggest building an XHTML version first, as a strategy, but there are two problems with this. 1. One of the issues is that good product design usual requires that you develop the interface first. The interface drives the content and data needed. What you are suggesting may help acheive the best underpinnings, but it is very hard to design a good product if you start with the data. The best way to design is really to start with the UI, which flex is very good at. So you end up with Flex code first and you tweak it with real users etc. So you probably use some kind or remoting model. Now you are left trying to figure out a good way to make your remoting based stuff searchable. 2. Even if you decide to do it the way you describe, which is to start out with an XHTML framework, this model really does not fit the remoting model very well because you cant build a pure XHTML site based around remoting. So what you are really suggesting is that you cant use remoting, which is a cornerstone of the Flex development model, and develop a searchable product. But throwing out the whole concept of remoting is really not very appealing from a development model. Now, I am sure that it is possible to build a framework that would help to resolve these issues (and it would be great if adobe would develop such a thing), but certainly just saying use XHTML first would be a very hard task for most people, without such a framework, to do in a clean Flex/remoting friendly way. Regards, Hank On 12/16/06, Claus Wahlers [EMAIL PROTECTED] wrote: This discussions hits the mailinglists and forums since forever. It seems to me that Adobe still is five or more generations behind their own technology with respect to SEO. A while back i wrote an article about that very topic: http://wahlers.com.br/claus/blog/seffs-to-flash-or-not-to-flash/ You can see this method in action in this (Flash-)website: http://guipaganini.com.br/ Hope this helps a bit. Cheers, Claus. -- claus wahlers côdeazur brasil http://codeazur.com.br/ http://wahlers.com.br/claus/blog/ -- Flexcoders Mailing List FAQ: http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txt Search Archives: http://www.mail-archive.com/flexcoders%40yahoogroups.com Yahoo! Groups Links
Re: [flexcoders] Re: SEO Compatibility
Hank, disclaimer: I didn't say that method works for everybody everywhere, nor that execution is easy. It's also more targeted towards Flash websites, not Flex. I too think that it's Adobes job to provide a framework to make these things easier for the developer. I don't agree with your UI-design-first approach though. Content should always come first. No content, no UI. At the very least, both should be developed hand in hand. In any case, for an application/website to be truly SEO'ed, you need a HTML site underneath that search engines can spider. This is all about data and nothing else, and it needs a 1:1 relation to the data that the human user is going to get when she clicks on a link presented by search engines (wrapped in a Flex UI or whatever). Cheers, Claus. You are of course right to suggest building an XHTML version first, as a strategy, but there are two problems with this. 1. One of the issues is that good product design usual requires that you develop the interface first. The interface drives the content and data needed. What you are suggesting may help acheive the best underpinnings, but it is very hard to design a good product if you start with the data. The best way to design is really to start with the UI, which flex is very good at. So you end up with Flex code first and you tweak it with real users etc. So you probably use some kind or remoting model. Now you are left trying to figure out a good way to make your remoting based stuff searchable. 2. Even if you decide to do it the way you describe, which is to start out with an XHTML framework, this model really does not fit the remoting model very well because you cant build a pure XHTML site based around remoting. So what you are really suggesting is that you cant use remoting, which is a cornerstone of the Flex development model, and develop a searchable product. But throwing out the whole concept of remoting is really not very appealing from a development model. Now, I am sure that it is possible to build a framework that would help to resolve these issues (and it would be great if adobe would develop such a thing), but certainly just saying use XHTML first would be a very hard task for most people, without such a framework, to do in a clean Flex/remoting friendly way. Regards, Hank -- claus wahlers côdeazur brasil http://codeazur.com.br/ http://wahlers.com.br/claus/blog/
Re: [flexcoders] Re: SEO Compatibility
Well of course we agree on most if this. And of course your general thrust that a spiderable HTML underpinning is necessary for search engines is right. But on the UI issue perhaps a slight divergence. Perhaps you can do data and UI hand in hand, but my view is that you dont know what your product should really be until you do some form of UI that you can test against real users who can tell you whether you are on the right track. This typically means building some form of UI, perhaps a wireframe though this will give you less good feedback, perhaps not even tied to a server but with mocked up data, for them to experience. If you go right to a data model, then you dont know if the content that you are trying to present is what the user really needs or wants. So I am always focused on making sure that what I am doing is what the user wants first. Once you know you are on the right track, then you can build a data model to present the user what they need. Of course this does not mean that great code cannot be written lots of other ways! Yup i think we can agree on that :) Btw, this just popped up in MXNA, very relevant to this discussion: http://www.randomusa.com/flash/index.php?entryID=1875 I just wished Adobe would actively approach and discuss the problem we are facing. I don't even ask for solutions. Maybe a technote that addresses this in some way would already be helpful. Cheers, Claus. -- claus wahlers côdeazur brasil http://codeazur.com.br/ http://wahlers.com.br/claus/blog/
Re: [flexcoders] Re: SEO Compatibility
I just wished Adobe would actively approach and discuss the problem we are facing. I don't even ask for solutions. Maybe a technote that addresses this in some way would already be helpful. AND, re: the potential problem that Google punishes websites which in whatever way tweak the display of the indexed data (for example by adding a Flex UI layer on top), it would be TREMENDOUSLY helpful if Adobe would approach Google and once and for all clarifies what's allowed and what's not. If that's ever possible, that is. Cheers, Claus. -- claus wahlers côdeazur brasil http://codeazur.com.br/ http://wahlers.com.br/claus/blog/
Re: [flexcoders] Re: SEO Compatibility
AND, re: the potential problem that Google punishes websites which in whatever way tweak the display of the indexed data (for example by adding a Flex UI layer on top), it would be TREMENDOUSLY helpful if Adobe would approach Google and once and for all clarifies what's allowed and what's not. If that's ever possible, that is. PLUS.. ;) I'd be interested in how Ajax applications handle SEO, as they likely face the same, or similar problems. Cheers, Claus. -- claus wahlers côdeazur brasil http://codeazur.com.br/ http://wahlers.com.br/claus/blog/
Re: [flexcoders] Re: SEO Compatibility
PLUS.. ;) I'd be interested in how Ajax applications handle SEO, as they likely face the same, or similar problems. Ok, Ajax apps probably don't face as much problems as Flex apps as the displayed data is HTML and contains links that spiders can follow, so disregard this. Sorry for talking to myself on a Saturday night. No, i don't have a life. Have a nice weekend, everyone! Cheers, Claus. -- claus wahlers côdeazur brasil http://codeazur.com.br/ http://wahlers.com.br/claus/blog/
Re: [flexcoders] Re: SEO Compatibility
On 12/17/06, Claus Wahlers [EMAIL PROTECTED] wrote: PLUS.. ;) I'd be interested in how Ajax applications handle SEO, as they likely face the same, or similar problems. Ok, Ajax apps probably don't face as much problems as Flex apps as the displayed data is HTML and contains links that spiders can follow, so disregard this. No, actually, you're quite right, Claus. A lot of data is displayed in AJAX by a Javascript function loading data via an XMLHttpRequest object, and writing the contents of the request into the current document. Spiders won't be able to follow the links in the Javascript functions, and so won't see the results. Ian
Re: [flexcoders] Re: SEO Compatibility
I would like to say that I feel strongly that jd has been poorly treated and wrongly insulted a number of times in this thread. I'd also like to suggest that allowing link spidering to dictate the future of content indexing may be shortsighted. It's convienient, but it gets worse every year as a way of finding information. Ten years ago Alta Vista was the stuff, today it's Google, but the nature of search engines is such that any year Google could find itself replaced by something else, rss being a perfect example for a specific kind of info. Also, as a side note, as advertisers and marketers optimize the hell out of their information, it gets harder to find real information on Google (and not have the first 5 pages of a simple query return only links to products). The natural progression is that that will continue until something else takes over the role. I realize that in many cases it makes sense to go with the flow for either marketing or technical reasons and that google is a useful tool, but it's far from the endgame on indexing information. I do agree that it would be in Adobe's interest to make publishing well tagged information easier with built in components, tools, examples and specs, but it's really going to be hard for them to do something like that by themselves. They are probably better off waiting for developers to articulate the problems and brainstorm solutions until it's clear what they could do to help. Just my thoughts, not to be taken to seriously, but my real purpose of commenting here is that I don't think jd was well treated and I wanted to mention that.
Re: [flexcoders] Re: SEO Compatibility
dougmccune wrote: While I know Adobe employees don't like to admit this, the answer is very simple: It is often impossible, and if not impossible then at least extremely difficult, to get your Flex content indexed by search engines. That's the straight answer. No more no less. A particular concrete example might help bring this conversation back to ground. Work using Flex as the creation tool can certainly be found by search engines. Identifying your reasonable target search terms is the first step. jd -- John Dowdell . Adobe Developer Support . San Francisco CA USA Weblog: http://weblogs.macromedia.com/jd Aggregator: http://weblogs.macromedia.com/mxna Technotes: http://www.macromedia.com/support/ Spam killed my private email -- public record is best, thanks.
Re: [flexcoders] Re: SEO Compatibility
On 12/15/06, John Dowdell [EMAIL PROTECTED] wrote: dougmccune wrote: While I know Adobe employees don't like to admit this, the answer is very simple: It is often impossible, and if not impossible then at least extremely difficult, to get your Flex content indexed by search engines. That's the straight answer. No more no less. A particular concrete example might help bring this conversation back to ground. I think in the body of his message in the next paragraph down from where you stopped quoting, he did exactly that. He provided a very concrete example of the problem that is faced. You proceeded to quote him and *not* quote exactly what you are asking for. Its funny but your additional response is almost humorous in its manner of highlighting his very good point about the adobe perspective on all of this. The first step to fixing the problem is when someone admits it. Hank
Re: [flexcoders] Re: SEO Compatibility
How about this one as an example: the Adobe Restaurant Finder sample app, with the Recent Reviews page in particular. The app is here: http://examples.adobe.com/flex2/inproduct/sdk/restaurant/recentReviews.html If you look at that app you can see user submitted reviews of restaurants. For example, there's a review of Addis Red Sea and the reviewer mentions E. Coli in the review. If anyone did a search for Addis Red Sea and E Coli this page would never come up. The only possible way to get the site to appear in search results would be to publish an alternative HTML version of all the reviews. And in fact a complete Google search for everything on examples.adobe.com shows that you can't find anything useful: http://www.google.com/search?q=site:examples.adobe.com+hl=enlr=filter=0 Yes, the Restaurant Finder app wrapper HTML page is indexed, but that's useless. Now, a Google search for ecoli on Yelp turns up tons of user-submitted results: http://www.google.com/search?hl=enlr=q=site%3Ayelp.com+ecoli The Yelp team would never give that up. They simply can't do Yelp in Flex because they'd lose the search engine indexing. Now, I'm not saying that this is a huge problem. All it means is that at the moment Flex is not the answer for many websites. That's OK, Flex is still great at what it does well. But if you want any of your dynamic content indexed by search engines Flex is not the way to go. And it's not a matter of just thinking about how to include keywords. Flex just simply isn't an option, nor does it need to be, for websites like this. Use Flex for what it does, but trying to make a website in Flex that needs to be indexed by a search engine simply isn't an option at the moment. And this example of the restaurant review stuff is a typical example of tons of other types of websites that shouldn't be done in Flex. Blogs, news sites, message boards, the list goes on and on. But if you're doing some stuff that needs data visualization or you can do without search engine indexing, then by all means use Flex. And I say this as a HUGE fan of Flex. People just need to use it for what it's good at. Doug John Dowdell wrote: dougmccune wrote: While I know Adobe employees don't like to admit this, the answer is very simple: It is often impossible, and if not impossible then at least extremely difficult, to get your Flex content indexed by search engines. That's the straight answer. No more no less. A particular concrete example might help bring this conversation back to ground. Work using Flex as the creation tool can certainly be found by search engines. Identifying your reasonable target search terms is the first step. jd -- John Dowdell . Adobe Developer Support . San Francisco CA USA Weblog: http://weblogs.macromedia.com/jd http://weblogs.macromedia.com/jd Aggregator: http://weblogs.macromedia.com/mxna http://weblogs.macromedia.com/mxna Technotes: http://www.macromedia.com/support/ http://www.macromedia.com/support/ Spam killed my private email -- public record is best, thanks.
Re: [flexcoders] Re: SEO Compatibility
I'm out of this conversation, sorry... if I say start with the search terms you're trying to be found on and don't get acknowledgment, I'll just bow out now. (That restaurant sample applet, I have no idea if it's data-fed text or internal text, and don't see mentions of E Coli myself, and that's not the common type of things people are looking for with search engine optimization. Undefined terms make the convo go 'round.) Recap: Work in Adobe Flex produces SWF files. Text within SWF files can be found and used by the search engines (contrary to widespread myth). Example: http://www.google.com/search?q=%22contrary+evidence%22+filetype%3Aswf If your content includes material fed in via database, then the search engine would not usually see that you use those words. As with all SEO tasks, you'd first figure what search terms you have a chance to compete on (eg, you will never appear on the first page of results for search terms like buy flowers online). Then set up your HTML hosting page with TITLE, URL, metadata and reinforcement of the targeted text terms. Then make sure you get plenty of inbound links from authoritative sources, preferably with your targeted search terms as anchor text. jd -- John Dowdell . Adobe Developer Support . San Francisco CA USA Weblog: http://weblogs.macromedia.com/jd Aggregator: http://weblogs.macromedia.com/mxna Technotes: http://www.macromedia.com/support/ Spam killed my private email -- public record is best, thanks.
Re: [flexcoders] Re: SEO Compatibility
Saying you shouldn't use Flex for content-focused website is going a little bit over the edge IMHO. I think we all definitely agree that for 100% content-focused sites, you should use HTML, and for 100% data-focused sites, you should use Flex. However in between those extremes, you can still use Flex and get your data indexed. For example, if you're going to create a blog in Flex, you are probably going to use some sort of ready-made blogging engine and plug it into a Flex front-end, using whatever means you feel are right (for example, using XML-RPC if you're using WordPress). Well, blogging engines create RSS feeds, and Google will index an RSS feed just fine. Then it's a matter of adding a link to the RSS feed in the HTML for the Flex app. Similarly if you create a message board. While I'm not convinced creating a blog or a message board interface in Flex is smart (I would advise against it personally), if you want to do it, you have options for getting it indexed. You don't have to sound angry when you're talking about it. It just sounds like you're trying to say PEOPLE, DON'T USE SCREWDRIVERS, YOU CAN'T DRIVE NAILS WITH THEM. Dude, that's why we have hammers. Patrick Doug McCune a écrit : How about this one as an example: the Adobe Restaurant Finder sample app, with the Recent Reviews page in particular. The app is here: http://examples. adobe.com/ flex2/inproduct/ sdk/restaurant/ recentReviews. html http://examples.adobe.com/flex2/inproduct/sdk/restaurant/recentReviews.html If you look at that app you can see user submitted reviews of restaurants. For example, there's a review of Addis Red Sea and the reviewer mentions E. Coli in the review. If anyone did a search for Addis Red Sea and E Coli this page would never come up. The only possible way to get the site to appear in search results would be to publish an alternative HTML version of all the reviews. And in fact a complete Google search for everything on examples.adobe. com shows that you can't find anything useful: http://www.google. com/search? q=site:examples. adobe.com+hl=enlr=filter=0 http://www.google.com/search?q=site:examples.adobe.com+hl=enlr=filter=0 Yes, the Restaurant Finder app wrapper HTML page is indexed, but that's useless. Now, a Google search for ecoli on Yelp turns up tons of user-submitted results: http://www.google. com/search? hl=enlr=q=site%3Ayelp. com+ecoli http://www.google.com/search?hl=enlr=q=site%3Ayelp.com+ecoli The Yelp team would never give that up. They simply can't do Yelp in Flex because they'd lose the search engine indexing. Now, I'm not saying that this is a huge problem. All it means is that at the moment Flex is not the answer for many websites. That's OK, Flex is still great at what it does well. But if you want any of your dynamic content indexed by search engines Flex is not the way to go. And it's not a matter of just thinking about how to include keywords. Flex just simply isn't an option, nor does it need to be, for websites like this. Use Flex for what it does, but trying to make a website in Flex that needs to be indexed by a search engine simply isn't an option at the moment. And this example of the restaurant review stuff is a typical example of tons of other types of websites that shouldn't be done in Flex. Blogs, news sites, message boards, the list goes on and on. But if you're doing some stuff that needs data visualization or you can do without search engine indexing, then by all means use Flex. And I say this as a HUGE fan of Flex. People just need to use it for what it's good at. Doug John Dowdell wrote: dougmccune wrote: While I know Adobe employees don't like to admit this, the answer is very simple: It is often impossible, and if not impossible then at least extremely difficult, to get your Flex content indexed by search engines. That's the straight answer. No more no less. A particular concrete example might help bring this conversation back to ground. Work using Flex as the creation tool can certainly be found by search engines. Identifying your reasonable target search terms is the first step. jd -- John Dowdell . Adobe Developer Support . San Francisco CA USA Weblog: http://weblogs. macromedia. com/jd http://weblogs.macromedia.com/jd Aggregator: http://weblogs. macromedia. com/mxna http://weblogs.macromedia.com/mxna Technotes: http://www.macromed ia.com/support/ http://www.macromedia.com/support/ Spam killed my private email -- public record is best, thanks.
Re: [flexcoders] Re: SEO Compatibility
OK, right, we were talking about two different things. Sorry if this has caused confusion. I was talking about dynamic data being indexable by search engines. You were talking about search engine optimization for static content (sorry again if I'm still misunderstanding). I guess I never think about search engine optimization in terms other than how to get your dynamic content indexed by search engines. If I have a restaurant review website I want google to index every review that my users write. I don't know what you call this is if doesn't count as search engine optimization, but I guess that's not what the term means. If I run a restaurant review website I don't want to show up for someone searching restaurant reviews. I want to show up for someone searching El Farolito burritos. And there's no way I can optimize static content with restaurant names or with what users are going to write. But I guess that's not SEO, my bad. John Dowdell wrote: I'm out of this conversation, sorry... if I say start with the search terms you're trying to be found on and don't get acknowledgment, I'll just bow out now. (That restaurant sample applet, I have no idea if it's data-fed text or internal text, and don't see mentions of E Coli myself, and that's not the common type of things people are looking for with search engine optimization. Undefined terms make the convo go 'round.) Recap: Work in Adobe Flex produces SWF files. Text within SWF files can be found and used by the search engines (contrary to widespread myth). Example: http://www.google.com/search?q=%22contrary+evidence%22+filetype%3Aswf http://www.google.com/search?q=%22contrary+evidence%22+filetype%3Aswf If your content includes material fed in via database, then the search engine would not usually see that you use those words. As with all SEO tasks, you'd first figure what search terms you have a chance to compete on (eg, you will never appear on the first page of results for search terms like buy flowers online). Then set up your HTML hosting page with TITLE, URL, metadata and reinforcement of the targeted text terms. Then make sure you get plenty of inbound links from authoritative sources, preferably with your targeted search terms as anchor text. jd -- John Dowdell . Adobe Developer Support . San Francisco CA USA Weblog: http://weblogs.macromedia.com/jd http://weblogs.macromedia.com/jd Aggregator: http://weblogs.macromedia.com/mxna http://weblogs.macromedia.com/mxna Technotes: http://www.macromedia.com/support/ http://www.macromedia.com/support/ Spam killed my private email -- public record is best, thanks.
RE: [flexcoders] Re: SEO Compatibility
I will chime in on this as well, but from a different perspective. IMHO this can't be complete weighted on the shoulders of Adobe. HTML has been around for a long time, and the need to search and catalog HTML has risen with the growing usage of HTML. In turn, companies like Yahoo and Google were born to accommodate our growing search needs. Their solutions have matured, but it didn't happen overnight. The problem with search engines and Flash content is, there hasn't really been a huge need to index Flash content, because let's face it, Flash was only really used for ads and marketing sites targeted at a focused product (I.E. movie sites, games, things like that). Sites we could easily add metadata to the HTML wrapper and get the users to our site. Since the introduction of Flex, flash has really gotten some maturity and the more and more developers are taking it seriously. We have assimilated ;) quite a few hard core java / HTML / MS programmers as of late. With Flex 2, this trend is only increasing. Correct me if I'm wrong, but I don't think there has been a time in the web history that RIAs have gotten this much attention, or been taken this seriously. Things are really starting to happen in the RIA world and it feels like this is just the beginning. I think we are seeing the same problems that were faced when HTML first came around. SOE will continue to be a problem until the usage of Flash / Flex RIAs increase to a number where the Googles and the Yahoos start seeing this as a market they need to get into. On the other hand, this seems like it should be something Adobe should be pursuing more aggressively with the search companies (for all I know, they may already be doing this). To wrap up my thoughts, Flash is radically different from HTML and because of that, retrofitting Flash to mimic HTML for SEO may not be an efficient design. The current way we search HTML was designed in tandem with HTML, Flash may need a different approach, one that Adobe may not be able to provide alone. SEO in HTML is somewhat effortless and hopefully the future for us Flashers will be the same :-) P.S. I haven't kept up with this from the AJAX / WPFE techs, but I imagine they will have these issues as well, the fact that Flash is a binary format that will make things much more challenging for us though. I do think we will start to see more solutions that are born with the RIA revolution. Dustin Mercer From: flexcoders@yahoogroups.com [mailto:[EMAIL PROTECTED] On Behalf Of dougmccune Sent: Thursday, December 14, 2006 1:16 PM To: flexcoders@yahoogroups.com Subject: [flexcoders] Re: SEO Compatibility I just wanted to pipe up with my opinion on this matter, because it comes up a lot and the answers are always similar. And I get a little frustrated because it seems like Adobe tries to say this isn't a problem when it really is. To reiterate this scenario: Someone asks Why isn't Flex content searchable by Google? Or how can I make it searchable by Google? and then someone invariably responds Of course you can get your Flex (or Flash) stuff indexed by Google! Google indexes SWFs and also here's a bunch of roundabout ways to add textual content into the HTML wrapper, etc, etc. While I know Adobe employees don't like to admit this, the answer is very simple: It is often impossible, and if not impossible then at least extremely difficult, to get your Flex content indexed by search engines. That's the straight answer. No more no less. If I make a dynamic app using ASP, PHP, Coldfusion, or whatever that outputs HTML, Google will index all the dynamic content because it follows query-string links (or if you use mod_rewrite or whatever). So if I have a full message board written like this then Google will index all the content. The only way to get the same thing to happen with a Flex app is to develop an alternative, non-Flex interface to output the message board contents. Basically you have to make a PHP or ASP version of your app as well as the Flex version. I find any attempt by Adobe to pretend like this isn't a huge problem very frustrating. EBay, Amazon, MySpace, YouTube, digg, you name any large website and you can be guaranteed that they will not be using Flex for the Web frontend for customers. They might use it for tons of internal business apps (ebay) or for something that can remain completely unindexed by Google (Yahoo Maps) or for media content (YouTube), but they will never use Flex or Flash (as it currently is) for the real frontend user interfaces. Sorry for going on a bit of a rant. But just once I'd like to see an answer from an Adobe employee saying Yup, this is a real problem. What you really want to do, for all practical purposes, is nearly impossible with Flex. We're trying to work on it but for now you're SOL. Because that's the real answer. --- In flexcoders@yahoogroups.com mailto:flexcoders%40yahoogroups.com , John Dowdell [EMAIL
