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 の検索結果ページに適切に表示されなくなるかもしれませんが、Googlebot の動作がブラウザに近くなるよう対応を続けていますので、サイトで必要な機能が実装されていくにつれて、特に何もしなくても Googlebot によってページが適切にインデックスに登録される可能性はあります。それでも、この AJAX クロール スキームを実装すれば、すでに AJAX を使用しているサイトのコンテンツをすぐにインデックスに登録できるという利点があります。ページの 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 スナップショットには、エンドユーザーのブラウザに表示されるコンテンツと同じコンテンツが含まれている必要があります。コンテンツが異なっているとクローキングと見なされる可能性があります。詳しくはこちらの説明をご覧ください。

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

Google ではリッチメディアのさまざまなファイル形式をインデックスに登録し、また継続的にクロールとインデックス登録の改善に努めています。ただし、リッチメディア アプリケーションのコンテンツによっては、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 スナップショットを作成できるからです。スナップショットに保持された関連コンテンツは、すべてスクリーン リーダーで読み上げ可能です。つまり、静的コンテンツを最新の状態に保つための手作業が減って楽になり、その時間を障がいを持つユーザーのためにアプリケーションを利用しやすくする取り組みに活用できます。

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 コールの終了を待つようになります。
  • waitForBackgroundJavaScriptwaitForBackgroundJavaScriptStartingBefore のいずれか、または両方の待ち時間を長くする。

これで問題はおそらく解決します。解決しない場合は、HtmlUnit のよくある質問(http://htmlunit.sourceforge.net/faq.html)をご覧ください。HtmlUnit にはユーザーのためのフォーラムもあります。