Google、レストランのナレッジカードに批評レビュー記事を掲載。Critic reviews用のschema.orgが掲載には必要。

[レベル: 上級]

Googleは、批評家が書いたレストランやカフェのレビュー記事をナレッジカードに掲載するようにしました。
批評レビュー記事を提供しているサイトは、構造化データでマークアップすることでナレッジカードに掲載される機会を得ることができます。

ナレッジパネルに掲載される批評レビュー

こちらは「restaurants seattle」(レストラン シアトル)の検索結果に出てきたローカルパックです。

「restaurants seattle」の検索結果に出てきたローカルパック

3つ出てきたレストランの下に「E」のロゴとともに、短いスニペットが見えます。
これらは、”食”をテーマにしたEaterというサイトに掲載された、そのレストランが言及された記事のタイトルです。

タップするとそのレストランのナレッジカードに移動し、そのレストランを紹介している、もっと多くのレビュー記事を見ることができます。
ここでは、レストランレビューサイトのZagat(現在はGoogleが所有)のレビューが「Critic reviews」(批評レビュー)というラベルとともにトップに大きく掲載され、そのほかのレビューがその下にリストアップされています。

Critic reviews

レビューをタップすれば、そのサイトに移動してレビュー記事の全文を読めます。

必ずしも、レストランのレビューサイトだけからとは限りません。
The GuardianCBS Local‎のようなニュースサイトも混じっています(レビューが掲載されるサイトは後述)。

いろいろなサイトのCritic reviews

PC検索のナレッジパネルにも「Critic reviews」は出てきます。

PC検索のナレッジパネルに掲載された「Critic reviews」

ちょうど1年前に、映画やTV番組に対する批評家のレビュー記事を、同じように「Critic review」としてGoogleはナレッジパネルに掲載し始めました。
レストランやカフェなどのローカルビジネスにも批評家によるレビュー記事の掲載をGoogleは拡大したのです。

構造化データで批評レビューをマークアップ

あなたのサイトがレストランの批評記事を提供しているなら、Critic review向けの構造化データでマークアップすることによりナレッジカードに掲載される機会を得ることができます。

Critic reviewsに必要なschema.orgは、デベロッパーサイトに先日公開されました。

Critic review definitions

ただし、Critic reviewはまだ試験運用中です。
ZagatやEaterなど限られたパートナーサイトが参加しているにすぎません。

興味を持った場合は、専用フォームから参加をリクエストする必要があります。

ローカルビジネスの批評レビューは、今のところ米Google (google.com) の英語のレビューが対象です。
しかしほかの国と言語にもすぐに展開するとのことです。

ユーザーによって投稿されたレビューではなく、精通しているライターによって書かれたレストランのレビュー記事を掲載しているサイトは今のうちから準備に取り掛かると面白いかもしれませんね。
ナレッジカードを通じて、あなたの批評レビュー記事をさらに多くのユーザーに読んでもらえるチャンスを手にできそうです

批評レビューのナレッジカード掲載に興味を持ったならこちらのGoogle公式情報をお読みください。

- Google、レストランのナレッジカードに批評レビュー記事を掲載。Critic reviews用のschema.orgが掲載には必要。 -

Posted on: 海外SEO情報ブログ - SuzukiKenichi.COM by Kenichi Suzuki

Google、www.google.comドメインにHSTSを適用。常にHTTPSで接続するように

[レベル: 上級]

Googleが検索を完全にHTTPS化して以来まもなく5年がたちます。
さらにセキュリティを高めるために、www.google.comドメインで HTTP Strict Transport Security (HSTS) の実装を始めたことをGoogleはアナウンスしました。

HSTSを適用したことにより、米Google検索を含む www.google.com ドメインを利用するときの2回目以降は、たとえ http で始まるURLでアクセスしようとしたとしても、ブラウザ側で https に置き換えてアクセスするようになります。

※HSTSに詳しくなければ、Web担当者Forum連載コラムでの解説をご覧ください。このブログのHTTPS移行の際にもHSTS(とPreload HSTS)を実装しています。

www.google.com のHSTSを検証

www.google.com が本当にHSTSになっているかどうかを確かめてみました。

HTTPヘッダー

HTTPヘッダーでは、Strict Transport Security がきちんと返されています。

Strict Transport Securityヘッダー

ちなみに、max-age が「86400」に設定されています。
単位は秒で、86,400秒は1日です。

非常に短い期間ですが、www.google.com は極めて巨大なサイトなので、移行にともなって発生するかもしれない問題を回避するためにあえてこのように短く設定しているとのことです。
今後数か月かけて、最低でも1年間の有効期間になるまで徐々に増やしていく予定です。

GoogleニュースのHTTPS移行でも、max-age を徐々に増やしていくことをGoogleはアドバイスしていましたね。

僕は最初から1年(31536000秒)でした。w

Google Chrome

Chromeのアドレスバーに「chrome://net-internals/#hsts」を打ち込むことで、ブラウザ(Chrome)が認識しているHSTSのステータスを調査することができます。

www.google.comで検索します。
「dynamic_upgrade_mode」の「STRICT」が、HSTSが適用されていることを示しています。

dynamic_upgrade_mode: STRICT

www.google.co.jpには(まだ?)HSTSは実装されていません。
「dynamic_upgrade_mode」は「UNKNOWN」になっています。

