投稿者: Google Webmaster Central

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

このような表示はユーザーにとって非常に紛らわしく、Google のガイドラインにも反します。そのため、ガイドライン（英語）に修正を加え、より明確にしましたのでご確認ください。

問題となっているのは、以下のような場合です。

クーポンなどを表示する場所に「イベント」マークアップを使用して、特典について記述しているサイトをよく見かけます。割引クーポンはユーザーにとって特別なものではありますが、やはりそれを「イベント」としてアピールするべきではありません。イベント マークアップ（英語）を使用してイベント以外の情報を記述すると、実際には何のイベントも開催されないにもかかわらず、時間になると何かが始まるかのようにリッチ検索結果が表示されるため、ユーザーのエクスペリエンスは確実に低下します。

どのようなサイトが問題なのか、いくつか例を見てみましょう。

このようなサイトは、ユーザーに誤解を与えるおそれがあるということで、手動による対策の対象となることがあります。その場合は、Search Console アカウントに通知が届きます。手動による対策の対象になった場合、サイト全体の構造化データ マークアップが検索結果に反映されなくなることもあります。

このブログ記事では特にクーポンを取り上げましたが、これ以外にもイベントと無関係な情報を「イベント」としてマークアップすると、このガイドラインが適用されます。つまり、マークアップをタイプの異なる情報に使用すると、手動による対策の対象になるおそれがあるということです。十分にご注意ください。

詳しくは、デベロッパー向けドキュメント（英語）をご覧ください。ご不明な点がありましたら、ウェブマスター ヘルプ フォーラムでご質問ください。

レスポンシブ ウェブ デザインを導入するサイトが増えるにつれて、ウェブマスターの方々の間で、モバイル用に別途設定する URL（英語）からレスポンシブ ウェブ デザインの利用に移行することへの関心が高まっています。ここでは、あなたのサイトが Google の検索結果でよいパフォーマンスが出せるよう、別々の URL から 1 つのレスポンシブ URL へ移行する際のおすすめの方法をいくつかご紹介します。

Googlebot にわかりやすい形でレスポンシブ サイトに移行する

レスポンシブ サイトの準備ができたら、移行時に考慮するべきポイントはひとつです。サイトの URL はデスクトップ向けバージョンでは変わらないので、必要な作業は、モバイル用の URL からレスポンシブ ウェブ デザインの URL への 301 リダイレクトを設定することだけです。

詳しい手順は次のとおりです。

1. レスポンシブ サイトの準備をします。
   
2. これまでお使いのモバイル用 URL からレスポンシブ バージョン（新しいページ）への 301 リダイレクトを設定します。このリダイレクトは、URL ごとに（モバイル用の各 URL からレスポンシブ URL に対して個々に）行う必要があります。

3. 条件付きのリダイレクトや Vary HTTP ヘッダーなど、モバイル用 URL 固有の設定をサイトで利用していた場合は、すべて削除します。
4. レスポンシブ URL については、rel=canonical を設定してその URL 自体を指すようにすること（自己参照型の正規 URL）をおすすめします。

現在、動的な配信を利用している場合は、レスポンシブ デザインへの移行にあたって、リダイレクトの追加や変更を行う必要はありません。

レスポンシブ ウェブ デザインに移行するメリット

レスポンシブ サイトに移行すると、今後のメンテナンスやレポート作成が簡単になります。すべてのページについて別々の URL を管理する必要がなくなるだけでなく、さまざまな手段や技術（国際化のための hreflang、高速化を実現する AMP、検索機能の向上に役立つ構造化データなど）も取り入れやすくなります。

ご不明な点などがありましたら、ウェブマスター ヘルプ フォーラムをご利用ください。

2017 年 8 月 25 日、Google 東京オフィスにおいて、Google の検索チームとウェブマスターやサイト運営に関わるみなさんを結ぶイベント、Google Dance Tokyo 2017 を開催しました。

Google Dance Tokyo は、米国 Google 本社で開催されている、検索などオンライン マーケティングの担当者を対象としたソーシャル イベントである Google Dance の日本版です。昨年行った第一回が大変好評でしたので、今年も開催する運びとなりました。

昨年同様、イベントには当ブログでのオープンな告知からご応募いただいた方々や、 Advanced Hosting Meetup の参加者、ウェブマスター ヘルプ フォーラムのトップ レベル ユーザーや注目ユーザーの皆さんをご招待し、約 100 名の方々にご参加いただきました。

