グーグルSERPのスニペット量が250文字に倍増！ SEOで考えるべきことは？【SEO記事12本まとめ】

今週のピックアップ

グーグルSERPのスニペット量が250文字に倍増！ SEOで考えるべきことは？
修正は必要？不要？ （Search Engine Land） 海外情報

グーグルの検索結果に表示されるスニペットの文字数が大幅に増えた。

近年はグーグルの検索結果における変更は、さまざまな「枠」に関するものが多かったのだが、いわゆる「10件の検索結果」の表示内容が大きく変わったのは久しぶりではないだろうか（リッチスニペット系を除けば）。

これまでのスニペットは、日本語でだいたい120文字前後だった。だが今は250文字前後だ。2倍になった。

検索結果に表示されたどの項目を検索ユーザーがクリックするかに大きく影響するのが、「タイトル」と「スニペット」だ。スニペットを読み、探しているものに関連すると判断したら、ユーザーはその結果をクリックしたくなるだろう。

SEOでは「いかに検索順位を上げるか」に意識が行きがちだが、それと同じぐらい「検索結果に表示されたときに、いかにクリックしてもらうか」も大切だ（もちろん、検索経由で訪問したユーザーのニーズをいかにして満たすかが最大の焦点なのだが）。

そのため、この表示変更はSEOに比較的大きな影響があると考えていいだろう。

では、拡大されたスニペットをSEOに活用するには、われわれは何を考え、行動するべきなのだろうか。

関係してくるのはmeta descriptionタグだ。このタグの内容がスニペットに使われることがあるので、そこに何をどう書くかは非常に重要だ。

まず、これから作る新しいページでは、今までよりも倍の文字数が使えることを念頭に置いてmeta descriptionタグの内容を作るのがいいだろう。

では、既存ページでも、meta descriptionタグをすべて、もっと長い文に更新するべきだろうか？

これは一概には言えない。さらに良いmeta descriptionタグになるのであれば、追加したり修正したりする価値はあるだろう。しかし、全ページのmeta descriptionタグを変えるのは大変だろうし、そうすることに確実に効果があるとも思えない。その理由は次の3点だ。

• meta descriptionの内容をただ長くしたからといって、必ずしも検索結果でのクリック率が上がるとは限らない。

• グーグルがmeta descriptionタグの内容をスニペットとして表示するとは限らない。クエリによっては、meta descriptionをまったく使わずに、ページのコンテンツだけを利用することもまったく珍しくない。

• そもそも検索結果で表示されていなければ、meta descriptionを変えても意味がない。

結論としては、既存ページに関しては、修正する価値の高いページからmeta descriptionを見直していくのがいいだろう。具体的には、次のようにするのだ。

1. Search Consoleの検索アナリティクスで「表示回数が多いにもかかわらずクリック率が低い」クエリを抽出する。

2. そのクエリでスニペットがどうなっているかを目視で確認する。

3. 修正することで検索ユーザーにより訴求できそうなページを見つけたら、順次修正していく。

なお、meta descriptionタグはランキング要因としては使われていない。したがって、meta descriptionをいじっても検索順位に直接的な影響を与えることはない。

あくまでも検索結果でのクリック率を上げるものだと考えてほしい（検索UXを考えれば、ニーズにマッチしないユーザーのクリックを事前に避ける目的でも活用できる）。

ところで、筆者が調査した限りでは、meta descriptionタグを設定していないページでは、ほぼすべて今までよりもずっと多い文字数のスニペットが生成されていた。最大文字数いっぱいで表示されることも頻繁にあった。

スニペットに使われる保証がないことを考えれば、meta descriptionタグを自分ではまったく設定せずに、グーグルに作ってもらうという選択肢もある。そうすれば、長いスニペットを常に表示させられるようになる。

グーグル検索SEO情報

rel="canonical"のよくある14個の間違い
ジョン・ミューラー氏も感激の誤用例 （John Mueller on Twitter） 海外情報

