This week Adobe released the Spry toolkit that finally allows web designers to join the, until now, programmer led world of Ajax development. At the same time, Backbase introduced an Ajax development tool for Java applications. But what use is an Ajax powered website when search engines such as Google can’t see it?
Ajax is the future of the web, declare the usual suspects, and with good cause. It is, undoubtedly an exciting technology that is already driving forward the idea of Rich Internet Applications. Yet dynamic client-server interaction and the display associated client-side trickery that accompanies it, cannot and will not be spidered, indexed or cached by search engines that don’t understand Ajax. In fact it’s even simpler than that: search engines not only don’t understand it, they don’t even see it. The irony being that Google is something of an Ajax pioneer, and GMail one of the best known Ajax applications
So what are the workarounds? Well you could have all the content in the page, but invisible to the user. Do that, however, and Google will almost certainly treat it as cloaking, serving up one page for web spiders and another for real people. The end result being much the same, your site gets blacklisted and so not listed. You could design two distinct versions of the content, the Ajax one and a ‘traditional’ one that is accessible to Google. While this may well work in as far as ensuring your site shows up in the land of search, it also means your Ajax development is a waste of time because Google will send everyone to the non-Ajaxified version anyway. Then there’s the database driven site solution of using querystring parameters using a Google sitemap. Apart from there being no querystring appended URLs, courtesy of the Ajax client side searching, unless you create them all artificially which is no mean feat for anything but the least complex of sites (and why bother with Ajax if all you have is a one page vanity web anyway?)
It seems to me that in order to successfully circumvent the Google search engine optimization, cloaking, spider-fodder rules in our Ajax driven vision of the future, you would have to make changes that would allow the SEO gangsters to ply their evil trade. Although there is some glimmer of hope in as far as Google has implemented Sitemaps, and it does enable pseudo content to flag text block priority to AdSense spiders. Until and unless a big change does come, some kind of content duplication would appear the only way forward. I know of one site which has a nifty Ajax navigation menu system that is fully duplicated within a static footer menu purely to bring server generated content to the party and allow Google to see the blasted thing. Or are I, and much of the Ajax obsessed development community, missing the point here? Is Ajax really only suitable for what has been cruelly described as client-side interface candy and nothing more?
I might run the risk of being called a heretic for saying it, but say it I will: in your head long rush towards Web 2.0, be careful you don’t get caught by the Ajax tripwire.
This leaves me to ask two things of you, dear reader:
2. How do you build an Ajaxified website without it disappearing from the face of the web?