Google ニュースでより成果を上げるために

本記事では、Google ニュースでより成果を上げるために、ニュース メディアの皆様におすすめの方法やアドバイスをご紹介いたします。

一般的なアドバイス

Google ニュースのニュース メディア向けヘルプセンターには、検討すべき有益な情報が多数掲載されています。特に、コンテンツ技術的なガイドラインに関する記事をご覧ください。

見出しと日付

  • 明確な見出しを提示する: Google ニュースでは、HTML のタイトルタグやページで最も目立つテキストなど、さまざまなシグナルを確認して記事の見出しを決定しています。見出しに関するヒントをご覧ください
  • 正確な日付と時刻を提示する: Google ニュースでは、記事に表示する日時の判断をさまざまな方法で行っています。次の点をご確認いただくことで、適切な判断に役立ちます。
  • 明確な日時を示す: 日付に関するガイドラインに基づいて、見出しと記事のテキストの間に明確な日時をはっきりと示してください。可能な限り、他の日付(関連記事の日付など)がページに表示されないようにしてください。
  • 構造化データを使用する: datePublished および dateModified プロパティを使用し、AMP非 AMP ページに正しいタイムゾーンの値を記述します。
  • 不自然に記事を更新しない: 大きな変更を加えた記事の場合、日時を更新するのは意味のあることです。しかし、やむを得ない理由もなしに、重要な情報を追加しないまま記事を不自然に更新するのはやめてください。また、以前に公開した記事をわずかに更新しただけの記事を作成し、古い方の記事を削除して、新しい記事にリダイレクトすることも避けてください。このような手法は、記事の URL に関するガイドラインに違反しています。
  • 重複するコンテンツ

    Google ニュースでは、発信元のニュース メディアを評価することにより、独立性のあるオリジナルの報道コンテンツに報いたいと考えています。これは、ユーザーにとってもメディアにとっても望ましいことです。つまり、重複したコンテンツ(無断複製されたコンテンツ、書き換えられたコンテンツ、再公開されたコンテンツなど)のパフォーマンスが元のコンテンツより有利にならないように努めています。そのため、ニュース メディアの皆様は、以下のガイドラインに準拠してください。

    • 無断複製されたコンテンツをブロックする: 一般に、無断複製とは別のサイトから素材を流用することを指し、自動化されている場合もよくあります。コンテンツを無断複製しているサイトでは、無断複製されたコンテンツを Google ニュースからブロックする必要があります。
    • 書き換えられたコンテンツをブロックする: 書き換えとは、別のサイトから素材を流用し、まったく同じにはならないように、その素材を書き換えることを指します。実質的な内容や明確な付加価値を加えずにコンテンツの書き換えを行っているサイトでは、書き換えたコンテンツを Google ニュースからブロックする必要があります。たとえば、わずかに変更しただけの書き換えや、多くの語句を置換しているものの、元の記事の全体的な意味は変わらない書き換えなどが挙げられますが、これらに限定されません。
    • 再公開されたコンテンツをブロックするか、canonical の使用を検討する: 再公開とは、あるニュース メディアが別のメディアや著者から元のコンテンツ(通信社の素材や、他のメディアと提携している素材など)を再公開する許可を受けている場合を指します。
      他のメディアにコンテンツの再公開を許可しているニュース メディアは、元のバージョンの記事が Google ニュースに適切に掲載されるように、再公開しているメディアにブロックcanonical の使用を依頼することができます。
      一方で、素材を再公開しているニュース メディアでは、Google ニュースが元のコンテンツを適切に識別して評価できるように、再公開されたコンテンツのブロックcanonical の使用を積極的に行うよう検討されることをおすすめします。
    • 重複したコンテンツを避ける: コンテンツを共有するニュースサイトのネットワークを運営している場合にも、再公開に関する上記のアドバイスが当てはまります。元の記事に相当するコンテンツを選択したうえで、重複したコンテンツをブロックしたり、canonical を使って元の記事を指定したりすることを検討してください。

    透明性

    • 透明性を保つ: サイトの訪問者は、コンテンツを公開している当事者や記事を書いた人に関する情報を把握して信頼したいと考えています。そのため Google のコンテンツに関するガイドラインでは、明確な署名、著者に関する情報、ニュース メディアの連絡先情報をコンテンツに明記するよう強調しています。
    • 虚偽の振る舞いをしない: Google のコンテンツ ポリシーでは、他人や組織になりすましたサイトやアカウント、または自らのオーナーや主な目的を偽ったり隠したりしているサイトやアカウントは認められません。ユーザーに誤解を与えるよう組織的に取り組んでいるサイトやアカウントも許可されません。たとえば、虚偽の前提のもとに配信元の国を偽装、隠ぺいしたり、コンテンツを別の国のユーザーに配信したりするサイトやアカウントなどが該当します。

    その他のヒント

    • リンク プログラムへの参加を避ける: リンク プログラム(大規模な記事マーケティング プログラムや PageRank を転送するリンクの販売など)には参加しないでください。詳しくは、リンク プログラムに関するページをご覧ください。
    • リッチな表示向けに構造化データを使用する: AMP ページと非 AMP ページのどちらを使用する場合でも、構造化データを使用して、リッチリザルトやカルーセル形式の表示向けにコンテンツを最適化できます。
    • ユーザーとそのデータを保護する: ウェブサイトのすべてのページを HTTPS で保護し、ユーザーがサイト上でやり取りするデータの完全性と機密性を確保することを検討してください。HTTPS を実装する場合のおすすめの方法では、さらに役立つヒントをご紹介しています。

    まとめ

    ニュース メディアの皆様に Google ニュースを適切に実装いただくうえで、上記のヒントが役立つことを願っています。Google ニュースについてさらにご質問がある場合、Google は 1 対 1 のサポートを行うことはできません。しかし、最近リニューアルされた Google ニュースのニュース メディア向けフォーラム(英語版)を確認し、多数のニュース メディアに同時に役立ちそうなご質問がある場合は、ガイダンスを提供しています。このフォーラムは、ニュース メディアの皆様にヒントやアドバイスを互いに共有していただける、素晴らしい情報源となっています。

    Rendertron によるダイナミック レンダリング

    多くのフロントエンド フレームワークは、コンテンツの表示に JavaScript を使用しています。そのため、Google がコンテンツをインデックスに登録したり、インデックスに登録されたコンテンツの更新に時間がかかる場合があります。

    昨年の Google I/O では、この問題の回避策としてダイナミック レンダリングが議論されました。ダイナミック レンダリングの実装方法はいくつかあります。このブログでは、Rendertron を使用したダイナミック レンダリングの実装例を紹介します。Rendertron は headless Chromium をベースとしたオープンソース ソリューションです。

    ダイナミック レンダリングを検討すべきサイト

    あなたのサイトにアクセスする検索エンジンやソーシャル メディア ボットが、すべて JavaScript を実行できるわけではありません。Googlebot が JavaScript を実行するのには時間がかかり、こちらに示すようにいくつかの制限が存在します。

    ダイナミック レンダリングは、変更頻度が高く、表示に JavaScript を必要とするコンテンツに対して有用です。

    また、ハイブリッド レンダリング(Angular Universal など)を検討することで、あなたのサイトのユーザー エクスペリエンス(特に first meaningful paint までの時間)を向上できる可能性があります。

    ダイナミック レンダリングの仕組み

    ダイナミック レンダリングとは、特定のユーザー エージェントに応じて、クライアント側でレンダリングされるコンテンツとプリレンダリングしたコンテンツを切り替えることを指します。

    JavaScript を実行して静的 HTML を生成するにはレンダラが必要になります。Rendertron はオープンソース プロジェクトであり、headless Chromium を使用してレンダリングを行います。シングルページ アプリでは、頻繁にバックグラウンドでデータを読み込んだり、コンテンツをレンダリングするための作業で遅延が発生したりすることがあります。Rendertron には、ウェブサイトでレンダリングが完了したタイミングを判定するメカニズムがあります。Rendertron は、すべてのネットワーク リクエストが完了し、未処理の作業がなくなるまで待機します。

    このブログ投稿で扱う内容

    1. サンプルのウェブアプリを確認する
    2. 小規模の express.js サーバーを設定して、ウェブアプリを配信する
    3. ダイナミック レンダリング用のミドルウェアとして Rendertron をインストールして構成する

    サンプルのウェブアプリ

    「kitten corner」ウェブアプリは JavaScript を使用して、さまざまな猫の画像を API から読み込み、グリッド形式で表示します。

    グリッド形式で猫の画像が表示され、ボタンでさらに画像を表示できます。可愛いと思いませんか?

    以下がこのウェブアプリの JavaScript です。

      const apiUrl = 'https://api.thecatapi.com/v1/images/search?limit=50';
      const tpl = document.querySelector('template').content;
      const container = document.querySelector('ul');

      function init () {
        fetch(apiUrl)
        .then(response => response.json())
        .then(cats => {
          container.innerHTML = '';
          cats
            .map(cat => {
              const li = document.importNode(tpl, true);
              li.querySelector('img').src = cat.url;
              return li;
            }).forEach(li => container.appendChild(li));
        })
      }

      init();

      document.querySelector('button').addEventListener('click', init);

    このウェブアプリでは、Googlebot でまだサポートされていない最新の JavaScript(ES6)が使用されています。Googlebot がコンテンツを認識できるかは、モバイル フレンドリー テストを使用することで確認できます。

    モバイル フレンドリー テストより、このページがモバイル フレンドリーであることがわかりますが、スクリーンショットには猫が一切見当たりません。見出しとボタンは表示されていますが、猫の画像がまったく表示されていません。

    この問題は簡単に修正できます。こうした修正は、ダイナミック レンダリングを設定する方法を学習するための良い練習となるでしょう。ダイナミック レンダリングにより、ウェブアプリのコードを変更せずに Googlebot に猫の画像を認識させることができます。

    サーバーの設定

    ウェブアプリを配信するために、node.js ライブラリの express を使用してウェブサーバーを構築します。

    サーバーのコードは以下のようになります(プロジェクトの完全なソースコードはこちらをご覧ください)。

    const express = require('express');
    const app = express();

    const DIST_FOLDER = process.cwd() + '/docs';
    const PORT = process.env.PORT || 8080;

    // Serve static assets (images, css, etc.)
    app.get('*.*', express.static(DIST_FOLDER));

    // Point all other URLs to index.html for our single page app
    app.get('*', (req, res) => {
     res.sendFile(DIST_FOLDER + '/index.html');
    });

    // Start Express Server
    app.listen(PORT, () => {
     console.log(`Node Express server listening on http://localhost:${PORT} from ${DIST_FOLDER}`);
    });

    こちらで実際の例を試すことができます。最新のブラウザを使用しているのであれば、複数の猫の画像が表示されるはずです。パソコンからプロジェクトを実行するには、node.js で次のコマンドを実行する必要があります。

    npm install express rendertron-middleware
    node server.js

    次に、使用しているブラウザで http://localhost:8080 を指定します。ここからはダイナミック レンダリングを設定します。

    Rendertron インスタンスのデプロイ

    Rendertron は、URL を取得して、headless Chromium によってその URL の静的 HTML を返すサーバーを実行します。Rendertron プロジェクトの推奨事項に沿って、Google Cloud Platform を使用します。

    新しい Google Cloud Platform プロジェクトを作成するためのフォーム

    新しい Google Cloud Platform プロジェクトを作成するためのフォームに関しては、無料枠でプロジェクトを作成できる点に注意してください。また、この設定を本番環境で使用すると、Google Cloud Platform の料金体系に応じた課金が発生する点にも注意してください。

    1. Google Cloud Console で新しいプロジェクトを作成します。入力フィールドにある「プロジェクト ID」をメモします。
    2. Google Cloud SDK をドキュメントに説明されているとおりにインストールしてログインします。
    3. 以下のコマンドで、GitHub にある Rendertron リポジトリのクローンを作成します。
        git clone https://github.com/GoogleChrome/rendertron.git
        cd rendertron
    4. 次のコマンドを実行して依存関係をインストールし、パソコンに Rendertron を構築します。
        npm install && npm run build
    5. 次の内容の config.json という新しいファイルを rendertron ディレクトリに作成して、Rendertron キャッシュを有効化します。
        { "datastoreCache": true }
    6. rendertron ディレクトリから次のコマンドを実行します。「YOUR_PROJECT_ID」は、手順 1 でメモしたプロジェクト ID に置き換えます。
        gcloud app deploy app.yaml --project EURE_PROJEKT_ID
    7. 任意のリージョンを選択して、デプロイを確定します。デプロイが完了するまで待ちます。
    8. YOUR_PROJECT_ID.appspot.com(「YOUR_PROJECT_ID」は、手順 1 でメモしたプロジェクト ID に置き換えます)をブラウザに入力します。入力フィールドといくつかのボタンがある Rendertron のインターフェースが表示されるはずです。
    Google Cloud Platform に導入した後の Rendertron の UI

    Rendertron のウェブ インターフェースが表示されたら、Rendertron インスタンスが正常にデプロイされたことを意味します。次の手順で必要になるため、プロジェクトの URL(YOUR_PROJECT_ID.appspot.com)をメモします。

    サーバーへの Rendertron の追加

    ウェブサーバーは express.js を使用しており、Rendertron には express.js ミドルウェアがあります。server.js ファイルのディレクトリで、次のコマンドを実行します。

    npm install --save rendertron-middleware

    このコマンドにより、npm から rendertron-middleware がインストールされます。これで、rendertron-middleware をサーバーに追加できます。

    const express = require('express');
    const app = express();
    const rendertron = require('rendertron-middleware');

    bot リストの構成

    Rendertron は、ユーザー エージェントの HTTP ヘッダーを使用して、リクエストが bot からのものなのか、ユーザーのブラウザからのものなのかを判断します。Rendertron には、比較に使用できる、適切に整理された bot ユーザー エージェントのリストがあります。Googlebot は JavaScript を実行できるため、デフォルトではこのリストに Googlebot は含まれません。Rendertron に Googlebot リクエストもレンダリングさせるには、ユーザー エージェントのリストに Googlebot を追加します。

    const BOTS = rendertron.botUserAgents.concat('googlebot');
    const BOT_UA_PATTERN = new RegExp(BOTS.join('|'), 'i');

    Rendertron は後でこの正規表現とユーザー エージェントのヘッダーを比較します。

    ミドルウェアの追加

    bot リクエストを Rendertron インスタンスに送信するには、express.js サーバーにミドルウェアを追加する必要があります。ミドルウェアはリクエストしているユーザー エージェントを確認し、既知のボットからのリクエストを Rendertron インスタンスに転送します。次のコードを server.js に追加します。必ず「YOUR_PROJECT_ID」を Google Cloud Platform プロジェクト ID に置き換えてください。

    app.use(rendertron.makeMiddleware({
     proxyUrl: 'https://YOUR_PROJECT_ID.appspot.com/render',
     userAgentPattern: BOT_UA_PATTERN
    }));

    サンプル ウェブサイトをリクエストする bot は Rendertron から静的 HTML を受け取るので、コンテンツを表示するために JavaScript を実行する必要がありません。

    設定のテスト

    Rendertron の設定に成功したかどうかをテストするには、もう一度モバイル フレンドリー テストを実行します。

    最初のテストとは違い、猫の画像が表示されます。HTML タブには、JavaScript コードが生成したすべての HTML が表示され、コンテンツを表示するための JavaScript が Rendertron によって不要になったことがわかります。

    まとめ

    ウェブアプリに変更を加えずに、ダイナミック レンダリングを設定しました。このような設定により、ウェブアプリの静的バージョンの HTML をクローラに提供できます。

    モバイル ファースト インデックスに向けて、構造化データと画像の代替テキストをお忘れなく!

    「モバイル ファースト インデックス」の取り組みについて最初にお知らせしてから 2 年が経過しました。これは、ユーザーがウェブにアクセスする際に最も使用しているデバイスを考慮してスマートフォン用 Googlebot でクロールを行う取り組みです。あらゆる種類のデバイスに対応する素晴らしいウェブサイトが作られ、世界中で数多くのウェブサイトがモバイルウェブに対応しました。まだすべきことは多くありますが、ここに、モバイル ファースト インデックスに移行したページがグローバルでの検索結果の半数を超えたことをお知らせします。

    モバイル ファースト インデックスの確認

    通常、モバイル ファースト インデックスへのサイトの移行は、移行準備が完了したことをテストで確認できたときに行います。サイトを移行させた場合には、Search Console のメッセージを通じて、サイト所有者への通知が行われます。サイトの移行はサーバーログでも確認できます。移行後はスマートフォン用 Googlebot からのリクエストが大半を占めているはずです。また、URL 検査ツールを使用することでより簡単に確認できます。サイト所有者は同ツールでサイトの URL が最後にどのようにクロールおよびインデックスされているかを確認できます(確認はサイトのトップページだけで十分です)。

    レスポンシブ デザインの手法がサイトに採用されているのであれば、特に準備は不要です。レスポンシブ ウェブデザインが採用されていないサイトでは、評価時に次の 2 種類の問題が比較的多く見られました。

    モバイル版ページの構造化データの欠落

    構造化データは、ページのコンテンツを把握しやすくする上で便利なものです。また、検索結果で自身のページをより効果的に強調できるようにもなります。デスクトップ版ページで構造化データを採用しているのであれば、モバイル版ページでも同じ構造化データを使用する必要があります。これは、非常に重要なことです。モバイル ファースト インデックスでは、インデックスの対象となるのはモバイル版ページのみになるため、モバイル版ページで構造化データが使用されていないと、構造化データが見落とされてしまいます。

    なお、この問題に関しては、ページのテストの際に気をつける点があります。テストに際しては、構造化データの一般的な検証を行い、次にモバイル版ページの構造化データと比較することをおすすめしています。モバイル版ページに対しては、モバイル端末のシミュレーションを行ってソースコードを確認したり、モバイル フレンドリー テストツールで生成した HTML を使用したりすることをおすすめしています。一点ご留意いただきたいのは、モバイル ファースト インデックスに関して言えば、ページがモバイル フレンドリーである必要ありません、という点です。

    モバイル版ページの画像代替テキストの欠落

    画像に alt 属性(「代替テキスト」)を指定することで、スクリーン リーダー(モバイルでも使用されます)を使うユーザーや検索エンジンのクローラに対して、画像の内容を説明できるようになります。画像に代替テキストが指定されていない場合、Google 画像検索でページ上の画像のコンテキストを把握することが非常に難しくなります。

    ウェブサイトの主要なモバイル版ページで、ソースコードの「img」タグを確認してください。上述のとおり、モバイル版ページのソースコードは、ブラウザでモバイル端末のシミュレーションを行って表示させることも、モバイル フレンドリー テストで、Googlebot が生成するバージョンを確認することもできます。ソースコードの「img」タグを探し、Google 画像検索で表示させたい画像に alt 属性が適切に指定されているか再度確認してください。

    たとえば、次のように指定します。

    代替テキストが適切に指定されている例:
    <img src="cute-puppies.png" alt="ブランケットの上にかわいい子犬がいる写真">

    代替テキストが指定されていない例:
    <img src="sad-puppies.png">

    多くの素晴らしいウェブサイトが、モバイルでも適切に表示されるようになるのは喜ばしいことです。より多くのウェブサイトがモバイル ファースト インデックスでインデックスされ、サイトへのアクセスに最も使用されるスマートフォンでより多くのユーザーがウェブを検索できるようになることを願っています。Google はこの変更を慎重に確認して評価し続けます。ご不明な点がございましたら、ウェブマスター フォーラムまたはイベントでご質問ください。

    Google ウェブマスター公式ブログのコメント機能に関して

    長年にわたり、Google ウェブマスター公式ブログの投稿に寄せられた何千ものコメントを読んできました。 思慮深いコメントや興味深いコメントもありましたが、同時に、内容に関係ないスパムのようなコメントも多く寄せられました。

    本日から、Google ウェブマスター公式ブログのコメント機能は終了します。 今後、このブログのコメント機能に代わり、他のチャンネルでのコミュニティ活動に注力していきます。コメントやフィードバックなどがある場合は、ウェブマスター ヘルプ フォーラムまたは Twitter でご連絡ください。

    世界中のウェブマスター コミュニティに感謝を込めて

    みなさま、あけましておめでとうございます!

    本年もどうぞよろしくお願いします。


    2018 年はウェブマスターのサポート コミュニティにとって大変重要な年でした。主な出来事として、プログラムの名称変更、グローバル サミット、様々な言語で数多くのウェブマスター オフィスアワーの実施、などが挙げられます。それぞれ軽く振り返ってみたいと思います。

    10 月には、従来の「トップレベル ユーザー」が「ゴールド プロダクト エキスパート」に、「注目ユーザー」が「シルバー プロダクト エキスパート」に変わりました。この名称変更はすべてのプロダクト フォーラムで実施されたもので、バッジと名称も以下のような新しいものになっています。

    シルバー プロダクト エキスパート: プロダクトに関する知識を習得中の新しいメンバー

    ゴールド プロダクト エキスパート: 深い知識を持ち、信頼の置けるユーザーとして積極的にフォーラムに参加しているメンバー

    11 月には、すべての Google ヘルプ フォーラム(Blogger や Google マイビジネスなど)のゴールド プロダクト エキスパートのみなさまをグローバル サミットにご招待しました。このイベントはカリフォルニア州サニーベールにある Google キャンパスで開催されました。世界中から集まった約 550 人の参加者のうち、ウェブマスターのゴールド プロダクト エキスパートは 約 70 人でした。出身国は 25 か国にわたり、イベントに参加したコミュニティの中で 2 番目に多い人数でした。11 月の後半には、モスクワでもう一つのイベントを開催し、こちらも大盛況でした。23 人のロシア語話者のプロダクト エキスパートが集まりましたが、そのうちの 10 人がウェブマスターでした。

    多くの参加者から、「本当に価値ある時間だった」、「どのセッションも大変興味深く、ためになる内容だった」、「イベント全体が素晴らしかった」などの感想が寄せられています。

    サニーベールで開催された昨年のグローバル サミットに参加したウェブマスターのゴールド プロダクト エキスパート

    この知識豊富なユーザーのグループは、フォーラムにおいて、検索、構造化データ、Search Console に関するさまざまな事柄について、年間 200 万人以上のユーザーに対して 16 言語でユーザーの抱える問題を解決するのを助けてくれています。

    このコミュニティの成り立ちはどのようなものでしょうか。シルバーやゴールドのステータスを持つプロダクト エキスパートの多くはサイト所有者で、参加のきっかけは(ユーザーによっては 10 年以上前に)ウェブマスター フォーラムに自分のサイトについての質問を投稿したことでした。自分の問題が解決した後も、彼らのほとんどは、自分の知識が他の人の役に立つかもしれないと考えて、コミュニティにお返しをしようと留まってくれました。すべてのエキスパートのみなさまの献身と、ウェブサイトで問題を抱えるユーザーを助けるために絶えず知識を共有してくださっていることに、感謝したいと思います。

    今年は年間を通じて、Google Webmasters の YouTube チャンネルで公開のオフィスアワー ハングアウトを 75 回実施しました。英語、日本語、ドイツ語、ヒンディー語、フランス語で行いましたが、スペイン語でも開始しました。このハングアウトでは、双方向のやり取りが可能で、どなたでも Google チームに直接質問していただけます。日本語ではこちらの#ウェブマスターオフィスアワーのハッシュタグを使ってインタラクティブに行っており、また、ご質問はこちらのフォームで事前に集めています。

    日本語のウェブマスターオフィスアワーは、 ほぼ毎月開催しており、その様子はこちらで過去のアーカイブをご覧いただけます。昨年 12 月にはプロダクト エキスパートのみなさんをご招待して Google のオフィスからオフィスアワーをお届けしました。後半プロダクト エキスパートのみなさんがどのようにフォーラムに取り組まれているかなど、インタビューしておりますので、その様子をぜひこちらからご覧ください。

    このコミュニティに参加したい、ウェブマスター フォーラムで互いに交流したり、他のユーザーを支援してみたい、とお考えのみなさまは、プロダクト エキスパート プログラムのウェブサイトで詳細をご覧ください。多様な経歴やスキルを持つユーザーのみなさまをお待ちしています。

    2019 年はコミュニティにとってどのような年になるでしょうか。またみなさまとお会いできることを楽しみにしております。

    2018 年もありがとうございました!ブログのアクセスランキングで振り返る 2018 年

    2018 年も残すところあと数日となりました。ウェブマスターのみなさまにとって 2018 年はどんな一年だったでしょうか?

    今年もウェブマスター向け公式ブログをはじめ、ウェブマスター ヘルプ フォーラムウェブマスター オフィスアワーやイベントなど、多くの方にご参加、ご愛読いただきありがとうございました!また、特にイベントについては今年は全国で 10 ヶ所以上の地域のイベントに参加することができました。お声がけいただいたみなさま、ご参加いただいたみなさま、ありがとうございました!

    さて、それでは 2018 年をウェブマスター向け公式ブログへのアクセスから振り返ってみたいと思います。今回は Search Console で計測したクリック数で振り返ってみたいと思います。
    1. モバイル ファースト インデックスを開始します
    2. 医療や健康に関連する検索結果の改善について
    3. 新しい Search Console をご紹介します
    4. Google Dance Tokyo 2018 開催のお知らせ
    5. reCAPTCHA v3 をご紹介します。Bot の活動を阻止する新しい方法
    6. Lighthouse Chrome 拡張機能に追加された SEO カテゴリのご紹介
    7. ページの読み込み速度をモバイル検索のランキング要素に使用します
    8. Google Dance Osaka 2018 開催のお知らせ
    9. HTTPS ページが優先的にインデックスに登録されるようになります
    10. 複数ページにまたがる記事やコンテンツをお持ちの方へ。rel=”next” と rel=”prev” を使用したページネーションのご紹介
    第一位は、2016 年の末に事前告知を開始したモバイル ファースト インデックス(MFI)開始の記事となりました。MFI については最近の記事(英語)でグローバルで MFI 移行率が 50% を超えたことを発表しました。まだ移行されていないサイトをお持ちでしたら、いま一度構造化データや画像の ALT タグなどがモバイルでもきちんと設定されているかどうかを確認して頂ければと思います。第二位には「医療や健康に関連する検索結果の改善について」が、第三位は 1 月に公開を開始した新しい Search Console のベータ版を公開した記事となりました。こちらは 9 月に正式版となり、旧ツールからの移行が進んでいます。

    第四位は Google 主催による検索のイベント、Google Dance Tokyo の告知となりました。今年は Google Dance を大阪でも開催し、第八位にもランクインしているのは非常に嬉しいですね。開催報告(東京大阪)も公開していますのでぜひ合わせてご覧ください。2019 年も開催できればと思いますので、楽しみにしていてください。

    第五位は、新しくなった reCAPTCHA の記事でした。スパムや不正行為を防ぎつつ、ユーザーの利便性も高めることができます。

    第六位は Lighthouse に SEO カテゴリが追加された記事となりました。第七位に入った Speed Update に関連して、ページの読み込み速度を計測するツールとしてPageSpeed Insights とともに注目を集めました。新しくなった PageSpeed Insights では、Lighthouse の分析エンジンを使用していますので 2 つのツールで測定する必要がなくなりました。

    第九位は https 関連の 3 年前の記事となりました。https の導入が進んでいくことでウェブの安全性が高まりますので非常に嬉しく思います。

    そして第十位にページネーションが入ったのも見逃せません。こうした記事に注目が集まる事で、検索ユーザーが探している情報をより見つけやすくなります。

    いかがでしたでしょうか?2017 年は検索結果やコンテンツの品質に関する記事が上位を占めていましたが、今年は 2018 年の様々な話題が散りばめられた結果となりました。見落としていた記事などありましたらぜひ年末年始の間にでもご覧いただければと思います。

    それでは 2018 年もありがとうございました!
    2019 年もよろしくお願いします!

    Takeaki Kanaya, Senior Search Evangelist, Google

    Google Dance Osaka 2018 を開催しました

    2018 年 11 月 15 日、Google の検索チームとウェブマスターやサイト運営に関わるみなさんを結ぶイベント、Google Dance Osaka 2018 を開催しました(Google Dance は、米国 Google 本社で開催されている、検索などオンライン マーケティングの担当者を対象としたソーシャル イベントである Google Dance の日本版です)。
    イベントには例年通り当ブログでの告知からご応募いただいた方々や、Advanced Hosting Meetup の参加者、ウェブマスター ヘルプ フォーラムプロダクト エキスパートのみなさんをご招待し、今回は関西の方々を中心に、170 名の方々にご参加いただきました。
    イベントは Juan Felipe Rincón による Keynote Speech “Creating the Future of Search Together” から始まり、続く Special Session では Idan Avraham が “The New Search Console & Helping The Long Tail Web” と題して新しい Search Console についてお話しました。さらに Gary Illyes が Google Image Search 画像検索についてお話しました。
    そしてQ&A タイムは、金谷武明小川安奈、そしてセッション スピーカーの 3 名も加わり、Search Console や検索結果に対する疑問など、多くのご質問に回答しました。
    また、Google Dance Osaka でも地元大阪の方々を中心に多くの方に Lightning Talk や 15 分程度の短めのセッションを披露していただきました。スピーカーのみなさま、ありがとうございました!(セッション リストは告知の記事でご確認ください)
    その他、当日の会場の様子に関しては、今年もハッシュタグ #GoogleDanceOsaka で多くの感想やコメントが投稿されましたので、ぜひご覧ください。
    最後に、今回もみなさんから沢山のフィードバックやコメントを頂き、Google の検索チームとしても非常に有益なイベントとなりました。そして何よりもみなさんと楽しい時間を過ごせたことを非常に嬉しく思います。お越しいただきましたみなさん、ありがとうございました!頂いたフィードバックは今後の検索エンジンの改善に役立てていきたいと思います。
    またイベントや #ウェブマスター オフィスアワーでお会いしましょう!
    ※ 残念ながら当日お越しいただけなかったみなさん、検索のご質問はウェブマスター ヘルプ フォーラムやウェブマスター オフィスアワーでも受け付けておりますのでぜひご利用下さい。また、様々なイベントに参加しておりますのでぜひ直接イベントにお越し頂き、その際にご質問いただければと思います。

    ライブストリーム用の Indexing API と構造化データを導入します

    ここ数年、ライブ動画のオンライン ストリーミングがこれまでになく簡単になり、セレブ動画からイベント動画まで大きな広がりを見せています。しかし、どの動画が進行中なのか、またいつ動画が始まるのかを見付けるのは必ずしも簡単ではありません。

    そこで、Google 検索やアシスタントでライブストリームを簡単に見つけられるようにするため、本日新たに「ライブストリーム構造化データ」を導入しました。ライブストリーム構造化データと Indexing API を使用すると、ライブ動画をいつストリーミングするかを Google に知らせることができます。それにより、ストリーミング中のライブ動画に赤色の「進行中」バッジを表示することも可能になります。

    ライブストリーム構造化データをページに追加する

    ウェブサイトでライブ動画をストリーミングする場合は、ライブストリームに関するデベロッパー向けドキュメントを参照し、動画がライブ配信であることを示すとともに、配信の開始時間と終了時間を指定してください。さらに、ページ上に動画があることを Google に伝えるために、VideoObject 構造化データを追加する必要があります。

    Indexing API でクロールをリクエストする

    今回の導入に伴い、Indexing API がライブストリーム構造化データに対応しました。Indexing API を呼び出して、ライブ配信に間に合うようにサイトのクロールをリクエストしてください。Indexing API は、ライブストリームの開始時と終了時、構造化データに変更を加えたときにも呼び出すことをおすすめします。

    詳しくは、デベロッパー向けのドキュメントをご覧ください。ご不明な点がありましたら、ウェブマスター ヘルプフォーラムまでお寄せください。皆様のライブ動画が、Google 検索に表示されるのを楽しみにしております。

    リッチリザルトが Q&A サイトにも対応します

    検索ユーザーはさまざまな疑問の答えを求めて Google を利用しています。

    求めている答えが、ユーザー同士が質問に答え合う Q&A サイトで見つかる場合も少なくありません。Q&A サイトには、人気のソーシャル ニュース サイト、エキスパート フォーラム、ヘルプやサポートに関するメッセージ ボードなどがあります。

    「USB ケーブルがポートから抜けなくなってしましまいました」というページの検索結果に、そのページの上位回答の一覧が追加されている例を示すスクリーンショット

    疑問に対する最適な回答を検索結果の中から簡単に見つけられるよう、Google は Q&A サイト向けの新しいリッチリザルトを開発しました。対応する Q&A ページの検索結果には、上位の回答のプレビューが表示されます。この新しい表示方法により、サイト所有者はコンテンツに適したユーザーにリーチでき、ユーザーは疑問に対する適切な情報をすばやく取得できるようになります。

    「タッチスクリーンでタッチが誤認識されてしまう」というページの検索結果に、そのページの上位回答のプレビューが追加されている例を示すスクリーンショット

    この機能に対応するには、Q&A コンテンツを掲載しているページに Q&A 構造化データを追加します。構造化データ テストツールを使用することで、ページがこの機能に対応していることを確認し、検索結果でどのように表示されるかをプレビューできます。Search Console では、統計情報とマークアップ エラーの例を確認できます。また、検索パフォーマンス レポートでは、どのような検索クエリに対して検索結果に Q&A リッチリザルトが表示されているかを確認したり、検索結果の推移を確認したりできます。

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

    PageSpeed Insights、Lighthouse の使用を開始しました

    Google では、スピードが重視されていることを考慮し、どなたでもページやサイトのパフォーマンスを把握できるよう各種ツールをご用意しています。これまで、こうしたツールでは異なる分析エンジンを使用していたため、ツールごとに最適化案が異なり、混乱を招くこともありました。そこで、本日、PageSpeed Insights(PSI)の分析エンジンとして Lighthouse の使用を開始する運びとなりましたことをお知らせいたします。これにより、デベロッパーはウェブ、コマンドライン、Chrome DevTools を問わず、どこでも同じパフォーマンス分析結果と最適化案を参照できるようになります。また、PSI には、Chrome ユーザー エクスペリエンス レポート(CrUX)で提供されるフィールド データも組み込まれます。PageSpeed Insights API バージョン 5 では、CrUX のデータのほか、Lighthouse 監査のすべてのデータが提供されるようになります。PSI API の以前のバージョンは 6 か月後にサポートを終了いたします。

    Pagespeed Insights で Lighthouse の使用を開始

    PageSpeed Insights で提供される情報は次のとおりです。

    • ラボデータ: PSI では、Lighthouse を使用してページを取得、分析し、モバイル端末でページがどのように読み込まれるかのシミュレーションが行われます。ページの一連のパフォーマンス指標(First Contentful Paint、Time to Interactive など)を計算し、これらの指標を要約して 0~100 のパフォーマンス スコアで表します。スコアは 3 つのレベルに分類され、90 以上は「良」と見なされます。
    • フィールド データ: PSI には、ページの実際のパフォーマンス指標(First Contentful Paint、First Input Delay など)とその origin も表示されます(これを受けて、PSI では origin: クエリのサポートも終了します)。ただし、必ずしもすべてのサイトに表示可能なフィールド データがあるとは限りません。データは、毎日更新される Chrome ユーザー エクスペリエンス レポートを利用し、過去 28 日間かけて収集されます。実際のネットワークの状態や Chrome ユーザーが使用する端末は広範囲に及ぶため、ここでの指標は、ラボデータ欄の指標とは異なることがありますのでご注意ください。
    • 最適化案: PSI では、ページのパフォーマンス指標を改善する方法についての最適化案が提供されます。各最適化案には、実装するとページの読み込みがどのくらい速くなるかの見積もりも表示されます。
    • 診断: この欄には、ページがウェブ開発のおすすめの設定にどの程度沿っているかについての追加情報が表示されます。

    PSI v5 API では、所定の URL について、この新しい分析データと CrUX のデータに加え、すべての Lighthouse カテゴリデータ(パフォーマンス、プログレッシブ ウェブアプリ、アクセシビリティ、ベスト プラクティス、SEO)が返されるようになります。

    変更内容について詳しくは、よくある質問をご覧ください。ご不明な点がありましたら、Stack Overflow をご利用ください(その際、質問には pagespeed-insights タグの設定をお願いいたします)。

    定期購入ページの説明が不十分な場合は警告が表示されるようになります

    モバイル向け定期購入ページの説明が不十分だと感じる Chrome ユーザーが増えています。 きちんと説明された覚えもなく、月末の請求書を見て驚くというのは、ユーザーにとって非常に不愉快な体験です。Google では、ユーザーが十分な情報に基づいて定期購入できるように努めています。そこで Chrome 71 (2018 年 12 月公開) 以降、Chrome ユーザーが説明が不十分な定期購入ページを開こうとした場合に警告を表示することにしました。警告が表示された場合は、定期購入ページに進むかどうかをユーザーが明示的に選択することになります。料金が発生することに気付いていなかった場合は、前のページに戻ることができます。

    説明が不十分なモバイル向け定期購入

    次のようなケースを考えてみましょう。隆史さんが、モバイル端末でブラウジングしていてゲームサイトにアクセスしたところ、携帯電話番号の入力を求めるページが表示されました。

    携帯電話番号を入力して [Continue] をクリックすると、コンテンツにアクセスできました。

    翌月届いた携帯電話の請求書には、身に覚えのない請求が含まれていました。オンラインのゲームサービスの定期購入はこんなに高額なのでしょうか。この金額を支払うことに本当に合意したのでしょうか。コンテンツの利用料金としていくら払うことに合意したのでしょうか。

    料金に関する情報を Chrome ユーザーに

    Chrome ユーザーがウェブ ブラウジング中に請求手続きに移行するときは、そのことをきちんと理解し、十分な情報を得たうえで意思決定できるようにしたいと考えています。

    ユーザーに十分な情報を提供するためには、Google が新たにまとめたモバイルでの料金請求のベスト プラクティスに沿って、十分に詳細な情報を請求ページに記載することが重要です。以下にチェックポイントを挙げておきますので、ユーザーに十分な情報を提供できているかどうかを確認してみてください。

    • 料金に関する情報がユーザーに明示されていますか?たとえば、定期購入ページに料金に関する情報が表示されていない(または見つけるのが難しい)と、支払いが必要だと認識しないまま手続きを進めてしまうおそれがあります。ユーザーが料金に関する情報を確認してから定期購入に同意できるようにしてください。
    • ユーザーが利用規約に同意する前に、料金を簡単に把握できますか?たとえば、料金に関する情報がグレーの背景にグレーの文字で記載されていては、ユーザーが見過ごしてしまうおそれがあります。ユーザーが料金を簡単に把握できるよう、わかりやすく表示してください。
    • 簡単に理解できる料金体系になっていますか?たとえば、サービスの料金がいくらになるかを計算式で示す場合は、できる限りシンプルでわかりやすい式になるよう工夫してください。

    モバイル版 Chrome、PC 版 Chrome、Android の WebView では、料金に関する情報が不十分なページが検出されると、ユーザーに対して次のような警告が表示されます。

    説明が不十分な請求ページにアクセスしようとすると警告が表示される。

    このようなページが検出された場合は、Search Console を通じてウェブマスターに通知します。変更を加えて料金に関する情報が明確になりましたら、通知から再審査をリクエストしてください。Search Console での確認が済んでいないウェブサイトにつきましては、ウェブマスターと連絡が取れるよう最善を尽くします。なお、ウェブマスター ヘルプ フォーラムでは、15 の言語で質問を受け付けています。Search Console 経由で再審査リクエストが届きましたら、変更後のページを審査し、基準を満たしていれば警告を削除します。

    料金に関する情報が Google のベスト プラクティスに沿ってわかりやすく明示されていれば、特に変更を加える必要はありません。また、今回 Chrome に表示されるようになった警告が、Google 検索でのウェブサイトの掲載順位に影響することもありません。

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

    reCAPTCHA v3 をご紹介します。Bot の活動を阻止する新しい方法

    本日は、ユーザーが操作することなくウェブサイトへの不正なトラフィックを検出できる最新の API、reCAPTCHA v3 についてご紹介します。確認用画像を表示するキャプチャとは異なり、reCAPTCHA v3 ではスコアが返されます。サイト所有者は、このスコアに基づいてウェブサイトに最適なアクションを選択できます。

    スムーズなユーザー エクスペリエンス

    ここ 10 年の間、reCAPTCHA のテクノロジーは常に進化を遂げてきました。reCAPTCHA v1 では、歪められた文字を読み取ってボックスに入力し、確認用画像のテストをパスすることがすべてのユーザーに求められていました。その後、ユーザー エクスペリエンスとセキュリティの両方を改善するために reCAPTCHA v2 が導入されました。reCAPTCHA v2 では、リクエストが人間によるものなのか、それとも bot によるものなのかを判別するために、他にも数多くの要素が使用されるようになりました。これにより、reCAPTCHA の確認用画像は、不正行為の検出においてメインの機能ではなく二次的な機能として利用されるようになり、ユーザーの約半数が 1 回のクリックでパスできるようになりました。そして今回、reCAPTCHA v3 により、人間と bot を判別する方法が根本的に変わります。reCAPTCHA v3 では、サイトに対するアクティビティがどの程度不審であるかを示すスコアが返され、確認用画像によってユーザーを妨げる必要がなくなります。バックグラウンドで適応型リスク分析が実行されるため、ユーザーにはスムーズなエクスペリエンスを提供しながら、不審なトラフィックがあった場合には通知を受け取れます。

    「アクション」を使ったより正確な bot 検出

    reCAPTCHA v3 では、「アクション」タグという新しいコンセプトが導入されています。このタグを使用することで、ユーザーの一連の操作における主要なステップを定義でき、コンテキストをふまえたリスク分析が reCAPTCHA によって実現します。reCAPTCHA v3 はユーザーの操作を妨げることがないため、複数のページに追加することをおすすめします。複数のページに追加することで、適応型リスク分析エンジンで複数のページにまたがるアクティビティを分析し、より正確に攻撃パターンを特定できるようになります。reCAPTCHA の管理コンソールでは、reCAPTCHA スコアの分布状況に関する全概要を確認でき、サイトの上位 10 件のアクションに関する統計情報も確認できます。これにより、どのページが bot の標的にされているかを正確に把握し、そのページへのトラフィックがどの程度不審なのかについても確認できます。

    サイトに適した方法で bot に対処する

    reCAPTCHA v3 のもう 1 つの大きな利点は、スパムや不正行為を防ぐ方法をウェブサイトに合わせて柔軟に選べるという点です。これまでの reCAPTCHA システムでは、多くの場合、いつ、どのようなキャプチャをユーザーに提示するかが決められており、限定的にしかウェブサイトのユーザー エクスペリエンスに関与できませんでした。reCAPTCHA v3 では、操作がどの程度不審であるかを示すスコアが返され、そのスコアを 3 つの方法で活用できます。1 つ目はしきい値を設定し、ユーザーをパスさせるか、さらに確認が必要かを判断する方法です。追加の確認手順としては 2 段階認証プロセスや電話での確認などを使用できます。2 つ目は、reCAPTCHA が利用できない要素(ユーザー プロファイルやトランザクション履歴など)とスコアを組み合わせる方法です。3 つ目は、不正行為に対抗するための機械学習モデルのトレーニングにおいて、reCAPTCHA のスコアを指標の 1 つとして活用する方法です。このように、新しいバージョンでは新たな方法を利用できます。さまざまなタイプのトラフィックに応じてアクションをカスタマイズすることで、ウェブサイトのニーズに基づいてサイトを bot から保護し、ユーザー エクスペリエンスを改善できます。

    reCAPTCHA v3 を利用することで、ユーザーの操作を妨げることなくサイトを保護し、危険性の高い状況においてどのように対処すべきかをさらに正確に判断できます。今後も Google では、攻撃者に先んじて、インターネットを快適に、そして安全に使えるように取り組んでまいります。

    reCAPTCHA v3 の利用に関心をお持ちの場合は、デベロッパー サイトで詳細をご確認ください。

    本日より Google プロダクト エキスパート プログラムを開始します!

    ウェブマスター フォーラムでの質問やフィードバックの受け付けを開始してから 12 年以上が経過しました(当初はサイトマップに関するご質問を Google グループで受け付けていました。その頃のブログ投稿はこちら)。小さなメーリング リストから始まったウェブマスター フォーラムも今では 15 言語に対応し、年間のスレッド数が 50,000 件を超える活発なフォーラムへと成長しました。Google にとってこのフォーラムは、ご報告いただいたさまざまな事例から多くを学び、フィードバックを収集してチームに伝えるプラットフォームとして欠かせない存在となっています。

    ウェブマスター フォーラムで積極的にユーザーの力になってくれているのが、Google のトップレベル ユーザー tc と注目ユーザー tc です。ウェブマスター フォーラムだけで 100 人以上、すべてのプロダクト フォーラムを合わせると 1,000 人以上のメンバーからなるエキスパート コミュニティが、Google のプロダクトを誰もが最大限に活用できるよう知識を共有してくれています。

    本日、このトップレベル ユーザー プログラムのブランドを変更し、Google プロダクト エキスパート プログラムとしてリニューアルすることをお知らせいたします。エキスパートのコミュニティはそのままに、新たなブランドとして生まれ変わることになります。

    今後数日の間にフォーラムのバッジを更新し、プロダクト エキスパートを簡単に識別できるようにします。バッジの種類は以下のとおりです。

    シルバー プロダクト エキスパート: プロダクトに関する知識を深めている、比較的新しいメンバー

    ゴールド プロダクト エキスパート: 豊富な知識を持ち活発に活動する、信頼のおけるメンバー

    プラチナ プロダクト エキスパート: ユーザーを助けるだけでなく、メンターとしての活動やコンテンツの作成などを通じてコミュニティに貢献している経験豊富なメンバー

    歴代プロダクト エキスパート: 現在は積極的に活動していないが、かつて頼りになるメンバーとして認められた歴代のメンバー

    新しいバッジと名称について詳しくはこちらをご覧ください。

    プロダクト エキスパートは、Google プロダクトを積極的に活用していて、他のユーザーの質問や悩みの解決に喜んで手を貸してくれる方々です。また、Search Console など、ユーザー向けのツールのフィードバックをくれたり、Google が答えるべきだと思われる質問を知らせてくれたりもしています。ユーザーからのフィードバックは Google が重視している情報の 1 つであり、プロダクト エキスパートは何が多くのユーザーに影響するかをしっかり理解しています。その一例として、新しい Search Console(英語) の開発につながったプロダクト エキスパートからのフィードバックについてブログに投稿しています。

    新しいプロダクト エキスパート プログラムのウェブサイトでは、プロダクト エキスパートになる方法をご紹介しています。ぜひウェブマスター フォーラムで共に活動しましょう。皆様の参加を心よりお待ちしております。

    Google Dance Osaka 2018 開催のお知らせ

    Google の検索チームと、ウェブマスターやサイト運営に関わる皆さんを結ぶことを目的にしたイベント Google Dance、日本でも 2016 年より 3 年にわたって毎年開催してまいりました

    今回、日本では初めて東京以外での開催となる Google Dance Osaka を開催することになりました!今回の Google Dance Osaka では、Google 画像検索、Search Console についてのセッションや Q&A の時間を設けるほか、Google 社員と参加者のみなさんの交流タイムなどを予定しています。開催概要は次のとおりです。

    開催概要

    日時:2018 年 11 月 15 日(木)
       13 時 00 分 : 開場
       14 時 00 分 : 開始
       18 時 00 分 : セッション終了
       20 時 30 分 : 懇親会終了

    スピーカー:
       ・Juan Felipe Rincón
       ・Gary Illyes
       ・Idan Avraham
       ・金谷 武明
       ・小川 安奈

    場所:グランフロント大阪
    費用:無料
    定員:最大 200 名(招待枠含む)
    お申し込みはこちらから!
    (締め切り:2018 年 10 月 21 日(日) 深夜 24 時まで)

    今回は Lightning Talk に加えて、一般の方によるセッションタイムを設けたいと思います。登壇を希望される方は、ぜひお申込みフォームからお知らせください!

    みなさまのご応募お待ちしております!

    ※ 応募多数の場合は、抽選とさせていただきます。
    ※ 参加者は 10/25 以降メールにてご連絡致します。なお、抽選の場合、参加者のみのご連絡とさせていただきます。
    ※ 会場までの交通費等のサポートはありませんのでご了承ください。

    Takeaki Kanaya, Senior Search Evangelist, Google

    Chrome のセキュリティにとって大きな一歩: HTTP ページに「保護されていません」と表示されるようになります

    Google では、Chrome を最初にリリースした時から、セキュリティを Chrome の基本原則の 1 つと考え、ウェブを閲覧するユーザーの安全を守る(英語)ために常に取り組んできました。Chrome で HTTPS によって暗号化されていないサイトに「保護されていません」と表示し、最終的にはすべての非暗号化サイトにこの警告を表示すると発表(英語)したのは、およそ 2 年前のことです。この警告により、ウェブ上で銀行口座の確認やコンサート チケットの購入などを行う際に、個人情報が保護されるかどうかを簡単に知ることができます。7 月 25 日より、Google はすべての Chrome ユーザーを対象にこの変更のロールアウトを開始しました。

    Chrome の最新バージョン(68)から、HTTP ページにアクセスすると、「保護されていません」という通知が新たに表示されるようになります。

    暗号化された接続が増えれば、セキュリティが高まる



    ウェブサイトを通常の HTTP で読み込む場合、サイトへの接続は暗号化されません。つまり、ネットワーク上にいる誰もが、やり取りされる情報を見ることができ、コンテンツが表示される前に内容を改ざんすることさえできます。HTTPS ではサイトへの接続が暗号化されているため、通信を盗み見ようとしてもアクセスできず、サイトに送信される情報(パスワードやクレジット カード情報など)が開示されることはありません。

    Chrome に「保護されていません」という警告を表示することで、ユーザーはアクセスしているサイトへの接続が安全でないことを確認でき、同時にサイトの所有者がサイトのセキュリティを強化するための動機付けとなります。約 2 年前の発表以来、HTTPS の使用は驚異的な伸びを見せました。Google の透明性レポートでは、次のような結果が出ています。
    • Android の Chrome トラフィックは、現在 76% が保護されています(2 年前は 42%)
    • ChromeOS の Chrome トラフィックは、現在 85% が保護されています(2 年前は 67%)
    • 上位 100 位中 83 のウェブサイトが、デフォルトで HTTPS を使用しています(2 年前は 37)
    すべての HTTP ページに警告表示を開始するまでに時間がかかることは明らかでしたので、暗号化されていないページでパスワードやクレジット カード情報が収集される場合にマークを付けることから始めました。その後、「保護されていません」という警告が表示される状況をさらに 2 つ追加しました。ユーザーが HTTP ページにデータを入力するときと、シークレット モードで HTTP ページにアクセスしたときです。

    Google の最終的な目標は、サイトが安全でない場合にのみ Chrome でマークを表示し、デフォルトのマークのない状態は安全であるようにすることです。2018 年 9 月から「保護された通信」の表示の削除を開始し、徐々にこの目標を実現していく予定です。さらに 2018 年 10 月からは、ユーザーが HTTP ページにデータを入力するときに表示される「保護されていません」の警告を赤に変更する予定です。

    10 月に公開される Chrome のバージョン(70)では、HTTP ページにデータを入力すると「保護されていません」という通知が赤字で表示されます。

    暗号化を容易にする



    Google では、サイトを HTTPS に移行(または新たに構築)しようとしているサイト所有者ができるだけシンプルにコストをかけずに実現できるように、サポートを提供しています。これまで、Google App Engine でのマネージド HTTPS の提供、すべての .app ドメインでの HTTPS 接続の必須化および自動化、(Chrome がプラチナ スポンサーである)Let’s Encrypt による証明書の無料発行と自動認証などの改善を図ってきました。なお、HTTPS への移行中は、Search Console からのメッセージに記載された詳細情報とガイダンスを確認してください。

    これからは、サイトが HTTPS でデータを保護していない場合は警告が表示されますので、コンサート チケットを購入したり、オンライン バンキングを利用したりするときもご安心ください。皆様が最も安全なブラウザを使用していると確信できるよう、Google では今後も Chrome のセキュリティを強化していきます。

    Google 画像検索の参照元 URL の変更について

    Google 画像検索を使って日々ウェブ上のコンテンツを視覚的に探索するユーザーはかなりの数に上ります。次に焼くクッキーのアイデア、視覚的にわかりやすいタイヤ交換の手順など、ときおりテキスト検索より画像検索のほうがずっと役立つ場合があります。

    参照元 URL の変更

    これまで、サイトへのトラフィックのうち Google 画像検索がどれだけ貢献しているかを把握するのは簡単ではありませんでした。そこで Google では、Google 画像検索専用の新しいリファラー URL を導入し、これから数か月かけて順次ロールアウトしていくことにしました。リファラー URL とは HTTP ヘッダーの一部で、これを見るとユーザーが 1 つ前にいたページ(目的のウェブページを訪れるためにクリックしたページ)がわかります。

    ウェブサイトへのトラフィックの追跡や分析を行うソフトウェアを開発している場合は、ぜひこの変更にご対応いただければと思います。新しいリファラー URL を取り入れて、Google 画像検索からのトラフィックを識別できるようにしてください。新しいリファラー URL は https://images.google.com です。

    サイトデータを Google アナリティクスで追跡している場合は、特に対処の必要はありません。新しいリファラー URL が自動的に適用され、Google 画像検索からのトラフィックを正しく識別できるようになります。なお、この変更は Search Console には影響しません。サイトへのトラフィックに貢献している上位検索クエリの集計リストは、これまでどおりご利用いただけます。

    国別のクエリへの影響

    新しいリファラー URL には、Google 画像検索で使用する URL と同じ国別コード トップレベル ドメイン(ccTLD)が含まれています。つまり、世界中のほとんどのユーザーは images.google.com からのアクセスとなります。昨年実施した変更(英語)で、世界中のユーザーが検索するとき、デフォルトで google.com が選択されるようにしたのはそのためです。ただし、一部のユーザーは引き続き、国別のサービス(日本なら google.co.jp)に直接アクセスしている可能性があります。その場合は、その国の TLD(たとえば images.google.co.jp)が使用されます。

    この変更により、ウェブ上の視覚的なコンテンツがさらに充実することを願っております。ウェブページを Google 画像検索に最適化する方法については、画像公開に関する Google のガイドラインをご覧ください。ご質問、ご意見、ご提案などございましたら、ウェブマスター  ヘルプ フォーラムからお寄せください。

    URL 検査ツールなど、Search Console に新機能を追加しました

    数か月前に新しい Search Console をリリースしましたが、その後も機能の拡充を続けています。ここでは、その最新の状況についてお知らせします。

    「URL 検査」ツール

    Search Console に関するご要望で最も多かったものの 1 つが、「Google 検索が特定の URL をどう認識しているのか、もっと詳しく知りたい」というものでした。こうした声にお応えし、Google 検索をより透明性の高いものにするため、本日新しいツール「URL 検査」のリリースを開始いたしました。URL 検査ツールを使用すると、各ページのクロール、インデックス登録、検索結果の配信に関する詳細情報を Google のインデックスから直接入手できます。

    所有するページの URL を入力すると、最終クロール日とそのステータス、クロールやインデックス登録のエラー、そのページの正規 URL などがわかります。ページが正常にインデックス登録されていれば、ページ内で検出された拡張機能(リンクされている AMP バージョン、レシピや求人のリッチリザルトなど)の情報やステータスもわかります。

    有効な AMP 拡張機能でインデックス登録されている URL

    ページがインデックス登録されていない場合は、その理由を調べることができます。新しいレポートには、ページの noindex robots メタタグと Google の正規 URL に関する情報が追加されています。

    HTML 内の noindex メタタグが原因でインデックス登録されていない URL

    ワンクリックで同じ問題が発生しているページの一覧が開きますので、問題を分析して、修正するのに役立ちます。

    新しい URL 検査ツールが、Google インデックス内の新規ページや既存のページの問題解決に役立つことを願っております。本日より順次リリースを開始し、数週間以内にはすべての方にご利用いただけるようにする予定です。

    その他の変更点

    URL 検査ツールのほかにも、Search Console に新しい機能やレポートを追加しています。

    フィードバックをありがとうございます

    Google では、皆様からお寄せいただいたフィードバック、アンケートの回答、使用統計情報などに常に注意を払い、Search Console の改善に役立てています。インデックス カバレッジ レポートや AMP レポートの新しい問題検証フローも多くの方にご利用いただいていており、これまでより迅速に問題を修正できているように思います。また、メールや [検証の詳細] ページによる検証プロセスの改善も高く評価いただき、チーム一同大変喜んでおります。

    こうしたフローの改善やバグの修正には、皆様からのご意見、ご要望が欠かせません。フィードバックをお寄せいただいたすべての方に感謝いたします。

    今後の展開

    新しい Search Console はまだベータ版ですが、毎月のように機能やレポートを追加しています。さまざまなフィードバック方法を用意しておりますので、今後もご意見、ご要望などございましたらぜひお知らせください。

    ウェブスパムに対する Google の取り組み – ウェブスパム レポート 2017

    Google が常に心がけているのは、Google 検索で情報を探しているユーザーにできる限り質の高い検索結果を提供することです。しかし、検索結果の掲載順位を操作し、そこから利益を得ようとする悪質な行為も後を絶ちません。こうした行為は、「世界中の情報を整理し、世界中の人々がアクセスできて使えるようにする」という Google の使命とは相反するものです。Google は長年にわたって、こうした検索における不正行為やスパムとの闘いに多大な労力を費やしてきました。ここでは、2017 年に Google がどのように不正行為と闘っていたかを紹介します。

    Google では、ウェブマスター向けガイドライン(品質に関するガイドライン)に違反するさまざまなタイプの不正行為をまとめて「スパム」と呼んでいます。独自に分析したところ、ユーザーが検索結果からアクセスしたサイトがスパムサイトだった割合は長年 1% を下回っており、さらにここ数年は 0.5% 以下に抑えることができています。

    2017 年のウェブスパムの傾向と Google の取り組み

    スパムとの闘いはまさにイタチごっこです。対策をとれば、スパマーたちがそれをすり抜ける方法を編み出してきます。2017 年を象徴する傾向の 1 つが、掲載順位の操作やマルウェアの拡散を目的とするウェブサイトへのハッキングの増加でした。ハッキングされたウェブサイトは、ユーザーにとって重大な脅威となります。ハッカーはサイトを完全な支配下に置いて、ホームページを改ざんしたり、有益なコンテンツを削除したり、マルウェアや有害なコードを挿入したりできるからです。また、パソコンなどのキー入力を記録したり、オンライン バンキングや金融取引のログイン認証情報を盗んだりすることもあります。2017 年はこの脅威を軽減することに力を入れ、ハッキングされたサイトの 80% 以上を検知して検索結果から除外できるようになりました。しかしハッキングは、検索を行うユーザーだけでなく、ウェブサイトの所有者にとっても深刻な脅威です。そこで Google では、所有者がウェブサイトを安全に運営できるよう、サイトのセキュリティを強化するための実践的なガイドを提供するとともに、サイトがハッキングされたときの対処方法をまとめたガイドも一新しました。このガイドは 19 の言語でご利用いただけます。

    Google は、堅牢なコンテンツ管理システム(CMS)の重要性も認識しています。多くののウェブサイトは、主要な CMS のいずれかで運営されています。そしてスパマーは、ユーザー生成コンテンツを悪用する(たとえばコメント欄やフォーラムにスパム コンテンツを投稿する)方法を見つけることで、CMS のセキュリティ上の弱点を突いてきます。Google は、主要な CMS を提供している WordPress や Joomla がフォーラム、コメント欄、ウェブサイトを悪用するスパム行為への対策を取れるよう緊密に連携し、支援しています。

    他にも典型的な不正行為として挙げられるのが「リンクの操作」です。リンクは、Google 検索での掲載順位を決める基礎的な要素の 1 つです。2017 年は、ランキング手法の改善と手動による対策の強化を通じて不自然なリンクの削除に力を注ぎ、スパムリンクを前年比でほぼ半数にまで減らしました。

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

    Google は皆様からの報告を歓迎します。スパムの検出やブロックは自動化されたシステムにより常に行われていますが、「フィッシングの疑いがある」といった報告はいつでもお寄せください。検索スパムに関するユーザーからの報告は、昨年 1 年間で 9 万件近く寄せられました。

    スパムやマルウェアなどの問題を Google に報告していただくことは、サイトの所有者や検索ユーザーを不正行為から守ることにつながります。報告フォームは、スパムフィッシングマルウェア用にそれぞれ用意しています。これまでにご報告いただいたすべての方に感謝するとともに、今後も引き続きご協力いただきますようお願いいたします。

    さらに Google は、ウェブ エコシステムの健全性を維持するため、ウェブマスターのみなさまとも積極的に連携しています。

    昨年は、ウェブサイトに問題があることが特定されたサイトの所有者宛てに、Search Console を通じて 4,500 万通のメッセージを送信しました。そのうち 600 万通を超えるメッセージが手動による対策に関わるものです。透明性のあるコミュニケーションにより、ウェブマスターのみなさまがウェブサイトが手動による対策の対象になった理由や問題を解決する方法を理解することができるようにしています。

    新しい Search Console のベータ版をリリース(英語)したのも昨年でした。当初は一部のユーザーに限定してリリースし、その後すべての Search Console ユーザーに公開しました。ユーザーの皆様が何を必要としているかをお伺いして、検索パフォーマンス レポートや、インデックス カバレッジ レポートなど、要望の多かった機能から順に追加しています。こうした機能の拡充により、Google 検索での掲載の最適化がさらに簡単になっています。

    Google は、セーフ ブラウジングの保護機能を強化し、不正なコンテンツ等からユーザーを保護しています。昨年は、この機能を大幅に改良しました。macOS 端末(英語)への保護対象の拡大、Chrome へのフィッシング予測保護機能(英語)の追加、望ましくないモバイル ソフトウェア(英語)への厳正な対処などのほか、不正な Chrome 拡張機能のインストール(英語)からユーザーを保護するために大幅な改善を加えました。

    ウェブマスターの皆様とコミュニケーションするためのチャンネルも多数ご用意しています。オンラインやオフラインで皆様のお話を伺う専門スタッフを配置するとともに、オンライン オフィス アワー、オンライン イベント、オフライン イベントは世界 60 以上の都市で 250 回以上開催し、22 万人を超えるウェブサイトの所有者、ウェブマスター、デジタル マーケティング担当者の皆様にご参加いただきました。また、公式のヘルプ フォーラムでは、さまざまな言語で寄せられた膨大な数の質問にお答えしています。昨年 1 年間にフォーラムで生成されたスレッドは 6 万 3 千件にのぼり、世界中の 100 人以上のトップレベル ユーザーが 28 万件もの回答を投稿してくれました(詳しくはこちらの投稿をご覧ください)。フォーラムブログSEO スターター ガイドに加え、Google ウェブマスターの YouTube チャンネルでもさまざまなヒントやアイデアを紹介しています。新たに SEO スニペットという動画シリーズも始まりました。SEO に関する具体的な質問に、スペシャリストが簡潔かつ的確にお答えしています。この機会にぜひチャンネル登録してください。

    以上のように、昨年 1 年間でさまざまな改善を施しましたが、もちろんこれで終わりではありません。Google が追い求めるのは、不正行為を一切心配する必要のないユーザー エクスペリエンスの実現です。これからもウェブ エコシステムに関わる皆様のご協力をいただきながら、引き続き改善に取り組んでまいります。

    Google I/O 2018 における Google 検索の発表内容をご紹介します

    今年で 10 回目となる Google I/O(英語) が先日開催され、盛況のうちに終了しました。本日はそのハイライトを振り返ってみましょう。

    I/O で検索チームが実施した内容

    このイベントは、世界各地の様々なコミュニティの多数のユーザーと出会い、アイデアを交換し、意見を集める素晴らしい機会となりました。さまざまなウェブ セッション(英語)コードラボ(英語)、オフィスアワーに加えて、私たちは検索に関する 2 つのセッションでコミュニティと情報を共有しました。

    これらのセッションでは、モバイル フレンドリー テスト ツールの JavaScript エラーレポートを発表し、ダイナミック レンダリングについて紹介し(これについては今後の投稿で詳しく取り上げる予定です)、CMS で Indexing API や Search Console API を利用してユーザーに情報を提供する仕組みについて説明しました。たとえば、Wix では、ユーザーがホームページをインデックスに送信(英語)すると、すぐに検索結果に反映されます。また、Squarespace では、見込みのあるユーザーが何を検索しているのかウェブマスターが理解するのに役立つ、Google 検索キーワード レポート(英語)を作成しました。

    また、イベント開催中に、サンドボックス エリアで新しい Search Console を公開し、ユーザーに試していただきました。AMP ステータス レポートについて興味を持った方から、検索に適したコンテンツの改善方法を探している方まで、前向きなフィードバックを多数寄せていただき、嬉しく思います。

    実践的なコードラボ、事例紹介など

    構造化データの追加とテストを体験していただける構造化データ コードラボ(英語)を実施しました。I/O では完了回数の多かったコードラボのトップ 20 にランクインし、大変感謝しています。構造化データを使用するメリットについて詳しくは、事例紹介(英語)をご覧ください。

    直接お会いするオフィスアワーでは、HTTPS、モバイル ファースト インデックス、AMP など、さまざまなトピックへの関心が高いことがわかりました。この形式のオフィスアワーは、毎月実施しているウェブマスター オフィスアワー ハングアウトに加えて、素晴らしい機会となっています。寄せられたご質問やご意見は、誰にとってもわかりやすく使いやすいようにドキュメントやツールを調整するために活用させていただきます。

    ハイライトと主なポイント

    ウェブ デベロッパーの皆様にウェブサイトを構築する際に注意していただきたい主なポイントもお伝えしました。

    • インデックス登録とレンダリングは同時には行われません。レンダリングは後に延期される場合があります。
    • 検索に表示したいコンテンツに、メタデータ、正しい HTTP ステータス、想定どおりの canonical タグが存在することを確認してください。
    • シングルページ アプリ ルーティング向けの JavaScript History API を採用するため、ハッシュベースのルーティング(「#」を含む URL)はサポートを終了する必要があります。
    • Googlebot がリンクを適切にたどれるように、リンクには URL を指す href 属性を指定してください。

    サイトのインデックス登録、ダイナミック レンダリング、トラブルシューティングについて詳しくは、こちらのトーク セッション(英語)をご覧ください。CMS やテーマ作成者としてできることや構造化データについて詳しくは、こちらのトーク セッション(英語)をご覧ください。

    今回の I/O や世界中で開催された I/O Extended(英語)で皆様とお会いし、検索に関する最新情報を共有できて嬉しく思います。今後の最新情報を入手するには、ウェブマスター フォーラムに参加してください。また、TwitterGoogle+YouTube で Google ウェブマスター チームをフォローしてください。

    Google アシスタントにあなたのレシピを届けましょう

    昨年発売した Google Home は、料理のレシピや詳しい手順を音声で案内する機能を備えています。Google Home を日常的に利用するユーザーが増えてきたことにあわせて、レシピを音声ガイド対応にするための新しいガイドラインを公開しました。これによりユーザーは Google Home の Google アシスタントを利用してあなたのレシピを発見することができるようになるため、あなたのレシピはより多くの方に発見されるようになるかもしれません。新しく追加された構造化データ プロパティ(英語)を利用してレシピについての詳しい情報を提供し、さらに良質なトラフィックをサイトに呼び込んでください。

    レシピのプロパティを更新してレシピを見つけやすくする

    このたび、レシピに関するデベロッパー向けドキュメント(英語)を更新しました。このドキュメントに沿ってレシピのプロパティを指定することで、Google 検索や Google Home においてレシピが見つかりやすくなり、サイトへのアクセスをさらに増やすことができます。ユーザーがいろいろな方法でレシピを検索できるようにするには、レシピについての情報をできるだけ詳しく指定する必要があります。特におすすめのプロパティを紹介します。

    • video: 料理の手順を解説する動画を配列として指定できます。
    • recipeCategory: 食事の種類やコース料理での位置付け(「ディナー」、「デザート」、「メイン ディッシュ」など)を指定できます。
    • recipeCuisine: 何料理のレシピかを指定できます(「地中海料理」、「アメリカ料理」、「広東料理」など)
    • keywords: レシピに関連するキーワードを追加します。たとえば、季節(「夏」)、行事(「クリスマス」、「ひな祭り」)、特別なイベント(「結婚式」、「誕生日」)、その他の説明(「クイック」、「低カロリー」、「オーセンティック」)などを追加すると効果的です。

    新たに追加された recipeInstructions を使用すると、料理の詳しい手順を記述できます。1 つ 1 つの手順は、HowToStep プロパティを使用して記述します。HowToSection プロパティを使用すると、こうした手順をセクション単位にまとめることができます。

    Google アシスタント用に手順と材料を追加する

    レシピを Google Home の Google アシスタントで利用できるようにするには、recipeIngredient プロパティと recipeInstructions プロパティを追加する必要があります。これらのプロパティを追加すると、レシピが Google アシスタントに対応して、ユーザーがアシスタントを通じてレシピを見つけることが可能になります。これらのプロパティを指定しない場合、レシピは Google アシスタントの音声ガイドでは利用できませんが、Google の検索結果には表示されます。

    詳しくは、レシピに関するデベロッパー向けドキュメント(英語)をご覧ください。機能についてご不明な点がありましたら、ウェブマスター ヘルプ フォーラムで質問してください。