海外SEO情報ブログ

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

9 years 7ヶ月 ago

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

Kenichi Suzuki

「文字数が多いページはグーグルで上位表示されやすい」はSEO都市伝説【海外&国内SEO情報ウォッチ】

9 years 8ヶ月 ago

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

今週のピックアップ

  • 「文字数が多いページはグーグルで上位表示されやすい」はSEO都市伝説
    Web担当者フォーラム 海外&国内SEO情報ウォッチの今週のイラスト

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

  • AMPの耳寄り情報ツイート×14
  • 常時HTTPSは○○だから良くない――それは古い知識からの思い込みかも!?
  • 検索結果のタイトル書き換え、強調スニペット、PubSubHubbub、HTTPSなど7月のオフィスアワー
  • プログレッシブ ウェブ アプリの実装でコンバージョン率が200%以上に!
  • Search Consoleの「HTMLの改善」に対処しなくても検索順位が下がることはない

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

  • ポップアップで隠されたメインコンテンツをグーグルは重要視しないかも
  • サイトの統合・分割とドメイン名の移転を同時にしたら、グーグルの処理に長い時間がかかることも
  • 「ペンギンはもう更新しないなんて、誰が言った?」グーグル社員が噂を否定
  • JSON-LDのschema.org構造化データを簡単に作れるツールが登場

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

  • HTML文法的に正しくないheadセクションの中のrel=hreflangやrel=canonicalをGoogleは認識しない
  • 【確定】誰が記事を書いたかをGoogleはランキング要因にしていない、もう一度ジョン・ミューラーに質問してみた。

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

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

こちらからどうぞ。

- 「文字数が多いページはグーグルで上位表示されやすい」はSEO都市伝説【海外&国内SEO情報ウォッチ】 -

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

Kenichi Suzuki

AMPカルーセルの画像サイズは幅が696px以上、縦は最小要件なし

9 years 8ヶ月 ago

[レベル: 上級]

Googleモバイル検索のトップニュースのAMPカルーセルに掲載されるにはその記事に画像が必須で、構造化データで指定します。
画像のサイズには要件があり、幅 (width) は 696px 以上です。
しかし高さ (height) には、最小サイズの要件はありません。

ポケモンGoのトップニュース AMPカルーセル

公式ドキュメントには高さの要件記載なし

トップニュースのカルーセルに必要な構造化データを説明した、Google公式のドキュメントには画像のサイズ要件が示されています。

Images should be at least 696 pixels wide.

画像の幅は最小で696ピクセルです。

ところが、幅の要件の記載はあるのですが、高さの要件の記載がありません。
高さ対しては要件は指定されていないのでしょうか?

高さの最小要件は定められていない

「高さは何でもいいのか?」という疑問に対して、GoogleのTomo T氏はヘルプフォーラムで次のように回答しています。

There is no minimum height requirement for images. As a general rule of thumb, the bigger the image provided, the better they would look in the carousel. In the spirit of AMP, it’s also important to be considerate with the img file size and format; as such, bitmaps aren’t recommended :)

画像に対しては、高さの最小要件はない。一般的な経験則から言えば、大きい画像を提供すればするほどカルーセルできれいに見える。

AMPの精神として、適切なファイルサイズとフォーマットを検討することも大切だ。たとえばビットマップは推奨されない。

ということで、AMP記事の構造化データで指定する画像のサイズは、横 (width) は 696px 以上である必要がありますが、縦 (height) には最小サイズの要件はありません。

構造化データで指定する
AMP記事内の画像のサイズ要件

大きけれが大きいほどいいようですが、だからといって 10,000px の画像は度を超えてますね。

画像のファイルフォーマットにも注意しましょう。
サポートされるのは、.jpgと .png、.gif になります。

[注意] 画像サイズの要件は、構造化データで指定する画像、言い換えればカルーセルに表示させたい画像に対して要求されます。
カルーセルに掲載するつもりがない画像には最小サイズは要求されません。任意のサイズの画像を掲載できます(構造化データに含める必要もない)。

