AMP status report

This report helps you fix errors that prevent your AMP pages from appearing in Google Search results with AMP-specific features.

The top level view shows critical issues affecting AMP pages on your your site. Click a specific issue to see pages affected by this issue and issue details.

OPEN AMP REPORT

 

AMP status report in Search Console - Google Search Console Training

 

What's in the report

Critical issues: Pages affected by critical AMP issues can't be displayed on Google. A list of critical issues found on your site is shown directly beneath the chart on the top-level page of the AMP report, with the title Why AMP pages are invalid. Click an issue in the list to see pages with the selected issue.

Non-critical issues (warnings): AMP pages with non-critical issues can still be shown on Google if they don't have any critical issues as well. A list of non-critical issues found on your site is shown below the critical issues list on the top-level page of the AMP report, with the title Non-critical issues. Click an issue in the list to see pages with the selected issue. AMP pages with warnings might not be shown with all possible AMP features (such as being shown in a Top Stories carousel). In other words, these pages might only be shown as plain blue link search results.

Page status (valid and invalid pages): AMP pages are either valid or invalid. Valid AMP pages can be shown on Google; invalid AMP pages can't be shown on Google. If a page has any critical issues, it is considered invalid; if it has only warnings, or no issues at all, it is considered valid. You can see a list of valid AMP pages by clicking View data about valid AMP pages below the chart on the top-level page of the AMP report.

What to look for

You should aim for the following numbers in your report:

The list of affected URLs is a sample, but isn't guaranteed to show every URL affected by a given issue. The report is limited to 1,000 URLs per issue. Also, it's possible that there are additional pages that we didn't detect or count for some reason.

The report can show only 200 critical + non-critical issues total. If your site has a very long list of issues (whether or not there are active instances), only the top 200 issues, ranked by importance, will be shown.

AMP issues

In addition to standard AMP-specific errors, the report can expose the following additional issues (errors and warnings).

Google-specific AMP issues
Issue Description
Content mismatch: Missing embedded video The canonical web page has an embedded video that is missing in the AMP version. It is usually best to include all the same important content resources in your AMP version as in the canonical web page. Note that the video is detected by URL; if you have two different URLs pointing to the same video, you will see this warning.
Image size smaller than recommended size The structured data in the AMP refers to an image that is smaller than our recommended size. This may prevent the page from appearing with all AMP-related features on Google Search, and may also prevent your Discover cards from appearing with large images (leading to decreased website traffic and user engagement). To fix, use a larger image according to our guidelines.
AMP page domain mismatch The AMP page is hosted on a different domain than its canonical version. This can be confusing to mobile searchers who see one URL domain in search results and a different one when they open the page in the AMP reader. (Does not affect page indexing or ranking.)
URL not found (404) The AMP URL requested could not be found. Learn about fixing 404 pages.
Server error (5XX) Unspecified 5XX server error when requesting the AMP page. Learn more about server errors.
Blocked by robots.txt The requested AMP URL was blocked by a robots.txt rule. If this is not what you want, test your robots.txt file for the blocking rule, and then modify or remove the rule (or ask your web developer to do it for you).
Crawl issue Unspecified crawling error for the AMP page. Use the URL Inspection tool on your AMP URL to troubleshoot the problem. 
Referenced AMP URL is not an AMP A canonical page references an AMP that is not, in fact, an AMP page. Learn how a non-AMP page should reference an AMP page.
Referenced AMP URL is self-canonical AMP The canonical page points to a stand-alone AMP. You cannot reference a stand-alone AMP as the AMP version of a page. Learn how to reference an AMP from a non-AMP page.
URL marked 'noindex' AMP is blocked by a 'noindex' directive. Google cannot index a page that is blocked by noindex; either remove the noindex directive, or remove the reference to the blocked page.
'unavailable_after' date for this page has expired AMP page has an "unavailable_after" meta tag or directive that has already passed, indicating that it should no longer be served. You should either update the tag to a future date, or remove the tag.
Canonical points to invalid URL A canonical page references an AMP version using an invalidly formatted URL. Learn how to properly reference an AMP version.
amp-story canonical error

