嘘ニュース対策をグーグルが導入。検索結果にファクトチェック情報を掲載【SEO記事12本まとめ】

グーグルは、ニュース記事などで語られている内容が事実かどうかの検証状況に関するラベルを検索結果に表示するようにした。「フェイクニュース」対策のために導入した、いわゆる「ファクトチェック」の情報提供だ。
ほかにも、グーグル社員によるSEO豆知識シリーズ【日本版】、AMPの機能強化、アメブロのHTTPS化完了、alt属性の2つのTIPS、ネガティブSEOへの対策などなど、SEOや検索エンジンに関する話題をまとめてお届けする。

嘘ニュース対策をグーグルが導入。検索結果にファクトチェック情報を掲載 [5]
ファクトチェック自体は第三者が行う （The Keyword）

illustration by つきのあめだま [6]

グーグルは、ニュース記事などで語られている内容が事実かどうかの検証状況に関するラベルを検索結果に表示するようにした。

世界的に問題となっている「フェイクニュース」対策のために導入した、いわゆる「ファクトチェック（Fact Check、事実検証）」の情報提供だ。国際ファクトチェック・デイ（4月2日）から少し遅れて4月7日に発表している。

ファクトチェックのラベル表示は、いくつかの国のグーグルニュースではしばらく前に導入されていたのだが、あらたに、すべての国のすべての言語での通常のウェブ検索の検索結果で、ファクトチェック結果があれば明確にわかる形で表示されるようになっている。

日本語サイトでの例を見つけることができなかったので、英語サイトの例をいくつか紹介する。

• こちらは、世界で最大2700万人が奴隷状態であることを報じた記事に関する表示だ。

  PolitiFactによるファクトチェック結果として、「Mostly True」（ほぼ事実）というラベルが付いている。

  

• こちらは、ナチスによるホロコースト（ユダヤ人大量虐殺）で、ユダヤ人の母親が殺される前に自分の赤ちゃんを抱っこしているとする写真に関する表示だ。

  Snopes.comによるファクトチェックの結果として「False」（偽り）というラベルが付いている。つまり、その写真は主張されている内容とは異なるということだ。

  

• こちらは、ヒラリー・クリントン氏がISISに武器を売ったと報じた記事だ。

  Snopes.comによるファクトチェックの結果として「Mixture」（事実と偽りの主張が混在している）というラベルが付いている。つまり、本当かどうかはっきりしない（または一部は正しいが事実ではない内容も含まれている）ということだ。

  

ラベルにはこのほかにも種類がある。

注意したいのは、事実かどうかを検証するのはグーグルではないという点だ。ファクトチェックを行うのは第三者のメディアであり、グーグルはその確認結果を表示しているに過ぎない。検索結果に表示されるファクトチェック情報を一切保証しないことを、グーグルは明言している。

そのため、検索結果で「True（事実）」のラベルが付いているからといって、絶対に事実とは限らない。また、1つの検索結果ページで、同じトピックに関して異なるファクトチェック結果が表示される可能性もあるという。

検索結果ページにおけるファクトチェック状況の表示は、記事発行者（サイト管理者）または第三者がファクトチェックしたうえで、記事が真実を語ったものか間違った情報なのかをグーグルに通知することで設定される仕組みだ。

通知には構造化データを利用 [7]する。グーグルは構造化データの情報を参照し、ファクトチェックの状態を検索結果に掲載する（Share the Factsウィジェット [8]を利用することでも可能）。

ただし、ファクトチェックの結果を構造化データで設定したとしても、必ずそれが採用されるわけではなく、次の条件を満たす必要がある。

• アルゴリズムが「信頼できる」と判断したサイトによるファクトチェックである
• Googleニュースのファクトチェックの条件 [9]を満たしている
• Googleニュースの一般的なガイドライン [10]を満たしている
• 構造化データの一般的な品質ガイドライン [11]を満たしている
• ファクトチェック構造化データのガイドライン [12]を満たしている

つまり、信頼性が低いサイトのファクトチェックは検索結果には利用されない。

とは言うものの、この表示はサイトが自らファクトチェック結果をグーグルに伝える形で示さなければ表示されない。そのため、意図的にフェイクニュースを掲載しているサイトの情報に関して、グーグルの検索結果で「このページの情報はフェイクニュースだ」と表示されることはない。

上記で紹介した検索結果の例も、ファクトチェック情報が表示されているのはファクトチェックを行ったサイトの検証ページであり、元のニュースページ自体ではない。

つまり、フェイクニュースが存在したとしても、グーグルの検索結果にフェイクニュースが通常どおり掲載される可能性は残っている。同じ検索結果ページ内に、その情報を検証した結果を伝える第三者のページの情報が並ぶだけだ。