dynamic_upgrade_mode: UNKNOWN

307リダイレクト

ブラウザがHSTSを認識している状態で、HTTPの http://www.google.com にアクセスしてみました。

307リダイレクトが返っています。

307 Internal Redirect

307はブラウザ内部でのリダイレクトです。
HSTSが正常に動作している証拠ですね。

GmailやYouTubeはすでにHSTSを実装しています。
Google検索のHSTS適用はむしろ遅めだったのかもしれません。
今のところは、www.google.com だけですが、いずれは www.google.co.jp はもちろんのこと世界中のGoogleに広めていくのでしょう。

常時HTTPSのサイトをあなたも運営しているなら、セキュリティをさらに高めるためにもHSTS(とPreload HSTS)の実装をお忘れなく。

- Google、www.google.comドメインにHSTSを適用。常にHTTPSで接続するように -

Posted on: 海外SEO情報ブログ - SuzukiKenichi.COM by Kenichi Suzuki

Googleニュース登録サイトのHTTPからHTTPSへの移行に際してよくある質問にGoogleが回答

HTTPからHTTPSへの移行に際して、Googleニュースに登録しているパブリッシャーからよく尋ねられる質問とその回答を、Google+のGoogleウェブマスター公式アカウントが共有しました。

We collected a few questions from news publishers related to HTTP to HTTPS site moves, but some of the answers are relevant to all webmasters who are considering going secure.

長山さんがそのうち日本語に訳してくれるように思いますが、それまでのつなぎとして代わりに僕が翻訳したものをこのブログに掲載します。

基本的には、Googleニュースに登録しているサイト向けですが、一般サイトのHTTPS移行のときにも役立つ情報も含まれています。

ではお読みください。

Googleニュース登録サイトのHTTPS移行でよくある質問

Q. HTTPSに一度に移行すべきですか? それとも少しずつ移行すべきですか?

A. トラフィックとインデックスに影響がないかどうかをテストするために、サイトの一部分だけを初めは移行することを推奨します。その後は、サイトの残りを一度に移行してもいいし、部分部分に分けて移行しても構いません。

サイトの最初にテストするセクションを決める際には、変更する頻度が少なく、頻繁だったり予測できなかったりする出来事によって大きな影響を受けないセクションを選ぶようにします。

1つのセクションだけを移行するのは移行を試すのにとてもいい方法ですが、検索に関して言えば、必ずしもサイト全体の移行の見本になるとは限らないことを覚えておいてください。多くのページを移行すれば移行するほど、解決が必要になってくる別の問題に直面しやすくなります。問題を最小限に抑えるために、綿密に計画します。

Q. どのくらいの期間テストを実行すべきですか?

A. クロールとインデックスが変更を認識できるようにするため、それに加えてトラフィックを監視するために数週間を予定してください。

Q. 1セクションだけから始めたとしても、サイト全体をHTTPSで利用できるように計画しています。HTTPSのコンテンツが先にインデックスされないように、リダイレクトやrel=”canonical”を使うべきですか?

A. 技術的な仕組みから、リダイレクトを設置したらそういったページ(HTTPでインデックスさせたままのHTTPSページ)をテストできないでしょう。したがって、rel=”canonical”を推奨します。

Q. HTTPのサイトマップをrobots.txtで参照しています。HTTPSの新しいサイトマップを含むように更新すべきでしょうか?

A. HTTPのサイトマップとHTTPSのサイトマップをそれぞれ指すように、HTTP用とHTTP用にrobots.txtファイルを別々に分けることを推奨します。また、1つのURLは片方のサイトマップだけに記述するようにすることも推奨します。

Q. HTTPS化のテスト中は、HTTPSのセクションをどちらのサイトマップに記述すべきでしょうか?

A. 移行するセクションだけのサイトマップを別個に作ることができます。こうすれば、テスト対象のセクションのインデックスをより正確に追跡できます。ただし、テスト対象のURLがほかのサイトマップに重複しないようにくれぐれも注意してください。

Q. HTTPSバージョン用のrobots.txtに、特別に何か追加するものはありますか?

A. いいえ、ありません。

Q. 私たちのHTTPSサイトは、まだ移行していないページをHTTPにリダイレクトして戻しています。サイトマップには何を記述したらいいでしょうか? HTTPとHTTPSの両方のURLをサイトマップに記述するのでしょうか? テストしているセクションで、HTTPのURLがHTTPSのURLにリダイレクトしている場合はどうなるでしょうか?

A. ユーザーが訪問したときにリダイレクトするかどうかにかかわらず、HTTPのURLはすべてHTTP用のサイトマップに、HTTPSのURLはすべてHTTPS用のサイトマップに記述します。リダイレクトとは関係なしにサイトマップにページを記述すれば、新しいURLを検索エンジンがより早く発見する手助けになります。

Q. includeSubDomains をHSTSヘッダーに設定した場合、どのドメインに影響しますか?

A. サイト全体をHTTPSに移行したあとは、セキュリティをさらに高めるためにHSTSプリロードに対応させることができます。HSTSを有効にするためには、includeSubDomains ディレクティブをHSTSヘッダーに設定しなければなりません。

includeSubDomains が設定されたHSTSヘッダーを www.example.com のサイトが返したとしたら、次のようなドメイン名のサイトに適用されます。

  • www.example.com
  • foo.www.example.com