rel="canonical"は、SEOでは重要なタグであるにもかかわらず、間違った使い方が多い。

「今までに出会ったことがあるrel="canonical"の誤用にはどんなものがあるか」――グーグルのジョン・ミューラー氏がツイッターできいた質問に、たくさんの回答がフォロワーから寄せられている。

「これは確かにあるあるだ」と筆者が認識したものをピックアップしよう。どんな結果になるかも付け足しておく。

• ×サイト内のすべてのページのrel="canonical"が、トップページを指している

  ⇒ トップページ以外が検索結果に出なくなる可能性がある（グーグル側で間違いに気付き無視してくれることもある）

• ×「HTMLのhead内のlink要素」と「HTTPヘッダー」の両方でcanonicalを指定する

  ⇒ これ自体は問題にならないだろうが、正規化するURLが一致していないとグーグルが混乱するかもしれない

• ×相対URLでcanonical先を指定している

  ⇒ 正しければ問題は発生しないが、rel="canonical"で相対URLを使うと間違ったURLを指定してしまいがちになるので、推奨されない

• ×モバイル向け表示をPC向けとは別のURLで提供している構成で、モバイルページのrel="canonical"で指定しているURLが、対応するPCページのURLになっていない

  ⇒ モバイル向けページでは正しく対応するPC向けページにcanonicalを向けなければならない（すべてのモバイルページで、rel="canonical"がPCのトップページを指しているというミスもある）

• ×ページネーション（ページ分割）しているときに、2ページ目以降をすべて1ページ目にrel="canonical"で正規化する

  ⇒ rel="canonical"の正しい使い方ではない。無視されることもある。

• ×hreflang を設定するページで、他の言語のページを指定したrel="canonical"を設定してしまっている

  ⇒ hreflangが機能しなくなり、rel="canonical"が向けられた言語のページだけしか検索結果に出なくなるかもしれない

• ×ページAのrel="canonical"をページBに指定し、ページBをページAにリダイレクトしている

  ⇒ いわば、rel="canonical"とリダイレクトの「正規化ループ」だが、どうなるだろうか？

• ×ページAのrel="canonical"がページBを指定し、ページBのrel="canonical"がページCを指定し、ページCのrel="canonical"がページAを指定している。

  ⇒ いわば「rel="canonical" ループ」だが、どうなるだろうか？

• ×（インデックスさせたくない）パラメータが付いたURLのページに、自己参照のrel="canonical"を設定している

  ⇒ パラメータなしのURLに正規化しなければならない。グーグルが自動で正規化してくれるかもしれないし、パラメータなしのURLとありのURLの両方がインデックスされるかもしれない（つまり重複コンテンツ状態）

• ×HTTPSへ移行したのにrel="canonical"が http: のURLに向いている

  ⇒ HTTPSではなくHTTPでインデックスされたままになってしまう可能性あり

• ×noindexを設定していないページのrel="canonical"が、noindexを設定しているページのURLを指してしまっている

  ⇒ 大きなトラブルに繋がるとは思わないが、インデックスさせないページに正規化するのはrel="canonical"の用法としてはおかしいため、無視されそう

• ×rel="canonical" とhreflangの同時使用。たとえば次のようなもの：

  <link href="https://www.example.com" rel="canonical"  hreflang="es" />

  ⇒ 実際にあったそうだ。気持ちはわからないでもないが無視されるだろう。

• ×URL末尾の「/」（スラッシュ）の有無が正しくrel="canonical"で指定されていない

  ⇒ ドメイン名の直後の「/」の有無が違っていても、グーグル側で等しく扱ってくれるはずだ：
  https://exmaple.com
  と
  https://exmaple.com/

  しかし、ドメイン名以降のパス部分で「/」の有無が違っていると、技術的には異なるURLだと扱われる：
  https://exmaple.com/dir
  と
  https://exmaple.com/dir/

  そのため、状況によってはrel="canonical"が正しく機能しないことがありうる