イベントはセッション タイムとソーシャル タイムの二部構成で行いました。セッション タイムでは製品開発本部長の徳生裕人が AI First の観点からアシスタントなどの最新情報をご紹介した後、Ninja Spamologist の長山一石が「Webmastering 101」と題して初心者ウェブマスターが知っておくべき検索エンジンとウェブ、そして SEO に関わる知識をご紹介しました。また、Live Q&A では、金谷武明と小川安奈が司会を務め、Gary Illyes （Webmaster Trends Analyst）、大倉務（Software Engineer）、徳生、長山が参加し、Mobile First Indexing や AI First などに関して活発な質疑応答が行われました。

Q&A で回答しきれなかったご質問は、後日実施したウェブマスター オフィスアワーで回答いたしましたので、ぜひご覧ください。

ソーシャル タイムでは会場を拡大し、Gary の乾杯音頭の後、Google の検索チームと参加者のみなさんとで軽食をつまみながら交流を深めました。同時に開催した参加者によるライトニング トークは大変盛り上がり、特に、「役に立たない検索結果の探し方（バカ毛）」、「私の考えるこれからの SEO （サイバーエージェント 木村 賢）」、「Twitter 廃人による Twitter 活用術（ちょまど）」（すべて敬称略）などのセッションが好評を博し、笑いと関心を誘っていました。

その他、当日の会場の様子に関しては、ハッシュタグ #GoogleDanceTokyo を作成しましたので、ぜひ Twitter をご覧ください。

みなさんから様々なご意見やご質問、コメントを直接いただき、Google の検索チームとしても、非常に有意義なイベントとなりました。頂いたフィードバックはできるだけ検索エンジンの開発に役立てていきたく思います。

お越しいただいた皆さん、ありがとうございました！また、当日お越しいただけなかった方々も、どこかのイベントでお会いできることを楽しみにしております。

たとえば、カップケーキを作りたいとしましょう。どんなカップケーキを作るか迷ったときは、画像検索でいろいろな写真を見ると良いアイデアが浮かぶかもしれません。ただし、画像検索からレシピを見つけるのはなかなか大変です。おいしそうな写真をクリックしてみたら、ケーキ屋さんのメニューが表示されるかもしれませんし、お気に入りのカップケーキを集めただけでレシピは載せていないサイトにたどり着くかもしれません。

このたび Google では、ユーザーが必要な情報を簡単に見つけられるようにするため、モバイル端末で画像検索を実行したときのサムネイルにバッジ（英語）が表示されるようになりました。現時点では、レシピ、動画、商品、アニメーション画像（GIF）のバッジを用意しています。

サイトに画像を掲載している場合は、ウェブページで適切な構造化データを使用することで、その画像がどのような内容なのかユーザーが簡単に把握できるようになります。これにより、ユーザーが必要としているコンテンツを簡単に見つけられるようになるだけでなく、ターゲットとしているユーザーがサイトにアクセスする可能性も高くなります。

サイトでレシピを公開しているなら、ページにレシピ マークアップ（英語）を追加します。商品を販売しているなら商品マークアップ（英語）、動画を公開しているなら動画マークアップ（英語）です。GIF の場合はマークアップ不要で、アルゴリズムによって自動的にバッジが追加されます。画像検索の画像に必ずバッジが表示されるとは限りませんが、必須のフィールドに加えて推奨の構造化データ フィールドを追加することで、その可能性が高まります。

なお、ページにエラーがあると画像検索バッジは表示されませんのでご注意ください。ページのエラーは、構造化データ テストツールでチェックできます。マークアップに関する統計情報は、Search Console のリッチカード レポートで確認できます。

この機能についてご不明な点などありましたら、ウェブマスター ヘルプ フォーラムでお気軽にご質問ください。

Google は 1 月に、Chrome で HTTP ページの接続セキュリティが通知される方法の改善に着手しました。Chrome では現在、パスワード フィールドまたはクレジット カード フィールドがある HTTP ページを「Not secure」とマークしています。2017 年 10 月からは、新たに 2 つの状況（ユーザーが HTTP ページにデータを入力した場合と、HTTP ページにシークレット モードでアクセスした場合）において「Not secure」の警告が表示されるようになります。

HTTP サイトを安全でないと明示するという Google の計画は、段階的により幅広い基準に基づいて進められる予定です。Chrome 56 での変更以来、PC からパスワード フォームまたはクレジット カード フォームがある HTTP ページにアクセスする割合は 23% 減少しました。今後は、さらに対策を講じていきます。

