もう待ったなし！ グーグルが全サイトをMFIに強制移行へ（2020年9月予定）【SEO情報まとめ】

• Google検索スピードアップデートの第2弾が来る！？
• hタグとtitleタグはページネーションの認識に役立つ、でももっと役立つのは……
• サイト内検索結果ページをインデックスさせると、大切なページの価値を薄めてしまうかも
• 「アニGIF使ってる人は、意識低すぎ」グーグルのエンジニアがダメ出し🙅
• PC画像検索で、レシピ／商品／動画にバッジアイコン表示へ
• クロールの統計情報にはご注意を。検索以外のクローラの情報も含まれている
• AMPのCSSサイズ上限が5割増しで75KBに
• AMP公式サイトはどのようにしてサイト内検索機能を実装しているのか
• ECサイトで試してみたいGoogleモバイル検索の3D&AR機能
• Google社員がコメント「アフィリエイトサイトであることをGoogleに隠す必要はない」

今週のピックアップ

もう待ったなし！ グーグルが全サイトをMFIに強制移行へ（2020年9月予定）
いよいよMFIが完結する （金谷 武明 on ツイッター） 国内情報

あなたのサイトがモバイル対応を完了させていようがいまいが、グーグルは問答無用でモバイル版をインデックスして検索の評価に使うようになる。

2020年9月からすべてのサイトをモバイル ファースト インデックス（以下、MFI）に移行することを、グーグルが告知したのだ。

こういうことだ：

• これまでは、準備ができている（とグーグルが判断した）サイトがMFIに移行していた
• 2020年9月以降は、準備ができているいないにかかわらずMFIに移行する（つまり強制移行だ）

準備ができていないのにMFIに移行した場合、ランキングが下がることもありうる。たとえば、次のようなことが発生する：

• PC向けとスマホ向けで出し分けている構成で、PC向けページに記載されているコンテンツ（文章など）がスマホ向けページにない

  → そのコンテンツの影響で検索ランキング上位だった場合、MFIになると検索順位が落ちる

• スマホ向けページには構造化データを設置していない

  → MFIになると検索結果にリッチリザルトが表示されなくなり、クリック率が下がる

いずれも、MFIではモバイル向けページがインデックス対象となり、検索順位の判定もモバイル向けページをもとに行われることから発生する現象だ。

MFI移行に向けて必要な準備に関してはデベロッパーサイトのドキュメントを参照すること（英語ページだけが更新されていることもあるので注意）。

ちなみに、PC向けしか用意していない場合は、特に心配はない。PC版がそのままインデックスされ続ける。あわてて中途半端なモバイルページを作るほうが問題になる。

（もちろん、モバイルフレンドリーの評価で影響がでる可能性もあるし、そもそもスマホで閲覧するユーザーにとって使いやすいサイトにするためには、モバイル向け表示はしっかりするほうがいいのだが）

グーグル金谷氏もがっくり!? MFI移行状況の確認方法を知らない人が17%もいた
移行済みサイトは65% （金谷 武明 on ツイッター） 国内情報

自分のサイトがMFI（モバイルファーストインデックス）に切り替わっているのかわからないし、どうやってどうやって確認すればいいのかもわからない人が、18% もいる！

これは、グーグルの金谷氏がツイッターでとった面白いアンケートで見えてきた事実だ。金谷氏は、管理サイトがモバイルファーストインデックスに移行しているかどうかをフォロワーに尋ねた。

移行していると回答した人が約65%いる一方で、移行しているかどうかがわからないうえに確認方法も知らないと回答した人が18%もいた。

サンプル数は200強だが、グーグル金谷氏のツイッターをフォローしている人なので、WebやSEOに関心がある人たちだろう。「MFIになっているかどうかわからない」人が18%もいる事実を、金谷氏は残念に感じたのではないだろうか（筆者の勝手な想像ではあるが）。

ここで、自分のサイトがMFIに移行しているかどうかを確認する方法を、念のために紹介しておく。Search Consoleを使うのがいいだろう。