• ×本番環境で公開したサイトのrel="canonical"に開発サイトのURLを指定している

  ⇒ 本サイトが検索結果に出てこないだろう

ほかにも誤用例が報告されている。どれも間違った使い方なので、ここで挙げたようなやり方でrel="canonical"を使わないように、くれぐれも注意してほしい。

ミューラー氏は「非常に参考になった」と感激している。担当チームにもフィードバックしたそうで、rel="canonical"の改善に役立てられることを期待したい。

MFIの公式情報を久しぶりにグーグルが提供。進捗はいかに？
目新しい情報なし （グーグル ウェブマスター向け公式ブログ） 国内情報

「モバイル ファースト インデックスに向けてサイトを準備するためのヒント」と題して、モバイル ファースト インデックス（以下、MFI）に向けて必要な対応をまとめた記事をグーグルが公開した。

のだが、とりたてて目新しい情報はなかった。

これまでに出てきた情報をまとめた印象が強い。とは言うものの、散発的に出ていた情報を1つの記事にまとめられたことには、価値があるだろう。

ちなみにMFIだといっても、次の構成のサイトでは、特別な対応は必要なし。

• レスポンシブ ウェブ デザインを採用しているモバイル向けサイト
• PC版とモバイル版で、同等のコンテンツおよびマークアップを提供しているサイト

注意しなければいけないのは、

• 別々のURLでモバイル向けサイト構成しているサイト

だ。特別な対応が必要になってくる状況がある。元記事に書かれているヒントをよく読んでおくように。

気になるMFIの展開に関しては次のように説明している。

Google では上記の基準に基づいて、モバイル ファースト インデックスに対応しているかどうかをサイトごとに評価し、準備が整ったサイトから移行していく予定です。このプロセスは、ごく一部のサイトに対してすでに開始されており、検索チームが経過を注意深く観察しています。

モバイル ファースト インデックスのロールアウトを完了する時期についても、現在のところ特に定めていません。

大きな混乱が起きないように、引き続き慎重に導入を進めているようだ。

グーグルの医療・健康系アップデート、「癌」に関して信頼性がないページを検索結果から駆逐
専門家の分析から判明 （辻正浩 on ツイッター） 国内情報

医療・健康系のクエリに対するグーグルのアップデートの分析続報を辻正浩氏が共有した。「癌（がん）」に関する検索結果の状況変化だ。

癌は、病気に関する人が検索するキーワードで最も多いものの1つに違いない。非常に深刻な病気であるため、今回のアップデートが機能しているのは喜ばしい。

アップデートがうまく処理できていないクエリもあるようだが、今後の継続的な改善に期待したい。

医療・健康関連アップデート、URLパラメータ設定、MFIなど2017年最後のオフィスアワー
最後を飾るにふさわしい良い質問が多い （ウェブマスター オフィスアワー） 国内情報

今年最後のウェブマスターオフィスアワーが開催された。

登場するグーグル社員は、もちろん金谷氏と長山氏、あんな氏の3人だ。

今回は、次のような質問が取り上げられた。筆者の独断と偏見で、興味深いと思った項目を強調しておく。

• URLパラメータの矛盾した設定
• ヤフーのモバイル検索のAMP Client APIサポート
• AMP by Example サイトのrel="amphtml"
• 別ドメイン名のサイトのRSSフィード送信
• 非公開ページのモバイルフレンドリーテスト
• 医療・健康関連アップデートについて
• 画像の圧縮
• 商用利用不可のブログでの違反行為
• 英語ページが英語ページと認識されない
• 準備中なのにMFIに移行されるのを防ぐには
• MFIはオプトインではないのか？
• 誤ってインデックスされたページの削除
• PC検索にモバイルページが表示される

2017年の最後を飾るにふさわしい良い質問が多い。YouTubeに録画がアップロードされている。視聴していなければ、どんな回答を3人が提供してくれたのかをチェックしておこう。

次のページへ