AJAX crawling schemeを使うsiteは2018年のrender切替前に主要pageの表示とURLを確認する

#! URLや_escaped_fragment_を使うAJAX crawling schemeのsiteは、2018年に予定されるGoogle側のrender切替を待つ前に、主要pageの表示とURLを確認します。最初に変えるべきものはURLではありません。利用者が開くpage、Googlebotが取得するpage、serverが返す内容が、同じ主要情報へ進めるかを一件ずつ確かめます。

Googleは12月4日、2018年第2四半期にAJAX crawling schemeのpageをGoogle側でrenderする予定だと案内しました。#!を含むURLやfragment meta tagを使うschemeでは、site側が?_escaped_fragment_=のURLでrender済みの内容を返します。切替後は、Googlebotが#! URLを直接renderします。既存URLをすぐ削除するという案内ではありません。表示の差を確認し、必要な修正を先に選ぶための案内です。 Google Webmaster Central Blog

renderの方式とpageの役割を同じものとして扱わない

AJAX crawling schemeでは、利用者が見る#! URLと、検索用に用意した?_escaped_fragment_=のresponseが並びます。二つのURLがあるからといって、二つの記事や二つの会社案内を作る必要があるわけではありません。どちらから見ても、同じpageの主題、本文、問い合わせ先、次に進むlinkが分かることが必要です。

たとえば、JavaScriptで施工事例を絞り込むsiteを考えます。利用者は条件を選び、事例の一覧から個別pageへ進みます。_escaped_fragment_で返す画面には一覧だけがあり、個別pageへ進むa要素のlinkがないとします。この場合、画面を見た人とGooglebotがたどれる情報が違います。renderの方式を替える前に、一覧、個別page、問い合わせへの入口を分けて確認します。

表の項目を一度に直す必要はありません。まず、問い合わせや資料請求につながるpage、よく見られる商品page、会社案内のように、事業上の役割が大きいURLを選びます。数が多いsiteほど、全pageを同じ深さで見る前に、失われると困るpageから確認した方がよいでしょう。

表示の差は画面とHTMLを分けて探す

JavaScriptを使うpageは、browserの画面だけを見ても、Googlebotがどの情報へ到達するかを判断できません。反対に、HTMLだけを見ても、scriptの実行後にnavigationや本文が消えていないかは分かりません。GoogleはSearch ConsoleのFetch and Renderで#! URLとescaped URLの結果を比べ、差がある部分を確認するよう案内しています。

比較するときは、画面全体の見た目から始めません。まず、pageの主題を示す見出し、本文、個別pageへのlink、問い合わせ先を見ます。次に、title、description、robots meta tag、構造化データがrenderしたpageにあるかを確認します。装飾の一部が違うことと、読者が判断する材料が欠けることを同じ重大さで扱わないためです。

仮に、画像の切替だけをJavaScriptで行うpageなら、画像が一枚表示されるかを確認します。一方で、料金の条件や受付の手順をJavaScriptで後から入れるpageなら、そこが表示されない差は大きくなります。何が欠けたかを、見た目ではなくpageの役割で判断します。表示を直す作業と、説明の内容を承認する作業も分けます。

URLを替える前に残すものを決める

render方式の変更に合わせて、#! URLや?_escaped_fragment_=の仕組みを整理したくなる場合があります。しかし、URLを先に外すと、内部link、外部からのlink、bookmark、serverのresponseのどこへ影響したのかを追いにくくなります。URLの整理は、現在のURLと対応する内容を記録してから行います。

記録するのは、技術者だけが分かる設定名ではありません。事業者側にも、代表URL、pageの役割、管理する人、変更前に確認する人を残します。制作会社へ作業を頼むなら、#! URL、escaped URL、通常のURLのどれが正本なのか、どのURLを残すのかを受け取ります。作業を委託することと、検索から入るURLの判断を委託先だけに残すことは別です。

URLを整理しても、利用者が必要な内容へ到達できる状態を保ちます。古いURLから別のpageへ送るなら、見出しだけが似ているpageではなく、同じ情報を確認できるpageへつなぎます。単にtop pageへ送ると、問い合わせへ進みたかった人は探し直すことになります。URLの管理は検索のためだけではなく、既に案内した人を迷わせないための仕事です。

切替前の確認を更新作業へ組み込む

この確認は、Googlebot向けに別の内容を作るためのものではありません。Googleの案内でも、Googlebotがrenderしたpageでlink、meta data、構造化データを確認するよう示されています。利用者に見せる内容とGooglebotへ返す内容を意図的に分けると、原因の調査も難しくなります。

更新するたびに全URLを確認できない場合は、変更した種類ごとに代表pageを決めます。事例一覧のtemplateを直したなら一覧と個別pageを一件ずつ、formの導線を直したならformへ進むpageを一件、company informationを直したなら会社案内を一件見るというように、変更と確認対象を対応させます。誰が確認したかと、何を見たかを短く残せば、次の更新で同じ確認をやり直せます。

2018年の切替前に行う最初の一手は、#! URLを使う主要pageを一件選び、利用者が見る画面とFetch and Renderの結果を並べることです。本文、link、title、description、robots meta tag、構造化データのうち、pageの役割に必要なものが同じように確認できるかを見ます。差が見つかってからURLを整理する方が、切替のために必要な作業を絞れます。