しかし、次のようなドメイン名のサイトには適用されません。

  • notexample.com
  • foo.example.com

ただし、HTTPに戻す際の手順をHSTSは複雑にします。次のステップを推奨します。

  1. まず、HSTSなしでHTTPSを展開する。
  2. 短い期間を指定した max-age でHSTSヘッダーの送信から始める。ユーザーとほかのクライアントの両方からのトラフィック、また広告などの付属要素のパフォーマンスを監視する。
  3. HSTSの max-age の期間を徐々に増やしていく。

HSTSがユーザーと検索エンジンに悪い影響を与えなかったら、望むのであれば、ChromeのHSTSプリロードリストにサイトを追加するように依頼できます。

[鈴木補足: HSTSとプリロードHSTSがわからない人は、Web担当者Forumのコラムでの解説記事をお読みください。]

Q. サイト全体に対して単体のGoogleニュースサイトマップを使っています。部分的に少しずつ移行するとしたらどうしたらいいですか?

A. HTTPSの新しいセクションに対してニュースサイトマップを使いたいのであれば、プロトコルが変わったことを知らせるためにニュースチームにコンタクトを取らなければなりません。その後、Search ConsoleのHTTPSのプロパティで、HTTPSに移行したセクションごとに新しいGoogleニュースサイトマップを送信できます。

Q. HTTPSの移行に伴って、Google ニュース パブリッシャー センターでやることが推奨されるようなことは何かありますか?

A. パブリッシャーセンターはHTTPからHTTPSへの移行を透過的に処理します。ニュースサイトマップを利用しないのであれば、一般的には、Googleニュースの観点からは何もする必要はありません。その場合は、ニュースチームにコンタクトして変更について知らせてください。変更したセクションについても知らせることができます。たとえば、HTTPSへ移行している場合は、http://example.com/section を https://example.com/section へ移行していることを指定できます。

以上です。

常時HTTPSへの移行を計画している人は、僕のブログのHTTPS移行時のステップ・バイ・ステップも参考にしてください。

- Googleニュース登録サイトのHTTPからHTTPSへの移行に際してよくある質問にGoogleが回答 -

Posted on: 海外SEO情報ブログ - SuzukiKenichi.COM by Kenichi Suzuki

低品質ページが多いからといってGoogleのアルゴリズム評価が下がるとは限らない、しかしユーザー体験の観点からは削除すべき

高品質なページに比べて低品質なページがサイト内にたくさんあるからといって、必ずしも、サイト全体の評価が下がるわけではありません。
とはいえ、質が悪いコンテンツばかりのサイトをユーザーが気に入るはずがありません。
したがって、ユーザー体験を高めるためにも低品質なページは削除するか改善することが望まれます。

Googleはページ数だけで評価しない

英語版のオフィスアワーで参加者がこんな質問を投稿しました。

もしサイト内のページの70%が低品質で、30%が高品質だったとしたら、Googleが直接割り当てるドメインスコアが低くなって、最終的に、サイト全体のランキングに影響しますか?

GoogleのJohn Mueller(ジョン・ミューラー)氏は次のように回答します。

なんとも言えない。場合によってはそういうことがあるかもしれない。

検索検索のどの順位にそうしたURLを配置したらいいかを私たちが判断する際には、単にページの数だけではなくもっと多くのことを見ている。

たとえば、カレンダーのスクリプトをサイトに1つ設置し、それが100,000ページを自動生成していて、同時に、質が本当に高いページも5つ持っている状況を考えてみてほしい。

スクリプトで作られた実質的に中身がない100,000ページと良い5ページという理由だけで、悪いウェブサイトということにはならない。

その5ページはとても良いページだということだってありえるから、検索結果で表示したいと私たちは考えるかもしれない。特定のクエリに対して検索結果で表示するのにふさわしいかもしれないからだ。役に立つ情報を提供するかもしれないし、ユーザーの疑問を解決するかもしれない。抱えている問題を解く助けになるかもしれない。

したがってページ数だけを見るというものではない。

だが一般的に言って、サイトを見て、「粗雑なページがたくさんある、このページのコンテンツは古くて質が低い」と感じたのなら、Google側のアルゴリズムによる対処がどうであれ削除した方がいい。

ユーザーがそういうのに出くわしたなら、「この1ページだけはすばらしいけど、このサイトにある他のページは本当にひどい」と言うかもしれない。そんなことになったら、忠実なユーザーにはそのユーザーはならないだろう。もう戻ってこないだろうし、ほかの人にあなたのサイトを勧めることもないだろう。

アルゴリズムの評価が下がるとは限らないがユーザーの評価は下がる

たとえ低品質なページが大部分を占めていたとしても、高品質なページに対するアルゴリズム的な評価までもが下がるとは限らないようです。
クエリによっては、(数少ない)高品質ページが検索結果で上位表示することがありえます。

しかし、低品質なコンテンツばかりのサイトをユーザーが好きになるはずがありません。
1回訪問して、それっきりでしょう。
ブックマークしたりRSSに登録したりすることはないでしょう。

リピーターになってもらう、評判を高めるという観点からは質が低いコンテンツは存在させるべきではありません。

もっとも、質が低いコンテンツばかりのサイトは検索結果でも全体的に不利になる傾向にあるように僕は経験から感じます。
むやみにページ数を増やすのではなく、本当に質が高いコンテンツだけでサイトを作り上げたほうが全体的な評価が上がるはずです。

