さようなら、Flash

かつて Microsoft は「1 つの時代の終わり」と題して、ウェブブラウザでの Flash のサポート終了を発表しました。Chrome(バージョン 76 以降)、Microsoft Edge、FireFox 69 では、Flash がデフォルトで無効になっています。そして、Google 検索のインデックス登録でも、Flash が除外されることとなりました。

Flash は、動きがなく平板な印象だったウェブページに、リッチなアニメーション、メディア、アクションをもたらしました。豊かな表現が可能なテクノロジーであったため、多くのクリエイターが刺激を受け、ウェブ上で新しいコンテンツを生み出してきました。Flash はあらゆるサイトで利用されてきたとも言えます。Flash コンテンツを再生する Flash ランタイムは、2013 年の後半だけで 5 億回インストールされました。

私の息子が Flash ゲームをやめられなくなって、妻に叱られていたことを思い出します。息子はしぶしぶゲームをやめましたが、今度は Flash が舞台を降りる番になりました。

Google 検索では、今年中に Flash のサポートを終了する予定です。ウェブページに Flash コンテンツが含まれている場合、Google 検索では Flash コンテンツが無視されることになります。単独の SWF ファイルは、Google 検索でインデックス登録されなくなります。ただし、ほとんどの場合、この変更はユーザーにもウェブサイトにも影響しないはずです。

Flash はウェブの発展に大きく貢献しました。その遺産は HTML5などのウェブ規格が引き継いでいくことでしょう。

Jalgayo /tʃɑlˈgɑjɔ/(韓国語で「さようなら」)、Flash。

レビュー リッチリザルトをさらに役立つものに

レビュー リッチリザルトが添えられた検索結果は、プロダクトやサービスを探すうえで大変役に立ちます(検索結果の横に時折表示されているあのスコアや星です)。

これをさらに便利で役立つものにするため、Google ではレビュー リッチリザルトのアルゴリズムの更新を行いました。これにより、ウェブマスターから報告された無効、または誤解を招くような実装の一部も解決されます。

Schema タイプをレビュー(クチコミ)が役立つものに限定

レビュー マークアップは、技術的にはどのスキーマタイプにも追加できますが、多くのタイプでは、星による評価はユーザーにとってあまり意味がありません。今回の変更により、検索でレビュー リッチリザルトをトリガーできるスキーマタイプが限定されます。具体的には、以下のタイプ(およびそのサブタイプ)へのレビューのみが表示されるようになります。

セルフサービングのレビューを禁止

「セルフサービング」と見なされるレビューは、ユーザーの利益を最優先にしたものではありません。Google では、エンティティ A に対するレビューがエンティティ A のウェブサイトに(直接マークアップで、または埋め込まれたサードパーティ ウィジェットを介して)置かれている場合、そのレビューを「セルフサービング」と呼びます。そのため、今回の変更により、レビュー対象のエンティティ自身がそのレビューを制御している場合、スキーマタイプ localBusinessOrganization(およびそのサブタイプ)に対するレビュー リッチリザルトは表示されなくなります。

レビュー対象の name を追加

今回の変更から name プロパティが必須となるため、レビューには必ず name を指定しなければならなくなります。

2019 年 9 月 18 日追記

さらなる情報提供を目的として、ローカル ビジネスや組織などのエンティティはこれまで、自身に関するレビュー マークアップをホームページやその他のページに追加して、そのページにレビュー スニペットを表示させることができました。こうしたマークアップは、エンティティが直接追加することもあれば、サードパーティ製のウィジェットを使用して埋め込むこともありました。

Google ではこれを「セルフサービング」であると考えています。ローカル ビジネスまたは組織が、自身に関するマークアップを、自身のページに自ら追加しているためです。

ローカル ビジネスまたは組織(LocalBusiness または Organization スキーマタイプ)によるセルフサービングなレビューは表示されなくなりました。たとえば、特定の商品やサービスに関するレビューを表示するリッチ レビュー スニペットも、それがセルフサービングであると見なされれば表示されません。

こちらのドキュメントに記載されているその他のスキーマタイプに関するレビューは許可され、表示されます。たとえば料理関連のサイトで、レシピに関する訪問者のレビューをまとめる目的で、マークアップを使用することは可能です。そのリッチ レビュー マークアップは、該当するレシピが検索結果に表示される場合にも適用される可能性があります。

よくある質問

当社の商品やサービスに関するレビューを、サードパーティ製のウィジェットを使用して表示している場合はどうなりますか?

その場合、Google 検索では、該当するページのレビュー スニペットが表示されません。サードパーティ製のウィジェットを埋め込むことは、レビューをリンクさせるプロセスを操作する行為であると見なされます。

セルフサービングなレビューは、LocalBusiness または Organization から削除する必要がありますか?

いいえ。削除する必要はありません。Google 検索では、そうしたページのレビュー スニペットが表示されなくなるというだけです。

自社のサイトにセルフサービングなレビューを掲載した場合、手動による対策はとられますか?

それだけで手動による対策がとられることはありません。ただし、構造化データが Google のガイドラインに違反していないことを確認することをおすすめします。

今回の更新は、当社の Google マイビジネスのリスティングやプロフィールには影響しますか?

いいえ。今回はオーガニック検索だけに関連する更新であるため、Google マイビジネスには影響しません。

他の組織に関するレビューをまとめたサイトには影響しますか?

いいえ。それについては何も変わりません。レビューをまとめたサイトの場合は、他の組織に関するレビュー スニペットを含めて検索結果に表示されます。

今回の更新は AggregateRating にも適用されますか?

はい。ReviewAggregateRatingに適用されます。

引き続き検索結果にセルフサービングなレビューが表示されている場合は、どのように報告すればよいですか?

Google では、必要に応じてそうした場合の専用フォームを用意することを検討しています。今回の変更は段階的に実施しているため、適切でないレビューの星が引き続き表示される可能性があります。

この変更により、ユーザーにとってのレビューの有用性が大きく向上する一方、ほとんどのウェブマスターにとって、必要となる作業は皆無か、あるとしてもわずかです。上記の変更はすべて、デベロッパー向けのドキュメントに記載されています。ご不明な点がございましたら、ウェブマスター フォーラムをご利用ください。

Posted by Yuxin Cao, Software Engineer & Sven Naumann, Trust & Safety Search

Webmaster Conference Tokyo & Osaka 開催のお知らせ

Google の検索チームでは、ウェブマスターやサイト運営に関わる皆さんを結ぶことを目的に 2016 年より毎年 Google 検索をテーマとしたイベントを開催しております。今年は、沖縄、福岡と札幌に続き、東京と大阪でも開催することが決まりましたのでお知らせします。

イベントでは Search Console や SEO for Single Page Apps、デジタルミレニアム著作権法(DMCA)のセッションや Q&A の時間を設けるほか、Google 社員と参加者のみなさんの交流タイムなどを予定しています。イベントの詳細をご確認の上、ぜひお申し込みください!

開催概要

1)東京会場

日時:2019 年 11 月 25 日(月)

13 時 00 分開場

14 時 00 分開始

19 時 30 分頃終了予定

21 時 00 分懇親会終了

スピーカー:

  • Gary Illyes
  • Idan Avraham
  • Martin Splitt
  • Daniela Matuschka
  • Takeaki Kanaya(金谷武明)
  • Anna Ogawa(小川安奈)

会場:Google 六本木オフィス

費用:無料

定員:200 名(招待枠含む)

お申し込みはこちらから!

(締め切り:2019 年 10 月 15 日(火) 深夜 24 時まで)



2)大阪会場

日時:2019 年 11 月 27 日(水)

13 時 00 分開場

14 時 00 分開始

19 時 30 分頃終了予定

20 時 30 分懇親会終了

スピーカー:

  • Gary Illyes
  • Malik Mairaj Syed
  • Martin Splitt
  • Daniela Matuschka
  • Takeaki Kanaya(金谷武明)
  • Anna Ogawa(小川安奈)

会場:グランフロント大阪(地図)

費用:無料

定員:200 名(招待枠含む)

お申し込みはこちらから!

(締め切り:2019 年 10 月 15 日(火) 深夜 24 時まで)



前回開催された Webmaster Conference Sapporo の様子

今回も一般の方による Lightning Talk を設ける予定です。登壇を希望される方は、ぜひお申込みフォームからお知らせください!

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

※ 応募多数の場合は、抽選とさせていただきます。

※ 参加者は 10 月 17 日以降メールにてご連絡致します。なお、抽選の場合、参加者のみのご連絡とさせていただきます。

※ 会場までの交通費等のサポートはありませんのでご了承ください。

※ 2 つのイベントに同時にお申し込みいただけますが、両方当選した場合、片方だけのキャンセルはできませんのでご了承下さい。

Google のコア アップデートについてウェブマスターの皆様が知っておくべきこと