秘密にする必要のあるデータは、パスワードとクレジット カードの情報だけではありません。ユーザーがウェブサイトに入力するあらゆる種類のデータに対して、ネットワーク上のその他のユーザーがアクセスできないようにする必要があります。そのため、Chrome バージョン 62 以降では、ユーザーが HTTP サイトにデータを入力すると、「Not secure」警告が表示されます。

ユーザーが Chrome のシークレット モードで HTTP ページを閲覧する場合、プライバシーが確保されていると考えられるかも知れませんが、HTTP ページの閲覧は、ネットワーク上の他のユーザーに対して非公開になっているわけではありません。そのため、Chrome バージョン 62 では、シークレット モードで HTTP ページにアクセスする場合も警告が表示されます。

最終的には、シークレット モードではないときも、すべての HTTP ページに対して「Not secure」警告を表示する予定です。今後のリリースが近づいた際にアップデートを公開しますが、HTTPS への移行はできる限り早く進めてください。HTTPS は今までになく簡単かつ安価に導入できるようになっており、HTTP では実現できない最高のパフォーマンスや強力な新機能を提供します。導入にあたっては、Google のセットアップ ガイドをご確認ください。

最近、サイトに投稿された記事にスパムリンクが含まれているケースが増えています。投稿者からの投稿、ゲストやパートナーによる投稿、シンジケーション提供された投稿などの形で、あるウェブサイトの名前で書かれた記事が別のウェブサイトに掲載されるケースが一般的です。

こうした投稿記事が好ましくないというわけではありません。他のサイトのユーザーに情報を提供したり、ご自身の活動や企業への認知度を高めたりするうえで効果的な方法の 1 つと言えます。ただし、投稿元のサイトへのバックリンクを大量に獲得することを意図している場合は、リンク プログラムに関するウェブマスター向けガイドラインに違反します。極端な例ですが、問題となるのは以下のような場合です。

• 大量のキーワードを含んだリンクが、記事の中で乱用されている
• 記事が大量のサイトに公開されている、または少数の大規模サイトに大量の記事が公開されている
• 対象分野の知識が乏しい人に記事を書かせている
• 複数の記事で同じかよく似たコンテンツを使用している、またはサイトに掲載されている記事の内容を完全に複製している（このような場合は、rel=”nofollow” に加えて rel=”canonical” を使用することを推奨しています）

スパムリンクが設定された記事を公開しているサイトが見つかった場合、Google はそのサイトの品質に対する認識を改め、その認識を掲載順位に反映します。サイトへの投稿を許可し、記事として公開している場合は、寄せられた投稿をしっかり吟味する必要があります。その投稿者は知り合いか、投稿の内容がサイトのユーザー層に合っているか、役に立つ内容が含まれているかなどを確認してください。記事内に疑わしいリンクがある場合は、投稿者が rel=”nofollow” を使用しているかどうかを確認するとよいでしょう。

リンク獲得を目的として記事を作成しているウェブサイトについては、ウェブ全体への悪影響を防ぐためにも厳正に対処します。リンク獲得を最優先にすれば、記事の品質は二の次になり、ユーザー エクスペリエンスが低下することは目に見えています。こうしたサイトから記事掲載リクエストがしつこく繰り返し届く場合は、スパム報告フォームから報告してください。最後に、ユーザーからの支持のほとんどはサイト管理者自身が築いていくものであり、リンクはその一形態にすぎません。スパムリンクをなくすことが、サイトの印象を改善する最適な方法ではないでしょうか。リンク獲得に関してアドバイスするとすれば、サイトのコンテンツをより魅力的にすることが最も効果的です。リンクを含め、他のものはみな後からついてきます。

2017 年に入って早くも数か月が過ぎましたが、ここで 2016 年のウェブスパム対策を通じて得た気づきをお伝えしてみたいと思います。Google は昨年も、スパムによって検索の品質が低下しないよう新たな方法を探し続けるとともに、世界中のウェブマスターと協力してウェブのさらなる改善に努めてきました。

世界中のすべての人に適切な検索結果を提供する、という使命を果たすためには、ユーザーにとって有害な（または単純に不快な）ウェブスパムとの戦いを放棄するわけにはいきません。ユーザーの皆さんがウェブを最大限活用できるようにするための Google のさまざまな取り組みをご紹介します。

2016 年のウェブスパムの傾向

