Clear search
Close search
Google apps
Main menu

Job postings status report

New Search Console Beta experience

This report helps you monitor Google's ability to process JobPosting rich results on your site, and to inform Google about any fixes or updates that you have made to those pages. Read the developers' documentation for job posting rich results here.


Using the report

The report is visible only if Google has found JobPosting rich results on your site. The report can be reached by clicking a JobPostings row in the summary table in the dashboard of the new Search Console, if JobPosting items were found on your site.


Sharing the report

You can share issue details by clicking the Share button on the page. This link grants access only to the current page, plus any validation history pages for this issue, to anyone with the link. It does not grant access to other pages for your resource, or enable the shared user to perform any actions on your property or account. You can revoke the link at any time by disabling sharing for this page.


What to look for

Ideally you should not see any current errors in your JobPosting data, so your current error count should be 0. If you do see errors:

  • A spike in errors might be the result of a change in your template, especially if errors are concentrated in specific types.
  • A drop in total items without corresponding errors might mean that Google can't access your pages, or that your JobPosting items aren't otherwise appearing on your pages.

If you find errors, handle them as described in the Prioritize and fix section below.

Warnings do not disqualify your job listings from being shown as rich results in Google Search, but they can provide a somewhat reduced experience for your users. See the prioritize and fix section to learn how to address warnings.

Prioritize and fix issues

Here is common process for prioritizing and fixing your issues from the summary Job postings page:

  1. On the summary Job postings page, filter out the warnings and focus on the errors first.
  2. See if you can find any correspondence between the total number of errors and an increase in a specific error as a clue to which issue might be affecting your total error or total indexed page count.
  3. Fix error rows in descending order of count:
    1. If there is a spike in the error chart, look for a corresponding spike in the error rows in the table.
    2. Click an error row to get to the error details page with more information. Read the description about the specific error type to learn how to handle it best. (It's possible that not all instances of this issue on your site will be shown in the list, for various reasons, such as instances that have appeared since the last crawl of your site, or instances that affect more than 1,000 items.)
    3. Fix the issue on your site, test your fix, and ensure that your fixes are live on the web.
    4. Return to the issue details page and click the Validate Fix button to begin the validation process. This process can take several days, and you will receive email notifications of the progress.
    5. If all instances of that issue are found to be fixed (that is, the fix is validated), the count of pages affected by that issue will become 0 and the issue status will be updated.
  4. Continue fixing errors.
  5. When all errors have been fixed, remove the filter for warnings, and consider fixing the warnings. Most warnings are about missing optional fields in your structured data. Having more information in rich result can be more useful to your site visitors.

Error spikes

Determine if a spike caused was by a group of items moving from one severity to another:

  1. If you see a spike, look for a corresponding drop in another state (error or valid).
  2. If you find a corresponding drop, confirm that they are the same URLs.
  3. If the items moved from one state to another, determine what you changed to cause this.

The most common reason for a spike in errors is adding an error to a template used by many pages on your site.

Missing Job Postings

 If you have implemented Job Posting structured data on your website, but you don't see any listed in your dashboard:

  • The most likely reason is that Google hasn't crawled the pages yet. Use the Sitemaps report or Fetch as Google to request indexing for those pages. Indexing requests are not immediate; it can take up to a week to fulfill an index request.
  • Other possible reasons:
    • Google can't access the page: try using Fetch as Google. Also check for the presence of a noindex directive.
    • The structured data might be so broken that Google doesn't recognize it as a Jobs posting. Use the Structured Data Testing Tool to check your page. Submit the URL of the live page rather than pasting page code.
    • Jobs isn't supported for your location.
  • Ensure that the pages hosting the data are visible to Google. Use the Structured Data Testing Tool to submit the URL of your page to confirm that Google has access to your pages.

Issue statuses

In the graph, issue status applies to the most severe status of the entire Job item; in the table, issue status applies to the individual field. The following statuses apply:

  • Error: A job posting with error issue cannot appear in Google Search as a rich result. Items in error state have at least one error, and can also have one or more warnings.
  • Warning: A job postings with a warning issue is eligible to appear in Google Search as a rich result. Warning issues are either suggestions for missing or invalid optional values, or errors in non-critical fields. Providing more optional field data can often enable a better experience for the user.
  • Complete: A job posting with status complete is eligible to appear in Google Search as a rich result. All required and optional data is correctly provided.

If you want to see all issues within a single job posting, run a test against that specific page.

A note about the status totals: The total value per status label in the table often exceeds the total value in the corresponding status tab totals above the graph. Two examples:
  • A single item with 3 different warnings will appear 3 times in the table, but count as only 1 item with a warning in the tab total.
  • An item with both an error and a warning will count only as 1 error item in the tab total. (An item is counted as the most severe status it contains.)

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 keeps track independently of the state of the issue and 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.


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.


Issue details page

Clicking on a row in the summary Job Postings page will show details for a specific issue. An issue can affect multiple job postings on a single page, and even can affect a single job posting multiple times.

The issue details page contains the following information:

  • State: Validation state of this issue. 
  • First detected The date when this issue was first detected on your site. If all issues of this type are resolved, and then a new instance of this issue appears within 90 days since the last instance was fixed, the date will be original first detected date, not date of the new appearance.
  • Examples: Job postings affected by this issue. It's possible that not all instances of that issue on your site will be listed for various reasons, such as instances that have appeared since the last crawl of your site, or issues that affect more than 1,000 items.
  • Item type: The name value of the job posting structured data.
  • Last crawled: The last time the page containing this issue was crawled.

To run a test on a specific page, click the issue in the table to test all structured data on that page.


Known issues

The following are known issues in this beta version of the new Search Console. No need to report them to us, but we'd love your feedback on any other features or issues you spot. Use the Feedback mechanism built into the navigation bar.

  • Some issues have long names that are not easy to understand.
  • The mobile experience is still a work in progress.
  • Property sets are not yet supported.
  • If your site has a very large number of issues (whether or not there are active instances), the report will show only the first 200 issues, sorted by importance.
Was this article helpful?
How can we improve it?