#NoHacked キャンペーンを開始して 3 週間経ちました。今回は、サイトを安全に保つために役立つリソースをいくつかご紹介します。
#NoHacked 3.0 はこれで終了しますが、さらにコンテンツを用意して近いうちにまた開催する予定です。それまでの間、ご不明な点がありましたら、ウェブマスター ヘルプ フォーラムにご投稿ください。また、サイトへの不正アクセスに関してフィードバックやご質問があった場合もぜひ、ウェブマスター ヘルプ フォーラムまでお寄せください。Google 社員やセキュリティに詳しいユーザーからアドバイスを得られると思います。
この投稿で #NoHacked キャンペーンは終了します。このキャンペーンを通じてコンテンツをお楽しみいただき、ハッカーの攻撃を防いでサイトの安全を確保していただければ幸いです。
これまで #NoHacked では、ハッキングの検出と防止に関するヒントをご紹介してきました。ハッキング攻撃を検出できるようになったところで、今度は、一般的なハッキング手法とその修正方法をご紹介いたします。
最後に、サイトをクリーンアップして問題を修正したら、Google チームがサイトを審査できるように、再審査リクエストを送信してください。
ご不明な点などありましたら、ウェブマスター ヘルプ フォーラムでお気軽にご投稿ください。それでは、また来週お会いしましょう。
#NoHacked（英語） では先週、ハッキングの検出と、サイトがハッキングされる原因について解説しました。今週はハッキングの防止に焦点を当て、ヒントをいくつかご紹介します。
どのような場合でも、サイトのソフトウェアをすべて常に最新の状態にしておくことは、ウェブサイトをハッカーから守るうえで不可欠です。
AJAX クロールに関するスキーム（英語）は、JavaScript ベースのページに Googlebot がアクセスできるようにするための方法として導入されましたが、廃止の予定であることを以前にお知らせいたしました。長期間にわたる Google のエンジニアの取り組みによって、Googlebot による JavaScript のレンダリング能力は大幅に向上してきました。こうした進歩を踏まえて、2018 年の第 2 四半期に、サイト側に JavaScript ベースのページのレンダリングを求めるのではなく、Google 側でレンダリングする形へと移行します。つまり、AJAX クロールに関するスキームは使用されなくなります。
ご存じのとおり、AJAX のクロールに関するスキームでは、URL に「#!」が含まれているページか、「fragment メタタグ（英語）」が設定されているページのいずれかを対象として、URL に「?_escaped_fragment_=」が含まれたページをクロールします。この URL でクロールされるページは、完全にレンダリング済みのページか、それと同等の状態のページ（そのウェブサイト自体で作成されるもの）である必要があります。
今回の変更に伴い、#! が含まれている URL は Googlebot によって直接レンダリングされるようになり、ウェブサイトの所有者はレンダリング済みのページを提供する必要がなくなります。こうした URL のページは Google 検索結果に引き続き表示されます。
ほとんどの AJAX クロールのウェブサイトに対しては今回のアップデートに伴う大きな変化はないものと想定していますが、ウェブマスターの皆様は以下に説明するようにページを再度確認してください。サイトに潜在的な問題が検出された場合は通知が送信されます。
サイトにおいて現在、#! が含まれている URL か fragment メタタグのいずれかをお使いの場合は、以下の手順を行うことをおすすめします。
この変更がウェブサイトの運営と管理をより容易にし、サイト側でページをレンダリングする必要性が軽減することを願っています。ご質問やご意見がございましたら、お気軽にウェブマスター ヘルプ フォーラムか JavaScript サイトのワーキング グループ（英語）までお寄せください。
先週、#NoHacked が Google+ と Twitter に帰ってきました！#NoHacked とは、ハッキング攻撃に対する認識を高め たり、サイトをハッカーから守るためのおすすめの方法をお知らせしたりすることを目的とした、Google のソーシャル キャンペーンです。今回はこのブログで、#NoHacked キャンペーンの内容についてご紹介します。
サイトがハッキングされる原因とは何でしょうか。ハッカーがウェブサイトに不正アクセスする目的はさまざまであり、ハッキング攻撃はそれぞれまったく異なるため、いつも簡単に見つかるとは限りません。ハッキングされたサイトを見つけるのに役立つヒントをいくつかご紹介します。
上記の方法をお試しになってもハッキングの形跡を見つけられない場合は、セキュリティ担当者にお問い合わせいただくか、ウェブマスター ヘルプ フォーラムに投稿していただき、再確認してください。#NoHacked キャンペーンは、今後 3 週間にわたって実施されます。毎週初めにここで 1 週間のまとめを掲載しますので、Google+ や Twitter で Google をフォローしていただくか、このブログの内容をチェックしてください。今後ともよろしくお願いいたします。
最近ユーザーから、検索結果の「イベント」スニペットが表示されるべき場所に、イベントと関係のない情報（たとえばクーポン情報）が表示されるとの報告が寄せられています。
このような表示はユーザーにとって非常に紛らわしく、Google のガイドラインにも反します。そのため、ガイドライン（英語）に修正を加え、より明確にしましたのでご確認ください。
問題となっているのは、以下のような場合です。
クーポンなどを表示する場所に「イベント」マークアップを使用して、特典について記述しているサイトをよく見かけます。割引クーポンはユーザーにとって特別なものではありますが、やはりそれを「イベント」としてアピールするべきではありません。イベント マークアップ（英語）を使用してイベント以外の情報を記述すると、実際には何のイベントも開催されないにもかかわらず、時間になると何かが始まるかのようにリッチ検索結果が表示されるため、ユーザーのエクスペリエンスは確実に低下します。
どのようなサイトが問題なのか、いくつか例を見てみましょう。
このようなサイトは、ユーザーに誤解を与えるおそれがあるということで、手動による対策の対象となることがあります。その場合は、Search Console アカウントに通知が届きます。手動による対策の対象になった場合、サイト全体の構造化データ マークアップが検索結果に反映されなくなることもあります。
このブログ記事では特にクーポンを取り上げましたが、これ以外にもイベントと無関係な情報を「イベント」としてマークアップすると、このガイドラインが適用されます。つまり、マークアップをタイプの異なる情報に使用すると、手動による対策の対象になるおそれがあるということです。十分にご注意ください。
詳しくは、デベロッパー向けドキュメント（英語）をご覧ください。ご不明な点がありましたら、ウェブマスター ヘルプ フォーラムでご質問ください。
AMP 形式の検索結果に関するユーザーの利便性を改善するため、AMP のコンテンツの同一性に関するポリシーの適用方法を変更します。2018 年 2 月 1 日以降、AMP ページのコンテンツを（オリジナルの）正規ページのコンテンツと同等にすることがポリシーによって義務付けられます。AMP はランキング要素ではなく、AMP に関する掲載順位のポリシーに変更はありません。
オープンソースの Accelerated Mobile Pages プロジェクト（AMP）は 2015 年に開始されて（英語）以降急速に成長しており、2,500 万超のドメイン（英語）で AMP 形式が導入されています。AMP を導入することで、最終的にはコンテンツへのエンゲージメントの促進につながる利便性が高まります。この急成長には、コンテンツを利用するユーザーにしっかりとこの利便性を提供し続けるという責任も伴います。
サイトによっては、非 AMP の正規ページと AMP ページという 2 つのバージョンのコンテンツが公開されている場合があります。このような場合、ユーザーが同じコンテンツを利用できるよう、両方のページでコンテンツを同等にしつつ、AMP ページ経由では利用が高速かつスムーズになるようにするのが理想的です。しかしながら、一部のサイトにおいて AMP ページのコンテンツとオリジナル（正規）ページのコンテンツが異なるケースが見られます。
ごく少数ながら、AMP ページがティーザー ページとして使用されている場合があります。そうしたページでは最小限のコンテンツしか含まれていないため、ユーザーの利便性が著しく低下してしまっています。そのような場合、ユーザーは実際のコンテンツにアクセスするためにもう一度クリックしなければなりません。次の画像は、AMP ページではメインの記事のテキストが少しだけ表示され、記事全体を読むにはクリックして別のページにアクセスするよう要求される、といったページの例となります。
AMP は、ウェブのパフォーマンスの大幅な向上と、高速で一貫したコンテンツ利用のエクスペリエンスの提供を目指して導入されました。こうした目標を踏まえて、今後、ページを Google 検索結果に AMP ページとして表示するためには、AMP ページと正規ページのコンテンツを同等にすることを要件として義務付けます。
非 AMP ページに含まれる重要なコンテンツが AMP ページに含まれていない場合、ユーザーには非 AMP ページが表示されます。検索結果での掲載順位には影響しませんが、こうしたページは AMP を必要とする検索機能（AMP のトップニュース カルーセルなど）の対象にはなりません。また、ウェブマスターには Search Console を通じて手動による対策のメッセージで通知され、サイト運営者が問題を修正すると AMP ページが再び配信されるようになります。AMP オープンソース プロジェクトのウェブサイトでは、高速で見やすく、成果の高い AMP ページの作成に役立つガイドを掲載しています。今回の変更によって、正規ページと AMP ページの間でコンテンツ の同一性を保つ流れが促進されることを願っています。コンテンツの同一性を実現することによってサイトの利便性が高まり、最終的にはユーザーの満足度の向上につながるのです。
Google は、世界中の情報を整理するという使命（英語）のもと、検索品質評価ガイドライン（英語）に準拠した質の高いコンテンツをユーザーに届けたいと考えています。ユーザーの役に立つ質の高いコンテンツは、その大部分がプロとして情報提供するサイトによるコンテンツです。このようなサイト運営者様の成功を Google としても後押ししたいのです。
情報提供のエコシステムは、主に広告と定期購読といった収入源によって支えられていますが、定期購読を採用する場合は、検索を有効に活用するうえで微妙なバランス感覚が必要になります。定期購読コンテンツはペイウォール方式を採用するのが通例であるため、定期購読を利用していないユーザーはコンテンツにアクセスできません。ペイウォールの向こう側に良質なコンテンツがあっても、そのことを知らないユーザーは、無料コンテンツを提供する別のサイトに移ってしまう傾向が強いことが評価を行う中で明らかになっています。定期購読コンテンツの有益さがユーザーに認識されていなければ、定期購読を申し込んでもらうことは容易ではありません。実際、定期購読が必要なサイトを敬遠するユーザーが一定数いることが、Google が行った調査の結果からわかっています。したがって、定期購読コンテンツが有益であることをユーザーに知ってもらうために、コンテンツの一部を無料サンプルとして提供することが不可欠なのです。
Google ウェブ検索（英語）とニュース（英語）に適用される First Click Free（FCF）ポリシーは、この問題に対処するために作成されました。FCF は、サイト運営者様には定期購読コンテンツのプロモーションとユーザー獲得の機会を、Google ユーザーには質の高いコンテンツに出会える機会を提供するものです。Google はこの一年にわたり、サイト運営者様にもご協力をいただいて、ユーザーの満足度や情報提供エコシステムの持続可能性といった面から FCF の効果を調査してきました。その結果、FCF そのものは妥当なサンプル提供モデルであるものの、効果的なサンプル提供モデルの選択は、各サイトで独自にご判断いただく方が良いということがわかりました。そこでこのたび、検索に含める要件から FCF を除外し、最新のウェブマスター向けガイドライン（品質に関するガイドライン）に違反しない限りは、無料サンプルをさまざまな方法で提供できるようにすることにしました。この方式を「Flexible Sampling（フレキシブル サンプリング）」と呼ぶことにします。
そもそも FCF の導入に至った理由の 1 つは、クローキングの問題に対処することでした。クローキングとは、ユーザーに配信するコンテンツと Googlebot がクロールするコンテンツを異なるものにする行為です。スパマーがよく使う手は、検索結果の掲載順位を操作する目的で、検索エンジンに対してはその評価が高そうなコンテンツ（たとえば健康に良い料理のレシピ）を表示する一方、ユーザーに対しては別のコンテンツ（たとえばダイエット薬の販売ページ）を表示するという方法です。こうした「おとり」手法は、期待していたのと違うコンテンツを見せられるという不快感をユーザーを与えます。ペイウォール方式を採用するサイトには、ページに新しい構造化データを追加することを強くおすすめしています。この構造化データを追加していないと、ペイウォールがクローキングの一種と解釈され、ページが検索結果から削除される可能性があるためです。
Google では、今回の調査結果に基づいて、フレキシブル サンプリングを実装するためのおすすめの方法（英語）を解説したガイドを作成しました。Google が提案するサンプル提供方法は 2 種類あります。1 つは、ユーザーに一定数の記事を無料で提供し、その後にペイウォールを提示する「メータリング」、もう 1 つは記事を完全には公開せず、一部だけを無料で見せる「リードイン」です。
メータリングについては、1 日単位ではなく 1 か月単位で設定する方が柔軟性が高く、安定した環境でテストできると考えています。たとえば、1 日に 3 件のサンプルを提供するよりも 1 か月に 10 件提供する方が、件数の変更がユーザーに及ぼす影響が小さく、件数を柔軟に調整できるからです。最適な無料サンプル数は、それぞれのサイトやそのユーザー層によって異なりますが、Google では、無料サンプルの数を 1 か月あたり 10 件から始めることを推奨しています。これは、定期購読の可能性があるユーザーに、サイトのコンテンツを十分に体験してもらうためです。まずは 10 件からテストしてみて、コンバージョンを最大化できるサンプル件数を特定することをおすすめします。
リードインの場合は、記事の一部（たとえば冒頭の数文）のみを表示します。これによりユーザーは、定期購読コンテンツの質の高さを体験できます。完全にブロックされているページとの比較で考えれば、リードインの方がコンテンツの有用性や価値を実感しやすいことは明らかです。
今回の変更が、良質なコンテンツを提供するサイト運営者様のさらなる成長を可能にし、ユーザーにより質の高いコンテンツを提供することにつながるものと期待しております。
レスポンシブ ウェブ デザインを導入するサイトが増えるにつれて、ウェブマスターの方々の間で、モバイル用に別途設定する URL（英語）からレスポンシブ ウェブ デザインの利用に移行することへの関心が高まっています。ここでは、あなたのサイトが Google の検索結果でよいパフォーマンスが出せるよう、別々の URL から 1 つのレスポンシブ URL へ移行する際のおすすめの方法をいくつかご紹介します。
レスポンシブ サイトの準備ができたら、移行時に考慮するべきポイントはひとつです。サイトの URL はデスクトップ向けバージョンでは変わらないので、必要な作業は、モバイル用の URL からレスポンシブ ウェブ デザインの URL への 301 リダイレクトを設定することだけです。
詳しい手順は次のとおりです。
現在、動的な配信を利用している場合は、レスポンシブ デザインへの移行にあたって、リダイレクトの追加や変更を行う必要はありません。
レスポンシブ サイトに移行すると、今後のメンテナンスやレポート作成が簡単になります。すべてのページについて別々の 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 つと言えます。ただし、投稿元のサイトへのバックリンクを大量に獲得することを意図している場合は、リンク プログラムに関するウェブマスター向けガイドラインに違反します。極端な例ですが、問題となるのは以下のような場合です。
スパムリンクが設定された記事を公開しているサイトが見つかった場合、Google はそのサイトの品質に対する認識を改め、その認識を掲載順位に反映します。サイトへの投稿を許可し、記事として公開している場合は、寄せられた投稿をしっかり吟味する必要があります。その投稿者は知り合いか、投稿の内容がサイトのユーザー層に合っているか、役に立つ内容が含まれているかなどを確認してください。記事内に疑わしいリンクがある場合は、投稿者が rel=”nofollow” を使用しているかどうかを確認するとよいでしょう。
リンク獲得を目的として記事を作成しているウェブサイトについては、ウェブ全体への悪影響を防ぐためにも厳正に対処します。リンク獲得を最優先にすれば、記事の品質は二の次になり、ユーザー エクスペリエンスが低下することは目に見えています。こうしたサイトから記事掲載リクエストがしつこく繰り返し届く場合は、スパム報告フォームから報告してください。最後に、ユーザーからの支持のほとんどはサイト管理者自身が築いていくものであり、リンクはその一形態にすぎません。スパムリンクをなくすことが、サイトの印象を改善する最適な方法ではないでしょうか。リンク獲得に関してアドバイスするとすれば、サイトのコンテンツをより魅力的にすることが最も効果的です。リンクを含め、他のものはみな後からついてきます。
2017 年に入って早くも数か月が過ぎましたが、ここで 2016 年のウェブスパム対策を通じて得た気づきをお伝えしてみたいと思います。Google は昨年も、スパムによって検索の品質が低下しないよう新たな方法を探し続けるとともに、世界中のウェブマスターと協力してウェブのさらなる改善に努めてきました。
世界中のすべての人に適切な検索結果を提供する、という使命を果たすためには、ユーザーにとって有害な（または単純に不快な）ウェブスパムとの戦いを放棄するわけにはいきません。ユーザーの皆さんがウェブを最大限活用できるようにするための Google のさまざまな取り組みをご紹介します。
より品質の高い検索結果のために、今年も Google はスパム対策に取り組んでまいります。
画像検索で「似ている商品」というサービスを、モバイルウェブと Android 版検索アプリで開始しました。「似ている商品」は、ユーザーが写真の中で気になった商品を Google 画像検索で見つけやすくする機能です。この機能は画像認識技術を使用しており、日常生活で目にする画像の中で商品を識別し、類似する商品をユーザーに表示します。「似ている商品」が現在サポートしているのはハンドバッグ、サングラス、靴ですが、今後数か月以内に衣料品やホーム＆ガーデンといった他のカテゴリにも対応する予定です。
この機能は、ユーザーが目に留まったファッションの写真をブラウジングしてショッピングしたり、興味がある商品の情報を見つけたりするのに役立ちます。「ブランド ハンドバッグ」のようなクエリで検索結果を開くと、実際の機能をお試しいただけます。
画像検索の機能に対するユーザーからのリクエストで多かったもののひとつは「価格や在庫状況を見つけやすいこと」でした。 「似ている商品」のカルーセル表示では、毎日世界中で何百万というインプレッションとクリックが発生しています。
サイトで扱っている商品を「似ている商品」に対応させるには、schema.org の商品メタデータをページに追加して管理します。schema.org の商品マークアップを使用すると、Google がウェブ上で商品を見つけられるようになり、商品情報の概要をユーザーに表示できるようになります。
サイトの商品を「似ている商品」の表示対象にするには、以下の操作を行ってください。
現在、「似ている商品」は全世界のモバイル ブラウザと Android 版 Google 検索アプリでご利用いただけます。2017 年には、さらに多くのプラットフォームに拡大する予定です。
ご不明な点がありましたら、ウェブマスター ヘルプ フォーラムまでお寄せください。商品の画像が「似ている商品」に表示されないようにしたい場合は、Google 画像検索からオプトアウトすることができます。
購入可能な商品をショーケースのようにして紹介することで、皆さんのサイトの商品がユーザーにとって見つけやすくなれば幸いです。さらに手軽なオンライン ショッピングを実現するために、今後ともご協力をお願い申し上げます。
Google セーフ ブラウジング（英語）で提供するツールは、マルウェア、望ましくないソフトウェア、ソーシャル エンジニアリングなどのインターネット上の脅威からユーザー自身を保護する目的でご利用になれます。Google の警告はよく知られているとおり、ユーザーが危険なサイトに移動しようとしたときや、危険なファイルをダウンロードしようとしたときに表示されます。Google は他にも、サイト ステータス ツールのように、ユーザーがウェブページの安全性の現状を、そのページにアクセスしなくても確認できるツールを提供しています。
このツールは Google のセーフ ブラウジングに関する透明性レポート内でご利用になれます。Google の透明性レポートの他のセクションと同様に、このサイト ステータスのデータを提供することで、オンライン エコシステムのセキュリティと健全性に関して、一般ユーザーがよく見通せるようになります。サイト ステータス ツールを使用するには、ツールにウェブページを（URL、ウェブサイト、またはドメインとして）入力します。そのウェブページに関するセーフ ブラウジングの最新の解析結果に加えて、トラブルシューティングのヘルプと関連資料への参照情報が表示されます。
Google はこのたび、サイト ステータス ツールの新バージョンをリリースしました。新しいバージョンでは、結果の表示が簡潔で明確になり、設計が調整されています。この変更により、セーフ ブラウジングの警告を受け取ってからツールにアクセスするユーザーや、Google でのマルウェアやフィッシングの検出についてオンラインで調べようとするユーザーにとってより使いやすいツールになりました。ツールのユーザー インターフェースも整理され、説明はわかりやすく、結果はさらに正確になりました。また、連携している自律システムの詳細な技術的データの一部を、透明性レポートの不正なソフトウェア ダッシュボードに移動しました。
インターフェースこそ整理されましたが、診断情報の詳細が表示されなくなったわけではありません。詳細について調べようとするユーザーは、セーフ ブラウジングの透明性レポートの他のセクションで深く掘り下げることができます。一方、サイト所有者は Search Console で詳細な診断情報について確認することができます。透明性レポートの目標の 1 つは、ポリシーとセキュリティの複合的な問題を明らかにすることであり、今回の設計の調整によって実際に、ユーザーにとって明瞭さが増す結果となることを願っております。
リッチカードが英語の検索結果に表示できるようになったのが 2016 年 5 月。この度、Google がサポートするすべての地域でリッチカードをご利用いただけるようになりましたのでお知らせします。
リッチカードは、ご好評いただいているリッチ スニペットをもとに開発した新しい検索結果形式です。リッチ スニペットと同様、schema.org 構造化マークアップを使用して、より視覚に訴えかける魅力的な形式でコンテンツを表示します。オープンソースの AMP 形式にも対応しており、モバイル ユーザーに高速なエクスペリエンスを提供できます。
サイトを所有している方は、リッチカードを活用して検索結果を目立たせることで、ターゲットとするユーザーからのページアクセスを増やすことが可能です。たとえばレシピサイトを運営しているなら、おいしそうな料理の画像をカード形式で表示してユーザーの目を引くことができます。探しものが画像ですぐに見つかるため、「特定の料理のレシピ」を探しているターゲット ユーザーをより確実にサイトに誘導できます。
現時点でリッチカードが表示されるカテゴリは、レシピ、映画、飲食店の 3 つで、すべて AMP 形式に対応しています。各種のリッチカードをギャラリーで紹介しています。スクリーンショットや、マークアップのコードサンプルも用意していますので、コンテンツに合ったタイプを見つける場合はこちらをご利用ください。リッチカードをサポートするカテゴリやデータ形式は、今後も積極的に増やしていく予定です。
サイト所有者やデベロッパーの皆様にリッチカードの実装から掲載結果の確認までをお試しいただけるよう、デベロッパー向けドキュメントを更新し、充実したツールを用意いたしましたのでいくつかご紹介します。
何かご不明な点がありましたら、ウェブマスター ヘルプ フォーラムで質問してください。
注 : この投稿は、Google のウェブ検索に固有のものです。Google の他のサービスについては、適切なヘルプセンター（Google ショッピングなど）またはヘルプ フォーラムに問い合わせてください。
今や「年中無休」が当たり前となっている世の中ですが、オンラインサービスでは、サイトを一時的に停止しなければならない場合もあります。今回は、検索結果の掲載順位に影響を及ぼすことなく、サイト（またはその一部機能）を一時停止する方法をご紹介します。
ユーザーによる購入のみを停止したい場合は、その特定の機能だけを無効にする方法が一番簡単です。ほとんどの場合、ショッピング カート ページのクロールかインデックス登録のどちらかをブロックすることで対応できます。クロールは robots.txt ファイルで、インデックス登録は robots メタタグでブロックできます。検索エンジンによるコンテンツの検出またはインデックス登録が停止するため、それを適切な方法でユーザーに伝える必要があります。たとえばカートへのリンクを無効にする、適切なメッセージを表示する、カートの代わりに情報ページを表示するなどの方法があります。
ユーザーがサイト全体にアクセスできないようにする場合は、サイトが一時的に利用できないことを示すメッセージ、情報ページ、またはポップアップを表示し、サーバーから 503 HTTP ステータス コード（「サービスはご利用いただけません」）を返します。503 ステータス コードを返すことで、ユーザーに表示する一時的なコンテンツが Google にインデックス登録されるのを防ぐことができます。503 ステータス コードを返さないと、インタースティシャルなどがウェブサイトのコンテンツとしてインデックス登録されてしまうことがありますのでご注意ください。
Googlebot は 503 を返すページに対して、最長で 1 週間ほどクロールを再試行します。その期間を過ぎても 503 を返すページはパーマネント エラーとして扱われ、検索結果から除外されます。Retry-After ヘッダーを追加すると、サイトが利用できない期間を示すことができます。ただしサイトのブロックが 1 週間を超えると、サイトを停止している方法に関わらず、サイトの検索結果に悪影響が及ぶ可能性があります。
サーバーを完全にオフにするという方法もあります。サーバーを別のデータセンターに物理的に移動する場合などはこの方法がよいでしょう。この方法を使用する場合は、一時的なサーバーを用意してユーザー向けの情報ページを表示し、すべての URL で503 HTTP ステータス コードを返します。その期間中は DNS を切り替えて、この一時的なサーバーを経由するようにします。
これらの方法が、ウェブサイトを一時停止するときにお役に立てば幸いです。ご不明な点などありましたら、ウェブマスター ヘルプフォーラムでお気軽にご質問ください。
なお、地域密着型のビジネスを展開されている方は、ローカル リスティングの営業時間にビジネスの停止期間を設定することも忘れないでくださいね。
昨今、「クロール バジェット（クロールの割り当て）」についてさまざまな定義を耳にします。しかし、外部的に「クロール バジェット」と言われているものを一言で説明できるような言葉はGoogle内部にはありません。そこで、この記事では、Googlebot での「クロール バジェット」の実状や意味を明らかにします。
まず重要なのは、以下で述べるように、クロール バジェットとは、ほとんどのウェブマスターの方々にとって気にすべきものではない、ということです。 新しいページが公開された当日にクロールされることが多い場合、ウェブマスターの方がクロール バジェットを重視する必要はありません。同様に、数千以下の URL 数しか持たないサイトにおいては、ほとんどの場合、クロールは効率的に行われるでしょう。
一方で、例えば、大規模なサイトや、 URL パラメータを使用してページを自動生成するサイトにおいては、クロールの対象やタイミング、サイトをホストしているサーバーでクロールに割り当て可能なリソースの量に関しても優先順位を付けることが重要となります。
Googlebot は、ウェブ上の善良な市民であるよう設計されています。その主要な優先事項は、そのサイトにアクセスするユーザーにとっての利便性を損なわないよう配慮しつつクロールを行うことです。こうした仕組みを「クロールレート（クロール速度）」と呼びます。これにより、サイトに対する取得速度の最大値が制限されます。
単純化を恐れず言えば、クロールレートは、Googlebot でサイトのクロール時に使用する同時並行接続の数、および次回のフェッチまでに必要な待ち時間を表します。クロールレートは、次のような要因によって変動することがあります。
クロール速度が上限に達していない場合でも、インデックス登録における必要性がなければ、Googlebot によるクロールは少なくなります。クロールが必要かどうか決める上で大きな役割を担うのが、次の 2 つの要素です。
また、サイトの移転など、サイト全体に関わる事象が発生した場合、新しい URL のコンテンツをインデックスに再登録するために、クロールの必要性が高まることがあります。
こうしたクロール速度とクロールの必要性の両方を考慮したうえで、Google ではクロールの割り当てを「クロールの必要性があり、かつ Googlebot がクロール可能な URL の数」と定義しています。
Google の分析によると、付加価値の低い URL がサイトに多数ある場合、そのサイトのクロールやインデックス登録に悪影響が及ぶ可能性があります。価値の低い URL は、重要度順に次のようなカテゴリに分けられます。
このようなページでサーバーのリソースが浪費されると、実際に価値のあるページのクロールの妨げとなるため、サイト上の優れたコンテンツの発見に大幅な遅れを引き起こしかねません。
クロールは、サイトが Google の検索結果に表示されるために欠かせないものです。ウェブサイトのクロールが効率的に行われると、Google 検索のインデックスに登録されやすくなります。
A: サイトの表示速度を上げると、ユーザーの利便性が向上するだけでなく、クロール速度も上がります。Googlebotは、速度に優れたサイトはサーバーが健全な状態であることを表すものと見なすので、同じ接続の数でより多くのコンテンツの取得が可能になります。一方、5xx エラーや接続タイムアウトが多い場合はサーバーの状態に問題があると見なされ、クロールが遅くなります。
このため、Search Console のクロールエラー レポートを利用して、サーバーエラーを少なく抑えるようにすることをおすすめします。
A: クロール速度が上がっても、必ずしも検索結果での掲載順位が高くなるとは限りません。Google では何百もの要素を使って検索結果のランキングを決定しています。クロールはサイトが検索結果に表示されるために必要なものではありますが、ランキング要素ではありません。
A: 通常、Googlebot によりクロールされる URL はいずれも、サイトのクロール バジェットにカウントされます。AMP や hreflang のような代替 URL、CSS や JavaScript といった埋め込みコンテンツについてもクロールが必要となる可能性があり、その場合にはサイトのクロール バジェットが使われることになります。同様に、長いリダイレクト チェーンはクロールに悪影響を及ぼすことがあります。
A:「crawl-delay」robots.txt ディレクティブは、Googlebot では処理されません。
A: 場合によります。 クロールされる URL はすべてクロール バジェットに影響します。したがって、ページ内で URL を nofollow として指定しても、サイト内の別のページやウェブ上のページでリンクが nofollow と指定されていない場合はクロールされる可能性があります。
サイトのクロールを最適化する方法については、クロールの最適化に関する Google のブログ記事をご覧ください。こちらの記事は 2009 年の投稿ですが、現在もお役に立つ内容です。ご不明な点がありましたら、フォーラムで質問なさってください。
Posted by Gary, Crawling and Indexing teams
