グーグルの検索結果（SERP）に表示されるスニペット（説明文）の文字数が一気に倍以上になった。これをSEOに活かすには、どうすればいいのだろうか。
ほかにも、「rel="canonical"のよくある14個の間違い」「MFI最新情報」「ただHTTPSにすればいいわけではない」「gooウェブ検索がPWA化」などなど、SEOや検索業界の情報をまとめてお届けする。
今週のピックアップ グーグルの検索結果に表示されるスニペットの文字数が大幅に増えた。
近年はグーグルの検索結果における変更は、さまざまな「枠」に関するものが多かったのだが、いわゆる「10件の検索結果」の表示内容が大きく変わったのは久しぶりではないだろうか（リッチスニペット系を除けば）。
念のために説明しておくと、「スニペット」とは、検索結果に表示されるページの説明文のことだ。ページのタイトルやURLの下に表示されるもので、ページのmeta descriptionや本文からグーグルが適切な内容を自動で作って表示している。
これまでのスニペットは、日本語でだいたい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を見直していくのがいいだろう。具体的には、次のようにするのだ。
Search Consoleの検索アナリティクスで「表示回数が多いにもかかわらずクリック率が低い」クエリを抽出する。
そのクエリでスニペットがどうなっているかを目視で確認する。
修正することで検索ユーザーにより訴求できそうなページを見つけたら、順次修正していく。
なお、meta descriptionタグはランキング要因としては使われていない。したがって、meta descriptionをいじっても検索順位に直接的な影響を与えることはない 。
あくまでも検索結果でのクリック率を上げるもの だと考えてほしい（検索UXを考えれば、ニーズにマッチしないユーザーのクリックを事前に避ける目的でも活用できる）。
ところで、筆者が調査した限りでは、meta descriptionタグを設定していないページでは、ほぼすべて今までよりもずっと多い文字数のスニペットが生成されていた
スニペットに使われる保証がないことを考えれば、meta descriptionタグを自分ではまったく設定せずに、グーグルに作ってもらうという選択肢もある。そうすれば、長いスニペットを常に表示させられるようになる。
グーグル検索SEO情報 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の同時使用。たとえば次のようなもの：
⇒ 実際にあったそうだ。気持ちはわからないでもないが無視されるだろう。
× URL末尾の「/」（スラッシュ）の有無が正しくrel="canonical"で指定されていない
⇒ ドメイン名の直後の「/」の有無が違っていても、グーグル側で等しく扱ってくれるはずだ：https://exmaple.comhttps://exmaple.com/
しかし、ドメイン名以降のパス部分で「/ 」の有無が違っていると、技術的には異なるURLだと扱われる：https://exmaple.com/dirhttps://exmaple.com/dir/
そのため、状況によってはrel="canonical"が正しく機能しないことがありうる
× 本番環境で公開したサイトのrel="canonical"に開発サイトのURLを指定している
⇒ 本サイトが検索結果に出てこないだろう
ほかにも誤用例が報告されている。どれも間違った使い方なので、ここで挙げたようなやり方でrel="canonical"を使わないように、くれぐれも注意してほしい。
ミューラー氏は「非常に参考になった」と感激 している。担当チームにもフィードバックしたそうで、rel="canonical"の改善に役立てられることを期待したい。
★★★★☆
すべてのWeb担当者 必見！ 技術がわかる人に伝えましょう 「モバイル ファースト インデックスに向けてサイトを準備するためのヒント」と題して、モバイル ファースト インデックス（以下、MFI） に向けて必要な対応をまとめた記事をグーグルが公開した。
のだが、とりたてて目新しい情報はなかった。
これまでに出てきた情報をまとめた印象が強い。とは言うものの、散発的に出ていた情報を1つの記事にまとめられたことには、価値があるだろう。
ちなみにMFIだといっても、次の構成のサイトでは、特別な対応は必要なし。
レスポンシブ ウェブ デザイン を採用しているモバイル向けサイトPC版とモバイル版で、同等のコンテンツおよびマークアップを提供しているサイト 注意しなければいけないのは、
別々のURLでモバイル向けサイト構成しているサイト だ。特別な対応が必要になってくる状況がある。元記事に書かれているヒントをよく読んでおくように。
気になるMFIの展開に関しては次のように説明している。
Google では上記の基準に基づいて、モバイル ファースト インデックスに対応しているかどうかをサイトごとに評価し、準備が整ったサイトから移行していく予定です。このプロセスは、ごく一部のサイトに対してすでに開始されており、検索チームが経過を注意深く観察しています。
モバイル ファースト インデックスのロールアウトを完了する時期についても、現在のところ特に定めていません。
大きな混乱が起きないように、引き続き慎重に導入を進めているようだ。
医療・健康系のクエリに対するグーグルのアップデート の分析続報を辻正浩氏が共有した。「癌（がん）」に関する検索結果の状況変化だ。
癌は、病気に関する人が検索するキーワードで最も多いものの1つに違いない。非常に深刻な病気であるため、今回のアップデートが機能しているのは喜ばしい。
アップデートがうまく処理できていないクエリもあるようだが、今後の継続的な改善に期待したい。
★★★★☆
SEOがんばってる人用（ふつうの人は気にしなくていい） 今年最後のウェブマスターオフィスアワーが開催された。
※毎回補足しているように、「ウェブマスターオフィスアワー」とは、グーグルの社員が登場して、一般のウェブマスターからのサイト運営に関する質問に回答したり、ウェブマスターとカジュアルに情報交換したりしていく動画プログラムだ。
登場するグーグル社員は、もちろん金谷氏と長山氏、あんな氏の3人だ。
今回は、次のような質問が取り上げられた。筆者の独断と偏見で、興味深いと思った項目を強調しておく。
URLパラメータの矛盾した設定 ヤフーのモバイル検索のAMP Client APIサポート AMP by Example サイトのrel="amphtml" 別ドメイン名のサイトのRSSフィード送信 非公開ページのモバイルフレンドリーテスト 医療・健康関連アップデートについて 画像の圧縮 商用利用不可のブログでの違反行為 英語ページが英語ページと認識されない 準備中なのにMFIに移行されるのを防ぐには MFIはオプトインではないのか？ 誤ってインデックスされたページの削除 PC検索にモバイルページが表示される 2017年の最後を飾るにふさわしい良い質問が多い。YouTubeに録画がアップロードされている。視聴していなければ、どんな回答を3人が提供してくれたのかをチェックしておこう。
Web担当者に役立つ最新情報 古いTLSのHTTPSサイトにグーグルが警告。ただしランキングへの影響はなし ツイッターがAMPのアクセス解析を改善 よくあるハッキング手法とその対処方法 Googleよりも先にgooウェブ検索がPWAとして生まれ変わった！ グーグル検索で2017年に人気急上昇した「○○とは」検索は？ 海外SEO情報ブログの掲載記事から 検索アナリティクスで1年分のレポートを取得可能に、最大13か月か。 検索結果数が10件⇒5件、「次へ」⇒「もっと見る」のモバイル検索をGoogleがテスト中 Web担当者に役立つ最新情報 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とこのリクエストで二重にトラッキングされているなどの可能性がないか確認したかったのだが、調べきれなかった。
というのも、日本のいわゆる「ニュースアプリ」で、そうした問題が過去にあったからだ。
具体的には、独自に高速表示版を提供しているニュースアプリが、「ニュース提供者側が分析しやすいように」と裏でウェブサーバーにリクエストを送っていた。しかし、それによって「実際にはユーザーの目に触れることがないのにサイト上で広告が表示されたことになる」という問題があり、その仕組みを廃止したという出来事があったのだ。
現時点では、ツイッターのこの仕様で、そうした副作用がないか確認できていない。念のためにツイッターの技術情報 や実際の挙動を確認しておくといいかもしれない。
★★★☆☆
AMPがんばってる人用（ふつうの人は気にしなくていい） アクセス解析担当者に伝えましょう よくあるハッキング手法とその対処方法 よくあるハッキング手法とその対処方法 （グーグル ウェブマスター向け公式ブログ） 国内情報 絶賛開催中の#NoHackedキャンペーン に関連した、第3弾となる記事をグーグルは公開した。今回のテーマは「一般的なハッキング手法とその修正方法」だ。
取り上げているハッキングは次の3種類になる。
キーワードとリンクのクローキングによるハッキング 意味不明な内容によるハッキング 日本語キーワードによるハッキング 最後に今回も、大切な心構えを繰り返しておく。
セキュリティ ＝ わからない・自分は気にしなくていい
という固定観念をもしあなたが持っていたとしたら、それを取り去り、ハッキングに対してほんの少しでもいいので素直に意識を向けてほしい。#NoHackedキャンペーンをそのきっかけ作りにしたい。
★★★★☆
すべてのWeb担当者 必見！ 技術がわかる人に伝えましょう gooウェブ検索が、プログレッシブ ウェブ アプリ（PWA）としてリニューアルされた。
PWAにより表示が高速になり、またホーム画面アイコンからのアクセスが可能になった。来年の春には急上昇ワードをプッシュ通知する予定だそうだ。
検索エンジンがサイトをPWA化した例は珍しい。グーグルですら検索サイトにはPWAを実装していない。先進的な印象を筆者は受けた。
goo検索を利用するユーザーはこのコラムの読者に多いとは想像しないが、PWA化した検索エンジンがどんなふうなのか体験してみてはいかだろうか？
★★★☆☆
SEOがんばってる人用（ふつうの人は気にしなくていい） グーグル検索の2017年のランキングをグーグルは発表した。
検索ニーズが急上昇したキーワードの全体ランキングは次のとおりだ。
昨年と比較して2017 年中に Google で検索が急上昇したキーワード
小林麻央 北朝鮮 ドラクエ11 台風 wbc 松居一代 安室奈美恵 清水富美加 iphone 8 ブルゾンちえみ あなたも今年検索したキーワードが含まれているだろうか？
また、急上昇のなかでも「○○とは」検索に限定した場合のランキングは、次のとおりだ。
意味を調べる時によく使われる「とは」検索で急上昇したキーワード
忖度 とは プレミアムフライデー とは リベラル とは 共謀罪 とは valu とは jアラート とは ハンドスピナー とは 溶連菌 とは 衆議院解散 とは 排他的経済水域 とは どれもナレッジカード/ナレッジパネルとして検索結果には答えが表示されるクエリだ。スマートフォンやスマートスピーカー（グーグル ホーム）で音声検索すれば、その答えを読み上げてくれる。
「○○とは」やこれと同じ意図を持つ検索はナレッジカードや強調スニペットとして表示されることが多く、音声検索の回答としても利用される。音声検索の増加を予想しているのであれば、こうした検索に対する回答をコンテンツとして提供するのもいいだろう。
ちなみに、このGoogle Japan Blogのページをスマホで閲覧すると、表の部分が少し残念な表示になっていた。
致命的ではないのだが、少なくとも見やすくはない。
モバイルフレンドリーを牽引しているグーグルなのだから、もう一息がんばってほしいものだ。
新しいSearch Consoleとモバイル検索結果のテストに関する記事をピックアップ。
※このコンテンツはWebサイト「Web担当者Forum - 企業ホームページとネットマーケティングの実践情報サイト - SEO/SEM アクセス解析 CMS ユーザビリティなど」 で公開されている記事のフィードに含まれているものです。グーグルSERPのスニペット量が250文字に倍増！ SEOで考えるべきことは？【SEO記事12本まとめ】 | 海外&国内SEO情報ウォッチ
忙しい人のためのこの記事の使い方：
