mobile-first indexingの通知を受けたsiteはGooglebotの増加だけで移行を完了としない

Search Consoleでmobile-first indexingへの移行通知を受けたsiteは、通知が来たことだけで作業を終えません。スマートフォンで読む人へ出している本文、見出し、画像の説明、内部link、問い合わせへの入口を、PC版とURL単位で比べます。スマートフォン用Googlebotのcrawlが増えても、mobile版に必要な情報がなければ、検索から来た人とGoogleが受け取る内容は少なくなる。通知は設定を一斉に替える合図ではなく、公開しているmobile版を確かめる機会として扱います。

Googleは3月26日、best practicesに従うsiteからmobile-first indexingへの移行を始めたと案内しました。mobile-first indexingでは、mobile版のpageをindexingとrankingに使います。ただし、別のmobile-first indexが作られるわけではなく、検索結果へ使うindexは一つです。移行するsiteにはSearch Consoleで通知が届き、スマートフォン用Googlebotのcrawl rateが大きく増えることがあるとされています。mobile-first indexingへ移行したこと自体に、ranking上の優位が付くわけでもありません。

通知が示すことと示さないことを分ける

通知が示すのは、そのsiteがmobile-first indexingへ移されるということです。PC版とmobile版のどちらを主な手掛かりにGoogleが内容を集めるかが変わるのであって、siteの評価が急に上がるという知らせではありません。通知を受けた日にtitle、本文、URLの構造を全て替える必要もありません。まず、いま公開しているmobile版が、PC版で伝えている用件を同じように伝えられるかを確かめます。

混同しやすいのは、mobile-friendlyの評価、page speed、mobile-first indexingです。mobile-friendlyの評価は、mobileで使いやすいpageかどうかに関わります。page speedは、読者が表示を待つ時間に関わります。mobile-first indexingは、Googleがどの版の内容をindexingとrankingに使うかに関わります。三つは関連して見えても、同じ設定ではありません。mobile-first indexingの通知だけを理由に、画像を外したり、本文を短くしたりしてはいけません。

たとえばPC版に料金の条件、対応地域、申込み方法があり、mobile版には短い紹介文と電話buttonだけがある場合を考えます。電話buttonが押しやすくても、読者は条件を確かめられません。Googleがmobile版を使うなら、検索結果へ結び付く内容もmobile版から読み取ることになります。表示を軽くするために必要な説明を省くのでなく、説明を読める順に置き、画像やscriptの役割を別に見直します。

PC版とmobile版は重要なURLから並べて見る

確認対象をsite全体へ広げる前に、検索や広告から最初に開かれるURL、サービスの条件を説明するURL、問い合わせや申込みへ進むURLを選びます。PC版とmobile版の画面を同時に開き、画面の見た目でなく、読者が判断に使う情報を比べます。特に、次の内容はmobile版だけで不足しないようにします。

• 本文の結論と、その結論に必要な条件
• 見出しで分けた説明の順序
• 画像だけで伝えていないかを確かめるための説明文
• 関連するpageへ進む内部link
• 電話、form、営業時間など、読後に行動するための入口

ここでいう同じ内容は、PC版とmobile版の改行や画像サイズまで同じにする意味ではありません。小さな画面では、説明の順や折りたたむ部分を変えることがあります。それでも、料金の対象条件だけが消える、申込みに必要な注意だけがPC版に残る、関連pageへのlinkがmobile版にない、といった差は残さない。読者がmobileで用件を完結できるかを基準にします。

URLを比べるときは、top pageだけを見て終えません。PC版のtop pageに十分な情報があっても、検索結果から個別のサービスpageへ入る人は、top pageを経由しないことがあります。検索から直接開かれるURLで、本文、条件、連絡先、内部linkを読めるかを見る方が、移行後の確認として役に立ちます。

crawl rateの増加は内容の一致を証明しない

移行したsiteでは、スマートフォン用Googlebotのcrawl rateが増えることがあります。server logやSearch Consoleでcrawlの変化を見つけても、それだけでmobile版の内容が正しくそろったとは言えません。crawlはGoogleがpageを取りに来た記録であり、読者が必要な説明を読めた記録ではないからです。

まず、スマートフォン用Googlebotが取得するURLで、mobile版へ正しく案内されるかを確かめます。PC用とmobile用でURLを分けているsiteなら、対応するpage同士の組合せを見ます。responsive web designなら、同じURLをmobileのbrowserで開き、画面幅によって本文やlinkが消えていないかを見ます。どちらの作り方でも、Googlebotが来た回数を数える前に、mobile画面で出ている内容を確認します。

また、crawlが増えた期間にserverの応答が遅くなったり、formや画像の表示が不安定になったりしていないかも見ます。crawlを止めることが目的ではありません。読者の利用とGoogleの取得を両立できるように、特定のURLで起きている問題を分けるためです。異常があれば、発生したURL、時刻、PCとmobileの表示差を残してから制作側へ渡します。情報がそろっていれば、原因をURLの振り分け、resourceの取得、serverの応答などへ分けて調べられます。

変更を急がず、読者の入口を残して確認する

mobile-first indexingへ移ると聞くと、mobile版だけを新しく作り直したくなることがあります。しかし、Googleはresponsive web designやdynamic servingを使うsiteを、一般にmobile-first indexingへ適した形として案内しています。既にmobile版が用意されているなら、先に必要なのは作り直しではなく、内容の差を見つけることです。

たとえば、PC版では詳細を読んだ後に問い合わせformへ進めるのに、mobile版ではformへのlinkがmenuの奥にあるなら、mobile版の導線を直します。反対に、PC版とmobile版で同じ本文と同じformを読めるなら、通知を受けたことだけを理由にtemplateを替える必要はありません。変更する場合も、URLの対応、本文、form送信、計測に必要な要素を一度に替えず、変更前後の画面を残します。

desktop版しかないsiteは、今回の移行対象ではなくても検索結果から消えるわけではありません。Googleはdesktop contentだけのsiteもindexに残ると案内しています。ただし、mobileで読む人が増えている以上、表示と操作をmobileで確かめる必要はあります。通知の有無だけで優先順位を決めず、読者が最初に開くURLから、読める内容と進める入口をそろえます。

mobile-first indexingの通知を受けたら、最初に重要なURLを三つ選びます。次にPC版とmobile版で、本文、条件、内部link、問い合わせの入口を比べます。その後にスマートフォン用Googlebotのcrawlとserverの状態を見ます。この順序なら、検索の仕組みを理由に必要な情報を削らず、読者とGoogleのどちらにも伝わるpageを保てます。