また可能であれば、低品質だからといって単純に削除するのではなく高品質になるように改善するほうが好ましいことを最後に付け加えておきます。

- 低品質ページが多いからといってGoogleのアルゴリズム評価が下がるとは限らない、しかしユーザー体験の観点からは削除すべき -

Posted on: 海外SEO情報ブログ - SuzukiKenichi.COM by Kenichi Suzuki

「301/302リダイレクトでPageRankが失われることはもうない」とGoogle社員が認める

[レベル: 中級]

Googleにおいては、301リダイレクトを設定した場合、いくらかのPageRankが喪失します。
しかしこれはもう過去の話です。
現在では、301リダイレクト302リダイレクトを含む30x系のリダイレクトでPageRankが失われることはありません。

Googleのゲイリー・イリェーシュとジョン・ミューラーがともに認める

PageRank喪失の仕様が現在は適用されないことを最初に明らかにしたのは、GoogleのGary Illyes(ゲイリー・イリェーシュ)氏です。

30xのリダイレクトがPageRankを失うことはもうない

ゲイリーのツイートが正しいことを、John Mueller(ジョン・ミューラー)氏も、昨日のオフィスアワーで認めています。

301リダイレクトも302リダイレクトも、300番台のリダイレクトではなんであろうが現在はPageRankを失うことはないだろう。

これからは安心して301/302リダイレクトを使える

301リダイレクトによるPageRankの喪失をGoogleが発生させていた大きな理由は、スパム対策です。

301を不正に利用する人たちがいます。
たとえば、301リダイレクトを繰り返して大元のサイトを隠蔽したりします。
マネーロンダリングみたいなものですね。
そうした不正利用に対処するためでした。

不正利用への別の対策が可能になったのかどうかはわかりませんが、いずれにしても現在は301リダイレクトでPageRankが失われることはありません。
喪失処理の撤廃は301リダイレクトだけではなく、302リダイレクトも307リダイレクトも含めて、300系リダイレクトすべてに当てはまります。

リダイレクトの影響で失われるPageRankはもともと微々たるものでした。
気にかける必要はまったくなかったのです。

それでもSEOを意識している人にとってはインパクトがある情報だったため、ドメイン名移転やHTTPS移行に際して301リダイレクトを使うことに強い抵抗を示す人がたくさんいます。
それしか手段がないにもかかわらずです。

ですが、もはやそういった(本当に些細な)心配をする必要はなくなりました。
これからは安心してリダイレクトを使えます。

ちなみにPageRank喪失の仕様が廃止されたのは、最近の話ではなくしばらく前からとのことです。

なお、301リダイレクトと302リダイレクトはどちらもPageRankを渡します。
「302リダイレクトはPageRankを渡さない」は必ずしも正しくありません。
301よりも302が適切だと考えるなら、302を使ってもなんら問題ありません。

301と302、307をはじめ各種リダイレクトの違いはこちらの記事を参照してください。

- 「301/302リダイレクトでPageRankが失われることはもうない」とGoogle社員が認める -

Posted on: 海外SEO情報ブログ - SuzukiKenichi.COM by Kenichi Suzuki

「ありがとうございます!」のような感謝系の1行コメントを削除すべきか?

[レベル: 初級]

「ありがとうございます!」「参考になりました!」こういった非常に短い、ただの感想コメントはそのままにしていおいても問題ないのでしょうか?
それとも削除すべきなのでしょうか?

GoogleのJohn Mueller(ジョン・ミューラー)氏がTwitterでフォロワーからの質問に回答しました。

スパムコメントを私は削除しています。「この記事に本当にひらめきを得ました!」のような感謝系のコメントはそのままにしおくべきでしょうか? それとも削除すべきでしょうか?

まったくあなた次第だ。私にとっては、問題ないものもあるだろうし、単にリンクを張ろうとしているものもあるだろう。

コメント管理はしっかりと

コメントはそのページのコンテンツの一部になります。
有益なコメントはほかのユーザーの役に立つことがあります。
コメントに書き込まれたことが検索にひっかかって、検索トラフィックが生じることすらあるでしょう。

とはいえ、「ありがとうございます!」「参考になりました!」のようなコメントがたくさん集まってもページの価値を上げることはなさそうです。
そうは言っても、本当に感謝の気持ちを伝えるために(人間)が書き込んでくれたのであれば、もちろん嬉しいことなのでそのままにしておいてもまったく問題ありません。

問題なのは、自動生成されたコメントやまったく関連性がないページヘのリンクを落としていくスパムコメントです。
放置しておくとそのページやサイト自体の評価が下がることがあり得ます。
その記事を読んだユーザーに不快感を与えるようなコメントは根本的に削除すべきです。

たいていのCMSは、コメント内のリンクにnofollowが自動で付く設定になっています。
しかしそれでも、リンク獲得を目的としたコメントなら削除対象にしたほうがいいでしょう。

コメントを開放しているサイトの管理者は、コメント管理も重要な仕事であることを認識しておかなければなりません。
自動承認せずに手動で承認したり、スパムコメントを弾くプラグインなどを活用できます。

コメントではありませんが、サイト管理者ではなくユーザーが生成したコンテンツが理由でGoogleから手動の対策を受けたケースが過去にあったので紹介しておきます。

最後におまけを。

