【ブログ読者へご連絡】8/4〜8/5のブログ更新をお休みします

TC Meetup

海外SEO情報ブログの読者のみなさまへ

いつもご訪問ありがとうございます。

8月4〜5日の2日間、Google主催のTop Contributor Meetup Tokyoに参加します。
Top Contributor Meetupは、Googleの公式ヘルプフォーラムで活動しているメンバーが招待される特別イベントです。
海外ではなく日本での開催ですが期間中めいっぱい楽しんできたいので、明日とあさってのブログ更新をお休みします。

金曜日のWeb担当者Forumの連載コラムはいつもどおりお届けします。

また来週お会いしましょう!

- 【ブログ読者へご連絡】8/4〜8/5のブログ更新をお休みします -

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

スマホ対応が不要になる!? Google、通常のモバイル検索結果でスマホ向けページの代わりにAMPページを表示する実験を開始

[レベル: 中級]

モバイル検索の通常の検索結果で、スマホ向けページに置き換えてAMPページを表示する実験をGoogleは開始しました。
これまでは、AMPに対応したページは「トップニュース」として、通常の検索結果とは別枠のカルーセル(またはリスト)の中に掲載されていました。

AMPページとスマホ対応ページが混在

通常の検索結果にAMPページが表示される実験用の検索ページには、g.co/ampdemo からアクセスできます(スマホでアクセスしてください)。
うまくいかない場合は、こちらからアクセスしてください。

トップニュース用のAMPカルーセルではなく通常の検索結果の中にAMPページが表示されます。
(僕たちにとっては)おなじみのAMPマークが付いているのですぐにわかります。

AMPページが通常の検索結果に差し込まれている

検索結果の上には、AMPを説明するためのメッセージが表示されていますね。

こちらは、AMPページとスマホ対応ページが混在する状況がもっとわかりやすい検索結果です。

AMPページとスマホ対応ページが混在

1つだけ(2つ目)が、スマホ対応で残りの3つはAMP対応です。

リッチスニペットの結果でもAMPとスマホ対応 (Mobile-friendly) が混在しています。

AMPとMobile-friendlyが混在するリッチスニペット

AMP対応ページがあるときはスマホ対応ページに置き換わる

検索結果に表示されたページにAMP対応したバージョンがあるときに、通常のスマホ対応バージョンのページに置き換わってAMP対応ページが表示されます。
つまりこの検索結果においては、AMP対応しているサイトでは通常のモバイル向けページは表示されなくなるということになります。

AMP対応していなければ、今までどおりにモバイル向けページが表示されます(モバイル対応していなければ、もちろん「スマホ対応」ラベルなしのPC向けページが表示される)。

ランキングアルゴリズムの変更ではない

注意したいのは、ランキングを決定するアルゴリズムの変更ではないという点です。

検索順位には影響しません。
そのページにAMP対応パージョンがあれば、代わりに、AMPページを優先して検索ユーザーに提示するというだけです。

AMPページを優先する理由は、単により速く表示されるページをユーザーに提供することで、ユーザー体験を向上させることが目的です。
AMPページの評価や順位を上げることが目的ではありません。

AMP対応で十分、スマホ対応は不要になる?

“early preview”(初期プレビュー)ということで、AMPを通常の検索結果に差し込むモバイル検索は実験が始まったに過ぎません。
実際に導入されるかどうかはユーザーの反応次第です。

とはいえ、いずれ導入されるだろうと個人的には思います。

ただし、解決しなければならない問題が出てくるだろうし、そのままではなくさまざまな改良がきっと加えられるでしょう。

通常の検索結果からだとしたら、AMPページにアクセスされることを望まないサイトがあるだろうことは容易に想像できます。

AMPは徹底的な高速性を追求するために、できることに制限がかかっています。
高速性を失わないようにさまざまな機能がAMPでも利用できるようにAMPプロジェクトは取り組んではいます。
しかし、今すぐに何でもできるようになるわけではありません。

AMP専用枠じゃないなら、通常のスマホ対応ページに来てもらったほうがメリットが多いと考えるサイトも必ず出てくるはずです。

またAMPページを優先表示するなら、モバイル向けページを作る必要がなくなりそうです。
Google検索のようにAMPをサポートするプラットフォームではなかったとしても、AMPページをユーザーに見せても問題はありません。
いっそのこと、これまでのモバイル向けページを完全にAMP対応ページに置き換えてしまったほうがコストも下がります。

もっとも、それはそれで良いことなのかもしれませんけどね。

