I am struck by the consequences of the experience Craig relates in this post:
http://staff.develop.com/candera/weblog2/CommentView.aspx?guid=54fd1ed8-ea12-4555-9ee3-4f9e3d57907e
He is discussing a Wiki site that mysteriously had its page content rolled back to a previous version. Wiki pages generally contain a link to do this, and it is assumed that a human would follow it with caution. Turns out that GoogleBot crawled the site and what-do-you-know the content rolled back. The underlying problem was that a GET request caused a significant side effect, in this case altering the content of the linking page.
The HTTP specification recommends that GET requests are idempotent, which means that a given action is performed once even if it invoked numerous times. The intent is that GETs are “safe and repeatable”. That is, it should be safe for a crawler to invoke any GET request (subject to authorization of course).
This bears on the question of how to best use ASP.NET controls, notably the data controls where you might attempt to optimize ViewState by eliminating postbacks and changing buttons to hyperlinks. Note that the LinkButton is safe because it causes a postback. You can also probably get away with using a form with method=GET because a spider is unlikely to submit a form (even one based on GET), but I don't recommend it.
I traditionally replace postbacks with links to optimize ViewState, as opposed to “simply” disabling ViewState, because a race condition exists if you do not have a DataKeys collection that is consistent before and after the postback. The race is that the resultset might have changed in the meantime, and the action would thus be carried out on the wrong data key. That is, you would be operating purely by ordinal. So, with this idempotence revelation I am back to square one with optimizing DataGrids.