- AMPカルーセルの画像サイズは幅が696px以上、縦は最小要件なし -

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

Kenichi Suzuki

Google、テーマパークの平均滞在時間をモバイル検索のローカルナレッジパネルに表示

9 years 8ヶ月 ago

[レベル: 初級]

Googleは、その場所を訪れた人がだいたいどのくらい時間滞在しているのかをローカルナレッジパネルに表示する機能を公開しました。

Now, you can find out how long people typically spend at a location before you head out the door, with the #GoogleApp

著名なランドマークやテーマパーク、博物館・美術館などの施設の平均滞在時間を知ることができます。
モバイル検索で利用可能です。

平均滞在時間

こちらは、東京スカイツリーのローカルナレッジパネルです。
1年前に導入された「訪問数の多い時間帯」の下に平均滞在時間が表示されています。

東京スカイツリーの平均滞在時間

こちらは、先日世界文化遺産に登録された国立西洋美術館の平均滞在時間です。

国立西洋美術館の平均滞在時間

こちらは、キッザニア東京の平均滞在時間です。
ここには「観光プラン」のラベルが付いています(ほかには見つけられなかった)。

キッザニア東京の平均滞在時間

旅行の計画に役立つかも

旅行の計画をたてるときに、どのくらいの時間をその場所で見込んでおけばいいかを見積もるのに「平均滞在時間」の機能は役立ちそうです。

と思ったのですが、ディズニーランドで3時間は短すぎませんかね?

の平均滞在時間

3時間では、下手すれば、2時間並んで1つのアトラクションに乗って終わりですよね。

ロケーション履歴を有効にしているユーザーから収集したデータをもとにしていると思われますが、実際の状況と合っていない場合もありそうです。
あくまでも参考程度にとらえておいたほうが安心かもしれません。

また、レストランやカフェなどは対象になっていないようです。
個人的には、飲食店の滞在時間がわかるともっと便利なように思いました。

- Google、テーマパークの平均滞在時間をモバイル検索のローカルナレッジパネルに表示 -

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

Kenichi Suzuki

Google、AMPに完全対応した爆速表示の広告 A4A を公開

9 years 8ヶ月 ago

[レベル: 上級]

Google (AMP Project) は、AMPページでも高速で表示される広告として、AMP for ads、略称 “A4A” を公開しました。
メインコンテンツの表示を遅らせることなく、広告のすばやい表示を A4A は実現しています。

広告表示も爆速

A4A 広告 と A4A ではない広告の表示速度にどのくらいの違いがあるかをデモンストレーションしたアニメーションを、AMP Projectが公式ブログの記事で紹介しています。

左が A4A ではない普通の広告で、右が A4A 広告です。
ページの上部にデモ用の青いバナー広告が表示されます。

A4A vs. Non-A4A

検索結果をタップしてページに飛んだあと、A4A ではない普通の広告が完全に表示されるまでには3.12秒かかっています。
それに対して、A4A 広告は0.5秒で表示が完了しています。

訪問者に広告をしっかりと見てほしい広告出稿者と広告掲載者にとっては、広告がすばやく表示されることはとても重要です。
かといって、広告表示を優先するあまりページ本体の表示を遅くしてしまったのでは、「限りなく速く」というAMPの基本精神を無視してしまうことになります。

ページの表示速度を犠牲にすることなく広告の高速表示も可能にしたのが、A4A、つまり AMP for ads になります。

A4A を速くしている要素

AMP for ads の高速表示を可能にするために、いくつもの技術が用いられています。
簡単に説明します。

リクエストとレンダリングを分離

広告のリクエストとレンダリングを完全に分けています。