• ウェブサイトのセキュリティは、かねてから私たちを悩ませてきた大きな問題の 1 つです。昨年ハッキングされたサイト数は過去最多を記録し、2015 年に比べ 32% も増加しました。そのため Google では、サイトがハッキングされたときに何をすべきかがすぐにわかるよう、ウェブマスター向けの資料（英語）の拡充に努めています。
• サイトに不正アクセスする目的は、ウェブスパムをホストすることだけではありません。多くのウェブマスターが、ソーシャル エンジニアリング、望ましくないソフトウェア、望ましくない広告の埋め込みなどの被害に遭っています。Google では、セーフ ブラウジング機能をさらに強化し、不正なダウンロード ボタンや繰り返し危険と判定されるサイト（英語）からユーザーを保護しています。また、Search Console の [セキュリティの問題] に関するレポートに、より詳細なヘルプ記事（英語）も追加しました。
• Google 検索をモバイル端末で実行する人が増えており、モバイル ユーザーをターゲットとしたスパムも急増しています。特に増えているのが、ページに挿入したウィジェットや広告ネットワークの広告ユニットを使って、ウェブマスターに気付かれないようにユーザーを他のサイトやページにリダイレクトするスパムです。

2016 年の Google のウェブスパム対策

• Google では、ウェブスパムに対処するためアルゴリズムを継続的に改良しています。サイトの掲載順位についても、中核的なアルゴリズムの 1 つである Penguin をリアルタイム化するなど、複数の改良を施しました。
• アルゴリズムで検出されなかったスパムには手動による対策を実施しています。サイトのウェブスパムに関する問題をウェブマスターに通知するため、これまでに 900 万通のメッセージを送信しました。また、Google アナリティクス経由でのセキュリティ通知も開始しました。
• Google は、アルゴリズムと手動でウェブサイトの品質をチェックし、サイトの構造化データ マークアップ（英語）が品質基準を満たしているかどうかを確認しています。手動による対策は、構造化データを利用した検索に含めるための品質ガイドライン（英語）を満たしていなかった 10,000 以上のサイトを対象に実施しました。

より快適なウェブの実現に向けたユーザーやウェブマスターとの連携

• 2016 年に世界中のユーザーから寄せられたスパムレポートは 180,000 件を数えます。これらの妥当性を慎重に確認した結果、報告されたサイトの 52% がスパムと判定されました。よりクリーンで安全なウェブ エコシステムの実現にご協力いただきありがとうございます。
• 世界中で 170 回以上のウェブマスター オフィスアワーやライブイベントを開催し、150,000 人以上のウェブサイト所有者、ウェブマスター、デジタル マーケティング担当者と交流する機会を持つことができました。
• ウェブマスター ヘルプ フォーラムを 15 言語で運営し、世界中のウェブサイト所有者を継続的にサポートしています。これらのフォーラムには 67,000 件以上の質問が寄せられ、その大部分において、トップレベル ユーザー、注目ユーザー、Google 社員のコミュニティから「ベストアンサー」が得られたと評価されています。
• ウェブマスター ヘルプ フォーラムでは、119 人のトップレベル ユーザーと注目ユーザーがボランティアで活躍してくれています。Google では、4 つの大陸（アジア、欧州、北米、南米）の 11 都市でトップレベル ユーザー ミートアップを開催しました。
• 日本では、11 のブログサービスを中心としたホスティングサービスの方々と連携し、共同でスパム対策を実施しました。こちらの取り組みは 2017 年も続けていきます。

より品質の高い検索結果のために、今年も Google はスパム対策に取り組んでまいります。

画像検索で「似ている商品」というサービスを、モバイルウェブと Android 版検索アプリで開始しました。「似ている商品」は、ユーザーが写真の中で気になった商品を Google 画像検索で見つけやすくする機能です。この機能は画像認識技術を使用しており、日常生活で目にする画像の中で商品を識別し、類似する商品をユーザーに表示します。「似ている商品」が現在サポートしているのはハンドバッグ、サングラス、靴ですが、今後数か月以内に衣料品やホーム＆ガーデンといった他のカテゴリにも対応する予定です。

この機能は、ユーザーが目に留まったファッションの写真をブラウジングしてショッピングしたり、興味がある商品の情報を見つけたりするのに役立ちます。「ブランド ハンドバッグ」のようなクエリで検索結果を開くと、実際の機能をお試しいただけます。

画像検索の機能に対するユーザーからのリクエストで多かったもののひとつは「価格や在庫状況を見つけやすいこと」でした。 「似ている商品」のカルーセル表示では、毎日世界中で何百万というインプレッションとクリックが発生しています。

サイトで扱っている商品を「似ている商品」に対応させるには、schema.org の商品メタデータをページに追加して管理します。schema.org の商品マークアップを使用すると、Google がウェブ上で商品を見つけられるようになり、商品情報の概要をユーザーに表示できるようになります。