1. Google Search Consoleにログインする

2. Search Consoleで自分のサイトを選ぶ（もしまだ自分のサイトをSearch Consoleに登録していなければ、登録してしばらく待つ）

3. Search Consoleの左のメニューで［インデックス］＞［カバレッジ］を選ぶ

4. カバレッジレポートが開くので、メインエリア右上の［メインクローラ］表示を見る。

   • ここが「スマートフォン」になっていれば、そのサイトはMFIに移行済みだ（おめでとう！）。

   • ここが「PC」ならば、サイトはまだMFIに移行していない。

     ※筆者注： MFIの準備が整っていても移行していないサイトがある。順番待ちの状態だ。

移行していないサイトは、移行向けドキュメントとあわせて、こちらのブログ記事も読んでおいてほしい。

グーグル検索SEO情報

Google検索スピードアップデートの第2弾が来る！？
もっと粒度の細かい評価方法とは？ （Google Webmaster Central office-hours） 海外情報

「スピード アップデート（Speed Update）」と呼ばれる検索アルゴリズムの変更を、グーグルは2018年7月に実施した。これは、ページの表示速度をモバイル検索のランキング要因に使うようにするものだった。

とはいえ、このときは「本当にものすごく遅いページだけに適用される」ものだった。常識的な範囲内の表示速度であれば悪影響を受けることはない。事実、導入後のランキング変動はまったくと言っていいほど観測されなかった。

「スピードアップデートでは、本当に遅いページだけが評価が下がる」これは今でも同じなのだろうか？

グーグルのジョン・ミューラー氏によれば、今のところ変わっていないとのことだ。依然として、極端に遅いページだけに影響する。

しかし、現状ではそうだという一方で、ミューラー氏は次のようにも付け加えている。

時がたてば、特にモバイルサイトにおいては、もっと粒度の細かい評価方法を私たちは見つけるかもしれない。

ミューラー氏の言う「もっと粒度の細かい評価方法」が具体的にどういったことを意味するのかは不明だが、将来的にスピードアップデートが改良される可能性があるということだと考えるのがよさそうだ。

現状では本当に遅いページが低評価を受けるが、ひょっとしたらものすごく速いページは高評価を受ける、なんていうふうに変わるかもしれない（※あくまでも筆者個人の単なる思い付き）。

いずれにしても、ランキング要因であろうがなかろうが、サイトの高速化はユーザー体験を高めるうえで最優先事項の取り組みであることに変わりはない。

hタグとtitleタグはページネーションの認識に役立つ、でももっと役立つのは……
内部リンク （Google Webmaster Central office-hours） 海外情報

1つのコンテンツを複数に分割している（「ページネーション」と呼ぶ）場合に、URLとしては別々のページが一連のコンテンツであることをグーグルに示すには、どうしたらいいのだろうか？ rel="prev/next"はグーグル検索ではもはや利用されていない。

グーグルのジョン・ミューラー氏によれば、次の2つは若干だが役に立つとのことだ

• titleタグ
• hタグ

titleタグで設定するページタイトルとhタグで設定する見出しが同じだったり（または共通の言葉が含まれていたり）ページ番号がふられていたりすれば、URLが別々のページであっても一続きのコンテンツだと認識する手がかりになるのだろう（人間も同じだ）。

しかし、さらに役に立つものがあるという。それは、内部リンクだそうだ。「前のページ」「次のページ」といったリンクを設置しておくと、一続きであることをより明確に伝えるシグナルとしてグーグルは認識できるのだという。

おそらく、当然のように設置している前後ページへのリンクだと思うが、もし設置していないのであれば、ぜひちゃんと出すようにしておきたいものだ。

サイト内検索結果ページをインデックスさせると、大切なページの価値を薄めてしまうかも
robots.txtでブロック （John Mueller on Twitter） 海外情報

あなたのWebサイトには、サイト内検索があるだろう。まさかとは思うが、そのサイト内検索の検索結果ページがグーグル検索にインデックスされてしまっていないだろうか？