サーバー側では、広告のリクエストが発生するとオークションなどの処理が発生し時間がかかることがあります。
一方クライアント(ブラウザ)側では、受け取った広告のレンダリングのためにCPUやメモリなどのリソースを消費するので、ページのメインコンテンツのレンダリングを遅らせる原因になります。

A4A では、両者を分離することでページのレンダリングが遅くなることを防いでいます。

AMPの制限されたサブセット

A4A はAMPの仕様に従って構成されます。
しかし、すべての仕様が広告にとって必要というわけではありません。

A4A の場合は、必要な一部分だけに制限して、AMPの仕様に従っているかどうかの有効性を検証するので、バリデーションチェックの時間が短縮されます。

また一般的な広告は、その広告(のコード)がさまざまなことを自由に実行できますが、A4A においては何ができるかはAMPが完全にコントロールします。
スピードを落とすような余計なことはできないということですね。

AMP用解析の再利用

広告には、その広告専用の解析機能を実装することが珍しくありません。
3個の広告を1つのページに掲載したら、3つの解析ツール(つまりJavaScript)が稼働するかもしれません。
表示を遅くさせる原因になります。

A4A では、amp-analytics を利用して計測します。
amp-analytics を利用すれば1つのコードで複数の計測が可能です。

見えるときだけ開始

A4A 広告は、それがスクリーンの見える範囲にあるときだけに表示されます。

たとえば、ページのいちばん下にある広告は、ページを下までスクロールして表示領域に入ったたときに初めて掲載のための処理が始まります。

また状況に応じてアニメーションのフレームレートを抑えるなど、スクロールなどのユーザー体験を阻害しないような仕組みも実装しています。

AMP for adsは2週間前に公開されたばかりで、まだ正式に仕様が固まったわけではありません。
それでも、広告が重要なビジネスモデルになっているパブリッシャーにとっては、AMPで実現できる高速性を犠牲にせずに掲載できる A4A はとても魅力的に映るのではないでしょうか。

AMPはオープンソースなので、どの広告ベンダーでも A4A に対応した広告を配信できます。
これも優れた点といえます。

A4A の技術的な詳細は、Githubで確認してください。

- Google、AMPに完全対応した爆速表示の広告 A4A を公開 -

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

Kenichi Suzuki

Twitterが日本語版モーメントを開始、AMPサポートは不完全?

9 years 8ヶ月 ago

[レベル: 上級]

日本語版のTwitterが「モーメント (Moments)」 を開始しました
モーメントは、今話題になっているトピックに関係するツイートを”ストーリー”としてまとめて閲覧できるサービスです。

モーメントは、米国英国オーストラリアなどの国で展開していました。
新たに日本が加わったことになります。

AMPサポートは不完全?

Twitterは、GoogleとともにAMPプロジェクトで中心的な役割りを果たしています。
今年の3月には、モーメントでAMPのサポートを始めました。

日本語版のモーメントもAMPをサポートしているようなのですが、完全なサポートには至っていないようです。

AMP CDNからキャッシュを返さず

通常、AMPではコンテンツはAMP CDNからキャッシュが返されます。

しかしモーメントのAMPコンテンツは、キャッシュではなくウェブサーバーから直接返されます。

こちらは、モーメントに掲載されている産経ニュースの記事です。
産経ニュースはAMP対応しています。

AMP対応記事のモーメント

タップして元記事を読みに行くと……

モーメント経由で直接返されるAMPコンテンツ

AMPフォーマットの記事が表示されるのですが、キャッシュから返されるのではなく直接開いています。

AMPはそれだけでもそれなりに高速に表示されます。
しかし高速を本当に実現するにはCDNキャッシュは必須のコンポーネントです。

英語版のモーメントがAMPサポートを開始した当初も、AMPコンテンツをCDNキャッシュではなく直接返していました。
ですが、数日後にはきちんとキャッシュから返されるようになっていました。

ただこの記事を書いている時点では、英語版も再び直接表示するように変わっています。