A page incorrectly references an amp-story page as its AMP version. This is not allowed because an amp-story page is, by definition, self-canonical: it must point to itself with a <rel="canonical"> tag, and cannot serve as an AMP version of another page.
Module script declared without nomodule alternative (or the reverse) You are using either a <script type="module"> tag without a matching <script nomodule async> tag, or the reverse. These tags must be used in matching pairs to enable proper handling by browsers that do or don't support module scripts.
Missing URL in HTML tag The specified HTML tag requires an attribute with a valid, non-zero-length URL, but the URL is an empty string. Provide a valid URL for the highlighted attribute.
The attribute is missing or incorrect, but required by the attribute 'on' The specified attribute is required but is incorrect or missing. This attribute is required because you specified an "on" attribute in the same tag.
<svg> child tag found outside of an <svg> block. You specified a tag outside an <svg> block that must be nested within an <svg> block.
The page is loading multiple versions of the same extension script The page is loading multiple versions of the same AMP extension. To fix, remove one version of the script.
Signed exchange issues

Both the AMP status report and the URL inspection report can show issues for AMPs that use the signed exchange protocol.

To see signed exchange details about an issue

You can find information about the signed exchange associated with an AMP in multiple places:

  • In the URL Inspection tool, click the issue under AMP version details.
  • In the AMP Status report, click a URL in the issue details table.

To see if your AMP uses signed exchange

To see whether or not Google has detected any signed exchange headers or payloads for your AMP:

  1. Inspect the AMP URL (either use the URL Inspection tool to inspect a specific URL, or in the AMP Status report, click the inspect icon next to the URL in the issue details table).
  2. Click View crawled page in the results page to open a side panel containing more information.
  3. Click the More Info tab.
  4. Below the Signed exchange label you will see a status that indicates whether Google detected any signed exchange components for that AMP.

List of signed exchange issues

The following issues can occur when your AMP uses the signed exchange protocol.

The signed exchange is invalid

The HTTP response was a signed exchange that did not meet the Google AMP Cache requirements. As a result, the page will be presented to users without any information from the signature.

Impact to your site:

The page will be presented in an AMP viewer with a Google URL, rather than its original URL.

Next steps:

Addressing this error is optional; pages with this error will still display properly inside an AMP viewer. If you wish for this page to be presented with its signed URL, then continue reading.

This error could occur for several reasons, including:

If you are using a signed exchange service provider, consult them for assistance.

If you are using AMP Packager:

  • Verify that you are running the latest release of AMP Packager.
  • If so, please file a bug.

The signed exchange payload has a parse error

The HTTP response was a signed exchange whose “payload” (body) did not meet the Google AMP Cache requirements. As a result, the page will be presented to users without any information from the signature.

Impact to your site:

The page will be presented in an AMP viewer with a Google URL, rather than its original URL.

Next steps:

Addressing this error is optional; pages with this error will still display properly inside an AMP viewer. If you wish for this page to be presented with its signed URL, then continue reading.

Try the following steps to find and fix the error:

  • Verify that the HTML does not contain an invalid UTF-8 encoding. For the erroring $URL, run curl $URL | iconv -f UTF-8 -t UTF-8 >/dev/null, and check for any error messages such as “illegal input sequence”. If it does, please ensure the document is properly UTF-8 encoded. Two common sources of multibyte characters are non-English text and spaces.
  • Verify that the HTML does not contain a U+0000 NULL or a Unicode character that causes an HTML parse error.
  • Verify that the HTML is unchanged after calling transform -config NONE. There are two common reasons for it to change:

The header 'header_name' for the signed exchange payload has an invalid value

The HTTP response was a signed exchange that contained a signed response header that didn’t meet one of the Google AMP Cache requirements. As a result, the page will be presented to users without any information from the signature.

Impact to your site:

The page will be presented in an AMP viewer with a Google URL, rather than its original URL.

Next steps:

Addressing this error is optional; pages with this error will still display properly inside an AMP viewer. If you wish for this page to be presented with its signed URL, then continue reading.