WordPressのコメントスパム対策プラグインといえば、Akismetが有名です。
僕はこれに加えてSiteGuard WP Pluginのコメント認証も併用しています。

SiteGuard WP Pluginの良いところは、「日本語」のキャプチャをコメント投稿時に要求することです。

SiteGuard WP Pluginのコメント認証

自動化されたボットのコメントスパムは海外(特にロシアや中国)から来るものが大半です。
キャプチャ認証を使っていても、英数字だとくぐり抜けてしまうコメントスパムもあります。

しかし海外製なので日本語入力ができません。
つまりSiteGuard WP Pluginの日本語キャプチャをパスできないのです。

Akismetは、ほとんどのスパムコメントを検出してスパムボックスに入れてくれますが、それでもコメント自体は投稿されてしまいます。
SiteGuard WP Pluginなら投稿すら拒絶します。

SiteGuard WP Pluginを入れて以来、スパムコメントが本当に激減しました。
ほかにもセキュリティを高める機能があり、SiteGuard WP Pluginは僕のお気に入りのプラグインの1つです。

- 「ありがとうございます!」のような感謝系の1行コメントを削除すべきか? -

Posted on: 海外SEO情報ブログ - SuzukiKenichi.COM by Kenichi Suzuki

Googleのゲイリーに、RankBrain・クリックデータ・AMP・アプリetc.について質問してみた【オーストラリア編】

5月にオーストラリアのアデレードでBig Digital Adelaideというカンファレンスが開催されました。
このときに、GoogleのGary Illyes(ゲイリー・イリェーシュ)氏に Woj Kwasi氏が1対1でインタビューし、それをブログに公開しています。

Wojさんから許可を得たので、一部ではありますが、そのインタビュー記事を僕のブログで紹介します。
RankBrainや検索結果クリックデータ、AMP、アプリなど興味深い部分に絞って翻訳したのできっと参考になるはずです。

Gary Illyes

RankBrain

Q. RankBrainが、どうやってGoogleがクエリをより適切に理解できるようにしているのかを説明してもらえますか? コア アルゴリズムとどんなふうに調和しているのでしょうか?

3番目に重要なアルゴリズムと言われているが)、どの側面から見るかによってその重要性は変わってくる。ほとんどすべてのクエリに影響を与えるので、重要なランキング要因だ。

多くの場合、検索結果はコア ランキング アルゴリズムによってすでに順位付けされているから、クエリスタックに対してRankBrainは何もしない [鈴木注: “クエリスタック (query stack)”がどんなものかはっきりしないのですが、たぶん、クエリに対して、一連のアルゴリズムがスコアリングしたプロセスまたはその結果だと推測します。]

しかしこれまでに見たことがないクエリ ―― 本当に長くて複雑なクエリ ―― に対しては、ユーザーにとって何が最も適切かをとても上手に推測できる。

RankBrainがやっていることというのは、事前に与えられた訓練データに基づいたクエリを見て、個々のクエリに対して最も適切な結果を提供するために設定された結果から予測しようとすることだ。

否定系のクエリを本当に上手に解釈することもできる。たとえば”Can I beat Mario without using a walk-through?”(攻略法なしでマリオブラザーズをクリアできるか?)というクエリでは、従来は、クエリの中にある”without”(〜なしで)を我々のアルゴリズムが理解することはとても難しかった。たいていは無視してしまう。RankBranでは、そういった種類のクエリを上手に扱える。

RankBrainはオフラインのアルゴリズムだ。新しい訓練データとともに時々リフレッシュされる。

検索結果のクリックデータ利用

Q. 検索結果をランキング付けするときに、クリック率と同様に検索結果への直帰もGoogleは考慮しているというのは本当ですか?

それは本当によく聞かれる質問だ。すべてのカンファレンスで聞かれる。

クリックは一般的に、非常にノイズが多いシグナルだ。クリックデータから観察調査しようと取り組んだことがある。難題を一刀両断に解くようなものだ。

(本来の使い方とは異なる目的で)検索結果を取得しランキングデータを集めようとする人がものすごくたくさんいる。理由が何であれ、そういう人たちは検索結果のリンクを自動でクリックしようとする。これは、とても乱雑な状態を作り出す。

制御した実験を行う際には、たしかに我々はクリックデータを見なければならない。ランキングアルゴリズムの変更を実施する前に我々が通常やることは、1%のユーザーを切り離して、その人たちに新しいアルゴリズムやそのアルゴリズムの一部によって修正された結果を見せて、その結果を気に入るかどうかを調べることだ。

こういった場合は、クリックした後の滞在時間が長いとか検索結果に直帰したとかなどを実際に調べている。

だが一般的には、さっき言ったようにクリックデータはとても乱雑だ。

パーソナライズに関して言えば、クリックデータを好んで使っている。はっきりしているからだ。

ボットの割合

Q. インターネットのどのくらいの割り合いが、ボットに対して本当の人間ですか?

面白い質問だ。

ビッグデータからいうと、だいたい「30%対70%(人間:ボット)」の割り合いだ。

モバイルもPCも同じくらいだ。

したがって、検索結果を不正に取得しているボットを我々は絶えず抑えようとしている。ボットをだますために、ウソの検索結果を見せることもときにはある。

我々にとってボットは大きな問題ではないが、注意して監視すべきものではある。

