本記事では、Google ニュースでより成果を上げるために、ニュース メディアの皆様におすすめの方法やアドバイスをご紹介いたします。
Google ニュースのニュース メディア向けヘルプセンターには、検討すべき有益な情報が多数掲載されています。特に、コンテンツと技術的なガイドラインに関する記事をご覧ください。
datePublished
dateModified
Google ニュースでは、発信元のニュース メディアを評価することにより、独立性のあるオリジナルの報道コンテンツに報いたいと考えています。これは、ユーザーにとってもメディアにとっても望ましいことです。つまり、重複したコンテンツ（無断複製されたコンテンツ、書き換えられたコンテンツ、再公開されたコンテンツなど）のパフォーマンスが元のコンテンツより有利にならないように努めています。そのため、ニュース メディアの皆様は、以下のガイドラインに準拠してください。
ニュース メディアの皆様に Google ニュースを適切に実装いただくうえで、上記のヒントが役立つことを願っています。Google ニュースについてさらにご質問がある場合、Google は 1 対 1 のサポートを行うことはできません。しかし、最近リニューアルされた Google ニュースのニュース メディア向けフォーラム（英語版）を確認し、多数のニュース メディアに同時に役立ちそうなご質問がある場合は、ガイダンスを提供しています。このフォーラムは、ニュース メディアの皆様にヒントやアドバイスを互いに共有していただける、素晴らしい情報源となっています。
多くのフロントエンド フレームワークは、コンテンツの表示に 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 は、すべてのネットワーク リクエストが完了し、未処理の作業がなくなるまで待機します。
このブログ投稿で扱う内容
「kitten corner」ウェブアプリは JavaScript を使用して、さまざまな猫の画像を API から読み込み、グリッド形式で表示します。
以下がこのウェブアプリの JavaScript です。
このウェブアプリでは、Googlebot でまだサポートされていない最新の JavaScript（ES6）が使用されています。Googlebot がコンテンツを認識できるかは、モバイル フレンドリー テストを使用することで確認できます。
この問題は簡単に修正できます。こうした修正は、ダイナミック レンダリングを設定する方法を学習するための良い練習となるでしょう。ダイナミック レンダリングにより、ウェブアプリのコードを変更せずに Googlebot に猫の画像を認識させることができます。
ウェブアプリを配信するために、node.js ライブラリの express を使用してウェブサーバーを構築します。
サーバーのコードは以下のようになります（プロジェクトの完全なソースコードはこちらをご覧ください）。
こちらで実際の例を試すことができます。最新のブラウザを使用しているのであれば、複数の猫の画像が表示されるはずです。パソコンからプロジェクトを実行するには、node.js で次のコマンドを実行する必要があります。
次に、使用しているブラウザで http://localhost:8080 を指定します。ここからはダイナミック レンダリングを設定します。
Rendertron は、URL を取得して、headless Chromium によってその URL の静的 HTML を返すサーバーを実行します。Rendertron プロジェクトの推奨事項に沿って、Google Cloud Platform を使用します。
新しい Google Cloud Platform プロジェクトを作成するためのフォームに関しては、無料枠でプロジェクトを作成できる点に注意してください。また、この設定を本番環境で使用すると、Google Cloud Platform の料金体系に応じた課金が発生する点にも注意してください。
Rendertron のウェブ インターフェースが表示されたら、Rendertron インスタンスが正常にデプロイされたことを意味します。次の手順で必要になるため、プロジェクトの URL（YOUR_PROJECT_ID.appspot.com）をメモします。
ウェブサーバーは express.js を使用しており、Rendertron には express.js ミドルウェアがあります。server.js ファイルのディレクトリで、次のコマンドを実行します。
このコマンドにより、npm から rendertron-middleware がインストールされます。これで、rendertron-middleware をサーバーに追加できます。
Rendertron は、ユーザー エージェントの HTTP ヘッダーを使用して、リクエストが bot からのものなのか、ユーザーのブラウザからのものなのかを判断します。Rendertron には、比較に使用できる、適切に整理された bot ユーザー エージェントのリストがあります。Googlebot は JavaScript を実行できるため、デフォルトではこのリストに Googlebot は含まれません。Rendertron に Googlebot リクエストもレンダリングさせるには、ユーザー エージェントのリストに Googlebot を追加します。
Rendertron は後でこの正規表現とユーザー エージェントのヘッダーを比較します。
bot リクエストを Rendertron インスタンスに送信するには、express.js サーバーにミドルウェアを追加する必要があります。ミドルウェアはリクエストしているユーザー エージェントを確認し、既知のボットからのリクエストを Rendertron インスタンスに転送します。次のコードを server.js に追加します。必ず「YOUR_PROJECT_ID」を Google Cloud Platform プロジェクト ID に置き換えてください。
サンプル ウェブサイトをリクエストする 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="cute-puppies.png" alt="ブランケットの上にかわいい子犬がいる写真">
代替テキストが指定されていない例: <img src="sad-puppies.png">
<img src="sad-puppies.png">
多くの素晴らしいウェブサイトが、モバイルでも適切に表示されるようになるのは喜ばしいことです。より多くのウェブサイトがモバイル ファースト インデックスでインデックスされ、サイトへのアクセスに最も使用されるスマートフォンでより多くのユーザーがウェブを検索できるようになることを願っています。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 年はコミュニティにとってどのような年になるでしょうか。またみなさまとお会いできることを楽しみにしております。
