I have developed a datacentric silverlight application that uses multiple pages.

Individual pages in the application need to be indexed by search engines. ie: a search for "john smith" gives a link to the silverlight page about john smith.

The silverlight content is loaded from a database using webservices; it is not hardcoded.

The most obvious approach to this would be to nest the SL content in a regular aspx page I think. In this case postbacks would be requried to navigate around the site. Would the Silverlight application be downloaded again every time the page changed or would it be cached?-I think it would be necessary to have different parameters passed to the Silverlight object - would that cause it to be downloaded again instead of the cached version being used?

Other approaches I've seen include cloaking - generating a seperate version of pages for search engines to use. Would that be feasible in a multipage Silverlight site? A fairly simplistic implementation of this idea would be to have indexable pages that contain the silverlight application with parameters setting which page to display - using the pages only as a jumping off point and not using postbacks - just having the seperate pages to catch relevant google searches.

The application uses WCF remote procedure calls. Would there be any significant advantages to using REST instead for making the content indexable?

http://blogs.msdn.com/silverlight_sdk/archive/2008/10/31/search-engine-optimization-for-silverlight-applications.aspx

Silverlight-help
Vb Tips
Space Coast .Net User Group

Thanks I've already looked at that document and it is useful. I'm trying to establish whether the techniques described in it are feasible for the multipage site I am looking at. Will the Silverlight object load from the cache in this context for example?

I think I'll need to break up the silverlight into the smallest parts possible and have them as content in different aspx pages.

peterdungan:

Other approaches I've seen include cloaking - generating a seperate version of pages for search engines to use. Would that be feasible in a multipage Silverlight site? A fairly simplistic implementation of this idea would be to have indexable pages that contain the silverlight application with parameters setting which page to display - using the pages only as a jumping off point and not using postbacks - just having the seperate pages to catch relevant google searches.

Hi Peter, 

I haven't really tried this.  But the "simplistic implementation" you mentioned sounds feasible:

1) Host your Silverlight application in either ASP/ASP.NET page.  The ASP/ASP.NET page must be capable of processing URL parameters and pass them as initialization parameters to the Silverlight application.

For example:  http://www.mydomain.com/MyApp.aspx?page=1&query=john_smith , MyApp.aspx processes the URL parameters and populates the HTML page with necessary metadata that search engines feed on; and at the same time, tells your Silverlight application what page it should display and what query it should use by passing it the necessary initialization parameters it needs.

2) At startup, your Silverlight application reads the initialization parameters and decides which relevent page to show and query to use.  And as far as application navigation, still use in-Silverlight navigation.

3) It'd be nice if the HTML page generated by MyApp.aspx contains a button/link that allows the user to bookmark the page or share it to link sharing sites, etc.  And also let your Silverlight app modify the relevant URL for this button/link everytime the Silverlight apps goes to a different page.

Anyway, just thinking out loudly.  What do you think?

Sherwin Chu