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 のセットアップ ガイドをご確認ください。
