AJAX: よくある質問

ここでは、AJAX クロールに関するよくある質問とその回答をご紹介します。
AJAX URL で _escaped_fragment_ と #! を使用するのは、それぞれどのような場合ですか?

AJAX クロール スキームを適用するすべての URL で #! シンタックスを使用する必要があります。 Googlebot では、_escaped_fragment_ 形式のハイパーリンクはクロールされません。

このスキームの実装例はどこで見ることができますか?

http://gwt.google.com/samples/Showcase/Showcase.html で AJAX アプリケーションのサンプルを見ることができます。左側のリンクをクリックすると、#! ハッシュ フラグメントを含む URL が表示され、このハッシュ フラグメントに対応するステートに移動します。#!(例: http://gwt.google.com/samples/Showcase/Showcase.html#!CwRadioButton)から ?_escaped_fragment_=(例: http://gwt.google.com/samples/Showcase/Showcase.html?_escaped_fragment_=CwRadioButton) に変更すると、HTML スナップショットがサイトから返されます。

AJAX サイトで #! を実装しない場合はどうなりますか?

今後短期間のうちに、ページが Google の検索結果ページに適切に表示されなくなる可能性があります。もっとも、Google では、Googlebot がよりブラウザに近い動作をするよう対応を続けています。サイトで必要な機能が実装されていくにつれて、特に何もしなくても Googlebot によってページが適切にインデックスに登録されるようになる可能性はあります。それでも、この AJAX クロール スキームを実装すれば、既に AJAX を使用しているサイトのコンテンツをすぐにインデックスに登録できるという利点があります。Google では、ページの HTML スナップショットが既にある場合や、ヘッドレス ブラウザを使用して HTML スナップショットを取得している場合は、AJAX クロール スキームの実装が有効な解決策になると考えています。

どの程度の頻度でコンテンツを更新する必要がありますか?

この質問に対する回答は、アプリケーションのコンテンツが変更される頻度によってまったく異なります。変更が頻繁に発生する場合は、クローラからのリクエストに応じて HTML スナップショットを常に作り直す必要があります。反対に、定期的な変更が発生しないライブラリ アーカイブの場合は、サーバーで同じ HTML スナップショットを繰り返し作成しなくても済むよう、関連するすべての HTML スナップショットを一度に、可能であればオフラインで作成し、将来参照できるように保存しておくとよいでしょう。また、Googlebot に 304(変更なし)HTTP ステータス コードを返すこともできます。

アプリでハッシュ フラグメントを使用していない場合はどうなりますか?

ハッシュ フラグメントを使うことをおすすめします。ハッシュ フラグメントはクライアント側のブラウザで処理され、ページ全体の更新を必要としないので、使用することでアプリケーションが大幅に高速化されます。 また、アプリケーションで履歴操作が可能になります(ブラウザの [戻る] ボタンに対応するようになります)。さまざまな AJAX フレームワークがハッシュ フラグメントに対応しています。たとえば、Really Simple History、jQuery の履歴プラグイン、Google Web Toolkit の履歴メカニズム、ASP.NET AJAX の履歴管理サポートなどがあります。

