バックボーンでは、ハッシュバンが「＃/ path」への標準フォールバックでコードから削除されました。これは、クロールには問題ありません（https://github.com/documentcloud/backbone/commit/10230e4d76e21f08a1dee1fe5d28994e2cf5f11d#commitcomment-477992を参照） 。
しかし、ie9ユーザーがFacebook共有（コピーして貼り付けるURL）を実行したい場合でも、_escaped_fragment_ハンドラーが必要です。そこで、正規URLを実行するか、リダイレクトしてクリーンな方法で処理できますが、「＃！」フォールバックはまだ必要ですよね？
問題は、サーバー#!があなたの居場所を特定する必要がある場合でした（数年前のTwitter / Gawker）。サーバーを正しく設定した場合、つまり、常にバックボーンアプリを返し、アプリ内の任意のURLに対してルーターを起動すると、すべてのユーザーに対して正しく処理されます。
IE8 / 9ユーザーには、ハッシュ化されたURLが表示されます。正常なブラウザは通常のURLを表示します。「正常な」ブラウザがハッシュされたURLをロードすると、バックボーンルーターは何をすべきかを認識します。同じことがIE8/9にも当てはまります。
また、サーバーから特定のURLの正しいビューステートを返す（つまり、サーバー側での事前レンダリング）限り、Googleは、通常のWebサイトのようにサイトを使用し、それに沿ってインデックスを作成するだけで問題はありません。
この問題は#!、_escaped_fragment_実際に処理するように設計されているため、もはやそれほど重要ではありません。
編集
例：
サーバーでBackboneアプリを実行していて、それがにあるとしますhttp://myserver.com/myapp/。これは、Backbone.historyオブジェクトに渡すベースです。
Backbone.history.start({pushState: true, root: '/myapp'});
これは、下のすべてのパス/myapp/がバックボーンアプリケーションによって「所有」されていることをルーターに説明します。で始まる要求されたルートがバックボーンアプリケーションを返す限り/myapp/、ブラウザーに関係なく機能します。
つまり、ユーザーがアプリを使用していて、最終的には。になるとし/myapp/awesome/thing/to/shareます。IE8 / 9ユーザーの場合、URLはになります/myapp#awesome/thing/to/share。
ブラウザがサーバーにこれを要求すると、要求するだけです/myapp。これにより、バックボーンアプリケーションが返され、履歴オブジェクト/ルーターが起動します。ルーターはハッシュフラグメントがあることを確認し、「ユーザーにawesome / things / to/shareを提供します」と言います。これは、このURLを要求するすべてのブラウザで発生します。
サーバーが同じバックボーンアプリを返す限り、IE8 / 9ユーザーがリクエスト/myapp/awesome/thing/to/shareすると、ルーターはパスが/ awesome / things / to / share'であることを再度確認し、IE8/9のURLを自動的にに変更します/myapp#awesome/thing/to/share。
あなたが何かトリッキーなことをする必要がある唯一の場所は、グーグル/フェイスブックがこのページをこすり落とすことができるようにしたい場合です。JavaScriptを実行しないため、ページは、Backboneがブラウザで作成した場合とまったく同じようにサーバーから送信する必要があります。または、Facebookの場合は、ドキュメントのセクションで<og:*>タグを使用できます。<head>
答えは（誰も代替案を提供しない場合）いいえ、これらの要件がある場合は悪い考えではありません。tkoneとの議論を参照してください。