AMPコンテンツの表示になぜTwitterはCDNを利用しないのでしょうか?
どんな理由があるのか知りたいものです(Twitterに知り合いがいる方は聞いてください)。

いずれにしても、Google以外でもAMPが利用される環境が少しずつですが増えてきました。
身近なところでは、はてなブックマークアプリもAMPをサポートするようになっています。

さまざまなプラットフォームで利用できるのは、AMPがオープンソースだからです。
AMP対応しているコンテンツ発行者はAMPの拡大に期待しましょう。

- Twitterが日本語版モーメントを開始、AMPサポートは不完全? -

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

Kenichi Suzuki

【ブログ読者へご連絡】7/12〜7/15のブログ更新をお休みします

9 years 8ヶ月 ago

MobileBeat 2016

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

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

7月12・13日に米サンフランシスコで開催される MobileBeat 2016 に参加してきます。

そのため今週の残り、7月12日〜15日のブログ更新をお休みします。
Web担当者Forumの連載コラムも今週はお休みです。

MobileBeatはモバイルをテーマにしたカンファレンスです。
ただし検索に直接かかわるカンファレンスではなく、AIやチャットボットをテーマにしたセッションが多いようです。
それでもモバイルの世界の新しいことが学べることを期待しています。
良い情報が手に入ればこのブログで共有します。

それではまた来週!

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

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

Kenichi Suzuki

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

9 years 8ヶ月 ago

[レベル: 中級]

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

Kenichi Suzuki

グーグルは情報の正しさを保証しない。嘘情報でも上位表示することがある【海外&国内SEO情報ウォッチ】

9 years 8ヶ月 ago

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

今週のピックアップ

  • グーグルは「情報の正しさ」を保証しない。嘘情報でも上位表示することがある
    Web担当者フォーラム 海外&国内SEO情報ウォッチの今週のイラスト

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

  • AMPで困ったときに頼れるAMP専用カテゴリが公式ヘルプフォーラムに開設
  • AMP対応する前に知っておきたいこと3つを、グーグル社員が共有してくれた
  • MERYが商品販売ページをAMP化したけど、これって問題ないの?
  • WordPressサイトを自力でAMP対応する方法

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

  • どんなタイプのサイトでも今すぐAMP対応すべきか?
  • AMPプロジェクトが第2四半期に重点的に取り組んできたこと4つ
  • リダイレクトの数の上限は1万?10万、それとも制限なし?
  • 歌詞サイトに大打撃か? グーグルが検索結果に歌詞を表示
  • Search Consoleでアプリのインデックス数とクロールエラー数のレポートに不具合発生

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

  • RankBrainはロングテールによく機能するランキング要因、Googleは著者情報を完全に使っていないなどSEO最新情報 from #SMX Advanced 2016
  • AMP対応で表示速度が22秒から0.7秒へ短縮、1億2500万のAMPページをGoogleはインデックスなど from #SMX Advanced 2016

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

今週はピックアップなし。

こちらからどうぞ。

- グーグルは情報の正しさを保証しない。嘘情報でも上位表示することがある【海外&国内SEO情報ウォッチ】 -

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

Kenichi Suzuki

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

9 years 8ヶ月 ago

[レベル: 中〜上級]

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

Kenichi Suzuki

Google Now on Tapに、便利そうな3つの新機能が登場 ―― 翻訳・関連ニュース・バーコード検索

9 years 8ヶ月 ago

[レベル: 中級]

GoogleはNow on Tapに新しい機能を3つ追加しました。

  • 翻訳
  • 関連ニュース
  • バーコード・QRコード検索

翻訳

翻訳機能が追加されました。
外国語のコンテンツでNow on Tapを起動すると、OS側で設定されている言語に翻訳してくれます。
複数の外国語が同時に表示されていても同時に翻訳できます。

Now on Tapの翻訳機能

ウェブページの閲覧中にしか使えないChrome拡張のGoogle翻訳とは違って、Now on Tap翻訳はどんな場面でも使えるのがメリットですね。

