In-house SEO Meetupが主催したGoogle MFI Nightで、Google社員にさまざまな疑問を質問するAMA with Google セッションを先週金曜日の記事でレポートしました。
日本語検索独自の品質評価アップデートがテーマでしたが、このイベントのメインテーマはモバイル ファースト インデックス (MFI) です。
当然AMAもMFI関連の質問が大部分を占めていました。
そこでこの記事では、Googleの金谷さんと長山さんを相手にしたMFIについてのQ&Aをレポートします。
MFIに関して2人のGoogle社員に何でも質問してみた
[質問に答える長山さん]
Q. 内部リンクの必要性
モバイル向けページではUXを考慮して、内部リンクをPC向けページよりも減らしている。
しかし、内部リンクが評価（ランキング）にも影響するなら、PC向けページと同じリンクをモバイル向けページにも設置する必要があるか？
評価への影響はない。
UXを優先してほしい。
【鈴木補足】
サイドバーのナビゲーションやフッターなどでPCページには存在するリンクを、モバイル向けページでは省略しているケースが珍しくありません。
目的はユーザー体験を高めることで、見やすくするためだったりコードを減らすことで表示速度を上げるためだったりします。
内部リンクはURLの発見に使われます。
こちらに関しては、サイトマップで解決できるので問題ありません。
まだはっきりしていないのは、内部リンクがランキングに及ぼす影響です。
内部リンクであっても、PageRankやアンカーテキストなど、ランキングに関わってくる指標として多少なりとも使われているはずです。
内部リンクをモバイル向けページで省くことによる影響を心配する人が（僕も含めて）たくさんいます。
長山さんによれば、評価の低下を心配する必要はなくUXを優先して設計してほしいとのことでした。
Q. 構造化データ
ブラウザで表示しないコンテンツに対して、構造化データのマークアップは可能か？
原則的には、ユーザーに見えるものに対してマークアップしなければならない。
ブラウザには表示されないコンテンツにはマークアップすべきではない。
【鈴木補足】
構造化データのポリシーに従ってください。
評価やレビューがページ上にはないのに、リッチスニペットに表示させたいがために、コードの中だけで構造化データを使うことはユーザーをだますことになります。
モバイルでは表示しないパンくずリストをJSON-LDでマークアップしていいか？
これは先ほどと同じように、見えない情報を構造化データでマークアップする質問だが、性質が違う。
検索結果にパンくずリストを表示するのはユーザー体験の向上につながる。
一方で、モバイル向けページでのUXを高めるためにパンくずリストを設置しないことも理にかなっている。個人的にはやってもいい施策だと考える。
チームには提案している（が、最終的に許可されるかどうかは今の時点ではわからない）。
【鈴木補足】
次のような要望があります。
スマホの小さいスクリーンを少しでも活用したいし、ほとんど使われていないのでモバイル向けページではパンくずリストは設置しない。
コードがなくなる分、表示速度も速くなる。
だけど、検索結果にはパンくずリストを出したいのでJSON-LDだけで設定する。
そうすれば、検索ユーザーのUXを向上できる。
この要望は、ユーザーや検索エンジンをだますことが目的ではなく、あくまでもUXを重視することから発生しています。
長山さんは、個人的には良い施策だと考えるとコメントしました。
Googleの見解として、正式に許可されるといいですね。
Q. ページネーション
PC向けページは1ページだが、モバイル向けページではページ分割している。どうすればいい？
PC向けページは3ページだが、モバイル向けページは5ページある。どうすればいい？
[金谷さん] まず、そのページネーションが本当に必要なのかどうかを考えてみてほしい。
個人的には、必要がないのにページ分割しているケースが多いように感じている。[長山さん] もしどうしても分けるのであれば、PC向けページとモバイル向けページそれぞれに
rel="prev/next"を設定する。
そのうえで、モバイル向けページからはrel="canonical"でPC向けページに正規化する。
PC向けページからはrel="alternate"をモバイル向けページに向ける。リストページでのページネーションに関しては、そのリストページの2ページ目、3ページ目が検索のランディングページににふさわしいかをまず考える必要がある。
出す必要がないなら、検索のことを考なくてもいいのではないか。いずれにしても、過度に短くしている傾向が見られる。
これはUXを損ねている。
表示速度を上げるために、モバイルでは細かく分けてるのだとしたら、日本では回線は遅くないので長くても大丈夫なはず。
別の部分で速くできる。
【鈴木補足】
モバイル向けページではページネーションする、あるいはモバイル向けページではPC向けよりも細かくページネーションしている、というサイトが多く存在します。
「モバイル向けページとPC向けページをそろえるべき」というのが金谷さんと長山さんの共通した第一の見解です（ちなみに僕も同意見）。
ただそうは言っても、さまざまな事情があってページネーションをそろえない選択をしていることもあるでしょう。
楽天の宮田さんと長山さんの長いディスカッションが続いたのですが、決着は付きませんでした（僕が途中で打ち切ったw）。
モバイル向けページとPC向けページのページネーションが異なる場合は次のようにするのが基本です。
rel="prev/next"をモバイル向けページとPC向けページに設置する- PC向けページからは、モバイル向けページを指す
rel="alternate"を設置する（内容的にいちばん近いと思われるページを指定する） - モバイル向けページからは、PC向けページを指す
rel="canonical"を設置する（内容的にいちばん近いと思われるページを指定する、1ページ目でもいい）
Q. コンテンツの差異
PC向けページとモバイル向けページのコンテンツの差異はどの程度なら許容されるのか？
[金谷さん] 重要なコンテンツであればモバイルユーザーにもきちんと見せるべき。
ページネーションと同じで、コンテンツを削り過ぎているサイトが多いように個人的に感じる。[長山さん] Googleが許容するかしないではなく、ユーザーがどんなクエリでそのページにランディングしているのかを考える必要がある。
たとえば「コーヒー」でランクしているURLが「紅茶」のことを書いているページだったらおかしい。
ユーザーが求めているものは絶対に必要。
【鈴木補足】
まず大事なことは、モバイルページでコンテンツを省略することが本当にユーザーのためになるのかどうかを見極めることです。
一方的な思い込みで、削ることがないようにしなければなりません。
そのうえで省略するとしても、検索からやってきたユーザーが探している情報は絶対に残しておく必要があります。
また、「コンテンツが異なるとペナルティを受ける」と心配する人がいることについて、金谷さんは次のように釘を差しました。
そもそも”ペナルティ”という概念はGoogleにはない。
ガイドラインの違反に対しては”手動の対策”という手段を取ることはあるが、ペナルティとは違う。
コンテンツが違っていてもペナルティなどというものはない。
[質問に答える金谷さん (真ん中の花柄シャツの人w)]
Q. 導入時期
で、いつ導入するの？
なんでもったいぶるの？
まだ決定していない。
ランキングに関わるモバイル フレンドリー アップデートやインタースティシャルはローンチできる状態で発表することが多い。
一方で、MFIはまだ開発中。
仕様も議論中。
早いほうがいいだろうということでアナウンスした。ウェブは日々変わるカオスなものなので、複雑。
ウェブマスターを困らせるような大きな影響が出ないようにするために、ゆっくり進めていくことが大切だと考えているGoogleにとっては、MFIは非常に大がかりな（インフラの）変更。
想定していなかった問題が起きることもある。
影響を最小限に抑えるためにも慎重に進めていきたい。
【鈴木補足】
少なくともどのくらい前にアナウンスしてほしいかを会場に尋ねてみました。
明日からでもいいという木村さん（もうやることを終えてる）みたいな人もいれば、半年は欲しいという辻さんのような人までさまざまでした。
それでも1か月前、3か月前という人が比較的多くいました。
金谷さんたちの参考情報にしてもらえるかもしれません。
Q. RWDへの変更
現在は「別々のURL」で構成している。
いずれはレスポンシブ ウェブ デザインへの変更を予定しているが、移行が完了するまでは、MFI導入後でもこのままで大丈夫か？
別々のURL構成のアノテーションのことを聞いているのだろうと思うが、アノテーションに関しては今までどおりでいい。
変更は不要。
【鈴木補足】
気を利かせて、PC向けページとモバイル向けページのアノテーションを入れ替えて、今までとは逆にしたらどうなるかを尋ねてみました。
つまり、PCページからモバイルページへ向けて canonical を張り、PCページからモバイルページへ向けて alternate を張ってもいいのでしょうか？
長山さんからの回答は次のとおりです。
推奨に従ったほうがいい（今までどおり）。
推奨外の構成でも対応できるように備えようとは思うが、推奨どおりにしてほしい。
hreflang をPC向けページではなくモバイル向けページに設置したらどうなるか？ もついでに質問してみました。
うーん、どうなるんでしょう？ 確認してみます。
とのことでした。
オフィスアワーの質問フォームからあらためて尋ねたいと思います。
ともかく大原則として、MFIが導入されてもアノテーション関連は今までと同じだと理解しておきましょう。
Q. RWDが推奨されるが？
レスポンシブ ウェブ デザインが推奨されるが、運用の観点から採用が難しい。
別URLまたは動的配信で気を付ける点を教えてほしい。
レスポンシブ ウェブ デザインが有利ということはない。
別URLも動的配信もGoogleはサポートしている。
【鈴木補足】
パネラーとして参加していたサイバーエージェントの木村さんと楽天の宮田さんに、RWDを採用しているかどうかを話してもらいました。
まとめると次のような見解でした。
RWDを使ってるサイトもあるけれど、ほかの構成（動的配信や別URL）のほうがデザインを柔軟に変えられるので都合がいい場合もある。
また、以前からの環境の関係でRWDを利用しづらいこともある。
自分にとって最も運用しやすいものを選べばいいということですね。
MFIとは切り離して考えましょう（RWDだと、MFI対応のために必要な作業がほぼないという事実はありますが）。
Q. リンクの分散
「別々のURL」構成の場合、外部リンクの評価が（PC向けページとモバイル向けページで）分散しないか心配。
しない。
wwwありとwwwなしのリンクの分散を心配する必要がないのと同じように、（アノテーションをきちんと設定していれば）心配いらない。
【鈴木補足】
正しくアノテーション構成していればリンクの評価は統合されます。
今までもそうでしたね。
MFIで変化することはありません。
Q. ページスピード
スマホ向けページの表示速度がランキング要因になると（ゲイリーから）聞いていた。
ところが、（ジョンは）MFIでは表示速度はランキング要因にしないと発言している。
どういうこと？
ゲイリーはゲイリーだし、ジョンはジョン。
ただ、ゲイリーは思ったことをポロッと言ってしまうことがある（会場爆笑）。いずれにしても今の時点では表示速度は利用しないことに決めた。
長期的に見たら、ゲイリーが言ったように利用すべきかとは（個人的には）思う。
【鈴木補足】
MFI導入後は表示速度がランキング要因から外されるからといって、遅くても構わないということでは全然ないですね。
UXを向上させるために、高速化への取り組みは最優先課題の1つです。
Q. JS/Ajaxのコンテンツ評価
JavaScriptやAjaxで生成されるコンテンツはどのように評価されるか？
今までと同じ。
きちんとレンダリングできていれば、JavaScriptによるコンテンツであってもHTMLコンテンツと区別なく評価する。レンダリングできるかどうかは、Fetch as Googleで確認する。
【鈴木補足】
スクロールやonclickのようなユーザーのインタラクションで発生するJSコンテンツは読まれないので注意してください。
また、Googlebotがどのようにそのページをどう見ているかは、キャッシュでは確認できません。
頼れるのはFetch as Googleだけです。
MFIの影響が発生するタイミング
MFIによる影響が発生するとしたら、どのタイミングになるのか？
導入後の再クロールの後？ それともMFIを適用したインデックスが完成してからローンチ？
そのページを再クロールした後になる。
ウェブは常に変化しているし膨大な量のデータがあるので、すべてにMFIを適用してからローンチというのは現実的ではない。
【鈴木補足】
クロールが数か月に1回、半年に1回なんていうページは、MFIに切り替わるのにかなり時間がかかるでしょう。
以上です。
1時間があっという間で、少しの延長をもらっても足りませんでした。
それでも、今までにはなかった鋭い質問が多く出てきました。
MFIへの理解が深まりましたね。
回答してくださったGoogleの金谷さん、長山さんありがとうございました。
また、パネラーの木村さんと宮田さんによる要所要所での非常に役立つ実体験談もありがたいサポートでした。
そして、三澤さんはじめIn-house SEO Meetupの運営者のみなさんにもこの場でお礼申しあげます。
またモデレータをやらせてください！w