News for hackers. Stuff that matters.

A comment on Google proposes standard for making Ajax crawlable. Parent comment

Re:Google proposes standard for making Ajax crawlable by unlinkedlist on Thursday October 08, 2009 @02:45PM (#869643)
To be fair, the "standard" part of this proposal doesn't really have anything to do with headless browsers. You could just as easily have a typical server-side app that generates these URLs as appropriate.

For example, a common approach to presenting content in an AJAXy kind of way is to just put a path after the hash. E.g.

    http://www.example.com#/products/bungee-cords
It's probably really easy for the web app to figure out the right content to serve up for #/products/bungee-cords, headless browser or not.

I know you'll be saying, "Of course, but apps should be doing that anyway with progressive enhancement." That's all well and good, but that leads to two separate sets of URLs: one that most users see, and one that search engines see. This fixes that.

[ Parent | on HN ]
Re:Google proposes standard for making Ajax crawlable by seldo on Thursday October 08, 2009 @03:25PM (#869742)
I don't understand what you're saying. Firstly, web apps can never see anything after a # in a URL: the browser does not send it to them. Javascript can see it, but I don't think that's what you meant.

With progressive enhancement, your URLs should look like http://www.example.com/products/bungee-cords. If clicked they should render the page as appropriate. JavaScript, if enabled, will attach a handler to the links and when it sees you trying to click on /products/bungee-cords will halt that click and instead make an AJAX request for the equivalent content. There should be no need to have # links whatsoever.

[ Parent | on HN ]
Re:Google proposes standard for making Ajax crawlable by boucher on Thursday October 08, 2009 @04:53PM (#869958)
That ignores the fact that people want the URL field to reflect the current state of things, so that URLs can be copied out and pasted elsewhere.

It also ignores the fact that there is no way to set the URL field (through JavaScript or any other mechanism) without actually triggering a page change.

[ Parent | on HN ]