3 ms·
Indexing AJAX websites is important, but I don't think much of this proposal. As far as I can tell, their plan is to create a standard way that AJAX hash links
by seldo 17y ago
Indexing AJAX websites is important, but I don't think much of this proposal.
As far as I can tell, their plan is to create a standard way that AJAX hash links can be translated into real links, which Google will then crawl, expecting that you are running a machine-readable web browser on your server(!) that will render the full page.
Expecting everyone to make a big modification like installing a Java-based browser to their infrastructure is crazy.
A much more sensible solution is the one webmasters should be doing anyway: progressive enhancement. Any AJAX link, when clicked with Javascript disabled, should render the page as it was intended, just more slowly and without animations etc.. Then your site is completely indexable, and as a bonus it's more robust and accessible too.
With a modern MVC framework this is really not that hard to achieve: your AJAX controller should just be spitting out a chunk of HTML, and whether it gets integrated into your template at the server-side or on the client by Javascript should be irrelevant.
- revetkn 17y ago"Expecting everyone to make a big modification like installing a Java-based browser to their infrastructure is crazy." I agree. Google is (IMHO) doing this because they view GWT as the near-term future of web development and it seems likely this will be baked into the framework sometime soon (see http://code.google.com/p/google-web-toolkit/source/browse/branches/crawlability/ http://code.google.com/p/google-web-toolkit/source/browse/br...). Katharina Probst and Bruce Johnson are both GWT team members, and as far as I can tell Dr. Probst is leading the engineering effort on the GWT side to support this. It seems to me that if you're not using GWT, this will be far too much effort for you to implement.
- unlinkedlist 17y agoTo 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.
- seldo 17y agoI 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 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.
- boucher 17y agoThat 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.