ただ残念ながら、日本語への翻訳には対応していません。
サポートしているのは現状では次の7つの言語です。

  • 英語
  • フランス語
  • イアリア語
  • ドイツ語
  • スペイン語
  • ポルトガル語
  • ロシア語

そんなわけで画像は公式アナウンスに掲載されているものキャプチャになっています。

スマートフォンで設定されている言語に依存せずに、任意の言語をNow on Tap側で設定できるようにしてほしいと個人的には望みます。
日本語への翻訳はどうしても質が低くなるので、英語に訳してもらったほうが役立ちそうだからです。
かといって、スマホ全体を英語にするには抵抗があります。

関連ニュース

関連ニュースがNow on Tapカードに仲間入りしました。
今見ているコンテンツに関係するニュースコンテンツがある場合は、関連するニュースも見ることができます。

こちらのキャプチャは、NASAが打ち上げた木星探査機「ジュノー」が周回軌道への投入に成功したニュースを、Yahoo!ニュースアプリで閲覧中にNow on Tapを起動したところです。
同じトピックを扱ったニュースが一覧で出ています。

「木星探査機 周回軌道へ投入」の関連ニュース

関連したほかのニュース記事も読みたいときには便利そうです。

バーコード・QRコード検索

Now on Tapには、OCR画像検索といった画像認識の機能も備わっています。
この画像認識技術に、バーコードとQRコードを読み取って情報を提供する機能が追加されました。
バーコードやQRコードを認識して、それをもとに情報をカードとして表示してくれます。

こちらのキャプチャは、Android標準のカメラアプリでミネラルウォーターのボトルのバーコードを写しながら、Now on Tapを起動させたところです。

クリスタルガイザーのバーコードを読み取ったNow on Tap

お店で買物をしているときに、その商品のレビューや評価を調べたいときに重宝しそうです。
バーコード・QRコードなので単なる画像認識とは異なり、正確にその商品の情報を手にできます。

Now on Tapが使える端末をあながた所有しているなら、新しい機能をぜひ試してみてください。

- Google Now on Tapに、便利そうな3つの新機能が登場 ―― 翻訳・関連ニュース・バーコード検索 -

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

Kenichi Suzuki

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

9 years 8ヶ月 ago

[レベル: 中級]

その記事が誰によって書かかれたものなのかを、コンテンツの品質評価の対象に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

Kenichi Suzuki

Google、Search Consoleの検索アナリティクスに「リッチ検索結果」のフィルタを追加

9 years 8ヶ月 ago

[レベル: 中級]

Google Search Console の検索アナリティクスに「リッチ検索結果」のフィルタが追加されました。
「リッチ検索結果」でフィルタをかけると、リッチスニペットが表示されたデータだけ絞りこんでレポートを参照できます。

検索アナリティクスのデータをリッチ検索結果でフィルタ

検索アナリティクスの「検索の見え方」指標のフィルタ オプションで「リッチ検索結果」を選べます。

検索アナリティクスの「リッチ検索結果」フィルタ

リッチ検索結果には、リッチスニペットとリッチカードでの検索結果表示が含まれます。
僕が調べた限りでは、トップニュース (AMP) に表示されたデータも含まれているようです。

なお、リッチスニペット/リッチカードが表示されたことがないサイトには「リッチ検索結果」のフィルタオプションは出てきません(AMPフィルタも同じようにAMPを実装していないと選べませんね)。

一般的に言って、リッチスニペットは高いクリック率が期待できます。
ところが最近はユーザーが慣れてきてしまっていたり多くのサイトが導入していたりするため、以前よりも効果が薄れているようにも思います。
今回新たに導入された、検索アナリティクスの「リッチ検索結果」でフィルタしてクリック数やクリック率を分析してみるといいでしょう。

- Google、Search Consoleの検索アナリティクスに「リッチ検索結果」のフィルタを追加 -

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

