テクニカルSEO情報

テクニカルSEO情報

割引クーポンをイベント構造化データにして露出アップ!? それガイドライン違反です
手動対策を受けることもあるので厳禁 （グーグル ウェブマスター向け公式ブログ） 国内情報

「イベント」構造化データの利用に関するガイドライン違反について、グーグルは公式ブログで通達した。

具体的には、イベントと関係のない情報たとえば、割引クーポンをイベントとしてマークアップすることを明確に禁止したのだ。

クーポン配布は構造化データが本来対象にしているイベントではない。そのため、イベント用のマークアップを使うのは明らかにおかしい。

しかし実際に、クーポンのような特典をイベントとしてマークアップし、検索結果にリッチスニペットを表示させているサイトが存在するらしい。

この情報を記載する公式ブログの書き出しは、次のようなものだ。

最近ユーザーから、検索結果の「イベント」スニペットが表示されるべき場所に、イベントと関係のない情報（たとえばクーポン情報）が表示されるとの報告が寄せられています。

ここからわかるように、実際に検索ユーザーからクレームが寄せられているようだ。そのためか、違反した場合には手動の対策が与えられることもあるということだ。

大事なのは、「クーポンをイベントとしてマークアップする」ことが問題ではない点だ。構造化データというセマンティックな世界を実現するための仕組みを悪用すること、そして検索ユーザーにまぎらわしい表示になることが問題なのだ。

クーポン以外でも、イベントと無関係な情報を「イベント」としてマークアップすると、ガイドライン違反に問われる。イベントの構造化データを利用しているなら、公式記事を丁寧に読んでおくように。

Fetch as Googleの乱用にグーグルは慎重になっている？
必要なときだけに使いたい （John Mueller on Twitter） 海外情報

グーグルのジョン・ミューラー氏にツイッターでフォロワーが次のような質問を尋ねた。

Fetch as GoogleのURLインデックス送信が実際に処理されるのにかかる時間は、URLによって異なってきますか？

たとえば仮にCNNのトップページと薄っぺらいコンテンツのページのURLを送信したとしたら、CNNのインデックスのほうが優先されるでしょうか？

ミューラー氏は次のように返信した。

インデックスは保証されない。

このツールを使ったとしても、すぐインデックスされるときもあれば、時間がかかるときもある。

このツールは乱用が多いため、われわれは慎重になっているんだ。

Fetch as Googleを実行すると、URLをインデックスに登録するために、Googlebotにクロールをリクエストできるボタンが現れる。

Search ConsoleでFetch as Googleをすると出てくるインデックス登録のリクエストボタン

しかし、このボタンを使ったからといって必ずクロールしてインデックスされるわけではない。あくまでもグーグルへの「リクエスト（依頼）」であることは、どのサイトでも同じだろう。

そして、ミューラー氏が「乱用が多い」とわざわざ発言している点にも注意したい。

「このボタンを使うと優先してクロールしてもらえるかも」と、むやみやたらに使いまくるウェブマスターが多すぎると、どうなるだろうか。もしかしたら、ツール経由のクロールリクエストが軽視されるようになったり、場合によっては無視されるようになったりすることもあるかもしれない。本当に必要な状況だけで使うようしたほうがいいのではないかと、筆者は思う。

大量のURLのクロールを促進したい場合にはサイトマップを使えばいいのだから。

HTTPS移行後はSearch ConsoleのURLパラメータ機能を設定すること
面倒だが仕方ない （John Mueller on Twitter） 海外情報

HTTPS移行で注意すべき点がある。

アクセス解析などの目的で独自のURLパラメータをサイトで使っているならば、どのパラメータがページ内容に影響を与えるのか・与えないのかを、Search Consoleの「URLパラメータ」機能で指定していることだろう。

HTTPSに移行したら、HTTPSのサイトをSearch Consoleを新規登録しなければいけないのだが、新しいサイトの登録でもURLパラメータをちゃんと設定しておく必要があるのだ。

HTTPとHTTPSでは同じサイトであっても別プロパティになるので管理は別だ。面倒だが、いたしかたない。

念のために解説しておくが、ほとんどの場合、グーグルは一般的なURLパラメータをうまく判別して処理してくれるはずだ。Search Consoleの画面にも警告があるように、この機能を使うのは、サイトの動作を正しく理解している場合だけにしておくのがいいだろう。

構造化データを実装するならサイト内の全ページにマークアップしなきゃダメ？
特定のページだけでも問題なし （John Mueller on Twitter） 海外情報

構造化データをサイトのHTMLに実装する場合は、特定のページだけでマークアップしても、何も問題はない。「すべてのページに実装しなければ」なんて思う必要ない。

家電のECサイトなら冷蔵庫カテゴリの製品にだけ商品の構造化データをマークアップして問題ないし、レシピサイトなら豚肉カテゴリの料理にだけレシピの構造化データをマークアップしてもいい。

構造化データを実装する際は、サイト内の全ページにマークアップしなければならないと認識しているサイト管理者がいるようだ（実際に筆者の身近にもいた）。

しかし、必要に応じて任意のページでマークアップするだけでもいい。「あるカテゴリは構造化データを実装し、あるカテゴリは実装しない」という形で、リッチスニペットの有無によるクリック率のA/Bテストを実行することもできる。

ただし、ブラウザで表示されないコンテンツ（ユーザーには見えないコンテンツ）を構造化データでマークアップすることは、ガイドラインでは原則として許可されていないので注意してほしい。

インデックス数、Search Consoleの「インデックス ステータス」と「サイトマップ」の違いは何？
site: は不正確 （Webmaster Central Help Forum） 海外情報

Search Consoleには、インデックス数を知るためのレポートが2つある。

• ［Googleインデックス］＞［インデックス ステータス］の「インデックスに登録されたページの総数」
• ［クロール］＞［サイトマップ］の「インデックスに登録済み」数

両者の違いをご存知だろうか？

インデックス ステータスの「インデックスに登録されたページの総数」は、Googlebotが発見したURLがすべて対象としている。

それに対してサイトマップの「インデックスに登録済み」数は、サイトマップファイルで送信したURLだけが対象だ。

つまり、インデックス ステータスのほうでは、サイトマップはもちろん、リンクやテキストで書かれたURLなどなど、その他の手段でGooglebotが発見したURLが含まれている。

自分が把握しているサイト内コンテンツのどれぐらいがインデックスされているのかを正確に把握したいのであれば、サイトマップのほうのレポートを参照するのがいいだろう。

なお、グーグル検索で「site:」コマンドを使って検索してもインデックス数を調べることができる。

しかし、インデックス数の調査という目的ではほとんど役に立たないと思っておくほうがいい。それどころか、ざっくりした目安としてでも信頼しないほうがいい。

site:検索が役に立つのは、単独のURLがインデックスされているかどうかを調べるときだけだ。

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

ヤフー検索のAMP対応とグーグルの求人検索に関するトピックを今週はピックアップ。

• 日本のYahooがついにAMPを正式サポートか？

  AMPの検索トラフィックが増えるサイトも出てくるはず

  ★★★★☆

  • すべてのWeb担当者は一応知っておく
  • AMPがんばってる人用
• 求人検索のGoogle for Jobsが給与情報と勤務地情報を提供するように

  今のところは米国のみのサービス

  ★★☆☆☆

  • 求人サイトのWeb担当者 必見か？
  • SEOがんばってる人用（ふつうの人は気にしなくていい）