If you are using a signed exchange service provider, consult them for assistance.

If you are using AMP Packager:

  • Verify that you are running the latest release of AMP Packager.
  • If so, please file a bug.

The mandatory header 'header_name' for the signed exchange payload is missing

The HTTP response was a signed exchange that was missing the given header, required either by the signed exchanges specification or the Google AMP Cache requirements. As a result, the page will be presented to users without any information from the signature.

Impact to your site:

The page will be presented in an AMP viewer with a Google URL, rather than its original URL.

Next steps:

Addressing this error is optional; pages with this error will still display properly inside an AMP viewer. If you wish for this page to be presented with its signed URL, then continue reading.

If you are using a signed exchange service provider, consult them for assistance.

If you are using AMP Packager:

  • Verify that you are running the latest release of AMP Packager.
  • If so, please file a bug.

The signature header for the signed exchange cannot be parsed

The HTTP response was a signed exchange that contained a signature header that was not well-formed according to the signed exchanges specification. As a result, the page will be presented to users without any information from the signature.

Impact to your site:

The page will be presented in an AMP viewer with a Google URL, rather than its original URL.

Next steps:

Addressing this error is optional; pages with this error will still display properly inside an AMP viewer. If you wish for this page to be presented with its signed URL, then continue reading.

If you are using a signed exchange service provider, consult them for assistance.

If you are using AMP Packager:

  • Verify that you are running the latest release of AMP Packager.
  • If so, please file a bug.

The parameter 'parameter_name' in the signed exchange signature header is invalid

The HTTP response was a signed exchange whose signature header had an incorrect value for the given parameter, as required by the signed exchanges specification. As a result, the page will be presented to users without any information from the signature.

Impact to your site:

The page will be presented in an AMP viewer with a Google URL, rather than its original URL.

Next steps:

Addressing this error is optional; pages with this error will still display properly inside an AMP viewer. If you wish for this page to be presented with its signed URL, then continue reading.

If you are using a signed exchange service provider, consult them for assistance.

If you are using AMP Packager:

  • Verify that you are running the latest release of AMP Packager.
  • If so, please file a bug.

The dates for the signed exchange are invalid

The HTTP response was a signed exchange whose signature header had an incorrect value for the date or expires parameter, as required by the signed exchanges specification or the Google AMP Cache requirements. (In particular, the signature must be valid at the time it is fetched, and at least 4 days in the future.) As a result, the page will be presented to users without any information from the signature

Impact to your site:

The page will be presented in an AMP viewer with a Google URL, rather than its original URL.

Next steps:

Addressing this error is optional; pages with this error will still display properly inside an AMP viewer. If you wish for this page to be presented with its signed URL, then continue reading.

If you are using a signed exchange service provider, consult them for assistance.

If you are using AMP Packager, this could happen for several reasons:

  • Verify that your front-end reverse-proxy is not caching signed exchange responses for too long. Make multiple requests for the page with curl -H 'Accept: application/signed-exchange;v=b3' -H 'AMP-Cache-Transform: any' and search for "date=" in each response; verify that the subsequent number is different each time.
  • Verify that you are running the latest release of AMP Packager.
  • If you have ruled out all of the above, there may be a bug in AMP Packager; please file a bug.

The certificate chain referenced by the signed exchange 'cert-url' cannot be parsed

The HTTP response was a signed exchange whose cert-url was not well-formed per the signed exchanges specification. As a result, the page will be presented to users without any information from the signature.

Impact to your site:

The page will be presented in an AMP viewer with a Google URL, rather than its original URL.

Next steps:

Addressing this error is optional; pages with this error will still display properly inside an AMP viewer. If you wish for this page to be presented with its signed URL, then continue reading.

If you are using a signed exchange service provider, consult them for assistance.

If you are using AMP Packager:

  • Verify that you are running the latest release of AMP Packager.
  • If so, please file a bug.

The certificate chain referenced by 'cert-url' is invalid for the signed exchange

