海外SEO情報ブログ

Google、AMP化を勧めるキャンペーンを開始。今すぐAMP対応すべきか、それともまだ待つべきか?

9 years 6ヶ月 ago

[レベル: 初〜中級]

Googleは、AMPに対応するように推奨する記事をウェブマスター向け公式ブログで公開しました。

What is AMP

AMPをサポートする通常検索を年内にリリース

特に新しい内容は記事には含まれていません。

簡潔にまとめれば、次のように説明し、

速く表示されるページをモバイルユーザーは求めています。
AMPはそうした要望をかなえられる仕組みだから、AMP対応しましょう。

関連コンテンツへリンクしているだけです。

気にかけるとしたら、次の一文でしょうか。

Later this year, all types of sites that create AMP pages will have expanded exposure across the entire Google Mobile Search results page, like e-commerce, entertainment, travel, recipe sites and many more.

ECサイトからエンタメ系、旅行、レシピに至るまでAMPページを作成したあらゆるタイプのサイトは、年内に、Googleのモバイル検索結果全体において表示機会を拡大するでしょう。

現在AMPコンテンツは、トップニュースとして、主に専用のAMPカルーセルの中だけでモバイル検索結果に掲載されます。
ニュース的な記事が掲載の対象です。

しかし、通常の検索結果にもAMPページを含めることをGoogleは決定しました。
開発版がプレビューとして試験公開されており、正式公開は年内を予定しています。

年内の正式公開は開発版の発表記事のなかでも触れられていましたが、サラッと書かれていたので見過ごしていた人がいるかもしれません(僕がそうだったw)。

つまり、「AMPを完全サポートしたモバイル検索を年内に公開するから、今から準備を始めよう」というのが今回の投稿された記事の目的の1つでもあるのでしょう。

