検索
検索をクリア
検索終了
Google アプリ
メインメニュー
true

求人情報ステータス レポート

新しい Search Console のベータ版

このレポートを使用して、サイト上の求人情報のリッチリザルトを Google で処理できるかどうかの監視や、修正や更新を加えたページの Google への通知ができます。求人情報のリッチリザルトに関するデベロッパー向けドキュメントはこちらをご覧ください

求人情報レポートを開く

レポートの使用

このレポートは、サイト上で求人情報のリッチリザルトが検出された場合にのみ表示されます。このレポートにアクセスするには、サイト上で求人情報の項目が検出済みの状態のときに、新しい Search Console のダッシュボードにある概要の表で、求人情報の行をクリックします。

 

レポートを共有する

問題の詳細を共有するには、ページで [共有] ボタンをクリックしてください。このリンクでは、現在のページと、この問題についての検証履歴ページへのアクセス権のみが付与されます。リソースのその他のページへのアクセス権は付与されません。また、共有ユーザーは、あなたのプロパティやアカウントに対して操作を実行することもできません。このページの共有を無効にすることで、いつでもリンクを取り消すことができます。

 

確認すべき点

求人情報のデータ内に現在のエラーがない状態にする必要があります。つまり、現在のエラー数が 0 になる必要があります。エラーがある場合は、次のような状態が考えられます。

  • エラーの急激な増加が見られる場合、特にエラーが特定のタイプに集中している場合は、テンプレートに加えた変更が原因である可能性があります。
  • 項目の総数が減少し、対応するエラーが見られない場合は、Google がページにアクセスできないか、求人情報の項目がページ上に表示されていない可能性があります。

エラーが検出された場合は、下記の「問題の優先順位の設定と修正」の説明に沿って対処します。

警告が出ている場合、求人情報が Google 検索にリッチリザルトとして表示されなくなることはありませんが、ユーザーの利便性が多少低下する可能性があります。警告への対処方法については、「問題の優先順位の設定と修正」をご覧ください。

問題の優先順位の設定と修正

求人情報の概要のページで、問題に優先順位を設定して修正する共通の手順は次のとおりです。

  1. 求人情報の概要のページで、警告をフィルタで除外して最初にエラーに焦点を合わせます。
  2. エラーの総数やインデックス登録されたページの総数に影響している可能性のある問題の手がかりとして、エラーの総数と特定のエラーの増加との間に対応関係がないかを調べます。
  3. エラーの行を、数が多いものから順に修正します。
    1. エラーのグラフで急激な増加が見られる場合は、表のエラーの行でそれに対応する急激な増加を探します。
    2. エラーの行をクリックしてエラーの詳細ページを表示し、詳細情報を確認します。該当するエラータイプの説明で、最適な対処方法を確認します(サイト上のこの問題に該当する箇所がすべてこのリストに表示されるとは限りません。これは、前回サイトがクロールされた後でこの問題に該当する箇所が出現した、この問題に該当する項目が 1,000 を超えている、などのさまざまな理由によるものです)。
    3. サイト上の問題を修正し、修正をテストしたうえで、ウェブに修正が反映されていることを確認します。
    4. 問題の詳細ページに戻り、[修正を検証] ボタンをクリックして検証の処理を開始します。この処理には数日ほどかかり、進捗状況を知らせる通知メールが届きます。
    5. 該当する問題のある箇所がすべて修正されると(つまり、修正が検証済みになると)、その問題の該当ページの数が 0 になり、問題のステータスが更新されます。
  4. 引き続き、エラーを修正します。
  5. すべてのエラーの修正が終わったら警告のフィルタを解除し、必要に応じて、警告の出ている箇所を修正します。警告のほとんどは、構造化データ内で必須でない項目が欠落していることに関する警告です。リッチリザルトに含まれている情報が多いほど、サイトの訪問者の利便性が向上します。

エラーの急激な増加

急激な増加が、特定の項目群のステータスの変化が原因で発生したのかどうかを判別します。

  1. 急激な増加が見られる場合は、別のステータス(エラーまたは有効)でそれに対応する減少があるかどうかを探します。
  2. 対応する減少が見つかったら、両者の URL が同じであることを確認します。
  3. 項目が別のステータスに変化している場合、ステータスが変わる原因となった変更を探します。

エラーの急激な増加の最もよくある原因は、サイト上の複数のページで使用されているテンプレートへのエラーの混入です。

求人情報の欠落