Kenichi Suzuki

Google、症状に関連する検索で病気の情報を提供。米国のモバイル検索でまず導入

9 years 8ヶ月 ago

[レベル: 中〜上級]

病気の症状に関係する検索が実行された場合に、その症状を引き起こしている原因になっている可能性がある病気に関する情報を、Googleはモバイル検索で提供するようにしました。

症状に関係しそうな病気の情報をカルーセルで表示

こちらは公式アナウンスで例に出ている「headache on one side」(片側の頭痛)の検索結果に出てくる関連情報のカルーセルです。

「headache on one side」のクエリで出てくる関連情報

頭の片側が痛む症状に対して、1つ目は「Headache」として(ただの)頭痛の情報を、2つ目は「Migraine」として偏頭痛の情報を提供しています。

カルーセル形式になっていて、横方向にフリックするとその症状に関係しそうな病気の情報が次々と出現します。
それぞれの病気に関する簡潔な説明やかかると危険な状況の人、その病気にかかるのはどのくらい一般的かなどの情報が含まれています。

こちらは「high fever in children」(子供の高熱)のクエリで出てくる関連情報のカルーセルです。

「high fever in children」のクエリで出てくる関連情報

1つ目は「Common cold」(普通のかぜ)、2つ目は「Flu」(インフルエンザ)です。
カルーセルを進めていくと、「Rota virus infection」(ロタウイルス感染)や「Roseola」(風疹)などかかりがちな病気が出てきます。

非常に多い病気関連の検索

Googleによれば、Googleが処理する検索のうち1%は病気関連だそうです。
たったの1%とあなどってはいけません。
数百万のクエリをGoogleは日々扱っていることを考えると、決して小さい数字ではありません。

そうした検索ユーザーのニーズに応えるために、こうした機能をGoogleは導入したのです。
「何かおかしいな。大丈夫かな?」と不安になったときに、そばにあるスマホを手にとって検索するユーザーも増えてきているに違いありません。

昨年2月には、病気やケガに関するナレッジグラフをGoogleは導入していました。

健康・医療に対する適切な情報をすばやく検索ユーザーに提供することをGoogleはとても重要視しています。
提供する情報は当然のことながら医療の専門家によって監修されたものです。

病気関連情報のカルーセルは、米国のモバイル検索でまず導入されました。
対応する症状を増やすとともに、ほかの国や言語にも導入したいとのことです。

医療関連のアフィリエイトも多いのですが、残念ながら情報の信ぴょう性に非常に乏しいサイトが少なくありません。
切羽詰まった状況では、そのサイトで提供されている情報が本当に正しいかどうかを適切に判断できないことがあるかもしれません。

病気やケガは人の生死に関わることがあります。
信頼がおける情報をGoogleが検索結果で提供してくれれば安心できます。

医師による診断が最終的には必要な場合もあるでしょうが、初期対応として検索結果で調べられるのはありがたいことです。
日本でも早く導入してほしいですね。

- Google、症状に関連する検索で病気の情報を提供。米国のモバイル検索でまず導入 -

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

Kenichi Suzuki

スマホでSEO&コンバージョン促進するための“マイクロモーメント”4種の対策【海外&国内SEO情報ウォッチ】

9 years 8ヶ月 ago

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