今後数週間にわたって、AMPを始めるのに役立つ情報を発信するキャンペーンを実施するとのことです(日本語でのアナウンスはこちら

What are the areas of Accelerated Mobile Pages (AMP) you want to hear more about:

In these next few weeks, we’ll help you understand how AMP makes mobile web faster for everyone and how you can use it! Be sure to follow us or share your experience using the hashtags #AMPlify #AcceleratedMobilePages

AMP対応すべきかどうか?

すでにAMP化しているなら問題ないとして、このようなアナウンスがあると、AMP対応したほうがいいのか悩みます。

僕の考えは次のようになります。

ニュース系サイト

毎日たくさんの記事を発行するサイトで、新しいトピックを扱うことが多いならAMP対応したほうがいいでしょう。特に、Googleニュースに登録しているサイトは必須といっていいかもしれません。高速表示という優れたユーザー体験を提供できます。
通常なら表示されないような、検索ボリュームが大きいクエリでカルーセルに掲載されることも多く、検索トラフィックの増加にも繋がります。
Googleニュース検索、GoogleニュースアプリもAMPに対応しています。

ブログ

企業のブログも(このブログのような)個人のブログも、多少の手間ひまをかけられるならAMP対応するといいと考えます。
ニュース系サイトと同様に、読みものコンテンツはAMPと相性がいいので、読み込み時間のストレスを与えることなくユーザーに記事を読んでもらえます。
WordPressやDrupalなどメジャーなCMSはAMP化のためのプラグインが出ているので、AMP対応するだけなら簡単です。日本でユーザーが多い、はてなブログもチェックボックス1つでAMP化できますね(現在は有料版のみ)。
AMPによる制限を許容できるなら、ブログのAMP対応はおすすめです。

記事コンテンツ

ブログにかかわらず、基本的に更新がなく、ユーザーからのアクションも発生しない、閲覧するだけの記事コンテンツもAMPに向いていると考えます。
ブログではないけれど、サイトの中に読ませるだけのページがあればそこだけAMP化するというやり方はありでしょう。
ただ、限られた一部だけをAMP対応するのは返って面倒かもしれませんね。

レシピサイト

個人的には、レシピサイトはAMP対応を推奨します。
通常の検索結果でのAMP表示もさることながら、レシピコンテンツの場合はトップニュースのようにカルーセルに別枠で表示される可能性があります。
検索結果での露出を増すチャンスになりそうです。

ECサイト

ECサイトは、判断が難しいところです。
カテゴリの一覧ページであれば、今でも十分AMP対応できるとAMPプロジェクトは強調していますが、ECサイトでの最終目的である”購入”ができない状態では、中途半端です。
eBayのように、ほかより先に試してみるというチャレンジングな精神があるならトライする選択肢はありえます。
ひょっとしたら、先行者利益があるかもしれせん。
なおECサイトに限らず、不動産サイトやトラベルサイトなどDBと連動させてたくさんのアイテムを扱うサイトもここに該当します。

SEOの観点からのAMP対応

ユーザー体験の観点から見たら、サクッと表示できるのでAMPは対応価値があります。
では純粋にSEO、言い換えたらランキングだけの観点から見たらどうでしょう?

完全に僕の個人的な予想ですが、しばらくはランキング要因には組み込まれないと思います。
なぜなら、AMP対応したくてもAMPに向いていない、AMP対応できないコンテンツ(ページ)が、今はまだ存在するからです。

モバイル対応とは異なり、今の時点ではまだAMP対応は誰にでもできるものではないのです。
対応したいのに対応できないのでは、不公平です。

ただし、モバイルフレンドリーのアルゴリズムに”スピード”の要素を組み込むことをGary Illyes(ゲイリー・イリェーシュ)氏は示唆しています。

もしこれが実現したら、AMPページは有利になるかもしれません。
AMPページだからということではなくて、高速表示するからという間接的な恩恵です。

最後も個人的な意見ですが、僕はAMPには対応べきだと思います。
ユーザーの立場に立つと、ページが速く表示されるのはやっぱり気持ちがいいものです。
自分のブログ読者にも、読み込みにかかるストレスを与えずサクッと記事を読んでもらいたいと考えます。

AMPはどのくらいもつの? いずれなくなるんじゃない? という懸念もないわけではないですが、まあ3、4年くらいもてば不満はありません。w

- Google、AMP化を勧めるキャンペーンを開始。今すぐAMP対応すべきか、それともまだ待つべきか? -

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

Kenichi Suzuki

Google CDNのAMPキャッシュを大解剖――URLフォーマット、更新プロセス、更新方法、削除方法

9 years 6ヶ月 ago

[レベル: 上級]

この記事では、Googleが公開しているドキュメントに基づいて、AMPキャッシュの仕組みについて説明します。

具体的には、次を扱います。

  • AMPキャッシュのURLフォーマット
  • AMPキャッシュの更新プロセス
  • AMPキャッシュの更新強制
  • AMPキャッシュの削除

あなたがAMPをすでに実装しているなら、知っておくと役に立つこともあるはずです。

では行ってみましょう⚡

AMPロゴ

AMPキャッシュのURLフォーマット

AMP CDNにキャッシュされたコンテンツはたとえば次のようなURLになります。

  • https://cdn.ampproject.org/c/s/example.com/amp_document.html
  • https://cdn.amproject.org/i/example.com/images/logo.png

分解して、どんな構成になっているのかを見てみましょう。
※ここでは、Googleが提供しているAMP CDNのキャッシュについて話します。もしGoogle以外のAMP CDNを使うなら仕様は異なるでしょう。

https://cdn.amproject.org

AMPキャッシュのURLは常に https://cdn.amproject.org で始まります。
Googleが公開しているAMP CDNのURIになります。

コンテンツのタイプ

https://cdn.amproject.org のあとには次の3つのいずれかが続きます。
これらは、コンテンツのタイプを表します。

  • /c −− HTMLドキュメント
  • /i −− 画像
  • /r −− フォントなどのリソース

HTTPS (TLS)

オリジナルのAMPページまたは画像、リソースがHTTPSで配信されているときは、コンテンツのタイプ (/c, /i. /r) の次に /s が続きます。

URI

最後に来るのは、オリジナルのAMPページのURLから、http:// または https:// を取り除いた部分です。
URLがパラメータ (?) を含んでいてもそのまま使えます。

ここまでをふまえて、AMPキャッシュのURLをもう一度見てみましょう。

オリジナルのAMPページ(あなたのサーバーに直接アクセスしたときのAMPページ)のURLが次のようだったとします。
http://example.com/amp_document.html

このとき、AMPキャッシュのURLはこのようになります。
https://cdn.ampproject.org/c/example.com/amp_document.html

まず、固定の https://cdn.ampproject.org で始まります。
https://cdn.ampproject.org/c/example.com/amp_document.html

次に、コンテンツタイプがHTMLドキュメントなので、 /c が続きます。
https://cdn.ampproject.org/c/example.com/amp_document.html

そのあとは、元のURLから http:// を取り除いた example.com/amp_document.html で終わります。
https://cdn.ampproject.org/c/example.com/amp_document.html

同じAMPページをHTTPSで配信していたとします。
https://example.com/amp_document.html

AMPキャッシュのURLはこのようになります。
https://cdn.ampproject.org/c/s/example.com/amp_document.html

先ほどと似ていますが、コンテンツのタイプを表す /c のあとに、HTTPSを示す /s が入っています。

今度は、画像のAMPキャッシュURLを見てみましょう。

オリジナルの画像を次のURLで配信しています。
https://example.com/images/logo.png

AMPキャッシュのURLはこのようになります。
https://cdn.ampproject.org/i/s/example.com/images/logo.png

画像なのでコンテンツのタイプの部分が /i になっていることに気付いてください。
またHTTPSで配信しているので、/s が入ります。

AMPキャッシュの更新プロセス

簡単に言うと、AMPキャッシュの更新は、ユーザーにキャッシュを配信したときにオリジナルのコンテンツが更新されていれば、更新されたコンテンツをAMP CDNサーバーが自動で取得しキャッシュし直す仕組みになっています。
ただし新しいキャッシュが配信されるのは、その次のユーザーに対してです。

もう少し詳しいプロセスは次のようになります。

  1. ユーザーがAMPキャッシュをリクエストする(例: 検索結果のAMPカルーセルからアクセスする)
  2. そのユーザーには今保持しているキャッシュを返す
  3. 同時に、オリジナルのコンテンツが更新されていないかどうかをチェックしに行く(Max-Ageヘッダーなどを見る)
  4. オリジナルのコンテンツが更新されていれば、それを取得しキャッシュを最新の状態に保つ
  5. 次のユーザーには更新されたコンテンツのAMPキャッシュを返す
  6. オリジナルのコンテンツに更新がなければ、キャッシュも更新せずそのまま使い続ける

コンテンツに更新が発生していた場合は、そのユーザーには現在のキャッシュを返しますが、次のユーザーには新しいキャッシュを返すというのが特徴的ですね。
ユーザーが頻繁に閲覧するページほど、最新の状態に保たれやすくなります。
逆に、ユーザーが閲覧しないページのキャッシュはいつまでたっても古いままです。

なおサーバーに負荷をかけないために、HTMLドキュメントに対しては最低でも15秒以上の間隔を空けてリクエストします。
画像やリソースに対しては最低でも1分以上の間隔を空けてリクエストします(間隔は将来変更される可能性あり)。

AMPキャッシュの更新強制

説明したように、ユーザーが閲覧する限りはAMPキャッシュは自動で更新されます。
しかしオリジナルのコンテンツを更新し、キャッシュも今すぐにでも更新したいことがあるでしょう。
そんな状況では、ユーザーの閲覧を待たずともAMPキャッシュを更新することができます。

方法はとても簡単です。

あなたが、AMPキャッシュのURLにアクセスすればいいのです。
オリジナルのコンテンツが更新されていることをAMP CDNが認識できれば、キャッシュも更新されます。
ユーザーには新しくなったキャッシュが返されます。

AMPキャッシュのURLは、この記事の初めに説明しましたね(なので、AMPキャッシュURLのフォーマットの理解は大切なのです)。

この記事のAMPキャッシュを更新したければ、次のURLにアクセスします。

https://cdn.ampproject.org/c/s/www.suzukikenichi.com/blog/anatomy-of-amp-cache/amp/

AMPキャッシュの更新には、Fetch as Googleのインデックス送信を使ったりしなくていいのです。

AMPキャッシュの削除

AMPページまたはAMPページで使っている画像やリソースは、本体を削除すればいずれAMPキャッシュからも削除されます。
一般的なウェブページや画像と同じです。

ですが、キャッシュを至急で削除したい場合に利用できる仕組みがあります。
update-ping“を使います。

AMPキャッシュされている https://example.com/amp_document.html のAMPページを削除リクエストするには次のURLにアクセスします。

https://cdn.ampproject.org/update-ping/c/s/example.com/amp_document.html

AMPキャッシュのURLで、https://cdn.ampproject.org の次に /update-ping を差し込みます。

http://example.com/images/logo.png の画像のAMPキャッシュを削除リクエストするには、次のURLにアクセスします。

https://cdn.ampproject.org/update-ping/i/example.com/images/logo.png

update-ping に加えて、おさらいの目的も兼ねて以下にも注意してください。

  • コンテンツタイプが画像なので /i になる
  • オリジナルのURLはHTTPなので、/s は付かない

HTTPとHTTPSは連動しません。
キャッシュは別々に保存されています。

なお、update-pingを使ったURLに「アクセスする」と表現しましたが、正確には「GETリクエストを送信」します。
“204 No Content”のHTTPステータスコードが返ってきます。

update-ping を使うとキャッシュが自然に削除されるのを待つよりもずっと早くキャッシュを削除できます。

この記事でのAMPキャッシュに関する説明は以上です。

ブログ読者に向けた解説というよりは、僕自身のためのまとめの意味合いのほうが実は強かったりします(AMPキャッシュの更新方法について、何度か質問されたことがあった)。
公式ドキュメントには、AMPキャッシュに関する情報がほかにも書かれていますが、僕にとって重要な部分に絞って説明しました。
AMPキャッシュの仕組みに興味を持ったなら、公式ドキュメントもお読みください。

- Google CDNのAMPキャッシュを大解剖――URLフォーマット、更新プロセス、更新方法、削除方法 -

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

Kenichi Suzuki

グーグルの“隠れた”品質評価アルゴリズムに対応する方法【海外&国内SEO情報ウォッチ】

9 years 6ヶ月 ago

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

今週のピックアップ

  • グーグルの“隠れた”品質評価アルゴリズムに対応する方法
    Web担当者フォーラム 海外&国内SEO情報ウォッチの今週のイラスト

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

  • モバイル検索へのAMP全体適用をグーグルがすでに本番で実施した!?
  • ついにアマゾン日本も常時HTTPS化
  • アドワーズ用のクローラーAdsBot-GoogleはSEOに影響を与えるのか?
  • プログレッシブ ウェブ アプリを実現するService Workerとは

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

  • PWAに取り組まないのは、SEOで大きなチャンスを逃しているも同然?
  • 米国のIPアドレスからのアクセスを制限してはいけない
  • h1タグは必ず設置すべし、グーグルの理解を助ける
  • API利用条件としてのリンクは有料リンクと同じ
  • この秋は、グーグル検索でファッションショーを楽しもう!

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

  • 今すぐ始められる、ECサイトでのAMP対応
  • Google、最新コンテンツをリアルタイムで検索結果に表示するSearch live coverage carouselを試験的に開始

こちらからどうぞ。

- グーグルの“隠れた”品質評価アルゴリズムに対応する方法【海外&国内SEO情報ウォッチ】 -

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

Kenichi Suzuki

Google Chrome、パスワード/クレジットカード情報をHTTPで送るページに安全ではないことを示す「Not secure」ラベルを表示。2017年1月リリースのバージョン56から

9 years 6ヶ月 ago

[レベル: 初〜上級]

パスワードまたはクレジットカードの情報をHTTP接続で送るページに、安全ではないことを示すラベルをChromeブラウザで表示するようにするとGoogleはアナウンスしました。

2017年1月にリリースを予定しているChromeのバージョン56から実装します。

HTTPページには「Not secure」ラベル

HTTP通信ではセキュリティが確保されません。
そのため、HTTPページでは送信する情報を第三者に盗み見されたり改ざんされたりする可能性があります。
そこで「Not secure」のラベルをアドレス欄に表示するようにしました。

日本語版では「安全ではありません」といったようなラベルになるのではないでしょうか。

下の画像はサンプルです。
上の段は現行のChrome(バージョン 53)です。
特別なラベルは何も付いていません。
しかし下の段のChrome 56からは「Not secure」のラベルがURLの前に付きます。

Not secure ラベル

なお、公式アナウンスには、サイトが対象と書かれていますがページが対象です。
パスワードやクレジットカードの情報をHTTPで送るページがあれば、そのページだけにラベルが付きます。
サイト全体ではありません。

パスワードとクレジットカードの送信フィールドがあるページのみ

Not secureラベルの対象になるのは、パスワードまたはクレジットカードの情報をHTTPで送信するページです。
メールアドレスや住所、電話番号などそのほかの個人情報を送信するページは、(最初の時点では)対象になりません。

もう少し細かく言うと、パスワードやクレジットカードのフォームフィールドがあるHTTPページになるかと思います。

対象範囲を拡大する可能性も

すでに説明したように、2017年1月リリースのバージョン56では、パスワード/クレジットカードをHTTPで送信するページだけがラベルの対象です。

しかし対象範囲をさらに拡大していきたいとのことです。

たとえば、シークレットモードでChromeを利用する場合です。
シークレットモードは、ユーザーがプライバシーを保護したいときに使われます。
そこで、シークレットモード利用時はすべてのHTTPページにNot secureラベルを表示するかもしれません。

最終的には、モードに関係なく、すべてのHTTPページにNot secureラベルを表示することを目指しています。
しかも赤色の警告マークも付けるかもしれません。

警告マークつきのNot secureラベル

今から準備を

「安全ではありません」なんて表示されたらアクセスしたくなるユーザーがおおぜい出てくることでしょう。

まさかパスワードやクレジットカードの情報を送信する際に、HTTPSを使っていないのは今どきありえないと思います。
それでも、もし万が一そういったページでHTTPのままであれば大至急HTTPSに変えなければなりません。
もっとも、パスワードやクレジットカード情報をHTTPで送らせるなんていうのはChromeのNot secureラベル以前の問題ですが。:(

パスワードやクレジットカードの情報を送信するページを持っていないとしても、HTTPS化は避けて通れないでしょう。
時代の流れなのであらがうことは得策ではありません。
さっさとHTTPSに移行して本当に僕は良かったと思っています。

なお自分のサイトがどんな影響を受けそうか(あるいは受けないか)は、開発版のChrome Canaryで確かめることができます。
安定版がリリースされるだいたい6週間前に新機能が実装されるとのことです。

- Google Chrome、パスワード/クレジットカード情報をHTTPで送るページに安全ではないことを示す「Not secure」ラベルを表示。2017年1月リリースのバージョン56から -

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

Kenichi Suzuki

Google、ローカルナレッジパネルに「ウェブ上のレビュー」を追加。レストランやテーマパークなどに対するさまざまなレビューサイトでの評価が検索結果でわかる

9 years 6ヶ月 ago

[レベル: 中級]

Googleは、ローカルナレッジパネルに「ウェブ上のレビュー」を追加しました。
「ウェブ上のレビュー」には、さまざまなレビュー系サイトから集められた平均評価が掲載されます。

レビューサイト運営者は、Review snippetsを設定することで「ウェブ上のレビュー」に含めてもらいやすくなります。

ローカルナレッジパネルに掲載された「ウェブ上のレビュー」

レストランやショップ、テーマパーク、公園など場所や建物に関係するナレッジパネルにウェブ上のレビューは掲載されます。

こちらは昭和記念公園のナレッジパネルに掲載されたウェブ上のレビューです。

国営昭和記念公園の「ウェブ上のレビュー」

Facebookジョルダンのウェブページに投稿されているレビューの情報が採用されています。

こちらはテーマパークのウェブ上のレビューです。

のレゴディスカバリーセンターの「ウェブ上のレビュー」

こちらはレストランのウェブ上のレビューです。

シェンロントーキョーの「ウェブ上のレビュー」

レビューの採用元がそれぞれ異なっているのがわかります。
どこから引っ張ってくるかはアルゴリズムによって判断されます(提供元として選ばれやすくする方法は後述)。
最大で3つのサイトからのレビュー情報が掲載されます。

PC検索でもウェブ上のレビューを見ることはできます。

PC検索でのナレッジパネルの「ウェブ上のレビュー」

詳しく書かれたレビュー記事を引用する「Critics reviews」という機能が先月から米国では試験的に始まっています。

Critics reviewsとウェブ上のレビュー(英語では「Reviews from the web」)はともに掲載されます。

Reviews from the web and Critics reviews

Critics reviewsは米Googleだけですが、「ウェブ上のレビュー」は世界中のGoogleで利用可能です。

Review snippetsの設定方法

さて、ここまでは一般ユーザーに向けての「ウェブ上のレビュー」という新機能の紹介です。

あなたがレビューを集めるサイトを運営しているなら、ローカルナレッジパネルのウェブ上のレビューに掲載されやすくすることができます。

ウェブ上のレビューは、技術的な用語では「Review snippets(レビュー スニペット)」と呼ばれます。

ローカルビジネスの場合のレビュー スニペットにはschema.orgを用いた次の2つの構造化データのマークアップが必要です。

構造化データを使うことにより、レビューのデータをGoogleは集めることができます。
そして、あなたのサイトでのレビューの対象とナレッジグラフに登録されているローカル”エンティティ“とを結び付けることができます。

レストランやお店、テーマパークなどのレビューを集めているサイトならレビュー スニペットに必要な構造化データを設定しておくといいでしょう。
ナレッジパネル経由でのアクセスが増えることが期待できます。

- Google、ローカルナレッジパネルに「ウェブ上のレビュー」を追加。レストランやテーマパークなどに対するさまざまなレビューサイトでの評価が検索結果でわかる -

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

Kenichi Suzuki

出現を遅らせたインタースティシャルならGoogleのアルゴリズムをすり抜けられるか?

9 years 6ヶ月 ago

[レベル: 初級]

閲覧をじゃまするインタースティシャルを表示するページの評価を下げるアルゴリズムを、Googleは来年1月に導入する予定です。

このアルゴリズム変更について、英語版オフィスアワーでおもしろい(?)質問が出ていたので紹介します。

インタースティシャルの出現を遅らせたらどうなる?

質問は次のようなものでした。

わずらわしいインタースティシャルを表示するページの順位をモバイル検索で下げる予定についてですが、インタースティシャルが出現するのを大幅に遅らせたとしても評価は下がりますか?

GoogleのJohn Mueller(ジョン・ミューラー)氏はこんなふうに回答しました。

インタースティシャルはユーザー体験を悪くすると私たちが言っているにもかかわらず、ずるいやり方でなんとかしてインタースティシャルを使おうと考えているように聞こえる。

インタースティシャル アルゴリズムで得しようと思っているんだとしたら気を付けたほうがいい。

法律上の理由があるなら、もちろんインタースティシャルを表示してかまわない。

そうじゃなくて、ユーザーがページを見たときに注意を引きたいなら私なら別の方法を考えるね。

ダメなものはダメ

インタースティシャルをすぐに表示させるのではなく、しばらく時間を置いてから表示させようという魂胆です。
たとえば、ユーザー画素のページを開いてから10秒経過したら表示させることができるでしょう。

Googlebotは時間をかけて滞在しないので、インタースティシャルを見ることはありません。
でもユーザーは見ます。

画面の上または下に出てくる適切な大きさのバナーや法律上の問題から必要なポップアップのように正しく使われているインタースティシャルなら問題視されません。
それ以外の目障りなインタースティシャルはどんな形式であれ使うべきではありません。
ダメなものはダメです。

本質に立ち返ってみると、Googleがインタースティシャルアルゴリズムを導入することにしたのは、すべてではないにしても大多数のユーザーがインタースティシャルを嫌っているからです。
Googleの目をすり抜けられたとしても結局はユーザーに嫌われます。

遅延インタースティシャルのほかにも、あの手この手でウザいインタースティシャルを仕掛けてくるサイトが出てくるような予感がします。
でもユーザーを最優先に考えていれば、そういったことを企もうとは思いませんよね。

- 出現を遅らせたインタースティシャルならGoogleのアルゴリズムをすり抜けられるか? -

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

Kenichi Suzuki

直帰率や滞在時間をランキングシグナルとしてGoogleは使っているのか? アルゴリズム評価には使っているが個々の検索結果を変更する目的では使わない

9 years 6ヶ月 ago

[レベル: 初〜中級]

Googleは、検索結果でのクリック率や直帰率、サイトでの滞在時間をランキングに反映させているのでしょうか?
たびたび出てくるこの質問にGoogleのJohn Mueller(ジョン・ミューラー)氏が直近のウェブマスターオフィスアワーで答えました。

検証には使っているが、個々のレベルでは使っていない

次の質問が尋ねられました。

Googleは、ランキングシグナルとして直帰率を使っていますか?

ミューラー氏はこう答えます。

直帰率みたいなものは、Googleアナリティクスのようなツールで昔から計測されている指標だ。でも、私たちはGoogleアナリティクスを検索順位を決めることにはまったく使っていない。検索に対しては通常は使っておらず、結びつけてはいない。

(クリックや直帰など)そういったデータを実際に使っている1つの場面は、アルゴリズムを評価するときだ。

概して、どちらのアルゴリズムがいいかを検証するときに使う。数百万の検索結果、数百万のさまざなサイトにわたって検証することができる。そして、「概して言えば、集計データに基づくとこちらのアルゴリズムのほうがうまくいってるな」と言うことができる。

だが、もっと狭い範囲では、そういうことは本当には簡単にはできない。私が知る限りでは、直帰のようなものはランキングには使っていない。

質問が続きます。

たとえば、1,000人のユーザーが訪問したとします。

300人のユーザーは探していたものを見つけた。400人のユーザーはそこそこ時間をサイトで費やしたけれど、また検索を続けた。400人はすぐに検索結果に戻った。

こういったユーザー行動の状態をGoogleは見ていますか? 検索順位を変化させますか?

ミューラー氏の回答は次のようでした。

基本的には先ほども言ったとおりだ。

非常に幅広く集約されたデータにおいては、そういったもののなかには見ているものも確かにある。何百万ものサイト、何百万もの検索結果を見たときには、そこから妥当な有用性を得ることができると思う。

しかしページ単位では、そういったことは普通は簡単にできるものではないだろう。

Googleアナリティクスのデータを検索には使っていない、これは信じていいでしょう。

すべてのサイトがGAを導入しているわけではありません。
ウェブ全体を考えれば、むしろ導入していないサイトのほうが多いのではないでしょうか。

そういった限られたデータを利用することは信頼性に欠けます。

一方で、検索結果でのクリックなどユーザー行動を実際に利用している場面があります。
それは新しいアルゴリズムを導入したり、アルゴリズムに改良を加えるときです。

検索品質評価者や、あるいは一般ユーザーを対象にしたテストで、新しい検索結果が良いものかどうかを判断するときの材料にしています。

たとえば、以前よりもユーザーがクリックしなくなったり再検索が増えたりしたとしたら、新しい検索結果は品質が返って落ちたと判断されるかもしれません。
テストで良い結果が得られれば実際に導入されるだろうし、良い結果が得られなければ導入は見送られるかもしれません。

アルゴリズムの改良や品質のチェックにクリックなどのユーザーデータが使われることは、GaryがGoogle Dance Tokyoで日本に来たときも説明していました。

さて問題は、個々のサイト/ページにおける検索結果でのユーザー行動がランキングに直接反映されるのかどうかです?
特にここ2、3年盛り上がっている(?)トピックです。

ミューラー氏によれば、ものすごく限られたデータだから簡単には利用できないとのことでした。
何百万もの検索結果とサイトを基にした集計データはアルゴリズムの評価に役立つけれど、1つのページや1つの検索結果だけのデータをそのまま検索結果には反映させることには問題があるからです。

あなたはどう思いますか?
僕はジョンを信じることにします。:)

- 直帰率や滞在時間をランキングシグナルとしてGoogleは使っているのか? アルゴリズム評価には使っているが個々の検索結果を変更する目的では使わない -

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

Kenichi Suzuki

AMPページでリアルタイムにコンテンツを更新する「amp-live-list」がベータ版を抜け一般公開

9 years 6ヶ月 ago

[レベル: 上級]

AMPプロジェクトは、<amp-live-list> がベータ版から抜けたことをアナウンスしました。
一般サイトでの利用が可能です。

<amp-live-list> は、ページを再読み込みすることなしに、更新されたコンテンツをAMPページで即座に表示する仕組みです。
7月の終わりにベータ版が公開されていました。

英国最大手パブリッシャーがライブブログでamp-live-listを採用

<amp-live-list>は、スポーツやイベントの実況中継、あるいは選挙速報のニュースのように、その瞬間に起きている最新の情報をリアルタイムで配信するページで用いられます。
ブログでのライブ中継なので、”live blog (ライブ ブログ)”と呼ばれることもあります。

完成版としての仕様が固まったわけではなくまだ試験運用の状態 (Experimental) ですが、英国最大手の新聞社であるThe Guardianはサイトのライブブログのセクション<amp-live-list> をさっそく実装しています。

こちらのアニメーションは公式アナウンスが紹介している <amp-live-list> によってAMPページでコンテンツが更新する例です。

amp-live-listでコンテンツが更新する例

ややわかりずらいのですが、「New updates」という赤いボタンがページの上部に出現し、それをタップするとコンテンツが更新してページのトップに自動的に移動します。
すると最新のコンテンツ(記事)が追加されていて、それを読むことができます。

ページを再読み込みしていません。
単にページ内を移動しているような感覚です。

ユーザーがタップしなくても自動的に更新したり、いくつの更新があるのかを表示したりといったオプション機能も今後は検討するとのことです。

ライブブログ形式でコンテンツを配信している日本のサイトを僕はほとんど聞いたことがありません。

それでも、Yahoo!がリオオリンピックの特設サイトでリアルタイムに近い形で試合の状況をテキスト配信していました。
僕は、TVを見られないときはこちらを読んでいました。

4年後の東京オリンピックは、<amp-live-list>を使ったAMPページで試合観戦できるかもしれませんね。

- AMPページでリアルタイムにコンテンツを更新する「amp-live-list」がベータ版を抜け一般公開 -

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

Kenichi Suzuki

ウザいインタースティシャル広告に徹底ペナルティ、グーグルが遂に決定【海外&国内SEO情報ウォッチ】

9 years 6ヶ月 ago

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

今週のピックアップ

  • ウザいインタースティシャル広告にペナルティ、グーグルが遂に決定
    Web担当者フォーラム 海外&国内SEO情報ウォッチの今週のイラスト
  • インタースティシャルのペナルティはページ単位で影響する

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

  • 重複ページのrel=”canonical”、アルゴリズム変更を事前告知する場合としない場合の違い、コンテンツの登用対策など、8月のオフィスアワー
  • あなたにも絶対に必要なユーザビリティテストとその始め方
  • やはり「AMP対応は待て」か? AMP導入3か月後に出した結論

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

  • HTTPSでインデックス済みのURLをHTTPに戻すにはどうすればいいのか?
  • キーワードを埋め込んだなフッターリンクにSEO効果はあるのか?
  • AMPでA/Bテストまで利用できるようになった
  • titleタグのおかしな書き換えが発生したらグーグルにフィードバックしよう
  • hreflangで、言語の順番は関係ないが、タグの場所は重要

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

  • インタースティシャルがわずらわしいかどうかを診断するツールをGoogleは提供する予定なし
  • JavaScriptのクロール用に特別なユーザーエージェントをGoogleは持っていない、JSの処理はクロールとは別

こちらからどうぞ。

- ウザいインタースティシャル広告に徹底ペナルティ、グーグルが遂に決定【海外&国内SEO情報ウォッチ】 -

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

Kenichi Suzuki

Google、最新コンテンツをリアルタイムで検索結果に表示するSearch live coverage carouselを試験的に開始

9 years 6ヶ月 ago

[レベル: 上級]

Googleは、「Search live coverage carousel(サーチ ライブ カバレッジ カルーセル)」という名称の、新しい機能の仕様をデベロッパー向けサイトで公開しました。
Search live coverage carousel は、公開したばかりのコンテンツを通常のクロールよりもずっと速く検索結果に表示することを可能にします。

今年5月の Google I/O 2016 で Richard Gingras(リチャード・ギングラス)氏は、今後公開を予定している新機能の1つとして Real time index を紹介しました。
この Real time index が Search live coverage carousel に相当すると推測されます。

通常クロールよりもずっと高速に最新コンテンツをカルーセルで検索結果表示

Search live coverage carousel を利用すると、最新のコンテンツが入手できるようになったときにGoogleに通知できます。
状況が刻々と移り変わるコンテンツを、Googleは、現在のように通常のクロールによって検索結果に表示するよりもずっと高速に検索結果に表示することが可能になります。

状況が刻々と移り変わるコンテンツとは、たとえば次のようなコンテンツです。

  • スポーツの生中継
  • 選挙速報
  • ニュース速報

コンテンツの種類は、記事・ライブブログ・動画などさまざまなものが対象です。

名前からもわかるように Search live coverage carousel はカルーセルで表示されます。

こちらはデベロッパーサイトに掲載されている Search live coverage carousel のサンプル画像です。

Search live coverage carouselのサンプル

プロ・アメリカンフットボール (NFL) チームの Dallas Cowboys(ダラス・カウボーイズ)に関する最新ニュースのようです。
写真とアイコンから判断するに、インタビューの動画でしょうか。

カルーセルを横にスワイプすると次のコンテンツが見えてくるのでしょう。

Search live coverage carousel の実装方法

Search live coverage carousel を実装するには、3つの設定が必要です。

  • AMP
  • 構造化データ
  • Atom XML feed

AMPフォーマットでコンテンツを発行します。
ということは、モバイル検索でのみ Search live coverage carousel 提供されるということになります。
最新ニュースを知りたいのに、もたもたとページが表示されたら確かに嫌ですよね。

schema.orgを用いた構造化データの設定が必要です。
どういったタイプのschema.orgをサポートしどのプロパティが必須なのかはドキュメントには書かれていません。
とはいえ、記事や動画ならトップニュース用のschema.orgと同じなのではないでしょうか。

公開したコンテンツを Atom XML feed に含め、HTTP POST を使ってGoogleに通知します。
こうすることにより、そのコンテンツをGoogleは直ちにクロール、インデックスできます。

試験運用が始まる

Search live coverage carousel はまだ正式公開されていません。
現在はパイロットプログラムとして、試験運用のための参加者を募集している状態です。

パイロットプログラムに参加するにはこちらのフォームから応募します。

ただし初めのうちは、ニュースやスポーツなどの最新のコンテンツを毎日数十以上発行するような大規模パブリッシャーを対象にしているような感じです。
このブログのような1日1記事のサイトは参加できないと思われます。

それでも、もしあなたが、速報性が問われるコンテンツを日々大量に発行しているなら関心を持っていることをGoogleに示すといいでしょう。

- Google、最新コンテンツをリアルタイムで検索結果に表示するSearch live coverage carouselを試験的に開始 -

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

Kenichi Suzuki

Android版Googleアプリ、端末内のパーソナルコンテンツを検索する「アプリ内」機能を導入

9 years 6ヶ月 ago

[レベル: 中級]

Android版のGoogleアプリで、端末にインストールしているアプリのなかにあるコンテンツを検索できるようになりました。
Gmailのメールやコンタクトの連絡先、YouTubeの動画などパーソナルなコンテンツを検索できる便利な機能です。
検索結果の「アプリ内」タブから利用できます。

アプリのなかにあるパーソナルコンテンツを検索

Googleアプリで検索し、「アプリ内」(英語では、”In Apps”)タブを選択するとアプリのなかにあるコンテンツの検索結果になります。

こちらは、僕のスマホでGoogleアプリから「夏」を検索した結果です。
GmailのメールとEvernoteのノートが表示されています。

Googleアプリの「アプリ内」結果

当然のことながら、パーソナルなコンテンツは自分の端末でしか結果に出てきません。
電話帳アプリの「コンタクト」もアプリ内検索の対象になるパーソナルコンテンツのひとつです。

Chromeからの結果もいちばん下にチラッと見えます。
閲覧履歴からだと思われます。(笑)

ほかには、TwitterとYahoo!ニュース、クックパッドからのコンテンツも表示されました。
どのアプリもインストールしてあります。

Googleアプリの「アプリ内」結果

App Indexingに対応しているアプリは、自動的に対象になるようです。

ただし、App Indexingアプリからは、パーソナルなコンテンツではなく一般公開されているコンテンツが返ってきます。

Twitterの結果に出ているユーザーは僕がフォローしているユーザーではありません。
通常の検索結果にも出てくる公開ツイートなので、関連性があったためアプリ内検索でも出てきたのでしょう。

対応アプリ

「アプリ内」検索をサポートしているアプリの例として公式アナウンスは次を紹介しています。

  • Gmail
  • Spotify
  • YouTube

今後数か月以内に次のようなアプリがサポートを予定しているとのことです。

  • Facebook Messenger
  • LinkedIn
  • Evernote
  • Glide
  • Todoist
  • Google Keep

対応予定のリストに含まれているEvernoteは、先ほどのキャプチャで見せたようにすでに対応していますね。

自分のスマホ端末であなたが利用している、あなた個人のアプリコンテンツをGoogleアプリのアプリ内検索で探せるようになりました。
アプリコンテンツを対象したパーソナライズ検索と言っていいかもしれません。
使う側としては便利な機能になりそうです。

また、App Indexingを実装しているアプリは露出機会が増えそうです。
App Indexingを実装しているアプリ開発者にとってもメリットになる可能性もあります。

- Android版Googleアプリ、端末内のパーソナルコンテンツを検索する「アプリ内」機能を導入 -

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

Kenichi Suzuki

Google、「スマホ対応」ラベル表示の廃止をモバイル検索で実施

9 years 6ヶ月 ago

[レベル: 初級]

Googleは、スマートフォン対応したページに対象にモバイル検索結果で付与していた「スマホ対応」のラベル表示を廃止しました。

インタースティシャルを表示するページのランキングを下げるアルゴリズム変更の導入とあわせて、「スマホ対応」ラベルの廃止も1週間前にGoogleは告知していました。
アルゴリズム変更は来年1月の実施予定ですが、ラベル廃止は早々に実施されたことになります。

「スマホ対応」ラベルが付かないモバイル検索結果

「スマホ対応」のラベルが付いていた以前の検索結果と、付かなくなった現在の検索結果を並べてみます。

「スマホ対応」ラベルが表示されていた検索結果と表示されなくなった検索結果

スマホ対応しているクックパッドにもNAVERまとめにも、「スマホ対応」ラベルはもう付いていません。

僕が目立つように付けた赤枠を取り去って、”素”の状態に戻します。

「スマホ対応」ラベルが表示されていた検索結果と表示されなくなった検索結果

一見するとラベルがないので確かにすっきり見えるのですが、表示に慣れていたせいか逆に、「”何か”がない」という違和感を覚えるのは僕だけでしょうか?

ラベルがなくなった分だけスニペットの文字数が増えるかと僕は予想していたけれど、変わってないですね。
増やしてくれればいいのに。

なお、米Googleのモバイル検索での「Mobile-friendly」ラベルも表示されなくなっています。
グローバルでラベル廃止をGoogleは実施したと思われます。

ラベルはなくなってもモバイルフレンドリーはランキング要因

Googleが推奨するとおりにモバイル対応しているはずなのに「スマホ対応」ラベルが突然消えたと慌てる人が出てきそうです。
まわりにそんな人がいたら、仕様が変わってラベル表示が廃止されたことを教えてあげましょう。

ただしラベルが表示されなくなったからといって、モバイルフレンドリーがランキング要因から除かれたわけではありません。
今までどおり、モバイル対応していないページは検索順位が下がることがあります。

きちんとモバイル対応できているかどうかは、モバイルフレンドリーツールモバイルユーザービリティレポートで確認できます。

- Google、「スマホ対応」ラベル表示の廃止をモバイル検索で実施 -

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

Kenichi Suzuki

Google、ローカルビジネス向けレビューの構造化データのガイドラインを更新。悪いレビューも許可すること、サードパーティサイトのレビューはマークアップ不可など

9 years 6ヶ月 ago

[レベル: 中級]

レビューのガイドラインを評価

Googleは、レビューの構造化データの仕様・ガイドラインを更新しました。
特にローカルビジネス向けのレビューに対して、重要な変更が含まれます。

ローカルビジネス向けレビューの新しいガイドライン

レストランやホテル、ショップなど実店舗型のビジネスが顧客のレビューをサイトに掲載し、構造化データでマークアップする際のガイドラインが更新されました。
下が、2016年8月4日に更新された、この記事を書いている時点でのローカルビジネスのレビューのガイドラインです。

  • Snippets must not be written or provided by the business or content provider unless they are genuine, independent, and unpaid editorial reviews.
  • Reviews must allow for customers to express both positive and negative sentiments. They may not be vetted by the business or restricted by the content provider based on the positive/negative sentiment of the review before submission to Google.
  • Reviews cannot be template sentences built from data or automated metrics. For example, the following is not acceptable: “Based on X number of responses, on average people experienced X with this business.”
  • Reviews for multiple-location businesses such as retail chains or franchises can only be submitted for the specific business location for which they were written. In other words, reviews for multiple-location businesses cannot be syndicated or applied to all business locations of the same company.
  • Aggregators or content providers must have no commercial agreements paid or otherwise with businesses to provide reviews.
  • Do not include reviews that are duplicate or similar reviews across many businesses or from different sources.
  • Only include reviews that have been directly produced by your site, not reviews from third-party sites or syndicated reviews.

日本語訳

日本語ページが存在しないので、日本語にしました。

  • 本物で、関係性がなく、対価を支払わず自発的に書いてもらったものでない限りは、レビューは、ほかのビジネスやコンテンツ提供者によって書かれたり提供されたりしたものであってはいけません。
  • レビューは、好意的な意見と批判的な意見のどちらも顧客が表せるようでなければなりません。Googleに投稿する前に、そのレビューが好意的か否定的かという感情にもとづいて、ビジネス運用者によって審査されたりコンテンツプロバイダーによって制限されたりしてはいけません。
  • レビューは、データや自動解析から作られた定型文であってはいけません。たとえば次のようなレビューは許可されません ―― 「◯件の返信にもとづくと、たいていの人はこのサービスに対して◯◯を体験しています」
  • チェーン店やフランチャイズのように複数の場所で営業しているビジネスに対するレビューは、そのレビューが書かれた店舗の場所においてのみ投稿できます。言い換えると、複数の場所で営業しているビジネスのレビューを、同じ経営元のほかの場所の店舗に複製したり掲載したりすることはできません。
  • レビューを配信するサービス提供者やコンテンツプロバイダーは、対価を支払っても支払わなくても、レビューを提供するために営利目的の契約を結んではいけません。
  • たくさんのビジネスに渡る、あるいは異なるソース元からの、重複したり類似したりするレビューを含めてはいけません。
  • あなたのサイトに直接投稿されたレビューだけを含めてください。サードパーティのサイトからのレビューや同報配信されたレビューを含めてはいけません。

わかりやすい日本語版

僕の日本語訳では意味がわかりにくいところがあったのではないでしょうか。
オリジナル自体が(僕にとっては?)わかりづらい英語で書かれていて、日本語に訳しづらい表現が多いのです。

要点を絞って、わかりやすく書き換えたのがこちらです。

  • 純粋な顧客ではない評論家や業者によってレビューが書かれたとしたら、そういった人・業者にはお金を払っていてはいけないし、関係性があってはいけない。宣伝目的ではなく、中立な立場でのレビューでなければならない。
  • 良いレビュー、悪いレビューのどちらも顧客は投稿できるようにする。悪いレビューだからといって検閲してはいけない。
  • 自動生成したレビューを掲載してはいけない。
  • 複数の店舗があるビジネスでは、レビューを掲載できるのはその場所の店舗(のサイト/ページ)だけ。たとえば、新宿・渋谷・池袋の3か所にお店があったとして、新宿店に対して書かれたレビューを渋谷店や池袋店(のサイト/ページ)に掲載することはできない。
  • レビューサイトは、営利目的でレビューを提供してはいけない。
  • 同一または類似したレビューを掲載してはいけない。
  • 構造化データでマークアップできるのは自分のサイトに投稿されたレビューだけ。たとえば、Googleや食べログに書き込まれたレビューを自分のサイトに掲載してそれをマークアップしてはいけない。

お金を払って書いてもらったレビューをマークアップしてはいけないのは当然として、レビューが批判的だから掲載しないとか、別の店舗のレビューを使いまわしするとか、レビューサイトに書かれたレビューをコピーしてそれをマークアップするとか、気を付けなければならない点がいくつもあります。

ガイドラインに違反していると、構造化データでマークアップしていてもリッチスニペットが検索結果に出なくなることがあります。
悪質な場合は手動対策の対象になるかもしれません。

あなたがローカルビジネスを営んでいてレビューの構造化データを設置しているなら、ガイドラインに沿っているか点検してください。

- Google、ローカルビジネス向けレビューの構造化データのガイドラインを更新。悪いレビューも許可すること、サードパーティサイトのレビューはマークアップ不可など -

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

Kenichi Suzuki

今すぐ始められる、ECサイトでのAMP対応

9 years 6ヶ月 ago

[レベル: 上級]

AMPプロジェクトは、ECサイトでのAMPサポートに現在取り組んでいます。
ですが、現状でもECサイトがAMPに対応することはできます。

今すぐ始められるECサイトのAMP対応についてAMPプロジェクト公式ブログが解説しました。
要点をまとめてこの記事で紹介します。

カテゴリページのAMP対応

一般的に静的で、商品の一覧を表示するために設計されているカテゴリページはECサイトの中では特にAMPに向いています。

<amp-carousel> のような要素を利用するとスマートフォンでも商品を閲覧しやすくなります。
<amp-carousel> はいわゆる”カルーセル”をAMPページで実装できる仕組みです。
水平方向にフリックすることで、次から次へとスライド式に商品を閲覧できます。

こちらはAMPで構成されたカテゴリページのサンプルです。

AMPでのカテゴリページ

Recommendations(おすすめ)のセクションはカルーセルになっています。

AMPカテゴリページのカルーセル

商品詳細ページのAMP対応

商品の個別の詳細ページでは、次のようなAMP要素を利用できます。

  • <amp-carousel> ―― カテゴリページでも紹介したカルーセルUI
  • <amp-video> ―― AMPページに動画を設置
  • <amp-accordion> ―― アコーディオン型のUI
  • <amp-social-share> ―― ソーシャルボタンの設置
  • <amp-sidebar> ―― サイドバーを設置(普段は隠れていて画面の左をタップすると出現させることができる)
  • <amp-list> ―― リスト表示のUI

最後に挙げた <amp-list>には CORS JSON を使うことで、関連商品を動的に表示させることができます。
試験運用中の <amp-access>を組み合わせると、ログインしたユーザーにはパーソナライズしたおすすめ商品を表示させることもできます(こちらもCORS JSONを使う)。
なお動的にコンテンツを表示するための amp-mustache テンプレートが準備されています。

ほかには、ECサイトでよく使われるサムネイル画像ギャラリーのようなUIも開発が始まっています。

こちらはAMPで構成された商品詳細ページのサンプルです。

AMP商品詳細ページのサンプル

画面の下部にある「SHOW VIDEO」をタップすると動画を視聴できます。
その下にはソーシャルボタンが設置されています。

Description(商品説明)やSpecification(仕様)などはアコーディオンUIです。
初期状態では見出しだけで、タップすると本文が出現します。

商品詳細ページのアコーディオンメニュー

アクセス解析のAMP対応

ECサイトでも当然のことながらアクセス解析は重要です。
<amp-analytics>を使えば、AMPページでもアクセス解析を設置できます。
Googleアナリティクスや現在はAdobe Analyticsを始め、現在は数多くのアクセス解析がAMPをサポートしています。

購入のAMP対応

ECサイトのコンバージョンポイントでもある、購入はまだAMPでは実装できません。
AMPでの購入を可能にする <amp-form> の実験が始まっています。

現状では購入は通常のページで処理するしかありません。
AMPページから通常ページに移ったときでもユーザーには一貫した体験を提供することが重要だと公式ブログの記事は説明しています。

もしProgressive Web App(PWA、プログレッシブ ウェブ アプリ)を実装しているなら、AMPからPWAへの連携が可能です。
<amp-install-serviceworker> を使います。

まだ購入ができないので、ECサイトでのAMP化を急ぐ必要はないと僕は思います。
それでもいずれは(近いうちに?)可能になるでしょうから、もし労力を確保できるなら一部分からでもAMPを試してみると面白いかもしれませんね。

もし運営するECサイトのAMP対応をすぐに始めるなら、詳細を知るために公式ブログ記事を自分でも読んでください。

AMP対応しないとしても、少なくとも、AMPのECサイトサポートがどんな状況にあるのかに関してはアンテナを張っておいたほうがいいでしょう。
AMP対応するにはどういった作業が必要なのかも今から調べておけば、AMP化をスムーズに始められます。

- 今すぐ始められる、ECサイトでのAMP対応 -

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

Kenichi Suzuki

AMPでは、ソーシャルボタンもサイドバーも広告もレコメンドも実現できる【海外&国内SEO情報ウォッチ】

9 years 6ヶ月 ago

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

今週のピックアップ

  • AMPでは、ソーシャルボタンもサイドバーも広告もレコメンドも実現できる
    Web担当者フォーラム 海外&国内SEO情報ウォッチの今週のイラスト
  • AMP対応すべきか? SEOプロの出した答

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

  • 不自然リンクのペナルティは回数が重なるとどんどん重くなる
  • 小規模サイトにアクセス解析はいらない、もっとやるべきことがある

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

  • コンテンツ品質の問題で順位が下がったら、それを修正しても元に戻るとは限らない
  • 【SEOに悲報】キーワードプランナーで検索ボリュームが調べられなくなってしまった
  • HTMLとPDFで同一コンテンツを公開したら重複コンテンツになるのか?
  • HTTPヘッダーのrel=”canonical”は画像には使えない
  • グーグルはSVGのなかのリンクをたどることができるのか?
  • 大手メディアサイトが常時HTTPS化に苦戦

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

  • AMPプロジェクトが第3四半期のロードマップを更新、ECサイトでのAMPサポートを目指す
  • AMPに対応した広告用ランディングページ「ALP」、DFPが年内に配信開始予定
  • Google、あらゆる種類のインタースティシャルを対象にモバイル検索で評価を下げるアルゴリズム変更を予告

こちらからどうぞ。

- AMPでは、ソーシャルボタンもサイドバーも広告もレコメンドも実現できる【海外&国内SEO情報ウォッチ】 -

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

Kenichi Suzuki

インタースティシャルがわずらわしいかどうかを診断するツールをGoogleは提供する予定なし

9 years 6ヶ月 ago

[レベル: 初級]

モバイル向けページに設置したインタースティシャルがわずらわしいかどうかを診断するツールを、少なくとも今のところはGoogleは提供する予定はないようです。
またSearch Consoleのモバイルユーザビリティレポートにもエラーとしてあがってくることもなさそうです。

診断ツールは出さない

モバイルフレンドリーツールやモバイルユーザビリティレポートを使って、わずらわしいインタースティシャルをチェックできるようになるかどうかをGoogleの長山さんにTwitterで質問しました。

次のような回答をいただきました。

ということで、そのインタースティシャルがわずらわしいかどうかは自分の目で実際に見て判断することになります。(´・ω・`)

質問の意図

誤解のないように、僕の質問の意図を説明しておきます。

強制的に差し込まれるインタースティシャルの全面広告ページや画面を覆い尽くして身動きをとれなくさせるインタースティシャルがわずらわしいのは、たしかに一目瞭然です。
ウザさ満天なので、わざわざツールに頼る必要はないでしょう。

一方で、公式アナウンスには、新しいランキング要素の影響を受けない手法の1つの例としてこのように書かれています。

画面スペースから見て妥当な大きさで、簡単に閉じることのできるバナー。ここで言う妥当な大きさとは、たとえば Safari や Chrome に表示されるアプリ インストール バナー程度の大きさです。

※強調は僕による

画面スペースから見て妥当な大きさのバナー

「妥当な大きさ」……。

インタースティシャルに対するアルゴリズム変更の発表があってすぐに知り合いが質問してきました。

その人のサイトは、ページを少しスクロールすると、画面の下部に(”Call to Action”用の)バナーを出現させるようにしていました。
スクロールしてもくっついきて常に表示される、いわゆるスティッキー広告です(コンバージョンに効く)。

そのバナーが、わずらわしいインタースティシャルだとしてみなされてしまうのではないかと心配になったのです。

僕が見た限りでは、ユーザーの閲覧をジャマするような大きさではありませんでした。
一般的なアプリインストールバナーと同程度の、妥当な大きさです。
簡単に閉じることもできます。

問題なさそうに見えたものの、絶対に大丈夫だと僕が断言することはできません。

そこで、診断ツールまたはエラーレポートがGoogleから提供されるかどうかを知ろうとしたのです。
でも残念ながら提供されないとのことでした。

「ユーザー目線で考えて、イライラさせるようなものでなければ大丈夫」と頭ではわかっていても、自分のサイトとなると心配になるものです。

これくらいなら大丈夫だろうと思う大きさよりも、さらにひと回り小さくしておけば安心かもしれませんね。(笑)
一般のユーザーに実際に見てもらって、わずらわしく感じるかどうかを判断してもらうのもいいでしょう。
ほかには、同じようなタイプのインタースティシャルを利用しているサイトを調査して参考にするのもよさそうです。

- インタースティシャルがわずらわしいかどうかを診断するツールをGoogleは提供する予定なし -

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

Kenichi Suzuki

煩わしいインタースティシャルのランキング要素への追加はモバイルフレンドリーアップデートの一部

9 years 6ヶ月 ago

[レベル: 初〜中級]

煩わしいインタースティシャルを表示するページの検索順位を下げるアルゴリズム変更を、2017年1月10日に実施することを昨日Googleは予告しました。

公式アナウンスの日本語訳がさっそく公開されています。
重要な変更だからでしょう。

変更にまつわる疑問をインターネット上で眺めていると「公式アナウンスをきちんと読んでいないな」と思わざるをえないものがたくさんあります。
誤って解釈しないためにも、時間をかけてしっかりと目を通すことを推奨します。

この記事では、発表から1晩明けての補足・追加の情報を提供します。

モバイルフレンドリーアップデートの拡張

今回の変更は単独の新しいアルゴリズムの導入ではなく、既存のモバイルフレンドリー アップデートへのランキング要素の追加です。
今までは、アプリのインストールを勧めるインタースティシャルだけが「モバイルフレンドリーではない」の判定対象でしたが、その対象範囲を広げた形になります。

問題があるインタースティシャルを設置しているページは「スマホ対応」のラベルが付かなくなるでしょう。
もっとも、スマホ対応ラベルの表示は撤廃されてしまいますけどね。

(h/t: @JohnMu & @0penkenhiro)

アプリインストールのインタースティシャルはエラーとしてレポートされなくなる

この変更にともない、アプリインストールのインタースティシャルはモバイルユーザビリティレポートにエラーとしてレポートされなくなります
アプリインストールのインタースティシャルのエラー警告を無視していたサイト(ないとは思いますが)では、エラーの減少が見られるかもしれません。

とはいえ、問題視されなくなったわけではもちろんありません。
エラーとしてレポートされなくなるだけです。
アプリインストールを含む、すべてのタイプの煩わしいインタースティシャルがモバイル検索でランキングが下がる原因になりえます。

ただしありとあらゆるインタースティシャルをGoogleは禁止しているわけでないことも認識しておく必要があります。
正しく使えばユーザー体験を損ねることがないインタースティシャルも存在します。

たとえば、このページのようなアプリのインストールバナーはまったく問題ありません。
モバイルフレンドリーだとして認定されます。

アプリインストールバナー

じゃまになるほど大きくないし、すぐに消せます。

アプリインストールバナー以外にも新しいランキング要素の影響を受けないインタースティシャルがあります。
公式アナウンスで例示されているので確認してください。

今後、もしあなたのサイトで設置しているインタースティシャルが新しいランキング要素にひっかかるとしたら、おそらくモバイルユーザビリティレポートにエラーとして出てくるだろうし、モバイルフレンドリーテストツールにも合格しないはずです(確認中)。

インタースティシャルを使い続ける場合は、Googleのツールを使って問題がないことを確認するようにしましょう。

法律上の必要性に基づいて表示しているなど正しく使っているはずなのに、不正なインタースティシャルだとしてもしも認定されてしまったとしたら、Googleにフィードバックできます(公式ヘルプフォーラムへの投稿でGoogleに届きます)。

- 煩わしいインタースティシャルのランキング要素への追加はモバイルフレンドリーアップデートの一部 -

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

Kenichi Suzuki

Google、あらゆる種類のインタースティシャルを対象にモバイル検索で評価を下げるアルゴリズム変更を予告

9 years 7ヶ月 ago

[レベル: 初・中・上級]

インタースティシャルを表示するモバイルページの評価を下げるアルゴリズムを導入することをGoogleはアナウンスしました。
種類を問わず、すべてのインタースティシャルが対象になりえます。
変更は2017年1月10に実施される予定です。

アプリインストールだけじゃない、すべてのインタースティシャルが対象

アプリのインストールを勧めるインタースティシャルを表示するページをモバイルフレンドリーとはみなさず検索順位を下げることもあるアルゴリズム更新を、Googleは昨年の9月に事前通知し、11月に実施しています。

ただしこのアルゴリズム変更は、「アプリインストール」のインタースティシャルだけが対象です。
そのほかのタイプのインタースティシャルを表示したとしても、依然としてモバイルフレンドリーとみなされていました。

しかし今回のアルゴリズム変更は、否が応でも入り込んでくるインタースティシャルすべてが対象になります。

たとえば次のようなインタースティシャルが対象です。

  • メインコンテンツを覆うポップアップを表示する。検索結果からそのページに着地してすぐに表示する場合もあるし、ページをしばらく見たあとに表示する場合もあるがどちらも含まれる。
  • ユーザーがメインコンテンツにアクセスする前に終了させないといけない、単独のインタースティシャルを表示する。
  • Above the fold(ファーストビュー、スクロールせずに最初に表示される領域)のエリアが単独のインタースティシャルのように見えるが、実際のコンテンツはその下に位置しているレイアウトを使う。

こちらは、2つめの「単独のインタースティシャル(standalone、スタンドアロン型)」の具体例です。
検索結果をタップすると、広告だけの独立したページが強制的に差し込まれます。

スタンドアロン型のインタースティシャル

実際のコンテンツに進むには、右上にある「先に進む」という意味の英語で書かれたリンクをタップするか(PC向けページなので非常に小さい)、10秒ほど待たなければなりません。

このようなインタースティシャルはアルゴリズム変更の影響を受け、モバイル検索での順位が下がる可能性があります。

インタースティシャルは何であれ、ユーザー体験を損ねる

なぜインタースティシャルを利用したページの評価をGoogleが下げるかというと、それはもちろんユーザー体験を損ねるからです。
たとえモバイルフレンドリーだったとしても、突然に無理やり入り込んでくるインタースティシャルを喜ぶユーザーはいないでしょう。
本当に見たいコンテンツを見ることをジャマします。

今までは、アプリのインストールを迫るインタースティシャルが対象でした。
ですが、アプリインストールでなくても、何であれインタースティシャルはユーザー体験を損ねる要因になります。

そこで、すべてのインタースティシャルに適用範囲を拡大することをGoogleは決めたのです。

対象にならないインタースティシャル

一方で、アルゴリズム変更の対象にならないインタースティシャルもあります。
正当で合理性があるインタースティシャルです。

たとえば次のようなインタースティシャルは評価を下げられることはありません。

  • 法的な義務に対応するためのポップアップ。たとえば、Cookieの保存や年齢確認のためのポップアップ。
  • コンテンツが公開されておらずインデックスされないサイトでのログインのためのダイアログ。たとえば、メールのようなプライベートコンテンツや購読者だけが読めるインデックスされないコンテンツ。
  • ディスプレイの妥当なスペースだけを占めていて簡単に消せるバナー。たとえば、SafariやChromeで提供されるインストールバナー。これらは妥当な大きさでディスプレイ領域に表示される。

アプリインストールのインタースティシャルのアルゴリズムは廃止

このアルゴリズム更新によって、例外はあるもののすべてのインタースティシャルが評価が下がる対象になります。
対象範囲の拡大にともない、アプリインストールだけを対象にしていたアルゴリズムは使われなくなります。

正確には、使われなくなるというよりは、新たなアルゴリズムに統合されます。
アプリインストールのインタースティシャルが評価が下がる対象であることに変わりはありません。

スマホ対応ラベルの撤廃

インタースティシャルのアルゴリズム更新とは直接の関係はありませんが、もう1つの変更をGoogleは同時にアナウンスしました。

モバイル検索での「スマホ対応 (Mobile-friendly)」ラベルの撤廃です。

2014年11月にスマホ対応ラベルを導入して以来(日本では翌月)、検索結果に表示される85%のページがモバイルフレンドリーになっているそうです。

大多数のページがモバイル対応しているので、スマホ対応のラベルはもう不要だと判断したようです。
検索結果をすっきりさせるためにラベルを表示しないようにするとのことです。

ただし表示しないというだけであって、モバイルフレンドリーがランキング要因であることに変わりはありません。

Search Consoleのモバイルユーザビリティレポートもモバイルフレンドリーテストツールも今までどおり提供されます。

インタースティシャルが僕は本当に嫌いです。
1ユーザーの視点から、今回のアルゴリズム更新は待ちに待っていた変更です。

対応を迫られるサイトも出てくるでしょうが、僕ほどではないにしてもインタースティシャルを好まないユーザーは多はずです。
ユーザー体験の向上を第一に考えてサイト運営してほしいと望みます。

2017年1月10に実施を予定しています。
モバイルに関してはGoogleは必ず事前通知しています。
余裕を持って対処にあたってください。

- Google、あらゆる種類のインタースティシャルを対象にモバイル検索で評価を下げるアルゴリズム変更を予告 -

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

Kenichi Suzuki

JavaScriptのクロール用に特別なユーザーエージェントをGoogleは持っていない、JSの処理はクロールとは別

9 years 7ヶ月 ago

[レベル: 中級]

Googleは、JavaScriptをクロールするために特別なUser Agent(ユーザーエージェント)を持ってはいません。
通常のGooglebotがJavaScriptもクロールします。

BB-8
[Image Credit https://goo.gl/vCy291]

JavaScriptのクロール用に特別なUAは存在しない

GoogleのJohn Mueller(ジョン・ミューラー)氏に、フォロワーがTwitterで次のように質問しました。

JavaScriptやAjaxを多用したサイトに対しては、普通のGooglebotとは異なるGooglebotがいるんですか?

ミューラー氏はこのように返信します。

特別なUAはない。だが、クロールの直後にいつもレンダリングするとは限らない。それでたぶん、そういうふうに考えたのではないだろうか?

JavaScript/Ajaxをたくさん使ったサイトを質問したユーザーは運用しているらしく、インデックスへの反映が遅いため、JavaScript専用のクローラがいるのではないかと疑ったようです。

しかし、JavaScriptであろうが通常のGooglebotがクロールします。

JSコンテンツのインデックスへの反映が遅い(遅く見える)理由

その後のやり取りを見ていると、JavaScript/Ajaxコンテンツのインデックスへの反映が遅いと質問者が感じた理由は、主に次の2つの要因によると思われます。

  • JavaScriptの実行は別プロセス
  • キャッシュはインデックスとは異なる

JavaScriptの実行は別プロセス

ミューラー氏が触れているように、JavaScriptはクロールと同時に実行されるわけではありません。
そのページのHTMLのクロールと、そのページにあるJavaScriptの実行は別々に処理されます。
JavaScriptも含めてレンダリングした、そのページの最終的なコンテンツのインデックスができあがるまでには時間がかかることもあります。

以前に詳しく解説しました。

キャッシュはインデックスとは異なる

質問者は、Googleのキャッシュを見てインデックス状態を判断していた可能性があります。
キャッシュを見た場合、そのページのJavaScriptを処理するのはGooglebotではなくあなたが今使っているブラウザです。
レンダリングが完了してGooglebotが実際に見ているページをキャッシュでは確認することはできません。

Googlebotがそのページをどのように見ているかを正確に知るには、Fetch as Googleのレンダリングを使います。

こちらも以前に詳しく解説しました。

ということで、この記事で伝えたかったことをまとめると、

  • JavaScriptのクロールのために特別なGooglebotは存在しない
  • JavaScriptのクロールとその処理は同時とは限らないため、インデックスへの反映にタイムラグが生じることがある

となります。

- JavaScriptのクロール用に特別なユーザーエージェントをGoogleは持っていない、JSの処理はクロールとは別 -

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

Kenichi Suzuki

Googleの検索結果に直接投稿する機能のテスト参加が拡大、ブラジルとインドにも展開予定

9 years 7ヶ月 ago

[レベル: 上級]

メッセージや画像、動画をあたかもソーシャルメディアであるかのように検索結果に直接投稿する機能をGoogleは試験的に公開しています。
この機能を、より多くのスモールビジネスに提供する予定とのことです。
また利用できるのは米国だけだったのが、ブラジルとインドにも展開していきます。

検索結果に投稿するとは?

TwitterやFacebookに投稿するように、メッセージや画像、動画を投稿してGoogleの検索結果にそのまま表示させることができます。
もともとは今年の3月に、米国の大統領選挙の候補者のために提供された機能です。

こちらは、ヒラリー・クリントン (Hillary Clinton) 氏の投稿が差し込まれている検索結果です。
Hillary ClintonのGoogle Posts

TwitterやFacebook、Google+での投稿ではありません。

ヒラリーさんの名前の下には”on Google”というラベルが記載されています。
どこかのソーシャルメディアではなく、「Googleに」投稿したということを示したいのでしょう。

検索結果に直接投稿する機能はその後、限られた数の中小規模のローカルビジネスに対しても試験的に提供が始まりました。

もう少し詳しいことはWeb担当者Forumの連載コラムで説明したので、そちらを参照してください。

より多くのローカルビジネスに開放、ブラジルとインドにも展開

ローカルSEOのエキスパートである、Mike Blumenthal(マイク・ブルーメンソール)氏によると、検索結果に投稿する機能(「Google Posts」などと呼ばれることがあるが、正式な名称をGoogleは公表していない)をさらに数十のローカルビジネスが利用できるようにGoogleは予定しているとのことです。

こちらは新たに試験運用に参加したと思われる、My Special Dayというウェディングドレスのブティックの投稿です。

My Special Dayの検索結果投稿

ショップ名の下には、ヒラリーさんと同じように”on Google”のラベルが付いていますね。

投稿をタップ/クリックすると、その投稿が拡大表示されます。

My Special Dayの検索結果投稿

また米国だけで提供していた機能ですが、ブラジルとインドにも展開するとのことです。

Googleが新しい機能を試験的に公開する場合は、たいてい大手企業のサイトが相手になります。
しかしこの機能に関しては、スモールビジネスが選ばれています。
珍しいことです。

大規模なビジネスであればFacebookやTwitterなどのソーシャルメディアを効果的にすでに利用できているはずです。
いっぽうで小さなお店では、ソーシャル運用まで手が回らないことも多いでしょう。
そういった小規模ビジネスに露出チャンスを与えたいというのがGoogleの狙いなのかもしれませんね。

そして、米国の次がなぜブラジルとインドなんでしょうね。
ソーシャルメディアがさほど普及していないから?
この機能は回線速度が遅くても利用しやすかったりするから?

実験のまま終了するか、このまま日本にも展開してくるかはまったくわかりません。
それでも「おもしろそう」と興味を持ったなら、ウェイティングリストに登録しておくといいでしょう。

- Googleの検索結果に直接投稿する機能のテスト参加が拡大、ブラジルとインドにも展開予定 -

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

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

人気記事トップ10

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

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