[レベル: 中級]
Googleは、Mobile First Index（モバイル ファースト インデックス）の導入を正式にアナウンスしました。
モバイル ファースト インデックスでは、PC向けページではなく、モバイル向けページの評価に主に基づいてランキングが決定されます。
Gary Illyes（ゲイリー・イリェーシュ）氏が米ラスベガスで10月に開催されたPubCon Las Vegas 2016で発表していたGoogle検索の仕様変更です。
正式な実施時期はまだ決まっていません。
今後数か月にわたり小規模な実験を行ったうえでの判断になるとのことです。
評価対象がPC向けページからモバイル向けページへ
詳細は公式アナウウンスを読んでいただくとして、概要としてはモバイル ファースト インデックス（以下、MFI）では次のように変わります。
- これまで（現状）: PC向けページの評価が検索結果のランキングに用いられている。たとえスマホからのモバイル検索であったとしても、PC向けページの評価を基準にしてできあがった検索結果が提示されていた。
- これから（MFI導入後）: モバイル向けページの評価が検索結果のランキングに用いられる。たとえPCからの検索であったとしても、モバイル向けページの評価を基準にしてできあがった検索結果が提示される。
ようは、ひっくり返ります。
モバイル向けページがプライマリ（主）となり、PC向けページがセカンダリ（副）になるのです。
評価だけではなく、検索結果のtitleタグやスニペット、構造化データなど検索に関するすべての情報とシグナルにモバイル向けページが利用されます。
モバイルユーザーの急増に検索を適応
MFIの導入にGoogleが踏み切った理由は、モバイルユーザーの増加です。
モバイルからの検索ユーザーがPCからの検索ユーザーを超えた現状では、モバイル向けページを中心に据えたほうがより良い検索ユーザー体験を提供できるからです。
たとえば、モバイル向けページではコンテンツの一部を省略しているサイトがあります。
ECサイトのレビューがモバイル向けページでは省略されていたとしましょう。
スマホから検索したときに、レビューに関係するクエリでそのサイトのページが検索結果に出てくることがありえます。
なぜならPC向けページが基準になって検索結果が作られるからです。
ところが、スマホからそのページを閲覧すると実際にはレビューは存在しません。
最悪の検索ユーザー体験です。
ユーザーは困惑するでしょう。
「Google壊れてる！ヽ(`Д´)ﾉ」と憤慨するかもしれません。
こうした事態をMFIでは防ぐことができます。
悪い面を例に挙げましたが、モバイル向けページを優先にすることで、今後もっともっと増えてくるであろうモバイルユーザーに今よりも快適な検索体験を提供することがGoogleの狙いです。
時代の流れに合わせただけのことです。
MFI導入に際しての疑問にGoogle社員が回答
MFIの導入にあたり、さまざまな疑問が出てきます。
一部は公式アナウンスに書かれているので、必ず目を通してください。
きちんと説明されているのに「どうなるの？」「どうしたらいいの？」の質問はやめましょうね。
とはいえ、公式アナウンスにない疑問が当然たくさん出てきます。
Googleのゲイリーと長山さんがTwitterで僕たちからの質問に答えてくれています。
This is big, so send us your questions so we know what's not clear & what we need to communicate more about
— Gary Illyes (@methode) 2016年11月5日
何かあれば気軽に質問してくださいねー
— Kazushi Nagayama (@KazushiNagayama) 2016年11月5日
この記事を書く時点までに出てきたQ&Aを可能な限りピックアップしたので参考にしてください。
Q. 具体的な導入時期はいつ？
わからない。数か月は先になると思う。（ゲイリー）
テスト結果次第。今後もアナウンスがあるはず。（長山さん）
@ThisIsAJames i dunno. We're months away from that
— Gary Illyes (@methode) 2016年11月5日
@tsuj MFIについては将来的にもブログ記事があると思います！時期は正直テスト次第なところがあるかなと
— Kazushi Nagayama (@KazushiNagayama) 2016年11月5日
A. 対応が終わるのに最長で4か月くらいかかるかもしれない。
そのくらいあれば大丈夫だろう。
@ThisIsAJames that should be OK
— Gary Illyes (@methode) 2016年11月5日
Q. モバイル向けページとPC向けページは完全に同一じゃなければ悪影響が出るか？
よほどの差異がない限りは大丈夫。
@bobsub06 ソースを同一にしてしまうとPCページになっちゃいませんか？笑 モバイル版がPC版から大きく異るケースを覗いて、そんなに気にしなくていいと思いますよ
— Kazushi Nagayama (@KazushiNagayama) 2016年11月5日
Q. レスポンシブ ウェブ デザインだけど、PC向けサイトに設置しているサイドバーなどの要素をモバイル向けサイトでは省いている。評価に影響が出るか？
基本的には変わらないはず。
@tsuj 基本的には評価は変わらないと思います。
— Kazushi Nagayama (@KazushiNagayama) 2016年11月5日
Q. UXを高めるために、モバイルではアコーディオンでコンテンツを隠すことがある。コンテンツが見えるか見えないかで評価に差が出るか？
取り組んでいる最中。その問題に関しては解決すべきことがたしかにある。
@rlbradley We're working on that. There are definitely things to figure out on that front
— Gary Illyes (@methode) 2016年11月5日
Q. PCページの場合は、アコーディオンの中のような（初期状態で隠れている）コンテンツは重要度が下がったりインデックスされなかったりする。モバイルでも同じか？
いいや。モバイルファーストの世界では、UXのために隠しているコンテンツは完全に評価される。
@schachin no, in the mobile-first world content hidden for ux should have full weight
— Gary Illyes (@methode) 2016年11月5日
Q. モバイル向けページでコンテンツを省略しているとしたら、悪影響が出るか？
そのコンテンツがページにないのであれば、（そのコンテンツに関連することで）上位表示することはかなり難しくなるだろう。
@denstopa @krystianszastok well yeah, if the content is not on the page, it's pretty hard to rank it
— Gary Illyes (@methode) 2016年11月5日
[鈴木注: コンテンツの差異に関しては、重要なコンテンツがモバイル向けページに存在しない場合、つまりモバイル向けページでメインコンテンツの一部を省略している場合は評価に影響が出る可能性が高そうです。一方で、サイドバーのような補助コンテンツの省略は気にするほどの影響はなさそうです。また、展開式UIで初期状態でコンテンツが隠れている場合、PCでは評価が下がることがありますがモバイルでは心配しなくてよさそうです（モバイルでは普通に使われるUIだから）。]
Q. （別URL構成の場合の）rel=”canonical”とrel=”alternate”を入れ替える必要はないのか？
必要ない。もし入れ替えさせるとしたら何十年もかかるだろうから、（Google側で）賢く処理しようと思う。
今度はモバイル向けページへのalternateがcanonicalのように機能して、評価を統合するようなもの。
@gfiorelli1 @aleyda asking people to switch these would take decades, so we're trying to be a bit smarty about them
— Gary Illyes (@methode) 2016年11月5日
@EdWords @gfiorelli1 @aleyda yup
— Gary Illyes (@methode) 2016年11月5日
Q. AMPページに設置するrel=”canonical”も、PC向けページに向けたままでいいのか？
そのままで大丈夫。
canonical関連はすべて現状どおりで、変更しなくていい。
@suzukik はい、今回、canonical 関連の変更はウェブマスター側ではありません！レスポンシブなら考えることが少なくなることは事実ですね
— Kazushi Nagayama (@KazushiNagayama) 2016年11月6日
[鈴木注: 結局、今回のMFIに限らずRWDはモバイル検索の変化に耐性がありますね。UXの観点からは必ずしもRWDが優れているわけではないしランキングにも直接影響しませんが、SEO的な作業だけにフォーカスすると「RWD最強！」と言いたくなってしまいます。]
Q. AMPはどうなるの？ モバイル向けページの別バージョンとして扱われるのか？ それとも別の存在として扱われるのか？
単にモバイル向けページ。
[鈴木注: アノテーションも含めてAMPに関しては何も変更点はないという解釈でよさそうです。]
@Andrew_Isidoro it's just a mobile page
— Gary Illyes (@methode) 2016年11月5日
Q. 内部リンクの構成がモバイルとPCで違う場合で注意することはあるか？
[鈴木注: おそらくPC向けページでは内部リンクにしているけど、モバイルでは内部リンクにしていないという意味のはず]
評価という点ではおそらく影響ない。（リンク先ページのURLの）発見という点では影響があるかもしれない。ただし、URLの発見はフィード（サイトマップ）で手助けできる。
@ItsHogg @PhilJCook signals wise probably not; discovery wise it could be, but then you can help that with feeds
— Gary Illyes (@methode) 2016年11月5日
Q. リンクに関しては？
リンクについてはまだ確実なことは言いたくない。まさに進行中なので、何かを言うには早すぎる。
@jennyhalasz @schachin I don't want to say anything definite about links yet. It's too early for that cos things are very much in motion
— Gary Illyes (@methode) 2016年11月5日
Q. PC向けページはまったくランキング要因ではなくなるのか？
確かなことを言うには早すぎる。が、モバイルファーストの世界ではPCページの価値はずっと低くなる。どのくらい低くなるかは言えない。
@schachin it's too early to be definite, but desktop version will have less value in the mobile-first world. How much less I can't tell yet
— Gary Illyes (@methode) 2016年11月5日
Q. PC向けサイトしかないとしたら検索結果にはもう出なくなるのか？
PC向けサイトだけだったとしても、依然として検索結果には出て来て見つけてもらえる。モバイルフレンドリーアップデートのときも、完全に消滅してしまったサイトなんてなかったよね。
Mobile-first: with ONLY a desktop site you'll still be in the results & be findable. Recall how mobilegeddon didn't send anyone to oblivion?
— Gary Illyes (@methode) 2016年11月6日
Q. ページの表示速度がさらに重要なランキング要因になるか？
表示速度に関しては、どうするのがいいかまだ検討している最中。なかなか難しい問題。
@SEOMalc we're still considering what more can we do on the speed front. It's a surprisingly hard nut to crack
— Gary Illyes (@methode) 2016年11月5日
Q. パンダアルゴリズムも、モバイル向けページに対する評価に変わると考えていい？
理論的にはそうなる。けど、実際にどうなるかはまだわからない。
[鈴木注: ゲイリーも言っているように、鋭い質問ですね。モバイル向けページがメインの評価対象になることで、スコアリングに変化が出てくるかもしれないアルゴリズムが、パンダに限らずほかにあっても不思議ではありません。]
@emerikusz_ whoa, great question! Theoretically yes, in practice I don't know yet
— Gary Illyes (@methode) 2016年11月6日
Q. レスポンシブウェブデザインであれば、構造化データは不要？
構造化データが大事なら、すべてのバージョンのページにマークアップすべき。
[鈴木注: RWDなら構造化データがいらないというのは、どこから出てくる発想なんでしょうか？ 必要に決まってます。何かの勘違いでしょうか？ なおMFIにおいては、動的配信でも別URLでもモバイル向けページに構造化データが必須です。とはいえ、モバイル向けページとPC向けページの両方に（同一の構造化データを）記述しておくのが安心でしょう。]
@Rajesh_TB all versions should if you care about structured data.
— Gary Illyes (@methode) 2016年11月5日
Q. レスポンシブウェブデザインの場合、Search Consoleで再度サイト確認しなければならないか？
必要ない。
@methode If we have only a responsive website do we have to verify again in the search console for mobile version/ mobile index?
— Infosolutions Goa (@infosolutionsg) 2016年11月5日
@infosolutionsg sorry, I misread your tweet. No, you don't have to reverify your responsive site. My bad
— Gary Illyes (@methode) 2016年11月6日
Q. AMP導入時のように、MFIを試すことができる開発版のモバイル検索を準備してもらえないか？
実現できる保証はないけど、提案はしてみる。
@tsuj フィージビリティはちょっとわからないですが伝えてみます！
— Kazushi Nagayama (@KazushiNagayama) 2016年11月5日
対応は必要か？
MFI導入速報をこのブログで伝えたときも結論付けたように、大多数のサイトでは特別な対応は不要だと僕は考えます。
対応が必要なのは次のようなサイトになるでしょう。
- モバイル向けサイトを作っていない（ただし、検索結果から削除されることはない）
- 中途半端にモバイル対応している
- モバイル向けページでコンテンツを極端に省略している（特に別々のURL構成の場合は注意）
- 超大規模サイトで、Googlebotのクロールをコントロールするためにゴニョゴニョやっている
モバイル向けサイトをきちんと提供していて、スマホユーザーとPCユーザーに基本的に同等のコンテンツを提供しているのであれば、現状維持でまったく問題ありません。
下手に騒ぐのはやめましょう。
それでも疑問が出てきた場合は、ゲイリーか長山さんに、あるいはオフィスアワーで直接聞いてみるといいでしょう。