ウェブサイトに求人情報の構造化データを実装したのに、ダッシュボードに何も表示されない場合:

  • 最も可能性の高い理由は、Google がまだページをクロールしていないことです。サイトマップ レポートFetch as Google を使って、そうしたページのインデックス登録をリクエストします。インデックス登録のリクエストは即時に処理されるわけではありません。処理されるまでに最大で 1 週間程度かかります。
  • その他に考えられる理由:
    • Google がページにアクセスできない可能性があります。Fetch as Google を使用してみてください。また、noindex ディレクティブがないかも確認してください。
    • 構造化データが破損しているために、データが求人情報として認識されていない可能性があります。構造化データ テストツールを使用してページをチェックします。ページのコードを貼り付けるのではなく、ライブページの URL を送信してください。
    • お客様の地域で求人情報の表示がサポートされていません。
  • データが掲載されているページを Google から認識できるようにします。構造化データ テストツールを使用してページの URL を送信し、Google がページにアクセスできることを確認します。

問題のステータス

グラフでは、問題のステータスはすべての求人項目のなかで最も重大度の高いステータスに適用されます。表では、問題のステータスは個別の項目に適用されます。適用されるステータスは次のとおりです。

  • エラー: 問題のステータスが「エラー」の求人情報は、Google 検索にリッチリザルトとして表示できません。エラー状態の項目には、エラーのほかに警告もある場合があります。
  • 警告: 問題のステータスが「警告」の求人情報は、Google 検索にリッチリザルトとして表示されます。ステータスが「警告」の問題は、任意指定の値が欠落しているか無効であることを示しているか、重要ではない項目にエラーがあることを示しています。通常、任意指定の項目のデータ提供が多いほど、ユーザーの利便性を向上できます。
  • 完了: ステータスが「完了」の求人情報は、Google 検索にリッチリザルトとして表示されます。必須のデータと任意指定のデータがすべて正しく指定されています。

1 つの求人情報内の問題をすべて確認するには、そのページに対してテストを実行します。

ステータスの合計数に関する注意事項: 表内のステータス ラベルごとの合計値が、グラフ上部の対応するステータスのタブの合計値より多くなることがよくあります。2 つの例を以下に示します。
  • 1 つの項目に種類の異なる 3 つの警告が出ている場合、表にはその項目が 3 回表示されますが、タブの合計では警告の出ている項目 1 件としてのみカウントされます。
  • 1 つの項目にエラーと警告の両方が出ている場合、タブの合計ではエラーの出ている項目 1 件としてのみカウントされます(項目は、自身に含まれている最も重大度の高いステータスでカウントされます)。

About validation

After you fix all instances of a specific issue on your site, you can ask Google to validate your changes. If all known instances are gone, the issue is marked as fixed in the status table and dropped to the bottom of the table. Search Console tracks the validation state of the issue as a whole, as well as the state of each instance of the issue. When all instances of the issue are gone, the issue is considered fixed. (For actual states recorded, see Issue validation state and Instance validation state.)

More about issue lifetime...

An issue's lifetime extends from the first time any instance of that issue was detected on your site until 90 days after the last instance was marked as gone from your site. If ninety days pass without any recurrences, the issue is removed from the report history.

The issue's first detected date is the first time the issue was detected during the issue's lifetime, and does not change. Therefore:

  • If all instances of an issue are fixed, but a new instance of the issue occurs 15 days later, the issue is marked as open, and "first detected" date remains the original date.
  • If the same issue occurs 91 days after the last instance was fixed, the previous issue was closed, and so this is recorded as a new issue, with the first detected date set to "today".

Basic validation flow

Here is an overview of the validation process after you click Validate Fix for an issue. This process can take several days, and you will receive progress notifications by email.

  1. When you click Validate Fix, Search Console immediately checks a few pages.
    • If the current instance exists in any of these pages, validation ends, and the validation state remains unchanged.
    • If the sample pages do not have the current error, validation continues with state Started. If validation finds other unrelated issues, these issues are counted against that other issue type and validation continues.
  2. Search Console works through the list of known URLs affected by this issue. Only URLs with known instances of this issue are queued for recrawling, not the whole site. Search Console keeps a record of all URLs checked in the validation history, which can be reached from the issue details page.
  3. When a URL is checked:
    1. If the issue is not found, the instance validation state changes to Passing. If this is the first instance checked after validation has started, the issue validation state changes to Looking good.
    2. If the URL is no longer reachable, the instance validation state changes to Other (which is not an error state).
    3. If the instance is still present, issue state changes to Failed and validation ends. If this is a new page discovered by normal crawling, it is considered another instance of this existing issue.
  4. When all error and warning URLs have been checked and the issue count is 0, the issue state changes to Passed. Important: Even when the number of affected pages drops to 0 and issue state changes to Passed, the original severity label will still be shown (Error or Warning).

Even if you never click "start validation" Google can detect fixed instances of an issue. If Google detects that all instances of an issue have been fixed during its regular crawl, it will change the issue state to "N/A" on the report.

When is an issue considered "fixed" for a URL or item?

An issue is marked as fixed for a URL when either of the following conditions are met:

  • When the URL is crawled and the issue is no longer found on the page. Note that for an AMP tag error, this can mean that you either fixed the tag or that the tag has been removed (if the tag is not required). During a validation attempt, it will be considered as "passed."
  • If the page is not available to Google for any reason (page removed, marked noindex, requires authentication, and so on), the issue will be considered as fixed for that URL. During a validation attempt, it is counted in the "other" validation state.