The HTTP response was a signed exchange whose cert-url was invalid according to the signed exchanges specification. As a result, the page will be presented to users without any information from the signature.

Impact to your site:

The page will be presented in an AMP viewer with a Google URL, rather than its original URL.

Next steps:

Addressing this error is optional; pages with this error will still display properly inside an AMP viewer. If you wish for this page to be presented with its signed URL, then continue reading.

If you are using a signed exchange service provider, consult them for assistance.

If you are using AMP Packager, this error could occur for several reasons. Some things to check:

  • Verify that your CertFile does not contain a full list of the leaf certificate plus intermediates.
  • Verify that AMP Packager was not launched with the -development or -invalidcert flag. In production mode, AMP Packager will verify several aspects of the certificate.
  • Verify that your frontend reverse-proxy is not caching /amppkg/cert/ URLs for longer than is set by their max-age.
  • Verify that your frontend reverse-proxy is not modifying cache headers; this could cause an upstream proxy to cache these certificate chains for too long. To test, determine the corresponding /amppkg/cert/ URL on your internal packager domain, fetch it including response headers (for instance, with curl -i), and compare the response headers to those returned by the frontend server.
  • Verify that your certificate contains an SCT, for instance using the openssl x509 tool. If it does not, please consult your certificate authority.
  • Verify that you are running the latest release of AMP Packager.
  • If you have ruled out all of the above, there may be a bug in AMP Packager; please file a bug.

The signed exchange cannot be parsed

The HTTP response had a content-type of application/signed-exchange;v=b3, but the response body could not be extracted. This could be because it failed to meet the high-level requirements of that type, or because its payload was improperly Merkle-encoded.

Impact to your site:

If the page has a corresponding non-AMP page, Google Search will index that instead. Otherwise, the page might not appear in Google Search at all.

Next steps:

If you are using a signed exchange service provider, consult them for assistance.

If you are using AMP Packager, this could happen for several reasons:

  • Verify that your front-end reverse-proxy is not altering the responses from the packager. For the erroring URL, determine the corresponding /priv/doc URL on your internal packager domain, and test it using dump-signedexchange. If the internal packager response is a valid signed exchange but the external front-end response is not, then there is likely a configuration error in the front end.
  • Verify that you are running the latest release of AMP Packager.
  • If you have ruled out all of the above, there may be a bug in AMP Packager; please file a bug.

The URL for the inner payload does not match the request URL for the signed exchange

The HTTP response was a signed exchange whose fallbackUrl did not match the request URL; they must be byte-for-byte equal. As a result, Google Search will not trust that the response is representative of the request URL.

Impact to your site:

If the page has a corresponding non-AMP page, Google Search will index that instead. Otherwise, the page might not appear in Google Search at all.

Next steps:

If you are using a signed exchange service provider, consult them for assistance. Possible workarounds include changing the page’s URL to avoid bugs in common URL parsers. For instance, try eliminating percent-encoded or reserved characters, or unusual query string encodings such as a ? with no parameters.

If you are using AMP Packager, this could happen for several reasons:

  • Verify that your front-end reverse-proxy is rewriting URLs correctly. Issues are especially likely on URLs with percent-encoded or reserved characters. For instance, nginx has issues with its rewrite directive and the pathless form of its proxy_pass directive. To test this, send some test requests to your front end, and compare these to the URLs that AMP Packager logs to its stdout.
  • Verify that you are running the latest release of AMP Packager.
  • If you have ruled out all of the above, there may be a bug in AMP Packager; please file a bug.

The header 'header_name' for the signed exchange HTTP response has an invalid value

The HTTP response had a content-type of application/signed-exchange, but the response headers were invalid in some other way. For instance, the content-type may be lacking a v=b3 parameter. As a result, the format is unknown to Google and hence the response body cannot be extracted.

Impact to your site:

If the page has a corresponding non-AMP page, Google Search will index that instead. Otherwise, the page might not appear in Google Search at all.

Next steps:

If you are using a signed exchange service provider, consult them for assistance.

