Re: [flexcoders] Re: SEO Compatibility

[dorkie dork from dorktown]

ok. i understand what you're saying.

heres what you can do. we continue to change the url by hash on the client
but we also, when the page loads, put links that the search engine can
follow.

On 12/28/06, Kevin Newman <[EMAIL PROTECTED]> wrote:


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/  you want the url to change to
> foo.com/bar/monkey  not 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.



> correct? have a look at 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.




Yeah. Lets keep on this thread. I agree. Part of me is trying to figure out
work arounds (something better than a hack) to fix the problem and another
part of me wants adobe to address it.

I hear you about a standard way. I think, not knowing if Adobe is working on
it or not, a way that works is made then we can base a standard off that.

Judah

Re: [flexcoders] Re: SEO Compatibility

[Kevin Newman]

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/  you want the url to change to
> foo.com/bar/monkey  not 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 . 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

[dorkie dork from dorktown]

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

[Ian Thomas]

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

[Kevin Newman]

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 
>  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 
> . 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 extens

Re: [flexcoders] Re: SEO Compatibility

[dorkie dork from dorktown]

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 . 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 alia

Re: [flexcoders] Re: SEO Compatibility

[Kevin Newman]

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 . 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

[dorkie dork from dorktown]

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

[Kevin Newman]

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

[hank williams]

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

[Kevin Newman]

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 
 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

[hank williams]

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]

> > 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

[hank williams]

> 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

[Kevin Newman]

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] 
> > 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.

>
>   

Re: [flexcoders] Re: SEO Compatibility

[hank williams]

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: [flexcoders] Re: SEO Compatibility

[Kevin Newman]

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

[Ralf Bokelberg]

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]
>
 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 t

Re: [flexcoders] Re: SEO Compatibility

[Mike Weiland]

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]
>  > 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
>>> eith

Re: Re: [flexcoders] Re: SEO Compatibility

[Rich Rodecker]

> 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

[dorkie dork from dorktown]

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

[Cortlandt Winters]

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

[Ian Thomas]

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

[Claus Wahlers]

> 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

[Claus Wahlers]

> 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

[Claus Wahlers]

> 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

[Claus Wahlers]

> 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

[hank williams]

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.



Claus,

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!

Regards,
Hank


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/


--
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]

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

[hank williams]

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

[Claus Wahlers]

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

[hank williams]

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

[hank williams]

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

[hank williams]

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

[Kelly]

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 misunderstandi

Re: [flexcoders] Re: SEO Compatibility

[dorkie dork from dorktown]

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.

Re: [flexcoders] Re: SEO Compatibility

[Doug McCune]

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: http://www.macromedia.com/support/ 


Spam killed my private email -- public record is best, thanks.

 

Re: [flexcoders] Re: SEO Compatibility

[Patrick Mineault]

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 
> 
>
> 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=en&lr=&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=en&lr=&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 
>> 
>> Aggregator: http://weblogs. macromedia. com/mxna 
>> 
>> Technotes: http://www.macromed ia.com/support/ 
>> 
>> Spam killed my private email -- public record is best, thanks.
>>
>
>  

Re: [flexcoders] Re: SEO Compatibility

[John Dowdell]

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

[Doug McCune]

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=en&lr=&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=en&lr=&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 

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

[hank williams]

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

[John Dowdell]

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

[Dustin Mercer]

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."

[flexcoders] Re: SEO Compatibility

[dougmccune]

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, John Dowdell <[EMAIL PROTECTED]> wrote:
>
> sanjaypmg wrote:
> > Is Flex SEO Compatible?
> > If yes, How can I my flex application SEC compatible? so that it can 
> > be easily available for search engines available.
> 
> 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.
>