サイトの商品を「似ている商品」の表示対象にするには、以下の操作を行ってください。

• ページに掲載している商品に、schema.org の商品マークアップ（画像参照を含む）を追加します。ホストページで商品の名前、画像、価格と通貨、在庫の各メタデータを記述すると、「似ている商品」の表示対象となります。
• Google の構造化データ テストツールでページをテストして、商品マークアップの形式が正しいことを確認します。
• 画像検索で「site:<ドメイン名>.com」というクエリを入力し、商品の画像を確認します。検索結果にマークアップが正しく適用されている場合は、サイトの商品画像をタップすると商品情報が表示されます。なお、Googlebot がウェブサイトを再クロールするまでに 1 週間程度かかることがあります。

ご不明な点がありましたら、ウェブマスター ヘルプ フォーラムまでお寄せください。商品の画像が「似ている商品」に表示されないようにしたい場合は、Google 画像検索からオプトアウトすることができます。

購入可能な商品をショーケースのようにして紹介することで、皆さんのサイトの商品がユーザーにとって見つけやすくなれば幸いです。さらに手軽なオンライン ショッピングを実現するために、今後ともご協力をお願い申し上げます。

注 : この投稿は、Google のウェブ検索に固有のものです。Google の他のサービスについては、適切なヘルプセンター（Google ショッピングなど）またはヘルプ フォーラムに問い合わせてください。

今や「年中無休」が当たり前となっている世の中ですが、オンラインサービスでは、サイトを一時的に停止しなければならない場合もあります。今回は、検索結果の掲載順位に影響を及ぼすことなく、サイト（またはその一部機能）を一時停止する方法をご紹介します。

方法 1: カート機能をブロックする

ユーザーによる購入のみを停止したい場合は、その特定の機能だけを無効にする方法が一番簡単です。ほとんどの場合、ショッピング カート ページのクロールかインデックス登録のどちらかをブロックすることで対応できます。クロールは robots.txt ファイルで、インデックス登録は robots メタタグでブロックできます。検索エンジンによるコンテンツの検出またはインデックス登録が停止するため、それを適切な方法でユーザーに伝える必要があります。たとえばカートへのリンクを無効にする、適切なメッセージを表示する、カートの代わりに情報ページを表示するなどの方法があります。

方法 2: インタースティシャルやポップアップを常に表示する

ユーザーがサイト全体にアクセスできないようにする場合は、サイトが一時的に利用できないことを示すメッセージ、情報ページ、またはポップアップを表示し、サーバーから 503 HTTP ステータス コード（「サービスはご利用いただけません」）を返します。503 ステータス コードを返すことで、ユーザーに表示する一時的なコンテンツが Google にインデックス登録されるのを防ぐことができます。503 ステータス コードを返さないと、インタースティシャルなどがウェブサイトのコンテンツとしてインデックス登録されてしまうことがありますのでご注意ください。

Googlebot は 503 を返すページに対して、最長で 1 週間ほどクロールを再試行します。その期間を過ぎても 503 を返すページはパーマネント エラーとして扱われ、検索結果から除外されます。Retry-After ヘッダーを追加すると、サイトが利用できない期間を示すことができます。ただしサイトのブロックが 1 週間を超えると、サイトを停止している方法に関わらず、サイトの検索結果に悪影響が及ぶ可能性があります。

方法 3: ウェブサイト全体をオフにする

サーバーを完全にオフにするという方法もあります。サーバーを別のデータセンターに物理的に移動する場合などはこの方法がよいでしょう。この方法を使用する場合は、一時的なサーバーを用意してユーザー向けの情報ページを表示し、すべての URL で503 HTTP ステータス コードを返します。その期間中は DNS を切り替えて、この一時的なサーバーを経由するようにします。

1. 切り替えの数日前に、DNS TTL の時間を短く（5 分など）設定しておきます。
2. DNS を一時的なサーバーの IP アドレスに変更します。
3. リクエストが一時的なサーバーに送信されるようになったら、メインサーバーをオフラインにします。
4. ... サーバーがオフラインになりました ...
5. 戻す準備ができたら、メインサーバーを再びオンラインにします。
6. DNS をメインサーバーの IP アドレスに戻します。
7. DNS TTL を通常の設定に戻します。

これらの方法が、ウェブサイトを一時停止するときにお役に立てば幸いです。ご不明な点などありましたら、ウェブマスター ヘルプフォーラムでお気軽にご質問ください。

なお、地域密着型のビジネスを展開されている方は、ローカル リスティングの営業時間にビジネスの停止期間を設定することも忘れないでくださいね。