グーグルは、サイト内検索結果ページをインデックスさせないように、ガイドラインで推奨している。

ウェブサーバー上の robots.txt ファイルを使用して、検索結果ページなどの無限のスペースのクロールを制限することによって、クロールの割り当てを管理します。

このガイドラインは、「クロール効率を良くする」ことを主眼に置いている。

それとは別の理由でサイト内検索結果ページをインデックスさせるべきではないポイントを、グーグルのジョン・ミューラー氏がツイッターで説明している。

（サイト内検索結果ページをインデックスさせると）互いに競い合う無価値なページができあがり、インデックスされているコンテンツの価値を薄めてしまう。

一般的に言って、サイト内検索は検索結果の羅列であり、検索したユーザーを除けばほとんどのユーザーにとっては価値がない。そうしたページを無尽蔵にインデックスさせることに意味はない。

クロール資源を無駄に使うだけでなく、価値が低いページを量産することにつながり、サイト全体としての品質も落としてしまう可能性があるというわけだ。

サイト品質とクロール効率の両面から、サイト内検索結果ページはインデックスさせるべきではないのだ。

Web担当者に役立つ最新情報

「アニGIF使ってる人は、意識低すぎ」グーグルのエンジニアがダメ出し🙅
表示速度を激遅にする （Addy Osmani on Twitter） 海外情報

アニメーションGIF（アニGIF）は、（場合によっては）使うべきではない

グーグルのエンジニアが、このように警告している。理由は、アニメーションGIFのファイルサイズだ。油断すると非常にファイルサイズが大きくなりがちで、そうなると、ページの表示時間を著しく遅くしてしまうのだ。

アニメーションGIFではなくMP4動画形式を使えば、同じ内容でもファイルサイズを80%～90%ほど減らせる。ページ表示がずっと軽くなるのは間違いないし、「ギガが減る」と嫌われることも少なくなるだろう。

TwitterやFacebookは、ユーザーがアップロードしたのがアニメーションGIFでも、表示時には自動変換して<video>にするという処理を昔から採用している。

それが実際にどれほど効果的なのかを確認してみよう。

グーグルの公式ブログでは、重いアニメーションGIFを使っていることが多い。たとえばこちらの記事だ。このページで使われているアニメーションGIFのファイルサイズは22.9Mバイトもある。

これを筆者がMP4に変換したところ、2.9Mバイトに縮小できた（87%も削減！）。

こちらは、アニメーションGIFから変換したMP4だ。元記事のアニメーションGIFと同じように動いているはずだ。

次の<video>タグで動画ファイルを設置している。タグの設定でアニメーションGIFのように自動再生かつループ再生にもできる。

<video autoplay loop muted playsinline>

アニメーションGIFからMP4への変換方法や<video>タグの構成については技術ドキュメントを参照してほしい。

ドキュメントではコマンドラインで変換しているが、「gif　mp4　変換」などで検索すれば、オンラインでブラウザから変換できる無料サービスもたくさんみつかる（変換するデータの扱いなどに関しては各サービスの解説をしっかりと確認してほしい）。

ちなみに、MP4よりもWebM（ウェブエム）形式の動画はさらにサイズを削減できるのだが、まだWebM形式をサポートしていないブラウザもあるのが欠点だ。とはいえ、<video>タグで<source>要素をうまく使えば、

• WebM形式をサポートしているブラウザにはWebMを読み込ませ
• WebM形式をサポートしていないブラウザにはMP4を読み込ませる

ということも可能だ。こちらの設定も詳しくはドキュメントに書かれている。

PC画像検索で、レシピ／商品／動画にバッジアイコン表示へ
構造化データで表示できる （金谷 武明 on ツイッター） 国内情報

PC版のグーグル画像検索で、検索結果画面に表示される画像に、

• レシピ
• 商品
• 動画

を示すバッジが表示されるようになった。2017年8月にモバイル画像検索に導入されたのと同等の機能だ。

