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

[レベル: 初級]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[レベル: 中級]

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

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

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

[レベル: 上級]

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

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

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

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

[レベル: 初級]

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

診断ツールは出さない

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

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

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

質問の意図

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

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

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

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

※強調は僕による

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

「妥当な大きさ」……。

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

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

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

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

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

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

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

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

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

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

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

[レベル: 初〜中級]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

インタースティシャルを表示するモバイルページの評価を下げるアルゴリズムを導入することを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

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

[レベル: 中級]

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