Google ではほぼ毎日、検索結果を改善するための変更をリリースしています。大半の変更は目に見える変化を伴わない場合が多いですが、これらを積み重ねることで、日々検索の改善に取り組んでいます。

時には、皆様がはっきりと変化に気づくようなアップデートを行う場合もあります。ウェブマスターやコンテンツ プロデューサーなどの皆様が対応したり措置を講じることができる実用的な情報がある場合、Google ではそのようなアップデートを周知しています。たとえば「Speed Update」を実施した際には、その数か月前から事前通知とアドバイスを公開しました。

Google では年に数回、検索アルゴリズムとシステムに重要かつ大規模な変更を加えており、このような変更を「コア アップデート」と呼んでいます。コア アップデートは、全体として、関連性が高く権威あるコンテンツを検索ユーザーに提供するという Google の使命を果たすために行われます。また、コア アップデートは Google Discover に影響する場合もあります。

コア アップデートは広範囲に変化や影響が現れるため、Google ではその周知を図っています。一部のサイトでは、コア アップデート後に掲載順位が下がったり、逆に上がったりすることがあります。掲載順位が下がった場合はサイトを修正しようと思うかもしれませんが、間違った修正を行わないように注意してください。場合によっては、まったく修正の必要がないこともあります。

コア アップデートとコンテンツの再評価

ページに問題がなくても、コア アップデート後にパフォーマンスが低下することがあります。こうしたサイトは、ウェブマスター向けガイドラインに違反したわけでも、手動またはアルゴリズムによって違反に対する対策が取られたわけでもありません。実際のところ、コア アップデートには、特定のページやサイトを対象とした変更はありません。コア アップデートの変更は、コンテンツ全体に対する Google のシステムの評価方法を改善するために行われます。この変更により、過小評価されていたページのパフォーマンス向上も見込めるようになります。

コア アップデートの影響を理解するには、例えば 2015 年に作成した映画トップ 100 のリストを想像してみるのがよいでしょう。2015 年からしばらくたった 2019 年では、リストを更新する必要があります。リストが変更されることは自然なことです。以前は存在しなかった新しい素晴らしい映画がいくつかトップ 100 に加わるかもしれません。評価が見直され、以前よりも高い順位にランクインする映画もあるかもしれません。

リストが更新され、以前は高い位置にランクインしていた映画のランクが下がったとしても、その映画が悪いわけではありません。それは単に、その映画よりも高い評価を得た映画があったというだけのことです。

コンテンツに集中する

これまで説明したとおり、コア アップデート後にページの掲載順位が下がったとしても、そのページに修正すべき問題があるとは限りません。それでも、コア アップデート後に掲載順位が下がった場合は、何かする必要があると感じるかもしれません。そのような場合は、できるだけ優れたコンテンツの提供に集中することをおすすめします。Google のアルゴリズムでは、コンテンツの品質に基づいて掲載順位を決定しているからです。

まずは、コンテンツの品質を自己評価する方法に関して Google が過去に提示したアドバイスを再確認しましょう。Google では、今回このアドバイスを更新し、コンテンツを自己評価するための新しい質問を追加しました。