そんなに激しいものでなければ、たいていはアクションを起こすことはない。だが激しくなってユーザーの検索体験に被害を与えるようならブロックする。

透明性

Q. 昨年2月に透明性をより高めるとGoogleは公表しました。これはGoogleにとって優先事項ですか? 透明性をもっと高めるべきだと考えていますか?

範囲がとても広い質問だ。透明性はとても重要だと思うが、透明性を高めることによって我々の運営が損なわれないようにもしなければならない。

モバイルに関してはどうしていくかを公表し続ける。通常、今までにはやらなかったことだ。新たなことを公開するのはGoogleでは簡単なことではないし間違ってしまうこともたくさんあるから、きちんと機能するまでは決して事前にアナウンスすることはなかった。

モバイルに関しては、絶えず取り組んでいく。

モバイルフレンドリーの更新であろうがAMPであろうがApp Indexingであろうが、(モバイルに関しては)実際に事前にアナウンスしてきた。Google I/Oでもかなりの事前アナウンスがあった。

改善の余地があるかどうかだって? もちろんだ。改善の余地は常にある。

改善に取り組んでいるところだ。報道発表にもっと多くのメディアを巻き込みたい。たとえば、米国以外の国にも広げたい。報道関係やブロガーへのリーチも広げている。

ウェブ vs. アプリ

Q. モバイルウェブよりもモバイルアプリの開発に投資したほうがいいビジネスはありますか?

答えは「Yes」だと思うが、ものごとに例外は付きものだ。

私自身の観点から見れば、一般的にはモバイルウェブのほうが重要だ。なぜならアプリにおいては、常に”付加物”があるからだ ―― アプリをダウンロードしてインストールするという追加のステップが必要になる。

Instant Apps [鈴木注: Instant Appsはこちらで] がおそらく状況を多少は変えるだろうが、アプリの情報にアクセスできるようになる前にはやはり、アプリの一部分をダウンロードしてインストールしなければならない。

ウェブサイトではこういったことは必要ない。すぐにコンテンツを利用できる。Facebookだろうがなんだろうがリンクをタップするだけだ。

AMP

A. どんな状況でAMPを考慮すべきですか?

AMPは我々にとってもっともっと重要になってくると思う。

実に遅いウェブに私たちは住んでいる。特に、自分がいる国にエッジサーバーがないほかの国のコンテンツにアクセスするときは特に遅くて、何かが表示されるまで長い間待つだろう。

たとえば私のお気に入りのニュースサイトは、ここオーストラリアでは表示に20秒もかかる。私のデータは2つの海と少なくとも3つの大陸を超えていかなければならず、それが表示や体感速度を遅くさせる。

AMPでは、自分の国のローカルサーバーあるいは最も近いエッジサーバーにコンテンツがキャッシュされるし、AMP化されたページは通常のページよりもずっとずっと軽量なので、コンテンツ発行者はこんなふうな遅い状況を避けることができる。

音声検索

Q. 音声検索で使われている語句や用語はテキスト入力とどんなふうに違っていますか?

テキスト入力で検索するときは、クエリはとても短い。なぜなら入力するのはみんな好きじゃないし、スマホでタイプするのは楽しいことじゃないからだ。

しかし音声検索では、ユーザーは質問を丸ごと、そのままの文で言う。だから、音声検索はもっとずっと長くなる傾向にある。また数語ではなく、自然な話言葉が使われる傾向にもある。

これは状況を変える。自然な言葉が使われても、短いクエリが使われたときと同じ結果を我々は取得したいと考える。クエリにはそれほど影響しないと考える。しかし、SEOの実験をするには面白いかもしれない。

以上です。
特にインパクトがあったのはどれだったでしょうか?

この記事では一部分だけの紹介ですが、全文はKwasiさんの元記事をお読みください。

Gary Illyes Interview – Let Me Google That For You

Thank you, Kwasi! :)

- Googleのゲイリーに、RankBrain・クリックデータ・AMP・アプリetc.について質問してみた【オーストラリア編】 -

Posted on: 海外SEO情報ブログ - SuzukiKenichi.COM by Kenichi Suzuki

【確定】誰が記事を書いたかをGoogleはランキング要因にしていない、もう一度ジョン・ミューラーに質問してみた。

[レベル: 中級]

GoogleのJohn Mueller(ジョン・ミューラー)氏によれば、記事がだれによって書かれたかをGoogleは認識しておらず、コンテンツ品質の評価要因にもしていないとのことでした。

とはいえ、僕の質問の仕方がよくなかったせいか、コピーコンテンツの判断をGoogleは上手にできるという話がメインになってしまっていました。

そこで、先週のオフィスアワーでもう一度、今度はもっと明確に、コンテンツ著者がだれなのかをGoogleは本当にランキング要因にしていないのかをジョンに尋ねてみました。

結論を一言で言えば、やはりコンテンツ著者が誰であるかをGoogleはランキング要因にはしていません

その理由をジョンは次のように説明してくれました。

Googleはなぜコンテンツ著者を見ていないのか?

僕からの質問です。

前回、だれが記事を書いたかをGoogleは本当にはわかっていないと言いました。それはつまり、だれがコンテンツを作ったかはランキング要因ではないということですか?

ダニー・サリヴァンはすばらしいコンテンツ著者です。もし僕のブログに彼が寄稿したとしたら、その記事は彼によって書かれたものだからきっとすばらしい記事に違いないとGoogleは考えたりはしないのですか?

