SEO
Romain David
Mark Tomlin
there is a single search engine out there that will respect the page
title from a JavaScript event, so make sure the html has the most
correct title for the content.
Use of heading levels are also a big part of getting good search
results placement, <h1> through <h6> will allow most search engines to
create a index of your site, good search placement will come from good
writing.
Also try to make sure any meta tags include relevant information, and
you can also include other titles (that would of come from a
JavaScript event) in the meta element's attribute name with the value
keyword and description (this is very important). Most search engines
will use the meta description as the text below the link to your page,
so keep it concise.
>
> You received this message because you are subscribed to the Google Groups
> "iui-developers" group.
> To post to this group, send email to iui-dev...@googlegroups.com.
> To unsubscribe from this group, send email to
> iui-developer...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/iui-developers?hl=en.
>
--
Thank you for your time,
Mark 'Dygear' Tomlin;
Remi Grumeau
Simple reminder (or those who don't know it yet): SE do not manage anchors since the anchor is not include in the header datas. They are only a client-side functionality. A couple months ago , Google has made a announcement about anchors, with the fact they now use them … but in fact only to put the "see also" link just down the link title. It's not used for the sitemap, neither page rank and is of course not a netlinking valuable data.
This said, the real problem of iUI (and JQTouch / most of iPhone JS-based frameworks also btw) is the fact it's all based on anchor… so exactly the kind of links Google is not using. Just test it by yourself with SEO tools like Xenu (Windows) or Integrity (OSX) with the music demo page : http://ejohn.org/files/border-image/iui/samples/music.html
Here is the result : http://www.remi-grumeau.com/medias/uploads/iui-music-demo-in-integrity.png
First issue: no artists, albums, songs, settings pages/links. Yes, we'll find them in the flat map but SE counts and save a URL link reference, without anchors.
Second issue (and defnitly the worse one): no headers informations in sublinks ! If you check out the only link Google would go for informations in this case, it would fall down on this: http://ejohn.org/files/border-image/iui/samples/stats.php. It's not even a valid HTML document … no html,head,title,meta-description,body tags and so of course values for them.
Third issue (linked to the previous one): no direct links to pages, which is a sitemap problem but also a real social media sharing issue !! Not on the mobile navigation -> social networks but on the other way: social network -> website subpage -> mobile website subpage if handheld device. example: you are on facebook, clic on a friend link … but you are redirected on the index of the mobile site, and don't know where to go/navigate to find this content.
So what to do about it ?
This is definitely THE one billion dollar question … for which i actually have no good technical answer but is one of my top priority in mind !
As usual, any ideas / debate would be greatly appreciate !
Remi
Remi Grumeau
(+33) 663 687 206
http://www.remi-grumeau.com
Mark Tomlin
and the iUI application?
Creating and submitting Sitemaps:
http://www.google.com/support/webmasters/bin/answer.py?hl=en&answer=156184
Google's Search Engine Optimization (SEO) Resource Guide:
http://www.google.com/support/webmasters/bin/answer.py?hl=en&answer=35291
Google 101: How Google crawls, indexes and serves the web.
http://www.google.com/support/webmasters/bin/answer.py?answer=70897
On Sun, Dec 13, 2009 at 9:48 AM, Remi Grumeau <remi.g...@gmail.com> wrote:
> So what to do about it ?
> This is definitely THE one billion dollar question … for which i actually have no good technical answer but is one of my top priority in mind !
> As usual, any ideas / debate would be greatly appreciate !
Sean Gilligan
I'm too busy to get involved in this thread for at least a couple of
days, but I am very interested in the issue of SEO and would love to
learn more and do want to try to help research and develop solutions.
Regards,
Sean
Sean Gilligan
thoughts and have some proposed best practices.
The typical iUI use case has been to add an iPhone version of an
existing website with a subset of the contents from the 'full' website.
Obviously this is not a good idea from an SEO perspective. Other iUI
webapps are truly web applications that just need to be found with a
search engine, but not indexed internally (e.g. utilities, games, etc)
Let's take a use case where SEO would be important. We've been talking
about producing updated documentation for iUI and publishing in both
desktop HTML and mobile (iUI-based) format. This is case where there
are multiple pages of content that will be accessed by both desktop and
mobile applications.
In this case, I believe the 'best practices' should be the following:
1) Assume search engines do not distinguish between mobile and desktop
(am I wrong?)
2) Make the pages search engine friendly and navigable without JavaScript
3) Use progressive-enhancement to optimize for desktop browsers
4) Enable iUI (or jQTouch, etc) for iPhone-class mobile devices
Q: But, how do you use iUI on multiple HTML pages that can also be
formatted for the desktop?
A: That's a good question. Here is one possible method:
1) Create a main iUI page that includes iui.css and iui.js
2) When you "ajax in" the content pages use the "X-Requested-With" :
"XMLHttpRequest" feature in iUI 0.40 to tell the server side to generate
fragments instead of full pages.
3) When an iPhone reaches one of the content pages via a search engine,
redirect it to the main iUI page and then "ajax in" the content page.
This will definitely require some "extension" to iUI and possibly some
modifications, but it's an effort I would support.
There are other possible approaches and my proposed best practices may
not actually be the 'best', but I'll throw this out as starting point
and see if anyone has any alternatives or suggestions for improvement.
I'm very interested in starting/participating in a conversation on
this. We might want to move the conversation to iPhoneWebDev because
this is of general interest and there are many smart folks on that list
that aren't here. It would also be a good subject for blog discussion.
I'd love to learn what others think and, even better, what others have
done.
Regards,
Sean
Remi Grumeau
> (am I wrong?)
> 2) Make the pages search engine friendly and navigable without JavaScript
> 3) Use progressive-enhancement to optimize for desktop browsers
> 4) Enable iUI (or jQTouch, etc) for iPhone-class mobile devices
>
> Q: But, how do you use iUI on multiple HTML pages that can also be
> formatted for the desktop?
>
> A: That's a good question. Here is one possible method:
>
> 1) Create a main iUI page that includes iui.css and iui.js
> 2) When you "ajax in" the content pages use the "X-Requested-With" :
> "XMLHttpRequest" feature in iUI 0.40 to tell the server side to generate
> fragments instead of full pages.
> 3) When an iPhone reaches one of the content pages via a search engine,
> redirect it to the main iUI page and then "ajax in" the content page.
Remi
Sean Gilligan
>> 1) Assume search engines do not distinguish between mobile and desktop
>> (am I wrong?)
>>
>
> Sure, even more important for subpages that can be relayed in social networks (see my previous answer about it)
>
Agreed.
>> 2) Make the pages search engine friendly and navigable without JavaScript
>>
>
> a SEO basic, not that related to desktop or mobile website
>
Agreed, but since an iUI-only, Ajax-based site is unnavigable by search
engines, it's worth mentioning.
>> 3) When an iPhone reaches one of the content pages via a search engine,
>> redirect it to the main iUI page and then "ajax in" the content page.
>>
>
> humm � this would need kind of a sitemap iUI could refers to nope ?
>
The sitemap idea (were you the one who mentioned it before?) is one
solution. I'd like to see a hook in iUI that would provide a function to
map a fragment to a full URL -- this would be done in a generic enough
way that one or more mechanisms for implementing hierarchy could be used
as well. This hook would also support the sitemap approach.
-- Sean
Remi Grumeau
The sitemap idea (were you the one who mentioned it before?) is one
solution. I'd like to see a hook in iUI that would provide a function to
map a fragment to a full URL -- this would be done in a generic enough
way that one or more mechanisms for implementing hierarchy could be used
as well. This hook would also support the sitemap approach.
Maximilian Melcher
google can read ajax pages too. Maybe its worth to dig that!
Cheers
Max
lictor4
> Second way to do it: have a header in every file, simply deleted by the ajax load. Only content between <body> and </body> would be added to the content when loading (let"s using the same example) board.php. So basically board.php would be a normal HTML document that Google can read, and iUI would only use its <body>content</body> to generate the page.
This is the approach I've taken, except PHP decides if the
"header&footer"should be included or just the fragment. Each view is
in its own php file so it can stand on its own as a legit page if a SE
is looking
Php also allows me to dynamically include the views that are needed/
logical on the initial load (like: if a catalog item is orderable,
include the basket and checkout fragñ )
> Issue here (neither it wouldn't be funny right ? :) ) how to deal with #_board and #_board1 which are in the same file ?
>
> In fact the problem is that we do have from one side board.php?id=1, and on the other side a index.php#_board1.
> So perhaps the solution of direct access could be a anchor synthax standardization !!
> Something like #_FILENAME_ANCHORTOGO would be here FILENAME and then ANCHORTOGO. In this case: #_board_board1 -> board.php and then #_board1.
> Huge point : no sitemap file is require (which is a real pain in - you know where - with dynamic content
My view IDs are the relative path to the file that holds the frag.
( id="/dir/page_name/")
I dynamically add a pre fix to my links, "http://domain.com" for
external frags and "#" for frags that have already been included.
Issue 174 is the missing link in my setup (but I'm workin on
it...slowly, as per my js skills ;). )
Sean Gilligan
>> Second way to do it: have a header in every file, simply deleted by the ajax load. Only content between <body> and </body> would be added to the content when loading (let"s using the same example) board.php. So basically board.php would be a normal HTML document that Google can read, and iUI would only use its <body>content</body> to generate the page.
>>
>
> This is the approach I've taken, except PHP decides if the
> "header&footer"should be included or just the fragment. Each view is
> in its own php file so it can stand on its own as a legit page if a SE
> is looking
>
I just (today) used this approach in the Groovy Template "form-echo.gtpl"
The diff is here:
http://code.google.com/p/iui/source/diff?spec=svn32b7ab6215cf20360a6f58ae5913271e5a9e658f&r=32b7ab6215cf20360a6f58ae5913271e5a9e658f&format=side&path=/web-app/test/form-echo.gtpl
You can test it out on AppSpot:
http://iui-js.appspot.com/test/form-test.html
When the forms use target="_self" they don't use AJAX and the full
document is returned, when they use AJAX only the "frag" is returned.
> My view IDs are the relative path to the file that holds the frag.
> ( id="/dir/page_name/")
> I dynamically add a pre fix to my links, "http://domain.com" for
> external frags and "#" for frags that have already been included.
> Issue 174 is the missing link in my setup (but I'm workin on
> it...slowly, as per my js skills ;). )
>
I definitely want to add hooks in iui.js to allow a pluggable mechanism
to do this. There can then be one or more extensions that use different
id -> URL mapping schemes (potentially using a sitemap, etc) If someone
submits a clean patch that allows an extension to do this, I'll merge
it. If they do it using Mercurial it will happen more quickly ;)
-- Sean