いずれにしても、Googleが検索でAMPをどのように扱っていくのか、目が離せない状況は続きます。

- スマホ対応が不要になる!? Google、通常のモバイル検索結果でスマホ向けページの代わりにAMPページを表示する実験を開始 -

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

「検索意図なし、ふと気になったから」48%――グーグル調査にみるスマホ検索の変化【海外&国内SEO情報ウォッチ】

Web担当者Forumの連載コーナー、「海外&国内SEO情報ウォッチ」を更新しました。今週取り上げた記事は次のとおりです。

今週のピックアップ

  • 「検索の意図はなし、ふと気になったから」48%――グーグル調査にみるスマホ検索の変化
    Web担当者フォーラム 海外&国内SEO情報ウォッチの今週のイラスト

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

  • 目立ってる? 今度の検索結果の絵文字はパンくずリスト
  • お待たせしました、AMPの公式ドキュメント日本語版も順次公開!
  • App Indexingって何? おいしいの? という人におすすめの記事
  • ヤフーが48億ドルで身売り!?

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

  • 音声検索は文字入力検索に比べてアクション系クエリが30倍多い
  • 大量のURLを再クロールさせるにはlastmod付きのサイトマップが役立つ
  • AMPの成功事例は今後もっと増えていきそう
  • 偽のスパムレポートを競合に繰り返し送られたらどうなる?
  • 外部サイトへの発リンクはランキングに悪い影響を与えるのか?

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

  • Google、AMPに完全対応した爆速表示の広告 A4A を公開
  • Google、テーマパークの平均滞在時間をモバイル検索のローカルナレッジパネルに表示

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

更新がなかったのでピックアップなし。

こちらからどうぞ。

- 「検索意図なし、ふと気になったから」48%――グーグル調査にみるスマホ検索の変化【海外&国内SEO情報ウォッチ】 -

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

AMPページでライブ更新を可能にする amp-live-list が試験公開される

[レベル: 上級]

AMPプロジェクトは、コンテンツのライブ更新を可能にする仕組みとして <amp-live-list> のベータ版を試験公開しました。
amp-live-listを実装すると、追加のナビゲーションやページのリロードなしでコンテンツを最新の状態に動的に更新できます。

AMPページをリロードなしで即座に更新

こちらはAMPプロジェクト公式ブログのアナウンスで紹介されている amp-live-list を実装したAMPページのデモです。

amp-live-listのデモ

“YOU HAVE UPDATES”(更新があります)という青いメッセージが画面上部に出現したあと、上にスクロールして戻ると新しいコンテンツが追加されています。

読み込んだという感覚は皆無で、AMPページの高速表示はまったく損なわれていません。

amp-live-list は刻々と状況が変化するコンテンツ向き

刻々と状況が変化するコンテンツに amp-live-list は向いています。

たとえば、イベントの内容をリアルタイムで配信するライブブログです。
執筆者が新たに書き込んだ記事を次から次へとAMPページで読むことができます。

amp-live-list は、ページのコンテンツの一部分だけに利用することが可能です。
スポーツの試合のスコアや選挙の開票状況を掲載しているページでは、ページ全体を更新する必要はありません。
スコアや開票状況の部分だけリアルタイムで更新すれば十分です。
こうしたケースでは、限定した部分のみに amp-live-list を適用することができます。

AMPは、変化しない静的なコンテンツに向いている技術なのに、ライブ更新が可能になるというのは面白い機能ですね。

バックグラウンドで、コンテンツを配信しているサーバーとクライアント(ブラウザ)が直接”ポーリング”して、コンテンツに更新があるかどうかをチェックするのだそうです。
更新があれば、更新を動的にクライアントのページに差し込みます。

amp-live-listが機能する仕組み

しかしAMPで高速化を実現しているキャッシュシステムをスルーするわけではありません。
データ量やスマホ側の帯域幅、CPUの負担を削減するためにAMPキャッシュの機能は依然として活躍しています。

amp-live-list によるライブ更新を必要とするサイトはそう多くはなさそうな気がしますが、興味があるなら試してみるといいでしょう。

実験段階なので利用するにはオプトインする必要があります。
JavaScriptコンソールで次のコードを実行するか、もしくは専用ページからオプトインします。

AMP.toggleExperiment('amp-live-list')

そのほか、amp-live-list の詳しい仕組みと実装方法に関しては、公式アナウンスGitHubを参照してください。

- AMPページでライブ更新を可能にする amp-live-list が試験公開される -

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