AJAXクロールでは_escaped_fragment_を新規導入せずJavaScriptとCSSをGooglebotへ許可する

Googleは、2009年に提案したAJAX crawling schemeを推奨しなくなりました。新しいsiteやリニューアルで_escaped_fragment_ URLを導入せず、Googlebotがpage表示に必要なJavaScriptとCSSを取得できるようにします。

ただし、既存の仕組みが正しくindexされているなら、廃止の発表だけを理由に急いで変更する必要はありません。新規設計と既存運用を分け、代表URL一件の取得結果を確認してから移行範囲を決めてください。

新規siteへ_escaped_fragment_を導入しない

GoogleによるAJAX crawling schemeの案内では、2009年の提案を今後は推奨しないと発表しています。GooglebotがJavaScriptとCSSを取得できれば、一般にmodern browserのようにpageをrenderして理解できるためです。

2009年のschemeでは、#!を含むURLと、serverが返す?_escaped_fragment_=形式のrender済み内容を対応させていました。新しいsiteで二系統のURLとrender処理を作ると、利用者向けpageとcrawler向けpageの内容を一致させ続ける運用が増えます。

新規制作では、最初から通常のURLで各pageへ到達できる構成を作ります。JavaScriptによる画面更新が必要なら、History APIのpushState()も候補になります。ただし、URLを変える機能だけを導入しても、reload、戻る操作、直接accessで同じ内容へ到達できなければ不十分です。

JavaScriptとCSSをrobots.txtで遮断しない

Googlebotがpageをrenderするには、表示に使うJavaScriptとCSSを取得できる必要があります。HTMLだけをcrawl可能にしても、本文、navigation、layoutがscript実行後に作られるsiteでは、利用者が見る状態とGooglebotの取得結果が変わることがあります。

代表URLを一件選び、次を別々に確認します。

robots.txtを変更する前に、遮断しているruleと対象fileを特定します。すべてのpathを無条件に許可するのではなく、page表示に必要なresourceをGooglebotが取得できる状態へ直します。

既存siteは動いている仕組みを急いで外さない

Googleは、_escaped_fragment_へ対応する既存siteも引き続きindexすると説明しています。現在の設定が正しく機能していれば、すぐ変更する必要はありません。一般には、Googleが#! URLをcrawlし、renderしてindexします。

既存siteの移行では、現在indexされているURL、#! URL、?_escaped_fragment_= response、内部link、外部からのlinkを記録します。新しい構成で同じ内容へ到達できることを確認してから、不要になったserver処理を外してください。

「推奨されなくなった」と「今日からindexされない」を同じ意味にすると、動いているsiteへ不要な一括変更を行うことになります。保守予定に合わせて検証し、変更前後の取得結果を保存します。

Googlebotだけへ別内容を返さない

performance改善のためにpageをserverでrenderする方法は使えます。ただし、Googlebotだけにrender済みの内容を返し、通常の利用者へ異なる内容や操作を見せてはいけません。

Googleは、pre-renderする場合も、Googlebotへ出す内容を利用者の体験と見た目および操作の両方で一致させるよう求めています。Googlebotと通常利用者へ異なる内容を返すことはcloakingに当たります。

render方法を制作会社へ委託する場合は、利用者向けHTML、Googlebot向けresponse、JavaScript実行後の画面を同じURLで比較できる記録を受け取ります。実装を任せても、どのURLを正本にし、誰が差分を監視するかはsite側で管理します。

最初の一手は、JavaScriptで主要内容が変わる代表URLを一件選び、GooglebotがHTML、JavaScript、CSSを取得したrender結果を確認することです。新規siteなら_escaped_fragment_を設計から外し、既存siteなら現在の取得結果を保存してから変更の要否を決めてください。