コンテンツと品質に関する質問
  • コンテンツは、独自の情報、レポート、研究、分析を提供しているか?
  • コンテンツは、特定のトピックに対して包括的または完全な説明を十分に提供しているか?
  • コンテンツは、あたりまえのことだけでなく、洞察に富んだ分析や興味深い情報を含んでいるか?
  • コンテンツが他の情報源から得られたものである場合、単なるコピーや書き換えでなく、付加価値とオリジナリティを十分に提供しているか?
  • 見出しやページタイトルは、内容を説明する有用なものになっているか?
  • 見出しやページタイトルは、コンテンツを誇張したり、読者に強いショックや不快感を与えたりするものでないか?
  • ブックマークしたり、友人と共有したり、友人にすすめたくなるようなページか?
  • コンテンツは、雑誌、百科事典、書籍に掲載または引用されるような価値があるか?
  • 専門性に関する質問
    • コンテンツは、明確な情報源、関係する専門知識の証明、著者またはコンテンツを公開しているサイトの背景情報(著者ページへのリンクやサイトの概要ページなど)など、掲載されている情報が信頼性の高いものであることを示すための情報を提供しているか?
    • コンテンツを制作しているサイトを調査した場合、そのトピックに関する権威者としてそのサイトが信頼されている、または広く認識されているという印象を受けるか?
    • コンテンツは、トピックに関して明らかに充分な知識を持つ専門家や愛好家によって書かれているか?
    • コンテンツに明らかな誤情報がないか?
    • お金や人生を左右するような問題について、このコンテンツを安心して信頼できるか?
    コンテンツの提示方法や制作に関する質問
    • コンテンツに誤字やスタイルに関する問題がないか?
    • コンテンツは適切に制作されているか?急いで制作されたような印象を与えていないか?
    • コンテンツが大量生産されていたり、多数のクリエイターへの外部委託によって制作されていたり、大規模なサイト ネットワークに散在しており、個々のページまたはサイトのプレゼンスが低下していないか?
    • コンテンツに、主要なコンテンツを妨害したり注意をそらしたりするほどの大量の広告が掲載されていないか?
    • コンテンツは、モバイル デバイスでも適切に表示されるか?
    比較に関する質問
    • 検索結果の他のページと比較した場合、コンテンツは十分な価値を提供しているか?
    • コンテンツは、サイトの訪問者が本当に求めるものを提供しているように思えるか?あるいは、検索エンジンで上位に表示するためだけを狙って作成されたように思えるか?

    これらの質問を自分自身に問いかけるだけでなく、あなたのサイトと無関係な信頼できる第三者に正直に評価してもらいましょう。

    また、掲載順位が下がった場合、その状況を精査することも検討してください。どのページが最も影響を受けたか、そしてどんなタイプの検索で最も影響を受けたかを調査しましょう。それらのページを詳しく調べることで、上記の質問に対してどのようにページが評価されたのかを理解できます。

    品質評価ガイドラインと E-A-T について

    最適なコンテンツに関するアドバイスを紹介するもう一つのリソースとして、検索品質評価ガイドラインをご紹介します。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 ウェブマスターから提供されるリソースでは、優れたコンテンツに関する多くのアドバイスを確認できます。詳細はこちらからご確認ください。

    Google 検索におけるコンテンツのプレビューをもっと制御できるようになります

    Google では、文字形式のスニペットを始めとする様々な形式のコンテンツをプレビューとして検索結果に表示していますが、これは、検索結果と検索クエリとの間に関連性があるかどうかを、ユーザーが判断しやすくすることを目的としています。どのような形式のプレビューが表示されるかは数多くの要因によって決められており、その要因の中には、ユーザーが探しているコンテンツの形式や、そのときに使用しているデバイスなどが含まれます。

    例えば、Google でレシピの検索を行っているユーザーには、サムネイル画像やレビュー スコアが表示されます。なぜなら、何を食べたいか決める際は、文字形式のスニペットよりも、そういった情報のほうが参考になると考えられるからです。上記のような形式の情報は、パブリッシャーが構造化データを使ってページを作成しているおかげで表示が可能になっています。

    Google は、表示された検索結果がユーザーのクエリと関連性が高く訪問したくなるサイトが表示されていることを分かりやすく示すために、プレビューを自動的に生成します。一方で、サイト オーナー側でも、プレビューで表示される情報をある程度調整したいという要望があることを私たちも理解しています。そこで本日は、ウェブマスターが行える新たな設定項目をいくつかご紹介します。これらの設定により、スニペットに表示する文字列はどの部分からどのくらいの長さであるべきか、その他の形式の情報はプレビューに表示するべきかどうか、などをそれぞれのサイトが簡単に定義できるようになります。

    スニペットとコンテンツ プレビューの設定を Google に知らせる

    これまでは、文字形式のスニペットの表示を許可するかどうかのみが設定可能でした。今回紹介する方法を使用することで、検索結果のページに対して表示されるプレビュー コンテンツを、より細かく設定できるようになります。その方法は、二種類の新しい設定を駆使して行います。その二種類とは、robots メタタグによる設定と、HTML 属性による設定です。

    robots メタタグを使用する

    robots メタタグは HTML ページの <head> 要素内に追加するか、x-robots-tag HTTP ヘッダー で指定します。ページのプレビュー コンテンツの設定で使用する robots メタタグは、以下の通りです。

    • "nosnippet"
      既存の設定値です。ページに対して文字形式のスニペットを表示したくないときに使用します。
    • "max-snippet:[number]"
      新しい設定値です!ページに対して表示するスニペットの最大文字数を設定します。
    • "max-video-preview:[number]"
      新しい設定値です!動画再生プレビューの最長再生時間(秒)を設定します。
    • "max-image-preview:[setting]"
      新しい設定値です!ページ内の画像がプレビューで表示されるときの最大サイズを指定します。指定可能な設定値は、"none"、 "standard"、 "large" のいずれかです。

    上記のメタタグは 2019 年 10 月 より有効になります。設定値は以下のようにまとめて記述することが可能です。

    例:

    <meta name="robots" content="max-snippet:50, max-image-preview:large">

    新しい data-nosnippet HTML 属性を使用する

    "data-nosnippet" HTML 属性は、ページ内のコンテンツのうち、スニペットとして表示してよい部分を制限するのに役立つ新しい方法です。span、div、section 要素で使用出来ます。"data-nosnippet" HTML 属性が指定された要素は、そのページに対する文字形式のスニペットとして表示されなくなります。

    例:

    <p><span data-nosnippet>Harry Houdini</span> is undoubtedly the most famous magician ever to live.</p>

    "data-nosnippet" HTML 属性は今年中に有効になります。詳しくは、robots メタタグと X-Robots-Tag HTTP ヘッダーの仕様に関する開発者ドキュメントを参照してください。

    リッチリザルトと強調スニペットについて

    構造化データ内のコンテンツは、検索結果におけるリッチリザルトとして表示することが可能です。リッチリザルトは、上記のメタ robots による設定で制限することは出来ませんが、構造化データ内のコンテンツ自体を制限したり修正したりすることで、より柔軟な設定が可能になります。例えば、レシピが構造化データに含まれている場合、その構造化データのコンテンツは、検索結果のうち、レシピのカルーセル内に表示されることがあります。そのような表示を制限するために、パブリッシャーは構造化データ内のコンテンツの量や形式を制限することが出来ます。

    検索の特別な機能の中には、プレビュー コンテンツが利用可能な場合のみ動作可能になるものがあります。つまり、プレビューを制限することで、それらの特別な機能の領域でコンテンツが使用されるのを防ぐことが出来ます。例えば、強調スニペットは表示するのに必要な最低文字数があり、それに満たない場合は表示されません。しかしながら、これは言語によって様々なので、強調スニペットで確実に表示されるための具体的な max-snippets の値は存在しません。強調スニペットとしてコンテンツを表示したくない場合は、 max-snippets の値を小さくしてみてください。強調スニペットから確実にオプトアウトしたい場合は、nosnippet を指定してください。

    AMP フォーマット

    AMP フォーマットには確実なメリットがあります。例えば、検索結果Google Discover のフィード画面で、より多くの注目を集めるような形でサムネイル画像を表示することが可能になります。このような特徴により、パブリッシャーはさらに多くのトラフィックを記事ページに誘導できるようになりました。一方で、パブリッシャーの中には、AMP ページが検索や Discover で表示された際に、大きいサムネイル画像を表示してほしくない場合があるかもしれません。その場合は、上記の meta robots タグのうち、max-image-preview に対して “standard” か “none” を指定します。

    本日ご紹介した新しい方法は、世界中のコンテンツ所有者の皆様が利用でき、全世界どこでも同じように機能し検索結果に反映されます。Google 検索におけるサイトの価値を最適化し、ビジネスの目標を達成するうえで、今回の方法が皆様のお役に立つことを願っています。さらに詳しい情報は、メタタグに関する開発者ドキュメントを御覧ください。ご質問がある場合は、私たちにお知らせいただくか、ウェブマスター ヘルプ フォーラムまでお越しください。

    サイトの検索パフォーマンス レポートでより最新のデータが利用可能に

    このたび、ユーザーの皆様から寄せられたフィードバックの分析を通じて最もご要望の多かった機能リクエストに基づき、レポートでのデータの更新頻度が新しく改善されましたのでお知らせします。
    パフォーマンス レポートでは、ウェブマスターやサイト所有者が Google 検索でのサイト パフォーマンスをより的確に把握できるほか、次のような疑問の答えを見つけることもできます。
    • 一般的な統計情報: Google 検索や Discover から自分のサイトが獲得したトラフィックはどのくらいか?
    • 検索クエリ: 自分のサイトの上位の検索クエリや急上昇中の検索クエリは何か?
    • 上位のコンテンツ: 自分のサイトのページのうち、Google 検索において最も成果を上げているページはどれか?
    • サイト訪問者: どの国からアクセスしているか?どのデバイスからアクセスしているか?そのほとんどがモバイルからか?
    • 形式: 自分のサイトは検索結果にどのような形式で表示されるか(AMP、レシピなど)?
    今後は 24 時間以内の最新データを確認できるようになります。従来は更新に数日かかっていたことを考慮すると、これは大幅な改善と言えます。
    今回のデータ更新頻度の改善により、サイト パフォーマンスのより的確な監視、トラッキングが可能になり、次のような重要なニーズに対処できるようになることが見込まれます。
    • 週末のパフォーマンスを月曜日の朝に確認する。水曜日まで待つ必要はありません。
    • 朝一番にサイトの統計情報を確認する。祝日や世界規模のイベント、ショッピング シーズンなどの重要な期間後、あるいは期間中でも確認できるようになります。
    • 重要な技術的問題を修正した後、すぐにサイトのトラフィックが回復するかどうかを確認する。


    さらに、データのタイムゾーン(太平洋時間)が明確に示されるようにレポートを更新しました。これは、ローカル タイムゾーンと比較してデータを解釈したり、Google アナリティクスなどの他のソースと統合したりする場合に便利です。



    最新のデータポイントはそれぞれ、数日後に最終的なデータポイントに置き換えられます。最新データは、最終的に確定する前に若干変更される可能性があります。

    Search Analytics API は、まだ最新データをサポートしていません。また、Discover のパフォーマンス レポートでも最新データは利用できません。そのため、Discover のパフォーマンス レポートで対象となるプロパティから、概要レポートの最新データを参照することはできません。将来的には、こうした問題にも対処していきたいと考えています。

    経時的なパフォーマンス データのエクスポート


    また、パフォーマンスの推移の確認やエクスポートを簡単に行えるようにしてほしいというフィードバックも寄せられていました。本日より、この点についても可能になります。操作はシンプルで、グラフの下の表で [日付] を選択して目的の期間を選び、Search Console でデータを確認するか、グラフをエクスポートするだけです。この新機能が、経時的なパフォーマンスの傾向や変化についてさらに詳しく調べる際に役立つことを願っています。



    まとめ

    今回の改善による最新のデータが、サイトのパフォーマンスをより的確に監視し、リアルタイムに近い状況で傾向、パターン、注目すべき変化を特定するうえでお役に立てば幸いです。また、表の新しい日付ディメンションも、経時的なパフォーマンスの傾向や変化を調べる際にぜひお役立てください。ご不明な点がありましたら、ウェブマスター ヘルプ フォーラムまたは Twitter よりお問い合わせください。

    投稿者: Ziv Hodak、Search Console プロダクト マネージャー

    Google 検索でインデックスの問題が発生: その対処法と教訓

    ほとんどの時間は、Google の検索エンジンは正常に動作しています。私たちは、ウェブを検索しているユーザーや、Google にインデックス登録されているサイトのウェブマスターに影響を及ぼすような、技術的な問題が起きないように尽力しています。同様に、検索エンジンの基盤となるシステムも、ほとんどの場合意図したとおりに動作しています。わずかな障害が発生しても、サービスの運用を担当するチーム以外はほとんどわかりません。ただし、複雑なシステムである以上、大規模な障害が発生することがあり、ユーザーとウェブマスターの双方に影響する可能性があります。

    過去数か月の間に、インデックス登録システムで問題が発生し、インフラストラクチャの他の部分にも波及しました。できる限り迅速に状況の改善に取り組みましたが、ユーザーとウェブエコシステムに高品質のサービスを継続的に提供するという目標に反することになり、誠に申し訳ありませんでした。

    その後、何が起きたのかを綿密に精査しました。その過程で得られたいくつかの教訓をここで皆さんと共有したいと思います。このブログ投稿では、発生した問題について詳細に説明したのち、今後同様の問題が発生した場合にどのようにみなさまにお伝えする予定でいるかを共有します。その上で、Google への問い合わせ方法ついてウェブマスターの方々に改めてお伝えします。

    数か月前に発生した問題

    4 月に、インデックスに関する問題がいくつか発生しました。Google の検索インデックスは、ウェブからクロールした、ユーザーの質問に答えるのに有用と思われる数千億のウェブページを保持するデータベースです。ユーザーが Google 検索エンジンでクエリを入力すると、ランキング アルゴリズムが検索インデックスに登録されているページの中から、最も有益で関連性の高い検索結果を瞬時に見つけます。では、何が起こったのか、詳しく見ていきましょう。

    1. インデックス登録の問題

    はじまりは検索インデックスの一部が一時的に失われたことでした。
    「インデックスの一部が失なわれた」とはどういうことでしょうか。

    基本的に、検索結果をユーザーに提供する場合、サービス速度を向上させるために、ユーザーのクエリは Google 検索サービスをサポートする最も近いデータセンターに「旅」します。ここで Search Engine Results Page(SERP)が生成されます。そのため、インデックスの構成に変更(一部のページの追加や削除、ドキュメントの統合、または他の種類のデータ変更)がある場合、対象となるすべてのデータセンターに変更を反映する必要があります。結果として、世界中のユーザーに、最新バージョンのインデックスから一貫したページが提供されます。

    Google は、上記の写真のようなデータセンター世界中で所有して運営しており、24 時間年中無休でサービスを稼働させています(出典)。

    すべてのデータセンターで同一のインデックスを維持し続けることは簡単な作業ではありません。大規模なユーザー向けサービスの場合、まず 1 つのデータセンターで更新をデプロイし、関連するすべてのデータセンターが更新されるまで拡大していきます。慎重に扱うべきインフラストラクチャについては、数日間にわたってロールアウトを実施し、異なる地域のインスタンスにインターリーブすることもあります(出典)。

    予定していた検索インデックスに対する変更を進めている最中の 4 月 5 日(金)にデプロイシステムの一部が破損しました。具体的には、一部のデータセンターでインデックスを更新しているときに、少数のドキュメントが誤ってインデックスから削除されてしまいました。これが「インデックスの一部が失なわれた」ということです。

    幸いにも、Google のオンコール エンジニアが問題を即座に察知しました。これは、私たちがソーシャル メディア上で問題を認識し始めたのと同時でした(週末に Google に連絡してくれた皆さん、ありがとうございました!)。その結果、問題が察知されてからわずか数時間で、すべてのデータセンターの検索インデックスを以前の安定した状態に戻し始めることができました(Google では、このような事態に備えてインデックスのバックアップを保持しています)。

    Google は 4 月 7 日(日)に、この問題を認識しており、正常な状態に戻りつつあることを報告しました。データセンターのインデックスが徐々に安定した状態に戻りつつある中、Twitter での発信を続けました(4 月 8 日4 月 9 日)。これは、4 月 11 日にすべてのデータセンターのインデックスが完全に元通りになったと確信できるまで続きました。

    2. Search Console の問題

    Search Console は、ウェブマスターが利用できる一連のツールやレポートであり、ウェブサイトの検索に関するパフォーマンスのデータにアクセスできます。たとえば、毎日のオーガニック検索結果における表示回数やクリック数、または検索インデックスに登録されているページ、未登録のページに関する情報を確認できます。

    検索インデックスに上記の問題が発生した結果、Search Console でも不整合が見られるようになりました。これは、Search Console で表示されるデータの一部が検索インデックス自体から抽出されているためです。

    • インデックス カバレッジ レポートは、データセンター間で整合性が取れた検索インデックスに依存します。
    • 検索インデックスにページを格納するとき、ページにリッチリザルトのマークアップが含まれている場合など、ページに関する重要なシグナルでエントリにアノテーションを付けることができます。したがって、検索インデックスの問題は Search Console のリッチリザルト レポートに影響を及ぼす可能性があります。

    基本的に、Search Console の個別レポートの多くは、専用データベースからデータを抽出しています。このデータベースの一部は、検索インデックスから取得した情報を使用して構築されています。以前のバージョンの検索インデックスに戻す必要があったため、Search Console データベースの更新も一時停止する必要がありました。これにより、一部のレポート(および URL 検査ツールなどの他のレポート)のデータが横ばい状態になりました。

    2019 年 4 月の Search Console のデータの更新頻度に関する問題を示す、インデックス登録ページのインデックス カバレッジ レポート。2 回の更新の間隔が通常よりも長くなっている。

    問題が発生した検索インデックス全体のロールバックに数日かかったため(上記の説明を参照)、インデックス登録の問題が修正された数日後まで Search Console データベースの修正に取り掛かることができませんでした。Google は 4 月 15 日に、Search Console に問題があり、修正に取り組んでいることをツイートで明らかにしました。修正が完了したのは 4 月 28 日(レポートで新しいデータの収集を再開した日。上のグラフを参照)でした。4 月 30 日には Twitter で問題が解決したことを報告しました(ツイート)。

    3.(インデックス登録の問題とは無関係な)その他の問題

    Google 検索は数多くのシステムで構成されており、それぞれが別のシステムと密に連携しています。問題が同時期に起きた場合そこには因果関係があることが多いですが、場合によっては同時期に直接関係のない複数の問題が発生することもあります。

    たとえば今回のケースでは、上記で説明したインデックス登録の問題とほぼ同時期に、新しい Google ニュースにおける最新のコンテンツの収集に関する問題が短時間発生しました。さらに、ページのレンダリング中に、特定の URL が Googlebot を他の無関係なページにリダイレクトし始めました。この問題はインデックス登録の問題とは関係ないもので、すぐに解決することができました(ツイート 1ツイート 2)。

    Google のコミュニケーションとその改善予定

    数週間の間に行った(これまでご紹介してきた)ソーシャル メディアを使用した報告に加え、2 つの別チャネル(Search Console と Search Console ヘルプセンター)でウェブマスターに詳細を説明しました。

    Search Console ヘルプセンター記事

    Google は、問題を完全に特定した後、Search Console のデータの異常に関するヘルプページを更新しました。このページは、多数のウェブマスターに影響が及ぶ場合に、データ破損に関する情報を Search Console サービスに伝えるために使用されます。

    Search Console

    すべてのユーザーがソーシャル メディアや外部のヘルプセンター ページを読むわけではないので、Search Console レポートにアノテーションを追加して、データが正確でない可能性があることをユーザーに通知しました(下の画像を参照)。この情報は、問題が解決した後に追加したものです。[詳細を見る] をクリックすると、ヘルプセンターの「データの異常」ページに移動します。

    インデックス登録ページのインデックス カバレッジ レポートで、特定の問題をユーザーに通知するために含めることができるデータ アノテーションの例。

    今後のコミュニケーションについて

    問題が発生した場合、Google には「事後分析」の文化があります。障害に関して報告するドキュメントを作成し、同じ問題が今後発生しないよう努めます。プロセス全体について詳しくは、Google サイト信頼性エンジニアリングのウェブサイトをご覧ください。

    4 月のインデックス登録の問題をきっかけに、大規模なシステム障害が発生した場合にウェブマスターに明確に伝える方法を事後分析に含めました。主な決定事項は次のとおりです。

    1. Search Console 内で広範な問題に関する情報を迅速に共有する方法を探り、機能停止が疑われる場合にウェブマスターが確認すべき主な参照ポイントとして役立つ情報を提供します。
    2. 必要に応じて、より迅速に Search Console のデータの異常ページに投稿します(Search Console データに長期間にわたって障害が見られる場合)。
    3. このような問題の発生時に、Google が問題を認識しており、その解決が近いことを速やかに知らせてウェブマスターの方々に安心していただけるよう、可能な限り速やかに Twitter で発信を続けます。

    上記のコミットメントは、今後起こり得る同様の状況に備えて、ウェブマスターに対し全体的な透明性を確保するためのものです。

    改善策の実施例「新しい URL のインデックスが登録されない」

    5 月 22 日に別の問題が発生した際、新しいコミュニケーション方法を試しました。発生した問題は、特定の URL の処理中、予定されていたインフラストラクチャ アップグレードの後に重複管理システムのメモリが不足し、すべての受信 URL の処理が停止したというものです。

    上記 の 3 つのポイントに加えて、コミュニケーションについて考慮した結果を時系列で示します。

    1. Google が問題を認識(カリフォルニア時間 5 月 22 日午前 5 時半頃)
      現在発生中の問題についてツイート(同 5 月 22 日午前 6 時 40 分頃)
      解決したことをツイート(同 5 月 22 日午後 10 時頃)
    2. ヘルプセンターの「データの異常」ページを更新することを検討しましたが、大部分のウェブマスターの Search Console データに長期的な影響はないと判断し、更新を見送ることにしました。
    3. この問題によりご迷惑をかけたことで、「いずれかの Google システムに問題が発生し、ウェブマスターに影響を及ぼす可能性がある」ことを Search Console 上で明確に知らせる手段が必要という以前の結論が裏付けられることになりました。こうしたソリューションの実装には時間がかかる場合があります。このトピックは今後も引き続き取り上げていく予定です。

    8 月にも同様のインデックスの問題が発生しました。5 月 22 日の時と同じように、みなさんに問題の発生と問題解決に取り組んでいることをお伝えするツイートを行い、問題が解決した際にもツイートしてお知らせしました。

    デバッグ方法とお問い合わせについて

    この投稿により、Google のシステムの複雑さと、時にはシステム障害が発生する事を知っていただけたことと思います。また、問題が発生したときに Google がどのようにお知らせするかをご理解いただく一助となれば幸いです。ただし、この投稿ではシステムの広範囲にわたる障害に焦点を当てていますが、ほとんどのウェブサイトにおけるインデックス登録の問題は、個々のウェブサイトの構成に原因があります。構成によっては Google 検索が対象のウェブサイトのインデックスを適切に登録できない場合がありますので、ご留意ください。そのような場合、ウェブマスターは Search Consoleヘルプセンターを使用して問題をデバッグすることができます。デバッグした結果、自身のサイトの問題ではないと考えられる場合、または解決方法がわからない場合は、Google や Google コミュニティまでご連絡ください。いつでもお待ちしております。Google に問題を報告する方法は次のとおりです。

    • ウェブマスター コミュニティを確認する。他のウェブマスターが報告した問題で、あなたのサイトに影響を及ぼすものが含まれている場合があります。
    • 直接、報告する。イベントの際などにも直接ご報告ください。いつでもお待ちしています(カレンダー)。
    • Google プロダクト内で報告する。Search Console のフィードバック ツールをご利用いただくと、非常に助かります。
    • TwitterYouTube もぜひご活用下さい。

    Webmaster Conference Sapporo 開催のお知らせ

    Google の検索チームでは、ウェブマスターやサイト運営に関わる皆さんを結ぶことを目的に 2016 年より毎年 Google 検索をテーマとしたイベントを開催しております。今年は、沖縄と福岡で同様のイベントを開催しました。そして今回、札幌でも開催することが決まりましたのでお知らせします。
    イベントでは検索の仕組み、Google 画像検索についてのセッションや Q&A の時間を設けるほか、Google 社員と参加者のみなさんの交流タイムなどを予定しています。開催概要は次のとおりです。

    開催概要

    日時:2019 年 09 月 12 日(木)
    13 時 00 分開場、14 時 00 分開始
    19 時 00 分頃終了予定
    20 時 30 分懇親会終了
    スピーカー:
    • Takeaki Kanaya(金谷武明)
    • Anna Ogawa(小川安奈)
    • Gary Illyes
    • Malik Mairaj Syed
    • Mariya Moeva
    会場:ACU 札幌
    費用:無料
    定員:100 名(招待枠含む)
    お申し込みはこちらから!
    (締め切り:2019 年 08 月 18 日(水) 深夜 24 時まで)
    今回も一般の方による Lightning Talk を設ける予定です。登壇を希望される方は、ぜひお申込みフォームからお知らせください!
    みなさまのご応募お待ちしております!
    前回開催された Webmaster Conference Fukuoka の様子
    ※ 応募多数の場合は、抽選とさせていただきます。
    ※ 参加者は 08 月 21 日以降メールにてご連絡致します。なお、抽選の場合、参加者のみのご連絡とさせていただきます。
    ※ 会場までの交通費等のサポートはありませんのでご了承ください。

    Webmaster Conference: 最適なイベントをあなたに

    Google では長年にわたり、数百ものカンファレンスやイベントに参加して数千人ものウェブマスターの皆様にお話をしたり、数百時間にもおよぶ動画を録画したりすることで、ウェブ制作者の皆様が Google の検索結果でのパフォーマンス向上に役立つ情報を容易に入手できるよう努めてきました。今回それをさらに一歩進めて、海外の会議への参加が困難な方でも同じ情報を入手できるようにしたいと考えました。

    そこでこの度 Google は、Webmaster Conference を世界各地で開催していくことを正式に発表します。このイベントは主に、検索カンファレンスへの参加や Google 検索関連情報の入手が困難な地域や、特に検索イベントの必要性が高い地域で開催します。たとえば、ある地域でハッキングされたサイトの問題が生じていることが判明した場合は、そのトピックに焦点を当てたイベントを開催するかもしれません。

    Google は、言語、経済状況、性別、場所などの属性に関係なく、ウェブ制作者の皆様に平等に機会を提供したいと考えています。そのため、Webmaster Conference は常に無料で、その地域のアクセスが容易な場所で開催されます。また、地域のコミュニティからのフィードバックと分析に基づいて、イベントに登録した皆様に適したものになるよう調整が行われます。つまり、このイベントは、参加者が Google 検索に対して持ち合わせている知識に関係なく、必要な情報を得られるように調整されているということです。スピーチは開催地の言語で行われ、他言語の場合は通訳が付きます。ご要望に応じて、可能な限り手話通訳も提供したいと考えています。

    Webmaster Conference Okinawa

    イベントの構成は地域によって異なります。たとえば日本の沖縄では、ウェブ制作の初心者から上級者の方までが一堂に会し、Google 画像検索でのパフォーマンス向上に焦点を当てた有意義なイベントが、半日にわたって開催されました。Webmaster Conference IndiaWebmaster Conference Indonesia では構成を変えて、より高速なウェブサイトの開発に焦点を移すことが考えられます。今年の後半にはヨーロッパと北アメリカでもウェブ コミュニティを開催する予定です。詳しくは今後の発表をお待ちください。

    Google は、今後もこれまでどおり外部のイベントに参加します。ここで紹介したイベントは、既存のイベントを補完する目的で開催するものです。今後のイベントについて詳しくは、毎月更新される Webmaster Conference サイトをご覧ください。また、Google のブログ@googlewmc(Twitter)のフォローもお忘れなく!

    Search Console で構造化データのモニタリングする

    構造化データに関する前回の記事で、構造化データとは何か、なぜサイトに追加すべきなのかという点について説明しました。Google では構造化データを重視しており、関連する検索機能の強化やツールの改良に継続的に取り組んでいます。そのため、Google はウェブマスターやデベロッパーの皆様による構造化データの実装および診断を支援するソリューションの開発に力を注いでいます。

    この記事では、サイトの構造化データをモニタリングし、最大限に活用するために、Search Console でできることについて説明します。また、より有用な新機能についてもご紹介します。以下が新たに追加される内容です。詳細については記事の中で取り上げます。

    1. 構造化データの構文エラーを集計できるように、「解析不能な構造化データ」の項目がレポートに追加されました。
    2. 拡張レポートに、サイトリンク検索ボックスロゴの項目が追加されました。

    構造化データ全体のパフォーマンスをモニタリングする

    Search Console では、ウェブサイトで構造化データに関する問題が新たに検出されるたびに、アカウント所有者にメールが送信されます。しかしながら、既存の問題が悪化した場合には、メールは送信されません。そのため、定期的に Search Console を確認する必要があります。

    毎日そのような作業を行う必要はありませんが、すべての機能が意図したとおりに動作しているか、時折確認することをお勧めします。ウェブサイトへ変更を加えた際にはしばらくして Search Console で変更が上手く行ったかどうかを確認するのを習慣づけるのも良いかもしれません。

    サイトの特定の構造化データ機能に関するすべてのエラーについて把握しておきたい場合は、左側のサイドバーにある拡張メニューに移動し、確認したい機能をクリックします。すべてのエラーと警告、正常な項目について、概要を確認できます。

    冒頭で述べたとおり、今回、新たにサイトリンク検索ボックスロゴの項目がレポートに追加され、サイトの構造化データについてより詳細に把握できるようになりました。レシピ、イベント、求人情報などの既存のレポート項目に加えられています。レポートの詳細については、Search Console ヘルプセンターをご覧ください。

    では、ここで拡張レポートのサンプルを見てみましょう。レポートに表示されるのは、拡張レポートの中でもページで検出された項目のみです。次のような内容を確認するのに役立ちます。

    • エラー、警告、正常な項目の傾向の確認: 棒グラフの上のボックスで色分けされた項目をクリックすると、それぞれの詳細が表示されます。
    • ページごとのエラー、警告の確認: 棒グラフの下の個別の行をクリックすると、現時点で問題の影響を受けているページが例示されます。
    画像: レシピの拡張レポート

    今回、解析不能な構造化データに関するレポートも導入されています。これは、構造化データの構文エラーなどにより、Google による機能タイプの識別が妨げられているケースを集計するものです。機能タイプの識別ができないことから、機能別のレポートを生成するのではなく、このようなケースの集計を行うことにしています。

    サイトに追加しようとした構造化データが解析されなかった場合には、データの種類にかかわらず、このレポートを確認してください。解析の問題が発生しているということは、サイトでリッチリザルトを活用できる機会が失われている可能性があります。下のスクリーンショットは、実際のレポートの様子です。さらに、レポートに実際にアクセスすることもできますし、ヘルプセンターでレポートについて詳しく確認することもできます。

    画像: 解析不能な構造化データに関するレポート

    URL レベルで構造化データをテストする

    ページが正常に処理されているか、またはリッチリザルトが有効になっているかを確認したい場合や、特定の URL でリッチリザルトが表示されない原因を突き止めたい場合には、URL 検査ツールを使用できます。このツールを使用することで、改善すべき部分を URL レベルで把握でき、対処すべき内容がわかりやすくなります。

    Search Console の上部にある検索ボックスに URL を貼り付けると、拡張した項目に関連する構造化データの正常動作部分や、エラーまたは警告が生じている部分を確認できます。下にレシピの場合のサンプルを示します。

    画像: 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 の事例紹介の中から、成果をいくつかご紹介します。

    • Eventbrite では、イベントの構造化データを使用したことで、検索からのトラフィックが前年比で 100% 増加しました。
    • Jobrapido では、Google 検索のしごと検索を導入したことで、自然検索トラフィックが 115% 増加し、自然検索トラフィックからの新規ユーザー登録数が 270% 増加しました。また、Google から求人ページにアクセスしたユーザーの直帰率は 15% 低下しました。
    • 楽天ではレシピ検索を使用したことで、検索エンジンからのトラフィックが 2.7 倍に増加し、セッション継続時間も 1.5 倍に増加しました。

    構造化データの使用方法

    サイトで構造化データのメリットを活用するには、いくつかの方法があります。以下では、目標(ブランド認知度を高める、コンテンツを紹介する、商品情報を紹介する)ごとに例を説明します。

    1. ブランド認知度を高める
    2. 構造化データを使ってブランドを宣伝する方法の 1 つとして、ロゴローカル ビジネスサイトリンク検索ボックスなどの機能を利用することが挙げられます。構造化データを追加するだけでなく、サイトのナレッジパネルを確認して、Google マイビジネスでビジネスを登録する必要があります。以下は、ロゴ付きのナレッジパネルの例です。

    3. コンテンツを紹介する
    4. ウェブ上でコンテンツを公開している場合、業界に応じて、コンテンツを宣伝してユーザーへの訴求力を高めるのに役立つ機能が多数用意されています。たとえば、記事パンくずリストイベント求人情報Q&Aレシピレビューなどがあります。レシピのリッチリザルトの例を示します。

    5. 商品情報を紹介する
    6. 商品を販売している場合、商品の構造化データ(価格、在庫状況、評価など)をページに追加できます。次に関連検索で商品がどのように表示されるかを示します。

    お試しいただいたご意見やご感想をお寄せください

    これで構造化データの重要性を理解していただけたと思います。Codelab を利用して、ページに構造化データを追加する方法を確認してください。本ブログでは、今後も構造化データについてご説明いたします。次回は、Search Console を使って構造化データによる効果を分析する方法について説明します。

    構造化データの有効な使用方法について、お客様のご意見、ご感想、事例をお待ちしています。フィードバックをご提供いただける場合は Google のコミュニティ フォーラムをご利用ください。

    Googlebot が常に最新のレンダリング エンジンをサポートするようになります

    Googlebot は、Google 検索のインデックスにウェブページを追加するためにウェブページを巡回しているクローラのことです。イベントやソーシャル メディアで寄せられる質問で最も多いものは、この Googlebot を最新の Chromium にアップデートしないのですか?というものでした。このたび、Googlebot では検索用にページをレンダリングする際に、最新の Chromium レンダリング エンジン(この投稿の時点でバージョン 74)を実行するようになりました。今後、Googlebot のレンダリング エンジンは定期的に更新され、最新のウェブ プラットフォームの機能をサポートできるようになります。

    皆様への影響

    以前のバージョンと比べて、Googlebot では次のような 1,000 以上の新機能がサポートされるようになりました。

    Googlebot 用の処理としてトランスパイルまたは polyfill を使用しているかどうかをご確認ください。使用している場合は、この処理が今後も必要かどうかをご検討ください。現在も一定の制限があるため、JavaScript 関連の問題のトラブルシューティングJavaScript SEO に関する動画シリーズをご確認ください。

    この投稿に関するご意見やご感想がありましたら、ウェブマスター フォーラムでお知らせください。または、オンライン オフィスアワーにご参加ください。

    求人情報ガイドラインを守って、より多くのトラフィックを集めましょう

    今年 1 月、仕事探しをよりスムーズにするために日本でもGoogle しごと検索がローンチしました。ウェブマスターが求人情報の構造化データを設定すると、求職者をあなたのサイトの求人情報に結びつけることにつながり、より関心の高い求職者をあなたのサイトの求人情報に誘導できます。そこで、求職者が満足できるよう、求人情報ガイドラインを遵守することが重要です。ここでは、以下の三点についてお知らせいたします。

    • 期限切れの求人情報を削除する
    • 求人の詳細ページに構造化データを配置する
    • 求人情報の詳細と構造化データ内の情報を一致させる

    期限切れの求人情報を削除する

    求職者が求人情報を見つけ、応募しようとしても、求人情報の有効期限がきれて応募できないのは、とても残念なことです。求職者は、求人情報に応募しようと決めたあとに、期限切れの求人であると気づくことがあります。期限切れの求人ページをあなたのサイトから削除することで、トラフィックが増加する可能性があります。求人情報を削除する方法については、求人情報を削除するを参照してください。

    求人の詳細ページに構造化データを配置する

    求職者は、求人情報の詳細ページにたどりつきたいのであり、求人リストにたどりつくのが目的ではありません。求人リストへのアクセスを回避するには、可能な限りもっとも詳細なページに構造化データを配置することです。求人リストの表示ページ(たとえば、求人検索結果ページ)に構造化データを配置しないで下さい。ひとつの仕事について詳細に記載されている求人情報ページにのみ、構造化データを配置してください。

    求人情報の詳細と構造化データ内の情報を一致させる

    JobPosting 構造化データに、求人掲載に存在しない情報が含まれているサイトがあります。Google しごと検索で表示される求人の詳細と、求人情報の説明ページが一致しない場合、求職者は混乱します。JobPosting 構造化データ内の情報が、常に求人掲載ページの情報と一致していることを確認してください。ここでは例を示します。

    • 構造化データに給与情報を追加する場合は、同一内容を求人情報の説明ページにも追加します。両方の給与の数字は一致させてください。
    • 構造化データの location は、求人掲載ページの職場と一致させてください。

    求人掲載ページのコンテンツと整合性のある構造化データを提供することは、求職者が仕事を見つけるのに役立つだけではなく、あなたの求人情報に対し、より関心の高い候補者を集められることにつながり、求人に適した候補者を見つけられるようになります。

    あなたのサイトが求人情報ガイドライン(このブログ投稿のガイドラインも含む)に違反している場合、Googleでは、あなたのサイトに対して手動による対策を実行し、Google しごと検索に求人を表示することができなくなる可能性があります。よくみられる違反例としては、構造化データの title フィールドに、給与や会社情報、キャッチコピーなどを詰め込んでいるケースです。タイトルには「ソフトウェア エンジニア」のように職務の名称のみを指定してください。求人情報のタイトルではありません。また、構造化データの hiringOrganization プロパティには、職務をを提供している組織名、会社名のみ指定してください。所在地や求人情報は含めないでください。手動による対策を受けた場合、問題を修正し、再審査リクエストを送信すると再審査を行えます。再審査で問題の修正が承認されると、あなたのサイトやページが、手動による対策から解除されます。

    詳細については、Job Posting 開発者向けドキュメントおよび Job Posting よくある質問を参照してください。

    Search Console で Discover のパフォーマンス データの提供を開始しました

    Discover は、検索をしていなくてもお気に入りのトピックに関する最新情報を入手できる機能として広く利用されています。そしてこのたび、ウェブマスターのみなさんがご自身のサイトへの Discover 経由のトラフィックを詳細に把握できるように、Google Search Console に新しいレポートを追加しました。このレポートにより、関連性の高い統計情報を共有し、次のような疑問に対する回答を見つけられます。

    • 自分のサイトはユーザーの Discover にどのくらい表示されているか?どのくらいのトラフィックがあるのか?
    • Discover で特にパフォーマンスの高いコンテンツはどれか?
    • 従来の検索結果と比べて、Discover ではコンテンツのパフォーマンスがどのように変化しているか?

    Discover とは

    Discover は Google 検索の一機能で、検索をしていなくてもお気に入りのトピックに関する最新情報を入手できます。ユーザーは、Google アプリや Google.com のモバイル版ホームページで、または Pixel スマートフォンのホーム画面から右にスワイプすることで、Discover を体験できます。2017 年のリリース以降、Discover は大幅な成長を遂げており、今や 1 か月のアクティブ ユーザーは 8 億を超えます。関心の高いトピックに関する記事や動画などのコンテンツを表示してユーザーを引き付け、新しい情報の探索を促しています。ユーザーは、トピックを直接フォローできます。また、表示させたいトピックや表示させたくないトピックを Google に伝えることもできます。さらに、Discover の魅力は最新情報の表示だけではありません。レシピから社会情勢、ファッション動画まで、公開日に関係なく最適なウェブ コンテンツを表示します。Discover 用のサイトの最適化方法については、こちらのガイドをご覧ください。

    Search Console における Discover

    新しい Discover レポートは、Discover に表示された実績が十分にあるウェブサイトに表示されます。なお、2019 年 3 月からのデータが表示対象となります。最適なコンテンツ戦略を策定し、公開日を問わず、魅力的な情報をユーザーに見つけてもらえるようにするうえで、このレポートがお役に立てば幸いです。

    レポートについてご不明な点やご意見などありましたら、ウェブマスター ヘルプ フォーラムまでお寄せいただくか、他のチャネルよりお問い合わせください。

    タイトル: 検索スパムの 2018 年の傾向 – ウェブスパム レポート 2018

    Google は、あらゆる検索に対して最高品質の結果を提供することを目指しています。この取り組みの一環として、Google では、いわゆる「ウェブスパム」という不正行為により検索体験、コンテンツ、行動の品質が低下し、ウェブマスター向けガイドラインに抵触しないよう対策を講じています。その結果、ユーザーがアクセスした検索結果ページに占めるスパムページの割合は 1% を大きく下回っています。本記事では、2018 年に私たちが行ったウェブスパム対策をご紹介します。

    2018 年のウェブスパムの傾向と Google の対策

    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 年もウェブスパムのない検索体験を皆様にお届けできるように努力を続けてまいります。

    ウェブサイトのトラフィックが正規 URL に統合されます

    現在 Search Console の検索パフォーマンス レポートでは Google 検索で表示された URL に、関連するすべての指標が記載されています。この仕様では詳細なデータがわかる反面、プロパティの管理は難しくなります。たとえばサイトのモバイル版と PC 版が複数のプロパティにわかれている場合、同じコンテンツの検索データをすべて表示するには、複数のプロパティを開かなければなりません。

    この問題を解消するため、Search Console では今後、検索指標の割り当て先を、Google 検索に表示された URL ではなく(Google が選択した)正規 URL にデータを統合することにしました。この変更には次のような利点があります。

    • 同一のコンテンツに対するすべての検索指標が(1 つの) 正規 URL に統合されます。特定のコンテンツの全体像を 1 つのプロパティで把握できるようになります。
    • 複数のモバイルページや AMP ページがある場合でも、すべてのデータ(一部のモバイル URL が正規となった場合はその URL を除く)が (1 つの)「正規の」プロパティに統合されます。
    • AMP レポートやモバイル フレンドリー レポートのユーザビリティが向上します。現在これらのレポートでは、エラーは正規ページ プロパティに関連付けられますが、表示回数は Google 検索で表示された URL が属するプロパティに関連付けられています。変更後は、表示回数とエラーが同じプロパティ内に表示されます。

    移行時期

    すべてのパフォーマンス データは 3 月末に移行が完了する予定です。データの継続性を確保するため、Google では統合済みデータの表示を 2018 年 1 月から開始しています。ユーザーの皆様は、移行期間中の数週間に新旧両方のバージョンを表示して、移行による影響や変化をご確認いただけます。

    API とデータポータルをお使いの皆様: Search Console API は 3 月末に正規データに変更されます。

    現在のデータへの影響

    • 個々の URL レベルでは、トラフィックが正規以外の URL(重複した URL)から正規 URL に移行されます。
    • プロパティ レベルでは、代替プロパティ(モバイルサイトなど)のデータが「正規のプロパティ」に移行されます。正規化がプロパティ レベルではなくそのページで行われ、モバイル プロパティにも正規ページがある可能性があるため、代替プロパティのトラフィックがゼロにならないこともありますが、ほとんどの場合はプロパティ レベルの大部分のデータが 1 つのプロパティに移行されます。また多くの場合、AMP プロパティ トラフィックはゼロになります(自己参照正規化ページを除く)。
    • トラフィックに関する重要な情報を失うことなく、デバイス、検索での見え方(AMP など)、国などのディメンションで引き続きデータをフィルタリングできます。

    トラフィックの変化について、以下に例を挙げましたのでご確認ください。

    変更に向けた準備

    • 各種プロパティに対するユーザー アクセスを変更するかどうかを検討してください。たとえば正規プロパティに新しいユーザーを追加する必要があるか、既存のユーザーが正規プロパティ以外のプロパティに引き続きアクセスする必要があるか、などです。
    • カスタム トラフィック レポートを作成していた場合は、トラフィック移行に適応するよう変更してください。
    • 特定の URL の正規 URL は、URL 検査ツールで確認できます。
    • 現在のシステムを使用して計算したトラフィック データを保存するには、パフォーマンス レポートの [データをエクスポート] ボタンまたは Search Console API を使用してデータをダウンロードしてください。

    サイト内で起こりうるデータの変化について、いくつか例を挙げました。以下の例で、正規サイト(example.com)と代替サイト(m.example.com)のトラフィック数がどのように変わるかをご確認ください。

    重要: 以下の例では、PC 版サイトにすべての正規ページが含まれ、モバイルサイトにすべての代替ページが含まれているものとします。実際には、一部の代替ページが PC 版サイトに、一部の正規ページがモバイルサイトに含まれている場合もあります。特定の URL の正規ページは URL 検査ツールで確認できます。

    総トラフィック

    現行バージョンでは、トラフィックが正規プロパティと代替プロパティで分かれています。新バージョンでは、すべてのトラフィックが正規プロパティに属するようになります。


    正規プロパティ
    (http://example.com)
    代替プロパティ
    (http://m.example.com)
    現行バージョン

    正規 URL に基づいた新バージョン

    差異+0.7K     |        +3K-0.7K        |          -3K

    ページ別のトラフィック

    ページ別の重複 URL と正規 URL のトラフィックの変化は、ページビューで確認できます。次の例は、正規ページと代替ページに分割されていたトラフィックが、すべて正規 URL に属するようになったことを示しています。


    正規プロパティ
    (http://example.com)
    代替プロパティ
    (http://m.example.com)

    現行バージョン

    新バージョン

    差異

    +150     |        +800

    -150     |        -800

    モバイル トラフィック

    現行バージョンでは、すべてのモバイル トラフィックが m. プロパティに属しています。新バージョンでは、次に示す [端末: モバイル] フィルタを適用すると、すべてのトラフィックが正規プロパティに属するようになります。


    正規プロパティ
    (http://example.com)
    代替プロパティ
    (http://m.example.com)

    現行バージョン

    新バージョン

    差異

    +0.7K      | +3K

    -0.7K      | -3K

    まとめ

    最初は少々混乱されるかもしれませんが、この変更によってサイトのトラフィック データは、今よりもずっと簡単にトラッキングできるようになります。ご不明な点がある場合は、ウェブマスター ヘルプ フォーラムをご利用ください。

    Search Console の新機能ドメイン プロパティをご紹介します

    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 ではさまざまな要素に基づいて日付を判断しています。たとえば、ページ自体に読者にもはっきりとわかるように明確に記載されている日付や、サイト運営者が構造化マークアップで指定している日付などが挙げられますが、これらに限定されません。

    どの要素も単独では信頼性にかけるため、Google が 1 つの要素にのみ頼ることはありません。サイト運営者が常に明確に表示される日付を提供しているとは限りません。構造化データが不足している場合や、正しいタイムゾーンが設定されていない場合もあります。そのため、Google のシステムでは、複数の要素を確認して、ページが公開された時点や大幅に更新された時点の最も正確と考えられる日付を推定しています。

    ページ上で日付を指定する方法

    Google が正しい日付を選択できるように、サイト所有者やサイト運営者は次のことを行ってください。

    • 明確な日付を表示する: ページ上で明確な日付を目立つように表示します。
    • 構造化データを使用する: datePublished および dateModified スキーマを使用し、AMP または非 AMP ページの正しいタイムゾーン指定子を指定します。構造化データを使用する場合は、ISO 8601 形式を使用するようにしてください。

    Google ニュースに関するガイドライン

    Google ニュースでは、コンテンツが公開または更新された日付と時刻の両方を明確に表示する必要があります。構造化データだけでは不十分なため、日付と時刻の表示に加えて、構造化データを使用することをおすすめします。日付と時刻は見出しと記事のテキストの間に配置してください。詳しくは、記事の日付に関するヘルプページもご覧ください。

    大きな変更を加えた記事の場合、日時を更新することには意味があります。しかし、やむを得ない理由もなしに、重要な情報を追加しないまま記事を人為的に更新するのはやめてください。また、以前に公開した記事をわずかに更新しただけの記事を作成し、古い方の記事を削除して、新しい記事にリダイレクトすることも避けてください。このような手法は、記事の URL に関するガイドラインに違反しています。

    ウェブページの日付に関するおすすめの方法

    • 上記の最も重要な要件に加えて、Google がウェブページに対して表示する最適な日付を判断するのに役立つ、おすすめの方法は次のとおりです。
    • ページがいつ更新されたかを示す: ページを大幅に更新する場合は、表示される日付も更新します(時刻を表示している場合は、時刻も更新します)。必要に応じて、2 つの日付(ページの当初の公開日と更新日)を表示することもできます。表示する場合は、読者にはっきりと見えるようにしてください。両方の日付を表示する場合は、やはり、アルゴリズムが認識しやすいように、AMP または非 AMP ページdatePublisheddateModified を使用することをおすすめします。
    • 正しいタイムゾーンを使用する: 時刻を指定する場合は、必要に応じて夏時間を考慮し、正しいタイムゾーンを指定してください。
    • 使い方に一貫性を持たせる: ページ内では、構造化データとページの表示部分とで正確に同じ日付(と時刻)を使用するようにしてください。ページで指定している場合は、同じタイムゾーンを使用します。
    • 将来の日付やページの内容に関連する日付を使用しない: そのページで取り上げているイベントに関連する日付、特に、今後発生するイベントやテーマの日付ではなく、ページ自体が公開または更新された時点の日付を必ず使用してください(必要な場合は、イベント マークアップを個別に使用できます)。
    • Google の構造化データのガイドラインに準拠する: Google では、ページで指定されている日付(一般には構造化データ)が使用されることを保証しているわけではありませんが、構造化
      データのガイドライン
      に準拠することで、Google のアルゴリズムに、コンピュータが解読できる形式で日付を認識してもらいやすくなります。
    • ページ上の他の日付を最小限に抑えることで問題を解決する: 上記のおすすめの方法を取り入れても、不正確な日付が選択されているのを見つけた場合は、ページに表示される他の日付(関連記事の横にある日付など)を削除するか最小限に抑えることを検討してください。

    これらのガイドラインをご活用いただくことで、ウェブサイトのページで正しい日付を指定するのが簡単になることを願っております。この記事や構造化データについてご不明な点などありましたら、ウェブマスター ヘルプ フォーラムでお気軽にご質問ください。

    Google 検索のイベントを沖縄と福岡で開催します

    2016 年から 2018 年まで 3 年間、Google の検索チームと、ウェブマスターやサイト運営に関わる皆さんを結ぶことを目的に、東京や大阪で Google 検索のイベントを開催してまいりました。
    今回、沖縄と福岡で Google 検索をテーマとしたイベントを開催します。イベントでは検索の仕組み、Google 画像検索、Search Console についてのセッションや Q&A の時間を設けるほか、Google 社員と参加者のみなさんの交流タイムなどを予定しています。開催概要は次のとおりです。


    開催概要

    1)沖縄会場
    日時:2019 年 04 月 09 日(火)
    13 時 00 分開場、14 時 00 分開始
    19 時 00 分頃終了予定
    20 時 30 分懇親会終了
    スピーカー:
    • Gary Illyes
    • Idan Avraham
    • Anna Ogawa(小川安奈)
    • Takeaki Kanaya(金谷武明)
    場所:沖縄青年会館
    費用:無料
    定員:120 名(招待枠含む)


    2)福岡会場
    日時:2019 年 04 月 12 日(金)
    13 時 00 分開場、14 時 00 分開始
    19 時 00 分頃終了予定
    20 時 30 分懇親会終了
    スピーカー:
    • Gary Illyes
    • Anna Ogawa(小川安奈)
    • Takeaki Kanaya(金谷武明)
    場所:ACU Hakata
    費用:無料
    定員:120 名(招待枠含む)


    お申し込みはこちらから!
    (締め切り:2019 年 03 月 17 日(日) 深夜 24 時まで)
    今回は一般の方による Lightning Talk を設ける予定です。登壇を希望される方は、ぜひお申込みフォームからお知らせください!
    みなさまのご応募お待ちしております!
    ※ 応募多数の場合は、抽選とさせていただきます。
    ※ 参加者は 3/20 以降メールにてご連絡致します。なお、抽選の場合、参加者のみのご連絡とさせていただきます。
    ※ 会場までの交通費等のサポートはありませんのでご了承ください。

    新しい Search Console で重大な課題に取り組みましょう ~ 今後のロードマップのご紹介

    Google では昨年、さまざまな新機能を備えた新しい Search Console正式版としてリリース(英語)しました。新しい Search Console では、サイト所有者の皆様がより重大な課題に取り組めるようにすることを目標とし、ユーザーの利便性を第一に新機能の開発に力を注ぎました。その結果、従来の Search Console の古い機能を一部廃止することができ、新しい Search Console にさらに機能を追加して改善する余地ができました。

    2019 年 3 月末までに予定している Search Console の変更点は以下のとおりです。

    新しいインデックス カバレッジ レポートのクロールエラー

    皆様からのフィードバックで多かったのが、Search Console のクロールエラーの一覧でどのエラーを優先的に解決すべきかわかりづらいというご意見でした(存在しない URL のクロールは通常の動作ですが、解決する必要のない 404 エラーが大量に報告されることがありました)。どの問題を重要視すべきかを再検討し、サイトのインデックス登録に使用するパターンを変更したことで、重要度の高い問題を特定しやすくなりました。この変更が、より迅速な問題解決と再クロール リクエストにつながるものと確信しています。これに伴い、パソコン、スマートフォン、サイト全体のエラーを示す従来のクロールエラー レポートを廃止します。エラーの認識や報告の方法は今後も改善してまいりますので、ご要望などございましたらツールからフィードバックをお送りください。

    クロールエラー レポートの廃止に伴い、同じ内部システムをベースとするクロールエラー API も廃止することにしています。現在のところ、代替となる API を提供する予定はありません。この変更については、API をご利用の皆様に改めてお知らせいたします。

    インデックス カバレッジのサイトマップ データ

    新しい Search Console への移行に伴い、サイトマップ レポートを一新します。新しいサイトマップ レポートは従来のサイトマップ レポートのほとんどの機能を継承し、さらに画像や動画などの情報を充実させることを予定しています。また、サイトマップ ファイルで送信した URL については、インデックス カバレッジ レポート内でサイトマップ ファイルを使用してどの URL をトラッキングするかを選択できるようにしました。これにより、注視しておきたい URL を簡単にトラッキングできるようになります。

    Fetch as Google は、URL 検査ツールに置き換わります

    新しい URL 検査ツールを使用すると、皆様のウェブサイト上の URL をさまざまな観点から検査できます。現在のインデックスの確認だけでなく、最近変更した URL のライブチェックも可能です。このツールを使用することで、URL に関する詳しい情報(HTTP ヘッダー、ページリソース、JavaScript コンソールログ、ページのスクリーンショットなど)も確認できます。ページの再クロールをツールから直接リクエストできるため、Google 検索への追加や更新がスムーズに行えるようになりました。

    ユーザー管理機能を [設定] に統合

    ユーザー管理インターフェースを改善し、これまで複数の場所に分かれていたユーザー管理機能を新しい Search Console の [設定] に統合しました。これに伴い、古い Search Console のユーザー管理機能は廃止となります。

    構造化データ ダッシュボードにカテゴリ別のレポートを追加

    サイトへのリッチリザルトの実装を容易にするため、新しい Search Console にいくつかのレポート(求人、レシピ、イベント、Q&A)を昨年追加しました。新しいレポートには、このような機能を今後も追加していく予定です。ページ上の構造化データの解析中に見つかった構文エラーについても、重大な問題を見過ごすことがないよう集計してレポートに表示することにしました。

    リッチリザルト機能でサポートされていないその他の構造化データタイプは、今後は Search Console のレポートには表示されません。これにより、重要性の低い問題に気をとられることなく、Google 検索への表示に影響する可能性のある問題に集中できるようになります。

    廃止された古い機能

    新しい Search Console では、不可欠と思われる機能に絞り込んだ結果、いくつかの機能を廃止することになりました。廃止された機能は以下のとおりです。

    HTML の候補 - 重複したタイトルや短すぎるタイトルを見つけることができるのは便利ですが、Google のアルゴリズムもここ数年で進化し、より効果的なタイトルを生成できるようになってきています。また、ウェブサイトをクロールしてタイトルと説明を抽出できる便利なツールも登場しています。

    プロパティ セット - 一部で高く評価されてきた機能ですが、利用者が少ないことから廃止することになりました。ただし、ウェブサイトをもっと包括的に把握したいというニーズがあることがわかりましたので、Search Console アカウントをドメイン全体にわたって(スキーマタイプやサブドメインに関係なく)管理するための機能を追加する予定です。今しばらくお待ちください(本機能につきましては、英語記事となりますが公開しました)。

    Android アプリ - 関連する機能のほとんどは、ここ数年で Firebase コンソールに移管されました。

    ブロックされたリソース - この機能を追加したのは、モバイル フレンドリーでないためにブロックされた CSS や JavaScript のファイルを特定し、ブロックを簡単に解除できるようにするためでした。この問題は数年前に比べるとかなり減少し、このツールの利用者数も大幅に減っています。また、ブロックされたリソースは URL 検査ツールで直接特定できるようになっています。

    フィードバックをお待ちしています!

    これらの変更は皆様の作業フローに影響する可能性があるため、可能な限り早い時期にお知らせすることにしました。ご不明な点、ご要望などございましたら、新しい Search Console から直接フィードバックをお送りください。詳細なフィードバックをご提供いただける場合はヘルプ フォーラムをご利用ください。スクリーンショットなども含めることができます。新しくなった Search Console が長きにわたって皆様のお役に立ち、サイトに影響する問題に集中して Google 検索をさらに有効に活用できるようになるものと確信しております。

    皆様にとって幸多き一年となりますよう。