それでも、自分の探している情報が事実なのか間違いなのか、あるいは真偽がはっきりしていないなどの記事の真実度を判断する一定の材料にはなる。何かの情報を目にした際に「この記事のファクトチェック状況は？」と気にする意識が進むといいだろう。

ちなみに、日本語記事のファクトチェックの例を見つけることができなかったのは、日本語のサイトでファクトチェックを行い構造化データを設定しているところがまだないからだろうと思われる。

グーグルの発表で紹介されているDuke Reporters' LAB [13]には日本報道検証機構のGoHoo（ゴフー）もリストアップされているが、サイトではまだ構造化データは設定されていないようだ。

日本でも、こうしたメディアが今後増えていくことに期待したい。

なおグーグルから日本語での公式アナウンスは出ていないが、ヘルプ記事は日本語化 [15]されている。

日本語で読めるSEO/SEM情報

グーグル社員がつぶやくSEO豆知識シリーズ【日本版】 [16]
ハッシュタグは #Google検索豆知識 （長山一石 on ツイッター）

SEOの豆知識をグーグルのゲイリー・イリェーシュ氏が解説する“DYK [17]（知ってたかい？）”で始まるツイートのシリーズがある。小ネタだが有用な情報が多いので、このコーナーでも何度か紹介 [18]している。

グーグル社員の長山氏も、ツイッターで「#Google検索豆知識」シリーズの投稿を始めた。もちろん日本語だ。

イリェーシュ氏に対抗してのものかどうかは定かではない。いずれにせよ、グーグル社員からSEOに役立つちょっとした知識を得られる機会が増えるのは、ありがたいことだ。

イリェーシュ氏もびっくりするような、役立つSEO豆知識がどんどん出てくることを期待しよう。

とは言っても、SEOには何の役にもたたない（でもおもしろい）お遊び的な小ネタもある（「SEO豆知識」ではなく「Google検索豆知識」なので）。せっかくなので、こちらも紹介しておこう。

動きのある画像コンテンツをAMPで提供可能に [25]
サムネイル付きカルーセルとフォーム＋画像サムネイル （Google Developers Japan）

AMPページで、画像のカルーセル表示や選択ができるようになった。具体的には、次の2つの仕組みを実装可能になった。

• サムネイル付きカルーセル

  画像カルーセルにサムネイル（縮小版）画像を添え、サムネイルをタップすることで、カルーセル内の特定の画像に直接ジャンプできるようにするもの。

  [25]

• フォーム ＋ イメージ サムネイル

  入力フォーム内で、画像をボタンのようにタップすることでチェックボックスやラジオボタンのような選択肢として使えるようにするもの（デフォルト設定・複数設定・無効化設定なども可能）。

  [25]

AMPと言えば「動かないシンプルなコンテンツ向け」という印象だが、動きがある要素も徐々に使えるようになってきた。

元記事ではアニメーションGIFで実際の動きを見ることができる。具体的な利用イメージや仕様の詳細は、元記事でチェックしてほしい。

毎月恒例のウェブマスター向けオフィスアワー3月開催版 [26]
今回はサイト固有の質問が多め （ウェブマスター オフィスアワー）

3月末に開催されたウェブマスター オフィスアワーを紹介する。

念のために毎回説明しているが、「ウェブマスター向けオフィスアワー」とは、グーグルの社員が登場して、一般のウェブマスターからのサイト運営に関する質問に回答したり、ウェブマスターとカジュアルに情報交換したりしていく動画プログラムだ。

だいたい1か月に1回開催されており、イベントページや専用のフォームから質問を投稿できる。

今回取り上げられた主な質問は次のとおりだ。いつものメンバーの、金谷氏と長山氏、アンナ氏の3人が回答してくれた。

• 日付が間違っているスニペット
• 違うページのmeta descriptionが表示される
• 毎年行われるキャンペーンのページがインデックスされない
• Googleアナリティクスのパラメータが付いたURLがインデックスされる
• iframeのインデックス
• クローキングの判断
• Google Optimizeのメリット
• スタンドアロンAMPのimgタグ
• スマホとフィーチャーフォンに存在しないページ
• インデックスが減少
• 手動対策の解除
• 「もっと見る」ボタンで出現するモバイル向けページのコンテンツ
• info:検索の結果がおかしい

今回はサイト固有の質問が多かったように思う。それでも参考になるだろう。YouTubeにアップロードされた録画で視聴できる。

アメブロがHTTPS移行を完了 [27]
日本のHTTPS率を押し上げるか？ （サイバーエージェントSEO情報ブログ）

