A 3 Step Plan for SEO-friendly Rich Internet Applications
Search engines are optimised for a non-RIA model of the web: a web made up of pages. SEO tuned web applications expose content in pages for search engines, even if the user will interact with the application through AJAX and page-rewriting (which is completely opaque to a search engine spider).
RIAs make this even harder, and most developers don't seem to bother at all. That's fine if your RIA is going to be used by employees or partners (i.e. people who know where to find it), but not if it will be public facing.
Fortunately, there's an easy way make your RIA search engine friendly.
I've been working on a public-facing RIA that needs to play nicely with search. We've done a lot of work investigating how existing web-apps show up in search engine indices and how to SEO RIAs. After a surprising amount of experimental work, we came up with a pretty robust strategy. Although there is a lot of finesse needed to get this working really well, these are the basic three steps:
1. Provide multiple URLs to access content. Without this, you are completely lost! In my application the user can interact with other user's profiles. We have exposed each person's profile in its own URL. Each URL maps to the same RIA, but it does so with the corresponding profile as the 'default'. The user can then navigate away, but they start on that content. If your RIA was a store you could do the same thing for products, or if you were working with flight details, do the same per flight code. One curved-ball in this: you have to make sure that when a user wants to bookmark a piece of content, that they get the right URL. You can do this by creating a 'bookmark this page', or 'link to this page' button and some javascript. Exact details I'll leave for another time, but it takes a bit of messing about.
2. On each content page, use javascript to dynamically insert the RIA code. This is slightly more difficult, but the basic idea is that each URL is mapped to a non-interactive page that provides a static view of the corresponding content. Javascript then detects that the viewer of the page is human, and replaces the static content with the RIAs viewing the same content. One other advantage of this (that we're not using) is that you can selectively replace the page's content. So you could, for example, have content-sensitive ads on the site that remain, with the RIA working around them.
3. Provide multiple SE-optimized navigation routes across your content. You should build both an XML and HTML site-map, linked from the static content at every URL. You should also provide inter-links between related content whenever possible. Search engine rank is only part of SEO - you also want users to see the best of your pages for their search term (because they'll be more likely to click your link rather than a competitor). On the same note, make sure you have content-specific titles for each page.
Anyway, like I said, there's a lot more to it and we're learning as we go, but this is the basics. Drop me a comment with your email if would be useful for me to go into more.
Comments
Regarding #2: Isn't that what gets sites banned from search engines, or am I mistaking that for something else? Anyhow, I thought search engines were pretty good at only indexing content that the user is likely to see.
Also #1 is a bit of a pet peeve of mine, where sites break browser functionality and then attempt to replace it with their own-- but I guess it's better than nothing.
Posted by: David | July 9, 2007 08:55 PM
Our tests seem to be fine on both points: no banning, and fine indexing. I think you're probably pretty safe for search engines if the RIA is presenting the same data as the website - its just a different view to the same content.
If you replace decent content with a flash ad, it would be a different matter.
I could see, however, that this might not work for long - if lots of people start abusing this, then we'd see a blanket ban I'm sure. Hey ho.
Of course the flip of that is that people will need to access content in RIAs - they aren't going away. At some point indexers are going to have to support RIA-based content, one way or another. Hey - maybe there's a business opportunity now if you can figure out how to do that well.
As for breaking the browser - this is inevitable for browser based RIAs because browsers, like search engines, are page-oriented, and that is just one (not optimal) navigation model. There's a lot of talk in Flex circles about navigation and browser interaction - its a tough one to get.
Although we're getting good results, this is a topic that I'd _love_ to see more inspiration on!
Posted by: Ian | July 10, 2007 12:37 AM