今年の Google I/O で発表したように、Googlebot では Chrome ベースのブラウザを使用してウェブページのレンダリングを行います。さらに、2019 年 12 月には、新バージョンのブラウザに対応する形で Googlebot のユーザー エージェント文字列を更新します。また、それ以降も Googlebot での Chrome の更新に合わせて、バージョン番号を定期的に更新します。
ユーザー エージェント文字列とレンダリングの背景情報については、Google クローラ（ユーザー エージェント）と Google が JavaScript をインデックスに登録できるようにするをご覧ください。
モバイル:
Mozilla/5.0 (Linux; Android 6.0.1; Nexus 5X Build/MMB29P) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/41.0.2272.96 Mobile Safari/537.36 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)
パソコン:
Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)
または
Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; Googlebot/2.1; +http://www.google.com/bot.html) Safari/537.36
12 月には、Googlebot で使用されている Chrome のバージョンを反映させるために、上記のユーザー エージェント文字列の定期的な更新を開始します。次のユーザー エージェント文字列では、「W.X.Y.Z」が、使用している Chrome のバージョンに置き換えられます。たとえば、「W.X.Y.Z」が「76.0.3809.100」のようになります。このバージョン番号は定期的に更新されます。
Mozilla/5.0 (Linux; Android 6.0.1; Nexus 5X Build/MMB29P) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/W.X.Y.Z Mobile Safari/537.36 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)
Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; Googlebot/2.1; +http://www.google.com/bot.html) Chrome/W.X.Y.Z Safari/537.36
評価を実施した結果、この変更はほとんどのウェブサイトに影響しないことがわかっています。
Google が推奨するように、ユーザー エージェント スニッフィングではなく機能検出とプログレッシブ エンハンスメントを使用しているサイトであれば、変更は不要です。
特定のユーザー エージェントを探索しているサイトでは、影響が生じている可能性があります。ユーザー エージェント スニッフィングではなく、機能検出を使用してください。機能検出を使用できず、ユーザー エージェント経由で Googlebot を検出する必要がある場合は、ユーザー エージェント内で「Googlebot」を探してください。
この変更の評価中に見つかった一般的な問題としては、たとえば次のものがあります。
サイトに影響が生じているか不明な場合は、新しい Googlebot ユーザー エージェントを使用して、ブラウザにウェブページを読み込んでみてください。Chrome でユーザー エージェントをオーバーライドする方法については、こちらの手順をご覧ください。
ご質問がある場合は、ウェブマスター ヘルプ コミュニティに問い合わせるか、YouTube のウェブマスター オフィスアワーに参加してください。または、こちらの Twitter をフォローしてください。
動画は、情報をオンラインで得るための重要なメディアとして、利用が拡大しています。Google では、ユーザーがためになる動画を簡単に見つけられるようにしたいと考えています。そこで今回、Google 検索における動画のパフォーマンスを把握し、動画のマークアップを改善する機会を特定できるツールを、新たに 2 つ導入しました。
現在、Google 検索では、メインの検索ページ、動画検索タブ、そして Discover に動画が表示されます。
左から右: メインの検索ページ、動画検索、Discover にそれぞれ表示された動画
構造化データにより、検索エンジンでは動画が表示されているページを認識でき、動画の長さ、アップロード日、その他のメタデータなどの正確な情報に加え、プレビューを含む豊富な視覚的情報が表示されます。ユーザーはそれらを通じ、動画の内容を詳しく把握したうえでクリックできるようになります。
構造化データを使用して動画にアノテーションを付けているサイトについて、Search Console では新たに「動画」レポートを使用できるようになりました。このレポートでは、サイトに実装されているマークアップに関するエラーと警告を確認できます。なんらかの問題を修正した場合には、該当ページが再クロールによって解決されたかどうかを、このレポートで検証できます。詳しくはリッチリザルト ステータス レポートをご覧ください。
Search Console の検索パフォーマンス レポートには、動画タブの検索結果（タイプ = 動画）のパフォーマンスを表示するオプションがすでに用意されていますが、今回、動画に関する機能がさらに拡張されました。動画の見え方を設定する新機能によって、メインの検索結果タブ（タイプ = ウェブ）と Discover でも動画のパフォーマンスを確認できるようになっています。VideoObject 構造化データを使用しているページの場合、または Google が他のシグナルを使用してページ上の動画を検出している場合には、ページ内のコンテンツと合わせて動画の見え方が表示されます。
こうした新しいツールを使用すれば、動画が検索結果でどのように表示されるかを把握でき、問題の特定と修正が容易になるはずです。動画に関するおすすめの方法も参考にしてください。ご質問がある場合は、フォーラムへの投稿をお願いします。
レビュー リッチリザルトが添えられた検索結果は、プロダクトやサービスを探すうえで大変役に立ちます（検索結果の横に時折表示されているあのスコアや星です）。
これをさらに便利で役立つものにするため、Google ではレビュー リッチリザルトのアルゴリズムの更新を行いました。これにより、ウェブマスターから報告された無効、または誤解を招くような実装の一部も解決されます。
レビュー マークアップは、技術的にはどのスキーマタイプにも追加できますが、多くのタイプでは、星による評価はユーザーにとってあまり意味がありません。今回の変更により、検索でレビュー リッチリザルトをトリガーできるスキーマタイプが限定されます。具体的には、以下のタイプ（およびそのサブタイプ）へのレビューのみが表示されるようになります。
「セルフサービング」と見なされるレビューは、ユーザーの利益を最優先にしたものではありません。Google では、エンティティ A に対するレビューがエンティティ A のウェブサイトに（直接マークアップで、または埋め込まれたサードパーティ ウィジェットを介して）置かれている場合、そのレビューを「セルフサービング」と呼びます。そのため、今回の変更により、レビュー対象のエンティティ自身がそのレビューを制御している場合、スキーマタイプ localBusiness と Organization（およびそのサブタイプ）に対するレビュー リッチリザルトは表示されなくなります。
今回の変更から name プロパティが必須となるため、レビューには必ず name を指定しなければならなくなります。
さらなる情報提供を目的として、ローカル ビジネスや組織などのエンティティはこれまで、自身に関するレビュー マークアップをホームページやその他のページに追加して、そのページにレビュー スニペットを表示させることができました。こうしたマークアップは、エンティティが直接追加することもあれば、サードパーティ製のウィジェットを使用して埋め込むこともありました。
Google ではこれを「セルフサービング」であると考えています。ローカル ビジネスまたは組織が、自身に関するマークアップを、自身のページに自ら追加しているためです。
ローカル ビジネスまたは組織（LocalBusiness または Organization スキーマタイプ）によるセルフサービングなレビューは表示されなくなりました。たとえば、特定の商品やサービスに関するレビューを表示するリッチ レビュー スニペットも、それがセルフサービングであると見なされれば表示されません。
こちらのドキュメントに記載されているその他のスキーマタイプに関するレビューは許可され、表示されます。たとえば料理関連のサイトで、レシピに関する訪問者のレビューをまとめる目的で、マークアップを使用することは可能です。そのリッチ レビュー マークアップは、該当するレシピが検索結果に表示される場合にも適用される可能性があります。
よくある質問
当社の商品やサービスに関するレビューを、サードパーティ製のウィジェットを使用して表示している場合はどうなりますか？
その場合、Google 検索では、該当するページのレビュー スニペットが表示されません。サードパーティ製のウィジェットを埋め込むことは、レビューをリンクさせるプロセスを操作する行為であると見なされます。
セルフサービングなレビューは、LocalBusiness または Organization から削除する必要がありますか？
いいえ。削除する必要はありません。Google 検索では、そうしたページのレビュー スニペットが表示されなくなるというだけです。
自社のサイトにセルフサービングなレビューを掲載した場合、手動による対策はとられますか？
それだけで手動による対策がとられることはありません。ただし、構造化データが Google のガイドラインに違反していないことを確認することをおすすめします。
今回の更新は、当社の Google マイビジネスのリスティングやプロフィールには影響しますか？
いいえ。今回はオーガニック検索だけに関連する更新であるため、Google マイビジネスには影響しません。
他の組織に関するレビューをまとめたサイトには影響しますか？
いいえ。それについては何も変わりません。レビューをまとめたサイトの場合は、他の組織に関するレビュー スニペットを含めて検索結果に表示されます。
今回の更新は AggregateRating にも適用されますか？
はい。Review と AggregateRating に適用されます。
Review
AggregateRating
引き続き検索結果にセルフサービングなレビューが表示されている場合は、どのように報告すればよいですか？
Google では、必要に応じてそうした場合の専用フォームを用意することを検討しています。今回の変更は段階的に実施しているため、適切でないレビューの星が引き続き表示される可能性があります。
この変更により、ユーザーにとってのレビューの有用性が大きく向上する一方、ほとんどのウェブマスターにとって、必要となる作業は皆無か、あるとしてもわずかです。上記の変更はすべて、デベロッパー向けのドキュメントに記載されています。ご不明な点がございましたら、ウェブマスター フォーラムをご利用ください。
Posted by Yuxin Cao, Software Engineer & Sven Naumann, Trust & Safety Search
【2019/11/11 追記】
Webmaster Conference Tokyo & Osaka の Lightning Talk の詳細が決定しました！スピーカー及びタイトルは次の通りです。 Webmaster Conference Tokyo タイトル＆スピーカー（敬称略）
Posted by Takeaki Kanaya, Senior Search Evangelist, Google
Google ではほぼ毎日、検索結果を改善するための変更をリリースしています。大半の変更は目に見える変化を伴わない場合が多いですが、これらを積み重ねることで、日々検索の改善に取り組んでいます。
時には、皆様がはっきりと変化に気づくようなアップデートを行う場合もあります。ウェブマスターやコンテンツ プロデューサーなどの皆様が対応したり措置を講じることができる実用的な情報がある場合、Google ではそのようなアップデートを周知しています。たとえば「Speed Update」を実施した際には、その数か月前から事前通知とアドバイスを公開しました。
Google では年に数回、検索アルゴリズムとシステムに重要かつ大規模な変更を加えており、このような変更を「コア アップデート」と呼んでいます。コア アップデートは、全体として、関連性が高く権威あるコンテンツを検索ユーザーに提供するという Google の使命を果たすために行われます。また、コア アップデートは Google Discover に影響する場合もあります。
コア アップデートは広範囲に変化や影響が現れるため、Google ではその周知を図っています。一部のサイトでは、コア アップデート後に掲載順位が下がったり、逆に上がったりすることがあります。掲載順位が下がった場合はサイトを修正しようと思うかもしれませんが、間違った修正を行わないように注意してください。場合によっては、まったく修正の必要がないこともあります。
ページに問題がなくても、コア アップデート後にパフォーマンスが低下することがあります。こうしたサイトは、ウェブマスター向けガイドラインに違反したわけでも、手動またはアルゴリズムによって違反に対する対策が取られたわけでもありません。実際のところ、コア アップデートには、特定のページやサイトを対象とした変更はありません。コア アップデートの変更は、コンテンツ全体に対する Google のシステムの評価方法を改善するために行われます。この変更により、過小評価されていたページのパフォーマンス向上も見込めるようになります。
コア アップデートの影響を理解するには、例えば 2015 年に作成した映画トップ 100 のリストを想像してみるのがよいでしょう。2015 年からしばらくたった 2019 年では、リストを更新する必要があります。リストが変更されることは自然なことです。以前は存在しなかった新しい素晴らしい映画がいくつかトップ 100 に加わるかもしれません。評価が見直され、以前よりも高い順位にランクインする映画もあるかもしれません。
リストが更新され、以前は高い位置にランクインしていた映画のランクが下がったとしても、その映画が悪いわけではありません。それは単に、その映画よりも高い評価を得た映画があったというだけのことです。
これまで説明したとおり、コア アップデート後にページの掲載順位が下がったとしても、そのページに修正すべき問題があるとは限りません。それでも、コア アップデート後に掲載順位が下がった場合は、何かする必要があると感じるかもしれません。そのような場合は、できるだけ優れたコンテンツの提供に集中することをおすすめします。Google のアルゴリズムでは、コンテンツの品質に基づいて掲載順位を決定しているからです。
まずは、コンテンツの品質を自己評価する方法に関して Google が過去に提示したアドバイスを再確認しましょう。Google では、今回このアドバイスを更新し、コンテンツを自己評価するための新しい質問を追加しました。
これらの質問を自分自身に問いかけるだけでなく、あなたのサイトと無関係な信頼できる第三者に正直に評価してもらいましょう。
また、掲載順位が下がった場合、その状況を精査することも検討してください。どのページが最も影響を受けたか、そしてどんなタイプの検索で最も影響を受けたかを調査しましょう。それらのページを詳しく調べることで、上記の質問に対してどのようにページが評価されたのかを理解できます。
最適なコンテンツに関するアドバイスを紹介するもう一つのリソースとして、検索品質評価ガイドラインをご紹介します。Google には、アルゴリズムが適切な検索結果を提供しているか検証し、知見を提供する品質評価者という役割が存在します。この品質評価者は、アルゴリズムに対する変更が正しく機能しているかを確認するのに貢献しています。
大事なこととして知っておいていただきたいのは、検索品質評価者はページの検索順位を制御できないということです。品質評価者のデータが直接ランキングのアルゴリズムで使用されることはありません。品質評価者のデータは、レストランにあるフィードバック カード（お客様アンケート）のようなものです。こうしたフィードバックを利用して、Google のシステムが機能しているかを確認しています。
品質評価者がどのようにコンテンツの品質を評価しているかを理解すれば、コンテンツの改善に役立てることができるかもしれません。そして、コンテンツを改善することで、Google 検索での掲載順位も改善される可能性があります。
品質評価者は、Google が E-A-T と呼ぶ基準に基づいてコンテンツが優れているかを判断するために特別な訓練を受けています。この基準は「Expertise（専門性）」「Authoritativeness（権威性）」「Trustworthiness（信頼性）」を意味します。品質評価ガイドラインを確認することで、E-A-T の観点からコンテンツを評価して、検討すべき改善点を見つけられるかもしれません。
以下に、品質評価ガイドラインをアドバイスとして活用したサードパーティの記事を紹介します（リンク先はすべて英語となります）。
注意: 上記の記事へのリンクは特定の SEO 企業または SEO サービスを推奨するものではありません。このトピックに関して役に立つコンテンツを掲載している記事としてのみ紹介しています。
コア アップデートが実施された後によく寄せられる質問は、コンテンツを改善した場合、サイトの掲載順位が回復するまでにどれくらいかかるかという質問です。
大規模なコア アップデートは、数か月ごとに行われる傾向にあります。サイトがコア アップデートの影響を受け、その後にコンテンツを改善した場合、掲載順位が回復する可能性があるのは、次の大規模なコア アップデートのリリース時です。
しかし、Google では常に検索エンジンのアルゴリズムを更新しており、その更新には小規模なコア アップデートも含まれます。一般的に、小規模なコア アップデートは変化が見えづらいため、個別にお知らせすることはしていません。それでも、コンテンツの改善行われていれば、小規模なコア アップデートがリリースされたときにサイトの掲載順位が回復する可能性はあります。
サイトの所有者が改善を行ったとしても、掲載順位の回復が保証されるわけではありません。また、ページの掲載順位が検索結果で固定されたり、一定の掲載順位が保証されたりすることもありません。Google のシステムで常にページが上位にランキングされるようにするには、それに相応しいコンテンツが必要です。
Google のような検索エンジンは、人間とは別の方法でコンテンツを理解しているということを意識することも重要です。Google では、コンテンツに関して収集できるシグナルを探しています。そして、それらのシグナルが、人間が関連性を評価する方法とどれくらい相関しているかを確認しています。ページ間のリンクは、有名なシグナルの 1 つです。それ以外にも多数のシグナルが存在しますが、検索結果の信頼性を守るためにそれらのシグナルを公開することはしていません。
大規模なコア アップデートを公開する前には必ずテストを行います。前述の検索品質評価者からのフィードバックを収集するなどして、シグナルの重み付けが好ましいものであるかを確認しています。
もちろん、Google 検索の改善に完璧なものなどありません。Google がアップデートをし続ける理由はそこにあります。Google では多数のフィードバックを取り入れて、テストを積み重ね、ランキング システムを常に改善しています。Google のこの取り組みは、コンテンツの所有者が変更を行わなかったとしても、ページの掲載順位が将来回復する可能性があるということを意味します。何もしなくてもページの掲載順位が上がった場合、ランキング システムの継続的な改善によって、そのページのコンテンツの評価が高くなった可能性があります。
この記事で紹介したガイダンスが皆様のお役に立てることを願っています。また、ツール、ヘルプページ、フォーラムなど、Google ウェブマスターから提供されるリソースでは、優れたコンテンツに関する多くのアドバイスを確認できます。詳細はこちらからご確認ください。
nosnippet
max-snippet:[number]
max-video-preview:[number]
max-image-preview:[setting]
<meta name="robots" content="max-snippet:50, max-image-preview:large">
<p><span data-nosnippet>Harry Houdini</span> is undoubtedly the most famous magician ever to live.</p>
ほとんどの時間は、Google の検索エンジンは正常に動作しています。私たちは、ウェブを検索しているユーザーや、Google にインデックス登録されているサイトのウェブマスターに影響を及ぼすような、技術的な問題が起きないように尽力しています。同様に、検索エンジンの基盤となるシステムも、ほとんどの場合意図したとおりに動作しています。わずかな障害が発生しても、サービスの運用を担当するチーム以外はほとんどわかりません。ただし、複雑なシステムである以上、大規模な障害が発生することがあり、ユーザーとウェブマスターの双方に影響する可能性があります。
過去数か月の間に、インデックス登録システムで問題が発生し、インフラストラクチャの他の部分にも波及しました。できる限り迅速に状況の改善に取り組みましたが、ユーザーとウェブエコシステムに高品質のサービスを継続的に提供するという目標に反することになり、誠に申し訳ありませんでした。
その後、何が起きたのかを綿密に精査しました。その過程で得られたいくつかの教訓をここで皆さんと共有したいと思います。このブログ投稿では、発生した問題について詳細に説明したのち、今後同様の問題が発生した場合にどのようにみなさまにお伝えする予定でいるかを共有します。その上で、Google への問い合わせ方法ついてウェブマスターの方々に改めてお伝えします。
4 月に、インデックスに関する問題がいくつか発生しました。Google の検索インデックスは、ウェブからクロールした、ユーザーの質問に答えるのに有用と思われる数千億のウェブページを保持するデータベースです。ユーザーが Google 検索エンジンでクエリを入力すると、ランキング アルゴリズムが検索インデックスに登録されているページの中から、最も有益で関連性の高い検索結果を瞬時に見つけます。では、何が起こったのか、詳しく見ていきましょう。
はじまりは検索インデックスの一部が一時的に失われたことでした。「インデックスの一部が失なわれた」とはどういうことでしょうか。
基本的に、検索結果をユーザーに提供する場合、サービス速度を向上させるために、ユーザーのクエリは Google 検索サービスをサポートする最も近いデータセンターに「旅」します。ここで Search Engine Results Page（SERP）が生成されます。そのため、インデックスの構成に変更（一部のページの追加や削除、ドキュメントの統合、または他の種類のデータ変更）がある場合、対象となるすべてのデータセンターに変更を反映する必要があります。結果として、世界中のユーザーに、最新バージョンのインデックスから一貫したページが提供されます。
すべてのデータセンターで同一のインデックスを維持し続けることは簡単な作業ではありません。大規模なユーザー向けサービスの場合、まず 1 つのデータセンターで更新をデプロイし、関連するすべてのデータセンターが更新されるまで拡大していきます。慎重に扱うべきインフラストラクチャについては、数日間にわたってロールアウトを実施し、異なる地域のインスタンスにインターリーブすることもあります（出典）。
予定していた検索インデックスに対する変更を進めている最中の 4 月 5 日（金）にデプロイシステムの一部が破損しました。具体的には、一部のデータセンターでインデックスを更新しているときに、少数のドキュメントが誤ってインデックスから削除されてしまいました。これが「インデックスの一部が失なわれた」ということです。
幸いにも、Google のオンコール エンジニアが問題を即座に察知しました。これは、私たちがソーシャル メディア上で問題を認識し始めたのと同時でした（週末に Google に連絡してくれた皆さん、ありがとうございました！）。その結果、問題が察知されてからわずか数時間で、すべてのデータセンターの検索インデックスを以前の安定した状態に戻し始めることができました（Google では、このような事態に備えてインデックスのバックアップを保持しています）。
Google は 4 月 7 日（日）に、この問題を認識しており、正常な状態に戻りつつあることを報告しました。データセンターのインデックスが徐々に安定した状態に戻りつつある中、Twitter での発信を続けました（4 月 8 日、4 月 9 日）。これは、4 月 11 日にすべてのデータセンターのインデックスが完全に元通りになったと確信できるまで続きました。
Search Console は、ウェブマスターが利用できる一連のツールやレポートであり、ウェブサイトの検索に関するパフォーマンスのデータにアクセスできます。たとえば、毎日のオーガニック検索結果における表示回数やクリック数、または検索インデックスに登録されているページ、未登録のページに関する情報を確認できます。
検索インデックスに上記の問題が発生した結果、Search Console でも不整合が見られるようになりました。これは、Search Console で表示されるデータの一部が検索インデックス自体から抽出されているためです。
基本的に、Search Console の個別レポートの多くは、専用データベースからデータを抽出しています。このデータベースの一部は、検索インデックスから取得した情報を使用して構築されています。以前のバージョンの検索インデックスに戻す必要があったため、Search Console データベースの更新も一時停止する必要がありました。これにより、一部のレポート（および URL 検査ツールなどの他のレポート）のデータが横ばい状態になりました。
問題が発生した検索インデックス全体のロールバックに数日かかったため（上記の説明を参照）、インデックス登録の問題が修正された数日後まで Search Console データベースの修正に取り掛かることができませんでした。Google は 4 月 15 日に、Search Console に問題があり、修正に取り組んでいることをツイートで明らかにしました。修正が完了したのは 4 月 28 日（レポートで新しいデータの収集を再開した日。上のグラフを参照）でした。4 月 30 日には Twitter で問題が解決したことを報告しました（ツイート）。
Google 検索は数多くのシステムで構成されており、それぞれが別のシステムと密に連携しています。問題が同時期に起きた場合そこには因果関係があることが多いですが、場合によっては同時期に直接関係のない複数の問題が発生することもあります。
たとえば今回のケースでは、上記で説明したインデックス登録の問題とほぼ同時期に、新しい Google ニュースにおける最新のコンテンツの収集に関する問題が短時間発生しました。さらに、ページのレンダリング中に、特定の URL が Googlebot を他の無関係なページにリダイレクトし始めました。この問題はインデックス登録の問題とは関係ないもので、すぐに解決することができました（ツイート 1、ツイート 2）。
数週間の間に行った（これまでご紹介してきた）ソーシャル メディアを使用した報告に加え、2 つの別チャネル（Search Console と Search Console ヘルプセンター）でウェブマスターに詳細を説明しました。
Google は、問題を完全に特定した後、Search Console のデータの異常に関するヘルプページを更新しました。このページは、多数のウェブマスターに影響が及ぶ場合に、データ破損に関する情報を Search Console サービスに伝えるために使用されます。
すべてのユーザーがソーシャル メディアや外部のヘルプセンター ページを読むわけではないので、Search Console レポートにアノテーションを追加して、データが正確でない可能性があることをユーザーに通知しました（下の画像を参照）。この情報は、問題が解決した後に追加したものです。[詳細を見る] をクリックすると、ヘルプセンターの「データの異常」ページに移動します。
問題が発生した場合、Google には「事後分析」の文化があります。障害に関して報告するドキュメントを作成し、同じ問題が今後発生しないよう努めます。プロセス全体について詳しくは、Google サイト信頼性エンジニアリングのウェブサイトをご覧ください。
4 月のインデックス登録の問題をきっかけに、大規模なシステム障害が発生した場合にウェブマスターに明確に伝える方法を事後分析に含めました。主な決定事項は次のとおりです。
上記のコミットメントは、今後起こり得る同様の状況に備えて、ウェブマスターに対し全体的な透明性を確保するためのものです。
5 月 22 日に別の問題が発生した際、新しいコミュニケーション方法を試しました。発生した問題は、特定の URL の処理中、予定されていたインフラストラクチャ アップグレードの後に重複管理システムのメモリが不足し、すべての受信 URL の処理が停止したというものです。
上記 の 3 つのポイントに加えて、コミュニケーションについて考慮した結果を時系列で示します。
8 月にも同様のインデックスの問題が発生しました。5 月 22 日の時と同じように、みなさんに問題の発生と問題解決に取り組んでいることをお伝えするツイートを行い、問題が解決した際にもツイートしてお知らせしました。
この投稿により、Google のシステムの複雑さと、時にはシステム障害が発生する事を知っていただけたことと思います。また、問題が発生したときに Google がどのようにお知らせするかをご理解いただく一助となれば幸いです。ただし、この投稿ではシステムの広範囲にわたる障害に焦点を当てていますが、ほとんどのウェブサイトにおけるインデックス登録の問題は、個々のウェブサイトの構成に原因があります。構成によっては Google 検索が対象のウェブサイトのインデックスを適切に登録できない場合がありますので、ご留意ください。そのような場合、ウェブマスターは Search Console やヘルプセンターを使用して問題をデバッグすることができます。デバッグした結果、自身のサイトの問題ではないと考えられる場合、または解決方法がわからない場合は、Google や Google コミュニティまでご連絡ください。いつでもお待ちしております。Google に問題を報告する方法は次のとおりです。
Google では長年にわたり、数百ものカンファレンスやイベントに参加して数千人ものウェブマスターの皆様にお話をしたり、数百時間にもおよぶ動画を録画したりすることで、ウェブ制作者の皆様が Google の検索結果でのパフォーマンス向上に役立つ情報を容易に入手できるよう努めてきました。今回それをさらに一歩進めて、海外の会議への参加が困難な方でも同じ情報を入手できるようにしたいと考えました。
そこでこの度 Google は、Webmaster Conference を世界各地で開催していくことを正式に発表します。このイベントは主に、検索カンファレンスへの参加や Google 検索関連情報の入手が困難な地域や、特に検索イベントの必要性が高い地域で開催します。たとえば、ある地域でハッキングされたサイトの問題が生じていることが判明した場合は、そのトピックに焦点を当てたイベントを開催するかもしれません。
Google は、言語、経済状況、性別、場所などの属性に関係なく、ウェブ制作者の皆様に平等に機会を提供したいと考えています。そのため、Webmaster Conference は常に無料で、その地域のアクセスが容易な場所で開催されます。また、地域のコミュニティからのフィードバックと分析に基づいて、イベントに登録した皆様に適したものになるよう調整が行われます。つまり、このイベントは、参加者が Google 検索に対して持ち合わせている知識に関係なく、必要な情報を得られるように調整されているということです。スピーチは開催地の言語で行われ、他言語の場合は通訳が付きます。ご要望に応じて、可能な限り手話通訳も提供したいと考えています。
イベントの構成は地域によって異なります。たとえば日本の沖縄では、ウェブ制作の初心者から上級者の方までが一堂に会し、Google 画像検索でのパフォーマンス向上に焦点を当てた有意義なイベントが、半日にわたって開催されました。Webmaster Conference India や Webmaster Conference Indonesia では構成を変えて、より高速なウェブサイトの開発に焦点を移すことが考えられます。今年の後半にはヨーロッパと北アメリカでもウェブ コミュニティを開催する予定です。詳しくは今後の発表をお待ちください。
Google は、今後もこれまでどおり外部のイベントに参加します。ここで紹介したイベントは、既存のイベントを補完する目的で開催するものです。今後のイベントについて詳しくは、毎月更新される Webmaster Conference サイトをご覧ください。また、Google のブログや @googlewmc（Twitter）のフォローもお忘れなく！
構造化データに関する前回の記事で、構造化データとは何か、なぜサイトに追加すべきなのかという点について説明しました。Google では構造化データを重視しており、関連する検索機能の強化やツールの改良に継続的に取り組んでいます。そのため、Google はウェブマスターやデベロッパーの皆様による構造化データの実装および診断を支援するソリューションの開発に力を注いでいます。
この記事では、サイトの構造化データをモニタリングし、最大限に活用するために、Search Console でできることについて説明します。また、より有用な新機能についてもご紹介します。以下が新たに追加される内容です。詳細については記事の中で取り上げます。
Search Console では、ウェブサイトで構造化データに関する問題が新たに検出されるたびに、アカウント所有者にメールが送信されます。しかしながら、既存の問題が悪化した場合には、メールは送信されません。そのため、定期的に Search Console を確認する必要があります。
毎日そのような作業を行う必要はありませんが、すべての機能が意図したとおりに動作しているか、時折確認することをお勧めします。ウェブサイトへ変更を加えた際にはしばらくして Search Console で変更が上手く行ったかどうかを確認するのを習慣づけるのも良いかもしれません。
サイトの特定の構造化データ機能に関するすべてのエラーについて把握しておきたい場合は、左側のサイドバーにある拡張メニューに移動し、確認したい機能をクリックします。すべてのエラーと警告、正常な項目について、概要を確認できます。
冒頭で述べたとおり、今回、新たにサイトリンク検索ボックスとロゴの項目がレポートに追加され、サイトの構造化データについてより詳細に把握できるようになりました。レシピ、イベント、求人情報などの既存のレポート項目に加えられています。レポートの詳細については、Search Console ヘルプセンターをご覧ください。
では、ここで拡張レポートのサンプルを見てみましょう。レポートに表示されるのは、拡張レポートの中でもページで検出された項目のみです。次のような内容を確認するのに役立ちます。
今回、解析不能な構造化データに関するレポートも導入されています。これは、構造化データの構文エラーなどにより、Google による機能タイプの識別が妨げられているケースを集計するものです。機能タイプの識別ができないことから、機能別のレポートを生成するのではなく、このようなケースの集計を行うことにしています。
サイトに追加しようとした構造化データが解析されなかった場合には、データの種類にかかわらず、このレポートを確認してください。解析の問題が発生しているということは、サイトでリッチリザルトを活用できる機会が失われている可能性があります。下のスクリーンショットは、実際のレポートの様子です。さらに、レポートに実際にアクセスすることもできますし、ヘルプセンターでレポートについて詳しく確認することもできます。
ページが正常に処理されているか、またはリッチリザルトが有効になっているかを確認したい場合や、特定の URL でリッチリザルトが表示されない原因を突き止めたい場合には、URL 検査ツールを使用できます。このツールを使用することで、改善すべき部分を URL レベルで把握でき、対処すべき内容がわかりやすくなります。
Search Console の上部にある検索ボックスに URL を貼り付けると、拡張した項目に関連する構造化データの正常動作部分や、エラーまたは警告が生じている部分を確認できます。下にレシピの場合のサンプルを示します。
上のスクリーンショットでは、レシピに関してエラーが発生しています。レシピの項目をクリックすると、エラーに関する情報が表示されます。さらに、エラーの右側にある小さなグラフアイコンをクリックすると、詳細を確認できます。
エラーについて確認し、修正を行ったら、[修正を検証]（下のスクリーンショットを参照）をクリックしてください。Google が本当に問題が修正されたかを検証します。[修正を検証] ボタンをクリックすると、いくつかのテストがすぐに実施されます。ページがテストに合格しなかった場合は、Search Console にすぐに通知が表示されます。問題がなかった場合は、該当するページの他の箇所が Search Console で再処理されます。
Search Console が役に立った事例や、構造化データとともに使用することでより便利になった事例などがありましたら、ぜひフィードバックをお寄せください。フィードバックは、ウェブマスター フォーラムからお送りいただけます。
Google では長年にわたり、優れた検索エクスペリエンスを提供するために、ウェブサイトで構造化データを使用することを推奨してきました。マークアップをコンテンツに追加すると、検索エンジンがページのさまざまなコンポーネントを認識できるようになります。Google のシステムにページをより具体的に認識させることで、本ブログ記事で紹介する魅力的な機能を使用して、Google 検索でコンテンツを際立たせることができます。これにより、ユーザー エクスペリエンスを向上させ、アクセス数を増やすことができます。
Google では、Google 検索の結果にウェブサイトがどのように表示されるか、また解決できる問題があるかどうか、この 2 点を把握するためのツールを提供するための取り組みを進めてきました。今回から、複数の記事にわたって構造化データの概要についてご紹介いたします。今回はまず構造化データについて簡単に紹介し、おすすめの方法について説明します。次回からは、Search Console を使用して構造化データを処理する方法に焦点を当てます。
構造化データは、ページとそのコンテンツに関する情報を提供するための一般的な手段です。そのためには schema.org の仕様に従ってマークアップを記述することをおすすめします。Google では、JSON-LD（推奨）、Microdata、RDFa の 3 種類のページ内マークアップ形式をサポートしています。検索機能が異なると、必要になる構造化データも異なります。詳細については、検索ギャラリーをご覧ください。Google のデベロッパー向けドキュメントでは、構造化データの基本について詳細に記載されています。
構造化データを記述することによって、Google のシステムがコンテンツをより正確に認識できるようになり、これにより、ユーザーもより関連性の高い結果が得られるようになります。構造化データを実装すると、Google の検索結果でページをさらに際立たせるための準備は完了です。
免責条項: ページが正しくマークアップされていても、構造化データが検索結果に表示されるとは限りません。構造化データを使用して、ある機能が表示されるよう設定することはできますが、その機能が必ず表示されるとは限りません。詳細については、構造化データに関するガイドラインをご覧ください。
ここ数年間で、エコシステムで構造化データを採用する動きが拡大してきました。リッチリザルトは一般的に、ユーザーが検索を行ったときに、検索している内容とページがどのように関連しているかを理解するのに役立ちます。そのため、リッチリザルトはウェブサイトに大きなメリットをもたらします。Google の事例紹介の中から、成果をいくつかご紹介します。
サイトで構造化データのメリットを活用するには、いくつかの方法があります。以下では、目標（ブランド認知度を高める、コンテンツを紹介する、商品情報を紹介する）ごとに例を説明します。
構造化データを使ってブランドを宣伝する方法の 1 つとして、ロゴ、ローカル ビジネス、サイトリンク検索ボックスなどの機能を利用することが挙げられます。構造化データを追加するだけでなく、サイトのナレッジパネルを確認して、Google マイビジネスでビジネスを登録する必要があります。以下は、ロゴ付きのナレッジパネルの例です。
ウェブ上でコンテンツを公開している場合、業界に応じて、コンテンツを宣伝してユーザーへの訴求力を高めるのに役立つ機能が多数用意されています。たとえば、記事、パンくずリスト、イベント、求人情報、Q&A、レシピ、レビューなどがあります。レシピのリッチリザルトの例を示します。
商品を販売している場合、商品の構造化データ（価格、在庫状況、評価など）をページに追加できます。次に関連検索で商品がどのように表示されるかを示します。
これで構造化データの重要性を理解していただけたと思います。Codelab を利用して、ページに構造化データを追加する方法を確認してください。本ブログでは、今後も構造化データについてご説明いたします。次回は、Search Console を使って構造化データによる効果を分析する方法について説明します。
構造化データの有効な使用方法について、お客様のご意見、ご感想、事例をお待ちしています。フィードバックをご提供いただける場合は Google のコミュニティ フォーラムをご利用ください。
2019/06/10 追記 タイトルを修正しました。
Googlebot は、Google 検索のインデックスにウェブページを追加するためにウェブページを巡回しているクローラのことです。イベントやソーシャル メディアで寄せられる質問で最も多いものは、この Googlebot を最新の Chromium にアップデートしないのですか？というものでした。このたび、Googlebot では検索用にページをレンダリングする際に、最新の Chromium レンダリング エンジン（この投稿の時点でバージョン 74）を実行するようになりました。今後、Googlebot のレンダリング エンジンは定期的に更新され、最新のウェブ プラットフォームの機能をサポートできるようになります。
以前のバージョンと比べて、Googlebot では次のような 1,000 以上の新機能がサポートされるようになりました。
Googlebot 用の処理としてトランスパイルまたは polyfill を使用しているかどうかをご確認ください。使用している場合は、この処理が今後も必要かどうかをご検討ください。現在も一定の制限があるため、JavaScript 関連の問題のトラブルシューティングや JavaScript SEO に関する動画シリーズをご確認ください。
この投稿に関するご意見やご感想がありましたら、ウェブマスター フォーラムでお知らせください。または、オンライン オフィスアワーにご参加ください。
今年 1 月、仕事探しをよりスムーズにするために日本でもGoogle しごと検索がローンチしました。ウェブマスターが求人情報の構造化データを設定すると、求職者をあなたのサイトの求人情報に結びつけることにつながり、より関心の高い求職者をあなたのサイトの求人情報に誘導できます。そこで、求職者が満足できるよう、求人情報ガイドラインを遵守することが重要です。ここでは、以下の三点についてお知らせいたします。
求職者が求人情報を見つけ、応募しようとしても、求人情報の有効期限がきれて応募できないのは、とても残念なことです。求職者は、求人情報に応募しようと決めたあとに、期限切れの求人であると気づくことがあります。期限切れの求人ページをあなたのサイトから削除することで、トラフィックが増加する可能性があります。求人情報を削除する方法については、求人情報を削除するを参照してください。
求職者は、求人情報の詳細ページにたどりつきたいのであり、求人リストにたどりつくのが目的ではありません。求人リストへのアクセスを回避するには、可能な限りもっとも詳細なページに構造化データを配置することです。求人リストの表示ページ（たとえば、求人検索結果ページ）に構造化データを配置しないで下さい。ひとつの仕事について詳細に記載されている求人情報ページにのみ、構造化データを配置してください。
JobPosting 構造化データに、求人掲載に存在しない情報が含まれているサイトがあります。Google しごと検索で表示される求人の詳細と、求人情報の説明ページが一致しない場合、求職者は混乱します。JobPosting 構造化データ内の情報が、常に求人掲載ページの情報と一致していることを確認してください。ここでは例を示します。
JobPosting
求人掲載ページのコンテンツと整合性のある構造化データを提供することは、求職者が仕事を見つけるのに役立つだけではなく、あなたの求人情報に対し、より関心の高い候補者を集められることにつながり、求人に適した候補者を見つけられるようになります。
あなたのサイトが求人情報ガイドライン（このブログ投稿のガイドラインも含む）に違反している場合、Googleでは、あなたのサイトに対して手動による対策を実行し、Google しごと検索に求人を表示することができなくなる可能性があります。よくみられる違反例としては、構造化データの title フィールドに、給与や会社情報、キャッチコピーなどを詰め込んでいるケースです。タイトルには「ソフトウェア エンジニア」のように職務の名称のみを指定してください。求人情報のタイトルではありません。また、構造化データの hiringOrganization プロパティには、職務をを提供している組織名、会社名のみ指定してください。所在地や求人情報は含めないでください。手動による対策を受けた場合、問題を修正し、再審査リクエストを送信すると再審査を行えます。再審査で問題の修正が承認されると、あなたのサイトやページが、手動による対策から解除されます。
詳細については、Job Posting 開発者向けドキュメントおよび Job Posting よくある質問を参照してください。
Discover は、検索をしていなくてもお気に入りのトピックに関する最新情報を入手できる機能として広く利用されています。そしてこのたび、ウェブマスターのみなさんがご自身のサイトへの Discover 経由のトラフィックを詳細に把握できるように、Google Search Console に新しいレポートを追加しました。このレポートにより、関連性の高い統計情報を共有し、次のような疑問に対する回答を見つけられます。
Discover は Google 検索の一機能で、検索をしていなくてもお気に入りのトピックに関する最新情報を入手できます。ユーザーは、Google アプリや Google.com のモバイル版ホームページで、または Pixel スマートフォンのホーム画面から右にスワイプすることで、Discover を体験できます。2017 年のリリース以降、Discover は大幅な成長を遂げており、今や 1 か月のアクティブ ユーザーは 8 億を超えます。関心の高いトピックに関する記事や動画などのコンテンツを表示してユーザーを引き付け、新しい情報の探索を促しています。ユーザーは、トピックを直接フォローできます。また、表示させたいトピックや表示させたくないトピックを Google に伝えることもできます。さらに、Discover の魅力は最新情報の表示だけではありません。レシピから社会情勢、ファッション動画まで、公開日に関係なく最適なウェブ コンテンツを表示します。Discover 用のサイトの最適化方法については、こちらのガイドをご覧ください。
新しい Discover レポートは、Discover に表示された実績が十分にあるウェブサイトに表示されます。なお、2019 年 3 月からのデータが表示対象となります。最適なコンテンツ戦略を策定し、公開日を問わず、魅力的な情報をユーザーに見つけてもらえるようにするうえで、このレポートがお役に立てば幸いです。
レポートについてご不明な点やご意見などありましたら、ウェブマスター ヘルプ フォーラムまでお寄せいただくか、他のチャネルよりお問い合わせください。
Google は、あらゆる検索に対して最高品質の結果を提供することを目指しています。この取り組みの一環として、Google では、いわゆる「ウェブスパム」という不正行為により検索体験、コンテンツ、行動の品質が低下し、ウェブマスター向けガイドラインに抵触しないよう対策を講じています。その結果、ユーザーがアクセスした検索結果ページに占めるスパムページの割合は 1% を大きく下回っています。本記事では、2018 年に私たちが行ったウェブスパム対策をご紹介します。
2018 年に私たちが対処したウェブスパムのうち、昨年までに引き続き目立っていたのは以下の 3 種類のスパムでした。
不正なハッキングに関するスパム: 2017 年のレポートでは、検索結果中のハッキングされたウェブサイトで、スパムの大幅な減少が見られました。この傾向は 2018 年も続いており、ハッキングされたウェブページが検索結果に影響したりユーザーに被害を与えたりする前に、より早く発見されるようになりました。ハッキングされたサイトのスパムが検索に及ぼす影響は軽減していますが、こうしたサイトは依然としてウェブの安全性を脅かすセキュリティ上の重要な問題であり続けています。ハッキングされてしまったウェブマスターに対しても、私たちはハッキングされたウェブサイトの復旧に役立つガイドを提供することで、ウェブサイトを侵害されたウェブマスターの支援に取り組んでいます。
ユーザー生成スパム: 私たちはユーザー生成スパムとして知られるタイプのスパムに引き続き注目しています。ユーザー生成スパムには、フォーラムへのスパム投稿や、無料のブログやサービス等のスパム行為があります。いずれも人が利用することを意図しておらず、コミュニケーションを混乱させるだけで、ユーザーには何の価値ももたらしません。2018 年には、この種のスパムが検索ユーザーに及ぼす影響を 80% 以上減らすことができました。ウェブサイトに対する不正行為を防止できなくても、私たちはウェブサイトの所有者が自己防衛の手段を簡単に習得できるようにしたいと考えています。そのため、サイトのコメント欄を不正行為から守る方法を提供しています。
リンクスパム: 私たちは、信頼性と関連性に優れるリンクの価値を検索ランキングにおける重要な要素として守り続けてきました。悪質なリンクスパムには速やかに対処し、ランキングを不正に操作しようとする多くのリンクの影響をできる限り排除しています。長年にわたり何度も浮上する「リンク施策」にまつわる数々の説についても、ウェブマスターやホワイトハットな SEO の専門家の皆様と連携して反証してきました。ウェブサイトの所有者に対しては、ランキングを上げることを主目的としてリンクを作成するのではなく、魅力的なコンテンツの作成に注力すれば、こうした説や現状について心配する必要はないと伝えてきました。私たちは、ウェブサイトの所有者に質の高いコンテンツの作成を奨励することが、あらゆるタイプのスパムと闘うための最善策のひとつであると考えています。検索エンジン最適化（SEO）スターター ガイド
などは、おすすめの方法に焦点を当てており、Google 検索結果でのランキングを上げる秘訣と称するよくある説や誤解を否定するのに役立つものです。リンクスパムのレポートも、こうした不正行為との闘いを支え、公正な検索ランキングを維持するのに大変役立ちます。
ユーザーからは日々、検索結果におけるウェブスパム、フィッシング、マルウェアが報告されています。そのおかげで、私たちは Google のフィルタとプロセスを逃れたウェブスパムやマルウェアなどが検索に及ぼす問題を発見できます。私たちがユーザーから受け取った検索スパムの報告は 18 万件を超え、処理した報告の 64% で対策を講じることができました。これらの報告は本当に効果があります。ご報告いただいたすべての皆様に感謝したいと思います。
私たちは、ウェブサイトに問題があることを発見したとき、その所有者に通知することが重要だと考えています。2018 年には、検索結果へのサイトの表示に影響を及ぼしうる問題点と改善点をお知らせするため、1 億 8,600 万件を超えるメッセージをウェブサイトの所有者あてに生成しました。こうした通知は、Search Console でサイトの確認が済んでいるサイト所有者にのみ送っており、その数は 9,600 万件に及びます。残りのメッセージは、有効である限りウェブサイトとのリンクが維持されるので、ウェブマスターが Search Console に自分のサイトを登録すれば表示されます。メッセージの大半は Search Console の新規ユーザーへの歓迎メッセージでした。その次に多かったのは、モバイル ファースト インデックスが利用可能になったときに、その旨を Search Console の登録ユーザーに通知するメッセージでした。全メッセージ中、2% をわずかに上回る約 400 万件が、Google のウェブマスター向けガイドライン違反に対する手動対策に関連するものでした。
高品質のコンテンツが増えることは、検索結果をウェブスパムから守ります。私たちは、ウェブマスターのみなさんが
そのようなコンテンツを作成するのに少しでもお役に立てるようツールやレポートを継続的に改善しています。Google Search Console は一から再構築され、新しいレポートと改善されたレポートの両方（パフォーマンス、インデックス カバレッジ、リンク、モバイル ユーザビリティのレポート）に加え、最新機能（URL 検査ツールとサイトおよびユーザー管理）が利用できるようになりました。この改良版 Search Console は 2018 年中にベータ版の提供を終了し、現在はすべての登録済みウェブサイト所有者に一般提供されています。
私たちは、最新のウェブを開発しているフロントエンド デベロッパーの存在も忘れてはいません。CMS を使用している場合でも、独自の CSS や JS を作成している場合でも、ウェブ フレームワーク上でサイトを構築している場合でも、ユーザーにとって魅力的で検索に適したサイトを作成するデベロッパーの取り組みを支援することに私たちは力を注ぎました。デベロッパーとウェブマスターは、ウェブページの品質向上に役立つオープンソースの自動監査ツールである Lighthouse の新しい SEO 監査機能を使用して、自分のページでアクショナブルな SEO ヘルスチェックを実行し、改善の余地がある領域を速やかに見つけられます。
私たちはまた、ウェブサイトの所有者と直接交流する機会を作り、解決が困難な問題についても支援しています。Google の専門チームのメンバーは、オンラインおよび対面で定期的に世界中のウェブマスターと交流しています。76 以上の都市で、190 を超えるオンライン オフィスアワー、オンライン イベント、オフライン イベントを、SEO、デベロッパー、オンライン マーケティング担当者を含む合計 17 万人以上の方々にお届けしました。また、東京、シンガポール、チューリッヒ、大阪の 4 都市では Google 主催の検索イベントを開催し、インドでは 11 の都市で検索に関するカンファレンスを開催しました。2018 年には、英語、フランス語、ドイツ語、ヒンディー語、日本語に加え、スペイン語でオフィスアワーのライブ配信を開始しました。ウェブマスターは、Google ウェブマスター YouTube チャンネルより、ヘルプ、ヒント、有益なディスカッションをご覧になれます。プロダクト エキスパートは、公式サポート フォーラムを通じて、12 を超える言語で、ウェブマスターの問題が解決するよう手助けをしています。
私たちは、2019 年もウェブスパムのない検索体験を皆様にお届けできるように努力を続けてまいります。
現在 Search Console の検索パフォーマンス レポートでは Google 検索で表示された URL に、関連するすべての指標が記載されています。この仕様では詳細なデータがわかる反面、プロパティの管理は難しくなります。たとえばサイトのモバイル版と PC 版が複数のプロパティにわかれている場合、同じコンテンツの検索データをすべて表示するには、複数のプロパティを開かなければなりません。
この問題を解消するため、Search Console では今後、検索指標の割り当て先を、Google 検索に表示された URL ではなく（Google が選択した）正規 URL にデータを統合することにしました。この変更には次のような利点があります。
すべてのパフォーマンス データは 3 月末に移行が完了する予定です。データの継続性を確保するため、Google では統合済みデータの表示を 2018 年 1 月から開始しています。ユーザーの皆様は、移行期間中の数週間に新旧両方のバージョンを表示して、移行による影響や変化をご確認いただけます。
API とデータポータルをお使いの皆様: Search Console API は 3 月末に正規データに変更されます。
トラフィックの変化について、以下に例を挙げましたのでご確認ください。
サイト内で起こりうるデータの変化について、いくつか例を挙げました。以下の例で、正規サイト（example.com）と代替サイト（m.example.com）のトラフィック数がどのように変わるかをご確認ください。
重要: 以下の例では、PC 版サイトにすべての正規ページが含まれ、モバイルサイトにすべての代替ページが含まれているものとします。実際には、一部の代替ページが PC 版サイトに、一部の正規ページがモバイルサイトに含まれている場合もあります。特定の URL の正規ページは URL 検査ツールで確認できます。
総トラフィック
現行バージョンでは、トラフィックが正規プロパティと代替プロパティで分かれています。新バージョンでは、すべてのトラフィックが正規プロパティに属するようになります。
正規 URL に基づいた新バージョン
ページ別のトラフィック
ページ別の重複 URL と正規 URL のトラフィックの変化は、ページビューで確認できます。次の例は、正規ページと代替ページに分割されていたトラフィックが、すべて正規 URL に属するようになったことを示しています。
現行バージョン
新バージョン
差異
+150 | +800
-150 | -800
モバイル トラフィック
現行バージョンでは、すべてのモバイル トラフィックが m. プロパティに属しています。新バージョンでは、次に示す [端末: モバイル] フィルタを適用すると、すべてのトラフィックが正規プロパティに属するようになります。
+0.7K | +3K
-0.7K | -3K
最初は少々混乱されるかもしれませんが、この変更によってサイトのトラフィック データは、今よりもずっと簡単にトラッキングできるようになります。ご不明な点がある場合は、ウェブマスター ヘルプ フォーラムをご利用ください。
Google では、Search Console でウェブサイトを包括的に管理するため、すべてのバージョンのウェブサイト（http、https、www あり、www なし）を Search Console に追加することをおすすめしています。しかし、すべてのプロパティのデータを手動で集計するのは大変な手間で、ドメイン全体が Google 検索でどう「認識」されているか把握するのを難しくしていました。そこで、Search Console に新たに「ドメイン プロパティ」を追加し、同じドメインのすべてのウェブサイトのデータを簡単に集計、検証できるようにしました。
ドメイン プロパティには、同じドメイン名のすべての URL のデータが表示されます。Search Console にウェブサイトを登録することで、同じドメインのすべてのプロトコル、サブドメイン、パスのデータが集約されるため、手動でデータを集計する必要はありません。モバイルページ用に「m.」で始まる URL を使用している場合でも、HTTP から HTTPS に移行する場合でも、サイトのデータが Search Console に自動的に集約され、Google 検索でドメイン全体がどう認識されているかを簡単に把握できます。
すでに DNS の確認が済んでいる場合は、これから数週間のうちに新しいドメイン プロパティが自動的に作成され、すべてのレポートに反映されます。新しいドメイン プロパティを手動で追加したい場合は、プロパティ タイプの選択画面から新しいドメイン プロパティを追加し、DNS レコードの確認を行ってください。なお、今後は可能な限りドメイン プロパティを使用することをおすすめします。
ドメイン プロパティは、皆様からのご意見に基づいて開発しました。貴重なご意見をお寄せいただき改めて感謝いたします。今回の変更により、サイト管理の手間が軽減され、手動でデータを集計しなくても全体像を把握できるようになることを願っております。ご不明な点などございましたら、ヘルプ フォーラムでお気軽にご質問ください。引き続き、皆様からのご意見もお待ちしております。Search Console のフィードバック機能をご利用ください。
Google の検索結果ではリストの横に日付が表示されることがあります。今回は、この日付がどのように判断されるのかなど、ウェブマスターの皆様から寄せられる一般的な質問にお答えし、日付の精度向上に役立つおすすめの方法をご紹介します。
Google では、自動化システムで適切と判断されると、ニュースのような日付や時間が重要なページに対して日付が表示されます。
Google ではさまざまな要素に基づいて日付を判断しています。たとえば、ページ自体に読者にもはっきりとわかるように明確に記載されている日付や、サイト運営者が構造化マークアップで指定している日付などが挙げられますが、これらに限定されません。
どの要素も単独では信頼性にかけるため、Google が 1 つの要素にのみ頼ることはありません。サイト運営者が常に明確に表示される日付を提供しているとは限りません。構造化データが不足している場合や、正しいタイムゾーンが設定されていない場合もあります。そのため、Google のシステムでは、複数の要素を確認して、ページが公開された時点や大幅に更新された時点の最も正確と考えられる日付を推定しています。
Google が正しい日付を選択できるように、サイト所有者やサイト運営者は次のことを行ってください。
datePublished
dateModified
Google ニュースでは、コンテンツが公開または更新された日付と時刻の両方を明確に表示する必要があります。構造化データだけでは不十分なため、日付と時刻の表示に加えて、構造化データを使用することをおすすめします。日付と時刻は見出しと記事のテキストの間に配置してください。詳しくは、記事の日付に関するヘルプページもご覧ください。
大きな変更を加えた記事の場合、日時を更新することには意味があります。しかし、やむを得ない理由もなしに、重要な情報を追加しないまま記事を人為的に更新するのはやめてください。また、以前に公開した記事をわずかに更新しただけの記事を作成し、古い方の記事を削除して、新しい記事にリダイレクトすることも避けてください。このような手法は、記事の URL に関するガイドラインに違反しています。
これらのガイドラインをご活用いただくことで、ウェブサイトのページで正しい日付を指定するのが簡単になることを願っております。この記事や構造化データについてご不明な点などありましたら、ウェブマスター ヘルプ フォーラムでお気軽にご質問ください。