アメーバブログ（以下、アメブロ）利用ブロガーにSearch Consoleの設定追加を依頼するお知らせが、サイバーエージェントSEO情報ブログに投稿された。

アメブロで進めていたHTTPS移行 [28]により、追加でHTTPSのURL（とAMP版のサブドメイン）もSearch Consoleに登録する必要が生じたのだ。

つまり、アメブロ全体のHTTPS移行が完了した。

アメブロは一般的なブログだ。匿名性や機密性が高い情報を扱っているわけではない。しかしそれでもサイト全体をHTTPSにしたのは、プライバシーやセキュリティをアメブロの運営側が重視しているからにほかならない。

日本でのHTTPSの普及率は低め [29]だが、日本最大級のブログサービスであるアメブロがHTTPSになったことで、目に見える程度に増えるのではないだろうか。

グーグルが、セーフブラウジングのサイトステータスツールをリニューアル [30]
万が一のときのために存在を知っておこう （グーグル ウェブマスター向け公式ブログ）

グーグルは、特定のサイトがウイルスやマルウェアが仕込まるなど危険な状態になっていないかチェックするツール「セーフブラウジング」のサイトステータスツール [31]をリニューアルした。

[32]

入力したURLに関するセーフ ブラウジングの最新の解析結果に加えて、トラブルシューティングのヘルプと関連資料への参照情報が表示される。

公式記事によれば、新バージョンは次のように改良されたとのことである（読みやすくするために編集部で改行を追加）。

結果の表示が簡潔で明確になり、設計が調整されています。

この変更により、セーフ ブラウジングの警告を受け取ってからツールにアクセスするユーザーや、Google でのマルウェアやフィッシングの検出についてオンラインで調べようとするユーザーにとってより使いやすいツールになりました。

ツールのユーザー インターフェースも整理され、説明はわかりやすく、結果はさらに正確になりました。

このツールは、安全かどうか不安なサイトにアクセスする前に自分でチェックするために使うことも可能だし、自分のサイトに問題が起きていないかチェックするためにも使える。

さらに今回のバージョンアップによって、事前のチェックだけでなく、万が一ハッキングによって自分のサイトでセキュリティの問題が発生した際に対処を知るためにも使いやすくなったはずだ。存在だけでも知っておこう。

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

AMPとAMP+PWAの記事を今週はピックアップ。

• AMP Start、レスポンシブウェブデザインのAMPサイトを簡単に構築できるテンプレートを公開 [34]

  美しいAMPサイトが簡単に作成できる！

  ★★★★☆

  • すべてのWeb担当者 必見！
• AMPとPWAのコンボで表示速度とコンバージョンを劇的に改善したフライト検索サイトのWego [35]

  通信環境が悪い国では効果絶大

  ★★☆☆☆

  • SEOがんばってる人用（ふつうの人は気にしなくていい）
  • ホントにSEOを極めたい人だけ

海外のSEO/SEM情報を日本語でピックアップ

グーグル社員が教えてくれた、alt属性の2つのTIPS [36]
不要な場合と必要な場合 （John Mueller on Twitter）

グーグルのジョン・ミューラー氏による、alt属性の使い方に関するTIPSを2つ紹介する。

プレースホルダー用の小さな画像にはalt属性は必要ない。

モバイル向けページの画像にも今後はきちんとalt属性を設定すること。未設定のサイトが多い。

念のために補足しておくと、「alt属性」とは、HTMLタグのimg要素（画像に使うタグ）内に記述する、画像を利用できないとき用の文字情報のことだ。

<img src="～" width="100" height="50" alt="画像の説明">

「グーグルは画像を認識できないため、SEOを意識するならalt属性に画像の情報をテキストで記述する」とがんばっている人もいるだろう。しかし、なんでもかんでもalt属性をがんばって入れる必要はない。

本来の画像や広告が読み込まれるまで代わりに表示しておく一時的な画像（プレースホルダー）や、背景に使うような画像には、alt属性を設定しなくても問題ない。コンテンツとしては特に意味がないからだ。

alt属性の本来の用途である、「画像が読み込まれない状況」「視覚障害などの閲覧者に画像ではなく文字で情報を伝える」いずれでも、alt属性を設定しないほうが自然だ。

ただし、その場合でもalt属性を省略するのではなく、alt=""と指定する。HTML5では、alt属性を省略するのは「この画像はコンテンツの重要な要素であり、代替テキストで表現できるものではない」ことを示し、空のalt属性を指定するのは重要な要素ではないことを示す [39]からだ。

一方、モバイル向けページでalt属性を省略しているサイトは実際にありそうだ。確かに、モバイル向けにできるだけデータ転送を減らすには、手段の1つとしては悪くない。