If you are using AMP Packager, this could happen for several reasons:

  • Verify that your front-end reverse-proxy is not altering the content-type headers. For the erroring URL, determine the corresponding /priv/doc URL on your internal packager domain, and fetch it including response headers (for instance, with curl -i). If the headers differ between the internal packager response and the external frontend response, this may be the source of the error. If the difference is in a header other than content-type, please file a bug against this help doc to update the list of requirements.
  • Verify that you are running the latest release of AMP Packager.
  • If you have ruled out all of the above, there may be a bug in AMP Packager; please file a bug.

Prioritize and fix issues

  1. Look at the list of critical issues for your site in the Why AMP pages are invalid table.
  2. Analyze your errors:
    • See if any increase in the total error count is caused mostly by a single error: look for a corresponding spike in a single issue in the table.
    • Fix errors caused by a common cause first (such as a bad template), then fix errors that are unique to each page.
  3. Fix your errors: click a row in the table to see the error details page:
    1. The details page includes a sample of affected URLs. The list limited to 1,000 rows, and might not include very recently discovered instances of this error, or pages that haven't been recrawled since the error appeared.
    2. Click Learn more next to an issue to get official documentation about the error.
    3. Click a URL in the example URLs table to see the issue highlighted in the page code.
    4. Click the inspect icon  to run a detailed test against a specific page. This test will pinpoint all errors (not just the current issue) and provide a code explorer highlighting the errors and providing more information. If the page hasn't been recrawled recently, you will see the issue for the indexed page but not the live page. if so, you can request indexing of that specific page.
    5. Fix all instances of the issue on your site, test your fix, and ensure that your fixes are live on the web.
  4. When you've fixed all instances, return to the issue details page and click the Validate Fix button to begin the validation process. This process is not immediate. See About validation to understand the validation process.
  5. Continue fixing errors.
  6. If the total of valid and invalid pages is significantly lower than the number of AMP pages on your site, see Troubleshooting missing AMP pages.
  7. When all critical errors have been fixed, consider fixing the non-critical issues. Some non-critical issues (for example, using deprecated features) can become critical in the future.

Sharing the report

You can share issue details in the coverage or enhancement reports by clicking the Share button on the page. This link grants access only to the current issue details 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.

Exporting report data

Many reports provide an export button to export the report data. Both chart and table data are exported. Values shown as either ~ or - in the report (not available/not a number) will be zeros in the downloaded data.

Troubleshooting missing AMP pages

If the count of AMP pages (valid + invalid) in the report is less than the count of AMP pages on your site, here are some possible reasons:

  • Confirm that your canonical non-AMP page is correctly linking to your AMP page.
  • Confirm that your AMP or canonical pages are not roboted or noindexed, or protected by login requirements.
  • Inspect the canonical page URL for your AMP to see if it's indexed.
    • If the canonical is there, confirm that it correctly links to your AMP page.
    • If the canonical is not there, submit it for indexing.
  • It can take a few days for Google to find and crawl the missing pages, depending on how you notify Google about the new pages.
  • Some valid AMP pages might not be included in this report, although they might be listed in the Page Indexing report. This is because the Page Indexing report must be more comprehensive in order to help you debug indexing issues on your report, while the AMP Status report potentially covers fewer, but more relevant pages, but in greater detail, in order to help you debug specific AMP issues on your site. To confirm whether an AMP page is indexed, use the URL Inspection tool, which will have the definitive answer.

Validate your fixes

After you fix all instances of a specific issue on your site, you can ask Google to confirm your fixes. If all known instances are fixed, the issue count goes to zero in the issues table and drops to the bottom of the table.

Why validate

Telling Google that you have fixed all issues in a specific issue status or category has the following benefits:

  • You'll get an email when Google has confirmed your fix on all URLs, or conversely, if Google has found remaining instances of that issue.
  • You can track Google's progress in confirming your fixes, and see a log of all pages queued for checking, and the fix status of each URL.

It might not always make sense to fix and validate a specific issue on your website: for example, URLs blocked by robots.txt are probably intentionally blocked. Use your judgment when deciding whether to address a given issue.