今週のピックアップ

  • スマホでSEO&コンバージョン促進するための“マイクロモーメント”4種の対策
    Web担当者フォーラム 海外&国内SEO情報ウォッチ

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

  • 【グーグル公式まとめ】検索関連の最新情報×8
  • アメブロのAMP裏事情 ―― なぜAMP対応したのか? その成果は?
  • 無害なサイトがグーグルに危険扱いされた珍しいケースとその原因
  • AMPページが有効かどうかを一括でチェックできるツール
  • App Indexingのクロールがうまくいかないときにチェックすべきこと

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

  • 米国のSEOエキスパートがSEOの質問に何でも答えてくれた(SMX Advanced情報)
  • 検索アナリティクスの全指標で「比較」ができるようになった
  • 手動対策の解除通知が届いているのに手動対策ビューアからは警告が消えないのはなぜ?
  • ハッキングを受けたら、Googleアナリティクスが警告を通知

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

  • 検索結果には表示されないがSearch Consoleのレポートに出てくるページからのリンクをGoogleは評価対象にするのか?
  • CDN移行にともないGooglebotのクロール速度が低下したときはフォームから問題を報告できる

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

  • Google Search Console(サーチコンソール)を強力なSEOツールとして使うための究極ガイド。
  • Googleが”リッチ検索結果”のフィルタ機能をSearch Consoleの検索アナリティクスに追加。

こちらからどうぞ。

- スマホでSEO&コンバージョン促進するための“マイクロモーメント”4種の対策【海外&国内SEO情報ウォッチ】 -

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

Kenichi Suzuki

次のAMPはECサイトの商品一覧ページか? Googleの協力のもとeBayがAMP対応の実験を開始

9 years 8ヶ月 ago

世界で最も大きいECサイトの1つ、eBayがAMP対応を始めた。eBayは、モバイル体験の向上に今年は注力しており、さらなる向上のために、”高速”がウリのAMPを利用することになった。eBayのAMP化にはGoogleも力を貸している。いつ頃、どのようにして検索結果に表示されるかは不明。

- 次のAMPはECサイトの商品一覧ページか? Googleの協力のもとeBayがAMP対応の実験を開始 -

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

Kenichi Suzuki

AMP対応で表示速度が22秒から0.7秒へ短縮、1億2500万のAMPページをGoogleはインデックスなど from #SMX Advanced 2016

9 years 8ヶ月 ago

米シアトルで先週参加したSMX Advanced 2016では、GoogleのAMPプロジェクトのプロダクトマネージャであるルディー・ガルフィ氏が AMPについてプレゼンしました。そのなかから、MP対応で表示速度が22秒から0.7秒へ短縮、1億2500万のAMPページをGoogleはインデックスなどのハイライトをこの記事では紹介する。

- AMP対応で表示速度が22秒から0.7秒へ短縮、1億2500万のAMPページをGoogleはインデックスなど from #SMX Advanced 2016 -

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

Kenichi Suzuki

AMP HTMLの有効性を検証するウェブUI版の公式バリデーションチェックツール

9 years 8ヶ月 ago

AMPプロジェクトは、AMP HTMLの有効かどうかを検証するウェブUI版のツールを公開した。これまでに提供されていた2つのバリデーションチェック方法に加わった新たなツール。validator.ampproject.orgからアクセスできる。

- AMP HTMLの有効性を検証するウェブUI版の公式バリデーションチェックツール -

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

Kenichi Suzuki

RankBrainはロングテールによく機能するランキング要因、Googleは著者情報を完全に使っていないなどSEO最新情報 from #SMX Advanced 2016

9 years 8ヶ月 ago

6月21〜21日に米シアトルで開催されたSMX Advanced 2016に参加してきた。このカンファレンスの一番の目玉セッションともいうべき、”AMA With Google Search”をレポートする。RankBrainや機械学習アルゴリズム、著者情報、次のモバイルフレンドリーアップデートなどのたくさんSEO情報がGoogleのGary Illyesの口から語られた。

- RankBrainはロングテールによく機能するランキング要因、Googleは著者情報を完全に使っていないなどSEO最新情報 from #SMX Advanced 2016 -

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

Kenichi Suzuki
確認済み
2 時間 46 分 ago
海外SEO情報ブログ
海外発の検索エンジン最新情報を配信するSEOブログ
海外SEO情報ブログ フィード を購読

人気記事トップ10

人気記事ランキングをもっと見る

企画広告も役立つ情報バッチリ! Sponsored