ジョンからの回答です。

たぶん、(ダニー・サリヴァンが書いたということは)わからないのではないだろうか。

どういうことかというと、その記事が優れていたとしても、それは、リンクのように、ほかの人に勧めることに関係してくるユーザーからのある種のフィードバックにもとづいて、その記事自身の評価から本質的に上位表示するだろうということだ。

だが、名前がよく知られた著者がだれかほかの人のサイトでコンテンツを発行したからといって、ただそれだけの理由でそのブログ記事が本当に関連性が高いと無条件でなることはない。

完全に無作為に選んだブログにダニー・サリヴァンが何かを投稿しても、それが彼によるものだとは私たちは認識しないだろうし、ユーザーも彼によるものだとは認識しないだろう。だれによるものかは結局わからなくなってしまう。

また、ある人が書いたからといって、その記事の品質が常に本当に高いとは必ずしも限らない。だから、もし仮にダニー・サリヴァンの著者情報のマークアップがそのページに記述されていたからといって、とたんにその記事が本当に価値があるものだと想定するべきではないし、上位表示させるべきでもない。

こうした観点から、人々によって書かれた記事というものは(著者がだれかということによるのではなく)その記事自体の評価でGoogle検索で表示される力がなければならない。

Googleではなく訪問者に信頼してもらえるようになる

ということで、Googleはそのコンテンツがだれによって作られたのかどうかを見ていません。
ランキング要因にもしていません。

少し残念に思います。
コンテンツを掲載しているサイトでなく、コンテンツを作った著者を対象にして評価してもらえるとしたら、一個人としてコンテンツを発行している身には嬉しいことです。

2011年のSMX Advancedで、米Googleのサーチクオリティチームに当時所属していたMatt Cutts(マット・カッツ)氏は次のように言っていました。

(著者情報プログラムが)個人のPageRankとも言うべき「Author Rank」になればいい。将来的には、質の高い記事を書く著者のコンテンツを高く評価できるようにしたい。

結局、著者情報プログラムは廃止されてしまいました。

著者情報プログラムなしでも、著者を評価する取り組みは続いているのかと期待していたのですが、少なくとも実現には至っていないようです。

ただ、ジョンの説明にも納得がいく部分はあります。
僕が書いた記事がいつも100%絶対に高品質だという保証はありません(そうなるように常に書いてますよ!)。
仮に、僕が手を抜いて書いた記事があったとして、それも無条件に高品質だと判断してしまうことは良いことではないですね。

だれが書いたかよりも、その記事(コンテンツ)そのもので評価するという考えは正しいように思います。

よくよく考えれば、個人としてGoogleに評価されるかどうかは些細なことです。
訪問者(あなた)に、この人(鈴木謙一)が書くことは信頼できるし役に立つとみなしてもらえるように、コンテンツを発行していくことがもっとずっと大切なことですよね。:)

- 【確定】誰が記事を書いたかをGoogleはランキング要因にしていない、もう一度ジョン・ミューラーに質問してみた。 -

Posted on: 海外SEO情報ブログ - SuzukiKenichi.COM by Kenichi Suzuki

HTML文法的に正しくないheadセクションの中のrel=hreflangやrel=canonicalをGoogleは認識しない

[レベル: 中〜上級]

headセクションがHTML文法的に正しくない場合、Googleは rel="canonical" 要素や rel="hreflang" 要素を正常に認識できないことがあります。
たとえば、headセクションの中での使用が許されていない img タグや iframe タグがあると、Googlebotはそこでレンダリングを停止しそれ以降の要素を読み取りません。

有効でないheadセクションはhreflangを無効にさせる

英語版オフィスアワーで、hreflangが正常に機能していない理由を質問した参加者に対してGoogleのJohn Mueller(ジョン・ミューラー)氏は次のようなことを指摘しました。

ページをレンダリングする際に、何かおかしなものがheadセクションにあるとheadセクションのなかにあるものをすべて無効にしてしまう。それにはhreflangも含まれる。

技術的には起こりうることで、そうなるとhreflangを私たちはまったく認識しなくなる。hreflangがなかったからといって悪いわけじゃないから、エラーとしてレポートしたりはしない。

Gary Illyes(ゲイリー・イェーシュ)氏によれば、headセクションが文法的に正しくない場合にGoogleが無効にしてしまうものには、rel=”canonical”も含まれるそうです。

hreflang/canonical を無効にしてしまうheadセクションとは?

rel="canonical"rel="hreflang" を無効にしてしまう、正しくないheadセクションとは具体的にはどのようなものなのでしょうか?

いろいろなパターンが考えられると思いますが、1つ確実なのはheadセクション内では許されていないタグの使用です。
たとえば、imgタグです。

ほかには、iframeタグです。
大手旅行サイトが、headセクションにiframeタグを埋め込んだことが原因でhreflangが機能しなかった事例が実際に発生しています。

headセクションに広告タグを埋め込んで問題が発生したケースも聞いたことがあります。
広告なので、ひょっとしたらiframeを使っていたのかもしれません。

imgタグもiframeタグもheadセクションの中で使えるタグではないですね。
そういう不適切な要素に出くわすと、headセクションの読み取りをそこでGooglebotはストップしてしまうのです。