バッジアイコンにマウスカーソルを当てると、レシピと動画ではテキストでの説明が出てくる。動画では再生時間が出てくる。

レシピと商品のバッジは、その画像が設置されているページに構造化データが追加されていれば出てくる。構造化データを実装しているサイトはバッジが出ているか確かめてみるといい。クリック率アップに貢献してくれるかもしれない。

クロールの統計情報にはご注意を。検索以外のクローラの情報も含まれている
新SCにクロールの統計情報レポートは移植されるのだろうか？ （Google Webmaster Central office-hours） 海外情報

もうほとんど見ることがなくなってきた旧Search Consoleだが、まだ新Search Consoleに移植されていない「クロールの統計情報」というレポートがある。Googlebotがクロールしたページ数や転送量などを知ることができるものだ。

たまに調べておきたくなるこのレポートだが、注意しておきたい点があるようだ。というのも、ここに表示されているデータには、

• ウェブ検索用のGooglebot（PC版Googlebotやスマートフォン版Googlebot）の活動

だけではなく、

• グーグル広告用など他のクローラの活動

も含まれているとのことなのだ。したがって、ウェブ検索用のGooglebotの活動を正確に監視したければ、サーバーログを見るほうがいいだろう。

ところで、新しいSearch Consoleには「クロールの統計情報」はまだ移植されていない。利用価値があるレポートなのだが、どちらかというと玄人向けだ。個人的には移植されないような気がする。

AMPのCSSサイズ上限が5割増しで75KBに
わずか25KBでもAMPでは価値ある増量 （The AMP Blog） 海外情報

AMPで利用できるCSSのデータサイズ上限が50Kバイトから75Kバイトに増加した。率にして150%への増量だ。

AMPではページで使うCSSをドキュメント内にインラインで記述することになっており、そのサイズにも厳しい制限がかけられている。

これは、ページの高速な読み込みを実現するためなのだが、そのせいで、非AMPページと同様のデザインやレイアウトにしづらいこともあった。今回増えたのはわずか25Kバイトではあるが、AMPでは価値のある増加のはずだ。

制限がゆるくなっただけなので、すでに公開済みのAMPページをわざわざ修正する必要はない。またWordPress向けの公式AMPプラグインも最新バージョンでは75KバイトまでのCSSが使えるようになっている

AMP公式サイトはどのようにしてサイト内検索機能を実装しているのか
通常サイトに勝るとも劣らない性能 （Google Developers Japan） 国内情報

AMP公式サイトが実装しているサイト内検索の仕組みを公式ブログが解説した。

AMP公式サイトはすべてAMPで構築されている。にもかかわらず、通常のサイトに勝るとも劣らないサイト内検索を提供している。

ご存知のとおり、通常のウェブサイトと比べてAMPは利用できる技術に制限がある。しかし、今のAMPをうまく使えばここまでできるということを示している。

実装に際しては次の3項目を目標にしたとのことである。

1. すべてのページで専用のレイヤーから検索できること
2. AMP デベロッパー エクスペリエンスの中核をなす AMP コンポーネントの検索に最適化されていること
3. 有効な AMP 機能を使って実装すること

活用したAMPコンポーネントは次のとおりだ。

• <amp-lightbox>
• <amp-list>
• <amp-autocomplete>
• <amp-mustache>
• <amp-bind>

技術的な詳細は参照元の解説記事を見てほしい。AMP対応していて、現在設置しているサイト内検索に満足できていなかったとしたら参考にするといい。

海外SEO情報ブログの
掲載記事からピックアップ

グーグル検索の試験機能とアフィリエイトに対するグーグル社員のコメントをピックアップ。

• ECサイトで試してみたいGoogleモバイル検索の3D&AR機能

  近未来的な機能

  ★★★☆☆

  • SEOがんばってる人用（ふつうの人は気にしなくていい）
• Google社員がコメント「アフィリエイトサイトであることをGoogleに隠す必要はない」

  隠しても品質は上がらない

  ★★★★☆

  • すべてのアフィリエイター必見！