ただし、アプリの構造上ハッシュ フラグメントを使用できるようにすることが現実的でない場合は、ハッシュ フラグメント(URL の # 記号より後の部分すべて)に特別なトークンを使用することもできます。ページ固有の状態を表すハッシュ フラグメントは、先頭に感嘆符を付ける必要があります。たとえば、AJAX アプリに次のような URL が含まれているとします。

www.example.com/ajax.html#mystate

この場合は次のように指定します。

www.example.com/ajax.html#!mystate

このスキームを実装したサイトは、「クロールできる AJAX」と見なされます。つまり、サイトで HTML スナップショットを提供していれば、クローラでアプリのコンテンツを確認できるようになるということです。

このアプローチにより「冗長な」_escaped_fragment_ URL が増加することはありますか?

URL の _escaped_fragment_ シンタックスは一時的な URL であり、エンドユーザーに表示されることはありません。ユーザーに表示される場合は必ず、簡潔な URL(#!_escaped_fragment_ の代わりに使用)が表示されます。これは、通常のアプリ操作、サイトマップ、ハイパーリンク、リダイレクトなど、URL がユーザーに表示される可能性のある状況すべてに適用されます。同じ理由で、検索結果にも冗長な URL ではなく簡潔な URL が表示されます。

このスキームによりクローキングが起きるおそれはありますか?

クローキングとは、検索エンジンに示したコンテンツとは異なるコンテンツをユーザーに表示することです。 通常、これは検索結果のランキングを上げる目的で行われます。クローキングは、検索エンジンにとって常に深刻な問題でしたし、これからもそうでしょう。とはいえ、AJAX アプリケーションをクロール可能にしたからといってクローキングが簡単になるということは一切ありません。ですから、HTML スナップショットには、エンドユーザーのブラウザに表示されるコンテンツと同じコンテンツが含まれている必要があります。コンテンツが異なっているとクローキングと見なされる可能性があります。詳しくはこちらの説明をご覧ください。

このスキームを使って、Flash などのリッチメディア ファイルをクロールしやすくすることができますか?

Google ではリッチメディアのさまざまなファイル形式をインデックスに登録し、また継続的にクロールとインデックス登録の改善に努めています。ただし、Flash などのリッチメディア アプリケーションのコンテンツによっては、Googlebot が認識できないものもあります(サイト上の動的コンテンツの一部がクロールできないことと同様です)。そのため、このスキームを使って、追加のコンテンツを Googlebot に示すことが有益になります。 そのためにも、HTML スナップショットには、エンドユーザーのブラウザに表示されるコンテンツと同じコンテンツが含まれている必要があります。 Google はクローキングしていると見なしたサイトを、インデックスから除外する権利を有します。

クロールされたくないハッシュ フラグメント付き URL がサイトにある場合はどうすればよいですか?

AJAX クロール スキームをサイトに実装すると、Google のクローラは、検出したすべてのハッシュ フラグメント付き URL をクロールするようになります。 クロールされたくないハッシュ フラグメント付き URL がある場合は、正規表現を使用したディレクティブを robots.txt ファイルに追加することをおすすめします。 たとえば、クロールされたくないハッシュ フラグメントに一定の命名規則を適用して、robots.txt ファイルでその規則に一致するすべての URL をクロール対象から除外します。たとえば、インデックスに登録したくないステートがすべて #DONOTCRAWLmyfragment という形式の場合、robots.txt に次の記述を追加すると、Googlebot は該当するページをクロールしなくなります。

Disallow: /*_escaped_fragment_=DONOTCRAWL
ハッシュ フラグメントで既に #! が使われている場合はどうすればよいですか?

#! は既存のハッシュ フラグメントではほとんど使われていないトークンですが、URL の仕様では使用が認められています。アプリケーションで #! を使用しているが新しい AJAX クロール スキームを導入するつもりではない場合は、robots.txt にディレクティブを追加してクローラに伝えます。

Disallow: /*_escaped_fragment_

このように記述すると、アプリケーションに #! の付いた URL(例 www.example.com/index.html#!mystate)のみが含まれている場合、その URL はクロールされません。他に通常の URL(例:www.example.com/ajax.html)が含まれている場合、その URL はクロールされます。

ユーザー補助はどうなりますか?

検索エンジンに静的コンテンツを提供するという現在の慣習からは、障害を持つユーザーでもアプリケーションを利用しやすいように作成されるという副次的な効果も生まれました。この新しいスキームを導入すると、これまでにないレベルのユーザー補助が実現し、手動で操作しなくても、ヘッドレス ブラウザを使用して HTML スナップショットを作成できるようになります。この HTML スナップショットは、関連するすべてのコンテンツを含み、スクリーン リーダーで使用することができます。その結果、手動での作業が減るため、静的コンテンツをより簡単に最新の状態に保てるようになり、障害を持つユーザーでもアプリケーションを利用できるようにすることにこれまで以上に取り組むことができます。

rel="canonical" はどのように使用すればよいですか?

<link rel="canonical" href="http://example.com/ajax.html#!foo=123" /> のように使用してください(<link rel="canonical" href="http://example.com/ajax.html?_escaped_fragment_=foo=123" /> とはしないでください)。

サイトマップではどの URL を指定すればよいですか?

サイトマップでは、検索結果に表示する URL を http://example.com/ajax.html#!foo=123 のように指定します。

#! URL は商品フィードに影響しますか?

Google ショッピングやウェブ検索に表示されるサイトの URL を統一したいというのは当然のことです。通常は、#! 付きの URL を「正規の」URL として、すべての状況で使用します。 _escaped_fragment_ 付きの URL は、エンドユーザーに表示されることのない一時的な URL と見なされます。

HtmlUnit がヘッドレス ブラウザとして機能しないのはなぜですか?

「機能しない」ということが、期待したようなスナップショットが HtmlUnit から返されないということであれば、JavaScript と XHR リクエストを実行する時間が足りなかったことが原因である可能性があります。これを修復するには、次のいずれか、またはすべてを行います:

  • NicelyResynchronizingAjaxController を使用する。 HtmlUnit が未処理の XHR コールの終了を待つようになります。
  • waitForBackgroundJavaScript または waitForBackgroundJavaScriptStartingBefore の待ち時間を長くする。
これで問題はおそらく解決します。解決しない場合は、HtmlUnit のよくある質問(http://htmlunit.sourceforge.net/faq.html)をご覧ください。HtmlUnit にはユーザーのためのフォーラムもあります。

 

この情報は役に立ちましたか?
改善できる点がありましたらお聞かせください。