You can also fix issues without validating; Google updates your instance count whenever it crawls a page with known issues, whether or not you explicitly requested fix validation.

Pro tip: Validate your fixes by sitemap
To speed up a fix request, create and submit a sitemap containing only your most important pages, then filter the report by that sitemap before requesting a fix validation. A validation request against a subset of your affected URLs can complete faster than a request that includes all affected URLs on your site.

Start validation

To tell Search Console that you fixed an issue:

  1. Fix all instances of the issue on your site. If you missed a fix, validation will stop when Google finds a single remaining instance of that issue.
  2. Open the issue details page of the issue that you fixed. Click the issue in the issues list in your report.
    • ⚠️ If you are filtered to a specific sitemap in your report, the validation will apply only to items in the sitemap at the time you requested validation. This might be what you want, or it might not. Just be aware of it.
  3. Click Validate fix. Do not click Validate fix again until validation has succeeded or failed. More details about how Google checks your fixes.
  4. You can monitor the validation progress. Validation typically takes up to about two weeks, but in some cases can take much longer, so please be patient. You will receive a notification when validation succeeds or fails.
  5. If validation fails, you can see which URL caused the validation to fail by clicking See details in the issue details page. Fix this page, confirm your fix on all URLs in Pending state, and restart validation.

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

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

  • When the URL is crawled and the issue is no longer found on the page. 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 labeled 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 categorized in the Other validation state.

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 issues table.

An 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 the new detection date.
Validation flow

Here is an overview of the validation process after you click Validate Fix for an issue. This process can take several days or even longer, 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 queued URLs have been checked for this issue and found to be fixed of this issue, the issue state changes to Passed. However, even when all instances have been fixed, the severity label of the issue doesn't change (Error or Warning), only the number of affected items (0).

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 count to 0 on the report.

Revalidation

⚠️ Wait for a validation cycle to complete before requesting another cycle, even if you have fixed some issues during the current cycle.

To restart a failed validation:

  1. Navigate into the validation log for the failed validation: Open to the issue details page of the issue that failed validation and click See details.
  2. Click Start new validation.
  3. Validation will restart for all URLs marked Pending or Failed, plus any new instances of this issue discovered through normal crawling since the last validation attempt. URLs marked Passed or Other are not rechecked.
  4. Validation typically takes up to about two weeks, but in some cases can take much longer, so please be patient.

See validation progress

To see the progress of a current validation request, or the history of the last request if a validation is not in progress:

  1. Open the issue details page for the issue. Click the issue row in the main report page to open the issue details page.
    • The validation request status is shown both in the issue details page and also in the Validation row of the Details table.
  2. Click See details to open the validation details page for that request.
    • The instance status for each URL included in the request is shown in the table.
    • The instance status applies to the specific issue that you are examining. You can have one issue labeled Passed on a page, but other issues labeled Failed, Pending, or Other on the same page.
    • In the AMP report and Page Indexing report, entries in the validation history page are grouped by URL.
    • In the Rich Result reports, items are grouped by the combination of URL + structured data item (as determined by the item's Name value).
Validation request status

The following validation states apply to validation for a given issue:

  • Not started: One or more instances of this issue have never been in a validation request for this issue.
    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.
    2. Click Learn more on the details page to see the details of the problem.
    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 start validation. Validation typically takes up to about two weeks, but in some cases can take much longer, 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 restart validation.
Instance validation status

After validation has been requested, every instance of the issue is assigned one of the following validation states:

  • Pending: Queued for validation. The last time Google looked, this issue instance existed.
  • Passed: [Not available in all reports] 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: [Not available in all reports] 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.

 

Known issues

The following are known issues in 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.
  • There can be a lag between when an issue is added to the graph and when it is added to the table.

Was this helpful?

How can we improve it?

Need more help?

Try these next steps:

Post to the help community Get answers from community members
true
New to Search Console?

Never used Search Console before? Start here, whether you're a complete beginner, an SEO expert, or a website developer.

Search
Clear search
Close search
Google apps
Main menu
1918900097833242217
true
Search Help Center
true
true
true
true
true
83844
false
false