普通にやっていれば、headセクションにimgタグもiframeタグを記述することはないでしょう。
しかしJavaScriptを使ってheadセクション内の要素を動的に生成している場合は要注意です。

ほかには、閉じタグがないことやタグのスペルミスなども hreflang や canonical の読み取りを妨げてしまう要因になるかもしれません。

HTMLは正しく使う

HTML文法が100点だからといってGoogleの評価が上がることはありません。
逆に、文法的に間違いがたくさんあるからといって、それだけで評価が下がることもありません。

とはいえ、Googlebotのクロールやレンダリングに支障をきたすような不適切なHTMLは問題を引き起こすことがあります。
rel=”canonical”が機能しない、rel=”hreflang”が機能しない、なんていうトラブルが発生したときには、headセクションがHTML文法的に正しく構成されているかどうかも確認項目の1つに含めましょう。

- HTML文法的に正しくないheadセクションの中のrel=hreflangやrel=canonicalをGoogleは認識しない -

Posted on: 海外SEO情報ブログ - SuzukiKenichi.COM by Kenichi Suzuki

Googleは、誰が記事を書いたのかをコンテンツ品質の評価要素にしているのか?

[レベル: 中級]

その記事が誰によって書かかれたものなのかを、コンテンツの品質評価の対象にGoogleは含めているのでしょうか?

先月開催されたSMX Advanced 2016のQ&Aセッションで、GoogleのGary Illyes(ゲイリー・イェーシュ)氏は次のように発言しました。

著者情報は今はまったく使っていない。著者情報がなくても、たとえば書き方で誰が書いたかがわかる。

その記事を誰が書いたかを認識できると実際に言っていたわけではないのですが、別々に人によって書かれたものは区別できるというようなことは言っていました。

もう少し詳しいことを知りたいと思い、英語版のオフィスアワーでJohn Mueller(ジョン・ミューラー)氏に質問してみました。

先月のSMX Advancedでゲイリーは、著者情報(プログラム)なしでも、誰がその記事を書いているかがわかると言いました。ということは、コンテンツの品質を判断するときには、その記事を誰が書いたのかをGoogleは考慮に入れているということですか?

ジョン・ミューラー氏からの回答

ジョンは次のように答えてくれました。

どの人がどの記事を書いているかをわかっているということでもない。

しかしウェブの複数の場所で同じ記事をもし発見したなら、どこで初めに投稿されたのかを上手に判断できる。

その点を考慮して、オリジナルのコンテンツが出てくるように実際に試みている。そしてそれは、どのようにページを検索で表示するべきかや特定のクエリに対して個々のページがどのくらい関連性があるかを考えるときに考慮に入れていることでもある。

「これは特定の記事のコピーか?それともその人やそのサイトによって書かれたオリジナルなのか?」を私たちは考慮する。

誰が書いたかはわかっていないっぽい

僕が本当に知りたかったことに対する回答は最初のひとことだけでした。

誰が書いたかをGoogleは認識できているふうではなさそうです。

たとえば、僕がこのブログやWeb担の連載コラムGoogleヘルプフォーラムTwitterGoogle+で、SEOに関する有益な情報を絶えず発信していたとします。

投稿する場所は異なりますが同一人物による投稿だとGoogleは認識して、コンテンツの品質を評価するときに”僕”という個人を評価の要素にするかどうかを知りたかったのです。
つまり、ヘルプフォーラムの投稿やTwitterの投稿が、このブログの評価にも影響するかどうかです。

ジョンの短い答えから判断すると、影響はしないということでしょうかね。

どれがオリジナルのコンテンツなのかはわかる

一方で、同じコンテンツがウェブの複数の場所に存在する場合は、どれがオリジナルのコンテンツかは上手に判断できているとのことです(トピックがこっちにすり替わってしまってしまいました。質問の仕方が悪かったのかも)。

「そんなことない、コピーのほうが上位表示している」という反論もあるかもしれませんが、ここでは深入りしません。

著者情報のマークアップはどうしたらいいか?

ついでにジョンは、使われなくなった著者情報のマークアップの扱いについてもアドバイスします。

彼(ゲイリー)は著者情報のマークアップはぜんぜん使っていないことにも(SMXで)言及した。

著者情報のマークアップをサイトに追加すべきかすべきでないかを決めかねているとしたら、追加する必要はまったくない。

と同時に、削除する必要もない。削除したことで何か問題が発生することはない。

サイトを大がかりにリニューアルしてきれいな状態にするなら、そのときに取り除けばいいかもしれない。

著者情報のマークアップに使う rel="auhtor" は今さら記述する必要はありません。
今後再利用される可能性はゼロでしょう。

かといって、わざわざ削除する必要もありません。
そのままでも構いません。

僕は、著者情報プログラムの廃止が発表された後も放置しておいて、モバイル対応のためにサイトをリニューアルしたタイミングで撤去しました(正確には、要件に含めたなかった)。

さて、コンテンツ著者が誰なのかをGoogleはアルゴリズムとして評価要因にしているかどうかに関しては、また機会を見つけて探ってみたいと思います。
複数の場所でコンテンツを発行しているとしたら、コンテンツ発行者個人の側面からもGoogleには見てほしいですよね。

- Googleは、誰が記事を書いたのかをコンテンツ品質の評価要素にしているのか? -

Posted on: 海外SEO情報ブログ - SuzukiKenichi.COM by Kenichi Suzuki