Revalidation

When you click Revalidate for a failed validation, validation restarts for all failed instances, plus any new instances of this issue discovered through normal crawling.

You should wait for a validation cycle to complete before requesting another cycle, even if you have fixed some issues during the current cycle.

Instances that have passed validation (marked Passed) or are no longer reachable (marked Other) are not checked again, and are removed from the history when you click Revalidate.

Validation history

You can see the progress of a validation request by clicking the validation details link in the issue details page.

Items in validation history are grouped by URL for the AMP report and Index Status report. In the Jobs report or other structured data reports, items are grouped by the combination of URL + structured data item (as determined by the item's Name value).

Issue validation state

The following validation states apply to a given issue:

  • Not started: There are one or more pages with an instance of this issue that you have never begun a validation attempt for. Next steps:
    1. Click into the issue to learn the details of the error. Inspect the individual pages to see examples of the error on the live page using the AMP Test. (If the AMP Test does not show the error on the page, it is because you fixed the error on the live page after Google found the error and generated this issue report.)
    2. Click "Learn more" on the details page to see the details of the rule that was violated.
    3. Click an example URL row in the table to get details on that specific error.
    4. Fix your pages and then click Validate fix to have Google recrawl your pages. Google will notify you about the progress of the validation. Validation takes anywhere from a few days up to about two weeks, so please be patient. 
  • Started:  You have begun a validation attempt and no remaining instances of the issue have been found yet. Next step: Google will send notifications as validation proceeds, telling you what to do, if necessary.
  • Looking good: You started a validation attempt, and all issue instances that have been checked so far have been fixed. Next step: Nothing to do, but Google will send notifications as validation proceeds, telling you what to do.
  • Passed: All known instances of the issue are gone (or the affected URL is no longer available). You must have clicked "Validate fix" to get to this state (if instances disappeared without you requesting validation, state would change to N/A). Next step: Nothing more to do.
  • N/A: Google found that the issue was fixed on all URLs, even though you never started a validation attempt. Next step: Nothing more to do.
  • Failed: A certain threshold of pages still contain this issue, after you clicked "Validate." Next steps: Fix the issue and revalidate.

Instance validation state

After validation has been requested, every known issue instance is assigned one of the following validation states for a specific issue (states Passed and Other not used in Index Status report):

  • Pending validation: Queued for validation. The last time Google looked, this issue instance existed.
  • Passed: Google checked for the issue instance and it no longer exists. Can reach this state only if you explicitly clicked Validate for this issue instance.
  • Failed: Google checked for the issue instance and it's still there. Can reach this state only if you explicitly clicked Validate for this issue instance.
  • Other: Google couldn't reach the URL hosting the instance, or (for structured data) couldn't find the item on the page any more. Considered equivalent to Passed.

Note that the same URL can have different states for different issues; For example, if a single page has both issue X and issue Y, issue X can be in validation state Passed and issue Y on the same page can be in validation state Pending.

 

問題の詳細ページ

求人情報の概要のページの行をクリックすると、その特定の問題の詳細が表示されます。1 つの問題について、1 ページ上の複数の求人情報に該当箇所がある場合や、1 件の求人情報内に複数の該当箇所がある場合もあります。

問題の詳細ページには、以下の情報が掲載されます。

  • ステータス: この問題の検証ステータスです。
  • 初検出日: サイトでこの問題が初めて検出された日付です。このタイプの問題がすべて解決され、最後の箇所を修正してから 90 日以内に同じ問題が新たに発生した場合、初検出日は、問題が新たに発生した日ではなく元の初検出日の日付になります。
  • 例: この問題に該当する求人情報です。サイト上のこの問題に該当する箇所がすべてリストに表示されるとは限りません。これは、前回サイトがクロールされた後でこの問題に該当する箇所が出現した、この問題に該当する項目の数が 1,000 を超えている、などのさまざまな理由によるものです。
  • 項目のタイプ: 求人情報の構造化データの name の値です。
  • 前回のクロール: この問題を含んでいるページが前回クロールされた日時です。

特定のページに対してテストを実行するには、表で問題をクリックして、そのページ上のすべての構造化データをテストします。

 

既知の問題

この新しい Search Console のベータ版には、次のような既知の問題があります。こうした問題について報告していただく必要はございませんが、その他の機能についてのご意見や、発見した問題がありましたら、ナビゲーション バーに組み込まれているフィードバック機能を使ってお知らせください。

  • 一部の問題には長い名前が付けられており、わかりにくい状態になっています。
  • モバイル版は現在開発中です。
  • プロパティ セットはまだサポートされていません。
この記事は役に立ちましたか?
改善できる点がありましたらお聞かせください。
false