グーグル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人が提供してくれたのかをチェックしておこう。

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

古いTLSのHTTPSサイトにグーグルが警告。ただしランキングへの影響はなし
とはいえ、脆弱性があるのですぐにアップデートすべし （Search Engine Roundtable） 海外情報

HTTPSで使用するサーバー証明書にTLS 1.0（TLS バージョン1）が利用されているサイトに対する警告を、グーグルが送っているようだ。TLS 1.0は脆弱性が発見されているプロトコルであり、安全ではないためだ。

このまま使い続けたとしても、グーグル検索におけるランキングへの悪影響はないとのことである。

だがランキングには影響しないとはいえ、ユーザーに対するセキュリティは確保できない。早急にバージョンアップするべきだろう。

「HTTPSにしているから大丈夫」だと思っていても、実際には、悪意をもった者による改ざんや傍受などの影響を受ける可能性があるのだから。

ツイッターがAMPのアクセス解析を改善
ツイート経由のAMPページへのトラフィックを記録できるように （Twitter Developer Blog） 海外情報

ツイッターは、ツイッター上でAMP版のコンテンツが閲覧された際に、そのアクセス解析をしやすくするように機能を改善した――というのだが、なかなかわかりづらい。

ツイッターはAMPをサポートしている。ツイートでシェアされたURL先のページがAMP対応しているときは、AMPページを表示する。

その裏で、オリジナルのURLに対して「__twitter_impression=true」というパラメータを付けてリクエストを飛ばすようになったのだ。

また、ツイッター上でシェアしたURLにトラッキングパラメータを付けていてもAMP版には反映されないが、そうしたトラッキングパラメータも含んでリクエストを飛ばすようになっている。

なかなかわかりづらい動きだが、これはリダイレクトを使ってトラフィック分析を実現しているツールでもAMP版へのアクセスを確認できるようにということのようだ（AMPは仕様によってリダイレクトを禁止している）。

また、ツイッターからの参照であることをわかりやすく示したいという同社の意図もありそうだ。

日本時間の12月7日から、すでにこうしたトラフィックが流れている。

ただ、少し調べてみた限りでは、amp-analyticsの挙動との関係が判断できなかった。amp-analyticsとこのリクエストで二重にトラッキングされているなどの可能性がないか確認したかったのだが、調べきれなかった。

というのも、日本のいわゆる「ニュースアプリ」で、そうした問題が過去にあったからだ。

具体的には、独自に高速表示版を提供しているニュースアプリが、「ニュース提供者側が分析しやすいように」と裏でウェブサーバーにリクエストを送っていた。しかし、それによって「実際にはユーザーの目に触れることがないのにサイト上で広告が表示されたことになる」という問題があり、その仕組みを廃止したという出来事があったのだ。

現時点では、ツイッターのこの仕様で、そうした副作用がないか確認できていない。念のためにツイッターの技術情報や実際の挙動を確認しておくといいかもしれない。

よくあるハッキング手法とその対処方法
よくあるハッキング手法とその対処方法 （グーグル ウェブマスター向け公式ブログ） 国内情報

絶賛開催中の#NoHackedキャンペーンに関連した、第3弾となる記事をグーグルは公開した。今回のテーマは「一般的なハッキング手法とその修正方法」だ。

取り上げているハッキングは次の3種類になる。

• キーワードとリンクのクローキングによるハッキング
• 意味不明な内容によるハッキング
• 日本語キーワードによるハッキング

最後に今回も、大切な心構えを繰り返しておく。

セキュリティ ＝ わからない・自分は気にしなくていい

という固定観念をもしあなたが持っていたとしたら、それを取り去り、ハッキングに対してほんの少しでもいいので素直に意識を向けてほしい。#NoHackedキャンペーンをそのきっかけ作りにしたい。

Googleよりも先にgooウェブ検索がPWAとして生まれ変わった！
検索エンジンのPWAは聞いたことがない （gooプレスリリース） 国内情報

gooウェブ検索が、プログレッシブ ウェブ アプリ（PWA）としてリニューアルされた。

PWAにより表示が高速になり、またホーム画面アイコンからのアクセスが可能になった。来年の春には急上昇ワードをプッシュ通知する予定だそうだ。

検索エンジンがサイトをPWA化した例は珍しい。グーグルですら検索サイトにはPWAを実装していない。先進的な印象を筆者は受けた。

goo検索を利用するユーザーはこのコラムの読者に多いとは想像しないが、PWA化した検索エンジンがどんなふうなのか体験してみてはいかだろうか？

グーグル検索で2017年に人気急上昇した「○○とは」検索は？
SEO視点では「◯◯とは」検索に注目 （Google Japan Blog） 国内情報

グーグル検索の2017年のランキングをグーグルは発表した。

検索ニーズが急上昇したキーワードの全体ランキングは次のとおりだ。

あなたも今年検索したキーワードが含まれているだろうか？

また、急上昇のなかでも「○○とは」検索に限定した場合のランキングは、次のとおりだ。

どれもナレッジカード/ナレッジパネルとして検索結果には答えが表示されるクエリだ。スマートフォンやスマートスピーカー（グーグル ホーム）で音声検索すれば、その答えを読み上げてくれる。

「○○とは」やこれと同じ意図を持つ検索はナレッジカードや強調スニペットとして表示されることが多く、音声検索の回答としても利用される。音声検索の増加を予想しているのであれば、こうした検索に対する回答をコンテンツとして提供するのもいいだろう。

ちなみに、このGoogle Japan Blogのページをスマホで閲覧すると、表の部分が少し残念な表示になっていた。

致命的ではないのだが、少なくとも見やすくはない。

モバイルフレンドリーを牽引しているグーグルなのだから、もう一息がんばってほしいものだ。

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

新しいSearch Consoleとモバイル検索結果のテストに関する記事をピックアップ。

• 検索アナリティクスで1年分のレポートを取得可能に、最大13か月か。

  全ユーザーへの提供は年内はない模様

  ★★★★☆

  • SEOがんばってる人用（ふつうの人は気にしなくていい）
• 検索結果数が10件⇒5件、「次へ」⇒「もっと見る」のモバイル検索をGoogleがテスト中

  トップ10入りは自慢できなくなるのか？

  ★★★★☆

  • SEOがんばってる人用（ふつうの人は気にしなくていい）