しかし、その手法は、前述のようにHTML5の仕様に照らすと適切ではないとともに、MFI（モバイルファーストインデックス）後のグーグルで問題になる可能性がある。

現状であれば、PC向けページの画像にさえalt属性があれば、グーグルはその内容を認識する。

しかしMFIに切り替わった後のグーグルが処理するのは、モバイル向けページに設置されているalt属性なしの状態だ。そうなると検索で不利になることもあるので、注意が必要だ。

ネガティブSEOへの対策にはリンクの否認だけが頼り？ [40]
ただし使い方には注意 （John Mueller on Twitter）

悪意を持って不正なリンクを張る「逆SEO（ネガティブSEO）」には、どう対処すればいいのだろうか？

「ネガティブSEOは存在しない」とグーグルは事あるごとに言っている。信じたいところだが、そうもいかないという人もいるかもしれない。

そんなときは、やはりリンクの否認に頼るしかないようだ。

ネガティブSEOをやると脅されたサイト管理者に対して、グーグル社員のジョン・ミューラー氏は否認ツールの利用（とそのリストを彼に送ること）を勧めていた。

ただし、否認ツールの利用には危険もつきまとう。不正なリンクと正当なリンクを正確に見極める力が重要だ。正当なリンクまで否認して重要な評価を失ってしまい、検索順位が下がってしまうこともある。

この件に関して、同じくグーグル社員であるゲイリー・イリェーシュ氏は次のようにもアドバイスしている。

否認したあとにランキングが下がったのなら、さほど怪しくないリンクを否認ファイルから除外するといい。否認ファイルは自分で制御できるのだから。

“良いコンテンツ”の定義は、また訪問したいと思わせるコンテンツ？ [49]
やっぱり検索エンジンではなくユーザーを向くことが大切 （John Mueller on Twitter）

「“良いコンテンツ”を定義するのは、グーグルにさえ難しい [50]」というグーグルの長山氏によるコメントを、前回このコーナーでお伝えした。

長山氏の同僚でもあるジョン・ミューラー氏は、良いコンテンツを作るために次のようにアドバイスしている。

経験に基づいておおまかに言えば、たとえ検索エンジンがなかったとしても、また戻ってこようとユーザーに思わせるようなコンテンツを作ることだ。

何度も何度も訪問してもらえるような価値があるコンテンツが、あなたのサイトにあるだろうか？ どんなコンテンツがあればリピーターになってもらえるかを考えることが、良いコンテンツ作りのヒントになるのではないだろうか？

ミューラー氏のアドバイスを抽象的だとしてそこで思考を停止させてはいけない。それでは、本当に良いコンテンツを作ることは永遠にできないだろうと筆者は考える。

少なくとも、“良いコンテンツ”を作る主眼が「検索エンジン（グーグル）に上位表示してもらうこと」ならば、何かがおかしい。

グーグルが検索結果で上位表示したいのは「グーグルを満足させようとしているコンテンツ」ではなく「検索ユーザーが満足するだろうとグーグルが判断するコンテンツ」であることは、強く認識しておきたい。コンテンツ作りにおいては、グーグルの方を向くのではなく、ユーザーの方を向かなければならない。

rel="canonical"とrobots.txtの合わせ技で重複コンテンツ対策←やっちゃダメ！ [52]
2つの間違いがある （Webmaster Central Help Forum）

重複コンテンツの発生を避けるためにURLを正規化しようとして、robots.txtによるブロックとrel="canonical"を同時に設定したサイト管理者がいた。

2つの問題があるのだが、わかるだろうか？

• 重複コンテンツ対策のためのrobots.txt使用

  まず、重複コンテンツを防ぐためにrobots.txtを使うことを、グーグルは推奨していない。そのページのコンテンツがほかのページと同じであることをグーグル自身が認識したうえで、正規化処理したいからだ。

  重複していると認識できれば、たとえサイト管理者が重複コンテンツを防ぐための施策をしていなくても、グーグルが適切に対処してくれることもある。

• robots.txtとrel="canonical"の併用

  robots.txtでブロックされているURLをGooglebotはクロールしない。クロールしないということは、ページの中身を見ない。ページの中身を見ないということは、rel="canonical"の存在を知ることができない。つまり、rel="canonical"は意味をなさない。

  似たようなミスでありがちなのが、noindexを設置したページをrobots.txtでブロックする場合だ。以前に説明 [53]したことがある。

「過ぎたるは、なお及ばざるがごとし」という言葉もある。rel="canonical"を利用して正規化するのであれば、rel="canonical"だけにするべきだ。

[54]SEO Japanの
掲載記事からピックアップ

更新なし。