Наразі ця сторінка недоступна вашою мовою. Ви можете вибрати іншу мову внизу екрана або миттєво перекласти будь-яку веб-сторінку потрібною мовою за допомогою вбудованої функції перекладу Google Chrome.

Page Indexing report

See which pages Google can find and index on your site, and learn about any indexing problems encountered.

Open Page Indexing report

 

I<span/>ndex coverage status in Search Console - Google Search Console Training

 

Getting started

Non-experts usage guide

If you are new to indexing or SEO, or have a small site, here's how to get started:

  1. Decide whether you need to use this report. If your site has fewer than 500 pages, you probably don't need to use this report. Instead, use the following Google searches to see if key pages (or any pages) on your site are indexed. Only if these searches return no results for your site and you are willing to spend the time to fully understand this report should you use the Page Indexing report to see why your site isn't indexed (see the troubleshooting section).
    • See a sample of pages from your site that Google knows about:
      Syntax: site:<<site_root_domain_or_path>>
      Examples: site:example.com or site:example.com/petstore
    • Search for subjects covered by your site (search for terms from your most important pages, including your homepage):
      Syntax: site:<<site_root_domain_or_path>> term1 term2
      Example: site:example.com/petstore iguanas zebras.
    • Search for the exact URL of a page on your site to see whether Google has indexed it (search for the most important pages on your site, including your homepage):
      Syntax: site:<<exact-url>
      Example: site:http://example.com/petstore/gerbil
  2. Read this short user guide for a quick, easy explanation of this report.
  3. If you want to delve deeper:
    • Read how Google Search works. If you don't understand indexing, this report will confuse or frustrate you–trust us.
    • This report is not used to investigate the index status of specific pages. To find the index status of a specific page, use the URL Inspection tool.
    • What to look for in this report:
      • Are all of your important URLs green (indexed)? Most sites have at least a few unindexed pages, but all of your important pages should be indexed. Remember that duplicate URLs shouldn't be indexed. Check the index status of your homepage and key pages using the URL Inspection tool. Note that the list of example URLs in the report is limited to 1,000 items, and isn't guaranteed to show all URLs in a given status, even when less than 1,000 items.
      • Are the gray (not indexed) URLs not indexed for good reasons? It's fine for a URL not to be indexed for the right reasons—for example, an expected robots.txt rule on your site, a noindex tag on the page, a duplicate URL, or a 404 for a page that you've removed and have no replacement for.
      • If the total URL count in this report is much smaller than your site's page count, then Google isn't finding pages on your site. Some possible reasons for this:
        • The missing pages, or your site, is new. It can take a week or so for Google to start crawling and indexing a new page or site. If your page or site is new, wait a few days for Google to find and crawl it. In an urgent situation, or if waiting doesn't seem to be working, you can explicitly ask Google to crawl individual pages.
        • The missing pages aren't findable by Google. Google needs a way to find a page in order to crawl it. This means that it must be linked from a known page, or from a sitemap. For a new website, the best first step is to request indexing of your homepage, which should start Google crawling your website. For missing parts of a site, make sure they are linked properly. If you are using a site hosting service such as Wix or SquareSpace, they will probably tell Google about any new pages, once you publish them: check your site host's documentation to learn how to publish your pages and make them findable by search engines.
      • Read the documentation for your specific indexing issue to understand and, if necessary, fix the issue. Skipping the documentation will cost you more effort and time in the long run than reading the docs.
    • What not to look for:
      • Don't expect every URL on your site to be indexed. Some URLs might be duplicates or might not contain meaningful information. Just be sure that the key pages on your site are indexed.
      • Non-indexed URLs can be fine. Read and understand the specific reason for each non-indexed URL to confirm that the page shouldn't be indexed.
      • Don't expect totals here to match exactly your estimate of the number of URLs on your site. The indexed + not indexed totals above the chart are complete and accurate from Google's perspective, but small discrepancies can occur for various reasons.
      • Just because a page is indexed doesn't guarantee that it will show up in your search results. Search results are customized for each user's search history, location, and many other variables, so even if a page is indexed, it won't show up in every search, or in the same ranking when it does. Therefore, if Search Console says a URL is indexed, but it doesn't turn up in your search results, you can assume that it is indexed and eligible to appear in search results.

FAQs

What does this report show?

The Page Indexing report shows how many URLs on your site have been crawled and indexed by Google. (If you don't have a good knowledge of what these terms mean, please read how Google Search works). Google finds URLs in many ways, and tries to crawl most of them. If a URL is missing or unavailable, Google will probably continue to try crawling that URL for a while.

What is indexing?

Indexing is when Google finds (crawls) your page, then processes content of the page and puts the page into the Google index (indexes it), where the page may be eligible to appear in Google Search results, as well on as other Google services, like Discover. For more about indexing, read how Google Search works.

How do I get my page or site indexed?

If you are using a site hosting service such as Wix or SquareSpace, your hosting service will probably tell Google whenever you publish or update a page. Check your site host's documentation to learn how to publish your pages and make them findable by search engines.

If you are creating a site or page without a hosting service, you can use a sitemap or various other methods to tell Google about new sites or pages.

We strongly recommend ensuring that your homepage is indexed. Starting from your homepage, Google should be able to index all the other pages on your site, if your site has comprehensive and properly implemented site navigation for visitors.

Is it OK if a page isn't indexed?

Absolutely. Google doesn't index pages that are blocked by a robots.txt rule or noindex tag, or pages that are duplicates of other pages on your site, or pages that are inappropriate to index them (for example, variations of a page with different filters applied). Use the URL Inspection tool to see why a specific page isn't indexed. If there is an indexing error, or if a page was not indexed for a reason that doesn't make sense, follow the documentation to understand and fix the issue.

SEOs, developers, and experienced website owners usage guide

If you're an experienced SEO, developer, or website owner, but haven't used the Page Indexing report yet:
  1. Read how Google Search works. If you don't understand indexing, this report will just be confusing or frustrating: trust us.
  2. Follow the guidelines in Navigating the report, including What to look for and What not to look for.
  3. Read the troubleshooting section to understand and fix common problems.
  4. Remember that Not indexed is not necessarily bad. Examine the reason given for not indexing a given URL.
  5. Read the documentation for your specific issue to understand the issue and see how to fix it.

Navigating the report

The Page Indexing report shows the Google indexing status of all URLs that Google knows about in your property.

Summary page

The top-level summary page in the report shows a graph and count of your indexed and non-indexed (but requested) pages, as well as tables showing reasons that URLs couldn't be indexed, or other indexing improvements.

  • Why pages aren’t indexed table shows issues that prevented URLs from being indexed on your site. Click a row to see a details page that shows URLs affected by this issue and your site's history with this issue.
  • Improve page experience table shows issues that didn't prevent page indexing, but we recommend that you fix them to improve Google's ability to understand your pages. Click a row to see a details page that focuses on all URLs with the same issue.
  • View data about indexed pages link shows historical information about your indexed page count, as well as an example list of up to 1,000 URLs that are indexed.

What to look for

Ideally you should see a gradually increasing count of indexed pages as your site grows. If you see drops or spikes, see the troubleshooting section.

Your goal is to get the canonical version of every important page indexed. Duplicate or alternate pages shouldn't be indexed. Having a page marked duplicate or alternate is usually a good thing; it means that we've found the canonical page and indexed it. You can find the canonical for any URL by running the URL Inspection tool.

See more reasons why pages might be missing.

What not to look for

  • 100% coverage: You should not expect all URLs on your site to be indexed, only the canonical pages, as described above.
  • Immediate indexing: When you add new content, it can take a few days for Google to index it. You can reduce the indexing lag by requesting indexing.

Status

A URL can have one of the following statuses:

  • Not indexed: The URL is not indexed, either because of an indexing error, or because of a legitimate reason (for example, if the page is blocked from indexing by your robots.txt file, or is a duplicate page). The reasons why URLs weren't indexed are listed in Why pages aren’t indexed table. Read the documentation for each reason to determine whether it is something that you should fix. The Source value indicates whether this is probably something you can fix.
  • Indexed: These URLs were successfully indexed. See a sample of indexed URLs by clicking View data about indexed pages below the chart on the summary page for the report.

Reason

The reason why a URL couldn't be indexed. See the reason descriptions below for a description of each issue and how to handle it, if necessary.

Source

The Source value in the table shows whether the source of the issue is Google or the website. In general, you can fix only issues where the source is listed as "Website".

Validation

Whether you have requested validation of a fix for this issue, and if so, what the status of the validation attempt is. You should prioritize fixing issues that are in validation state "failed" or "not started" and source "Website".

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.

Sitemap filter

You can use the dropdown filter above the chart to filter index results by whether or not they are included in a sitemap. The following options are available:

  • All known pages [Default] - Show all URLs known to Google, whether or not they are listed in a sitemap.
  • All submitted pages - Show only URLs listed in a sitemap or sitemap index that was submitted using either the Sitemaps report or a robots.txt file on your site.
  • Unsubmitted pages only - Show only URLs that were not listed in a sitemap submitted using either the Sitemaps report or a robots.txt file on your site.
  • Specific sitemap URL - Show only URLs listed in a specific sitemap or sitemap index submitted using either the Sitemaps report or a robots.txt file on your site.

A URL is considered to submitted by a sitemap even if it was also discovered through some other mechanism (for example, by organic crawling from another page).

Details page

Click on a row in the summary page to open a details page for URLs on that site with the same issue or status. You can see details about the chosen issue by clicking Learn more at the top of the page.

The graph on this page shows the count of affected pages over time.

The examples table shows an example list of pages affected by this issue. The list does not necessarily show all URLs with that issue, and is limited to 1,000 rows. Each example row has the following functionality:

  • Click the row to see more details about that URL.
  • opens the URL in a new tab.
  • opens URL Inspection for that URL.
  • copies the URL

When you've fixed all instances of an error or warning, click Validate Fix to let Google know that you've fixed the issue.

See a URL marked with an issue that you've already fixed? Perhaps you fixed the issue AFTER the last Google crawl. Therefore, if you see a URL with an issue that you have fixed, be sure to check the crawl date for that URL. Check and confirm your fix, then request re-indexing

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

The table is sorted by what we think are the most important issues to address. To investigate a specific reason in the indexing errors table:

  1. Click a row in the Why pages aren't indexed table. Decide whether there is a problem based on the not indexed reason and your indexing goal, and whether this is something that you can fix, based on the source value.
  2. Read the specific information about the issue.
  3. Inspect an example URL affected by the issue:
    1. Click the inspect iconnext to the URL in the examples table to open URL Inspection for that URL.
    2. See crawl and index details for that URL in the Coverage > Crawl and Coverage > Indexing sections of the URL Inspection report.
    3. To test the live version of the page, click Test live URL.

Understand and fix common indexing issues

Here are some of the most common indexing issues that you might see in this report:

Drop in total indexed pages without corresponding errors

If you see a drop in total indexed pages without a corresponding increase in errors, you might be blocking access to your existing pages via robots.txt, 'noindex' or a required login. Look for a spike in non-indexed URLs that corresponds to your drop in indexed pages.

More non-indexed than indexed pages

If you see more non-indexed pages than indexed pages, look at the reason shown in the report. Common reasons for large groups of non-indexed pages include:

  • You have a robots.txt rule that blocks Google from crawling large sections of your site. If you are blocking the wrong pages, unblock them.
  • Your site has a large number of duplicate pages, probably because it uses parameters to filter or sort a common collection (for example: type=dress or color=green or sort=price). These page probably shouldn't be indexed, if they are just showing the same content that is sorted, filtered, or reached in different ways.
Error spikes

Error spikes might be caused by a change in your template that introduces a new error, or you might have submitted a sitemap that includes URLs that are blocked for crawling by robots.txt, noindex, or a login requirement.

If you see an error spike:

  1. See if you can find any correspondence between the total number of indexing errors or total indexed count and the sparkline next to a specific error row on the summary page as a clue to which issue might be affecting your total error or total indexed page count.
  2. Click into the details pages for any errors that seem to be contributing to your error spike. Read the description about the specific error type to learn how to handle it best.
  3. Click into an issue, and inspect an example page to see what the error is, if necessary.
  4. Fix all instances for the error, and request validation by clicking Validate Fix in the details page for that reason. Read more about validation.
  5. You'll get notifications as your validation proceeds, but you can check back after a few days to see whether your error count has gone down.
Server errors
A server error means that Googlebot couldn't access your URL, the request timed out, or your site was busy. As a result, Googlebot was forced to abandon the request.
Check the host status verdict for your site in the Crawl Stats report to see if Google is reporting site availability issues that you can confirm and fix.

Testing server connectivity

You can use the the URL Inspection tool to see if you can reproduce a server error reported by the Page Indexing report. Note that server errors can be transient, so your live test might succeed when Google's crawl failed due to a server error.

Fixing server connectivity errors

  • Look at your recent host availability in the Crawl Stats report to see if there is a persistent or large-scale issue with your site.
  • Reduce excessive page loading for dynamic page requests.
    A site that delivers the same content for multiple URLs is considered to deliver content dynamically (for example, www.example.com/shoes.php?color=red&size=7 serves the same content as www.example.com/shoes.php?size=7&color=red). Dynamic pages can take too long to respond, resulting in timeout issues. Or the server might return an overloaded status to ask Googlebot to crawl the site more slowly. In general, we recommend keeping parameter lists short and using them sparingly.
  • Make sure your site's hosting server is not down, overloaded, or misconfigured.
    If connection, timeout or response problems persists, check with your web hoster and consider increasing your site's ability to handle traffic.
  • Check that you are not inadvertently blocking Google.
    You might be blocking Google due to a system level issue, such as a DNS configuration issue, a misconfigured firewall or DoS protection system, or a content management system configuration. Protection systems are an important part of good hosting and are often configured to automatically block unusually high levels of server requests. However, because Googlebot often makes more requests than a human user, it can trigger these protection systems, causing them to block Googlebot and prevent it from crawling your website. To fix such issues, identify which part of your website's infrastructure is blocking Googlebot and remove the block. The firewall may not be under your control, so you may need to discuss this with your hosting provider.
  • Control search engine site crawling and indexing wisely.
    Some site owners intentionally prevent Googlebot from reaching their websites, perhaps using a firewall as described above. In these cases, usually the intent is not to entirely block Googlebot, but to control how the site is crawled and indexed. If this applies to you, check the following:
404 errors

In general, we recommend fixing only 404 errors that you link to yourself or list in a sitemap. If a page has been moved, you should return a 3XX redirect to the new page. Learn more about evaluating and fixing 404 errors.

Missing pages or sites

If your page is not in the report at all, one of the following is probably true:

  • Google doesn't know about the page. Some notes about page discoverability:
    • If this is a new site or page, remember that it can take some time for Google to find and crawl new sites or pages.
    • In order for Google to learn about a page, you must either submit a sitemap or page crawl request, or else Google must find a link to your page somewhere.
    • After a page URL is known, it can take some time (up to a few weeks) before Google crawls some or all of your site.
    • Indexing is never instant, even when you submit a crawl request directly.
    • Google doesn't guarantee that all pages everywhere will make it into the Google index.
  • Google can't reach your page (it requires a login, or is otherwise not available to all users on the internet).
  • The page has a noindex tag, which prevents Google from indexing it.
  • The page was dropped from the index for some reason.

To fix:

Use the URL Inspection tool to test the problem on your page. If the page is not in the Page Indexing report but it is listed as indexed in the URL Inspection report, it was probably indexed recently, and will appear in the Page Indexing report soon. If the page is listed as not indexed in the URL Inspection tool (which is what you'd expect), test the live page. The live page test results should indicate what the issue is: use the information from the test and the test documentation to learn how to fix the issue.

FAQs

Why is my page in the index? I don't want it indexed.

Google can index any URL that it finds unless you include a noindex directive on the page (or it has been temporarily blocked), and Google can find a page in many different ways, including someone linking to your page from another site.

  • If you want your page to be blocked from Google Search results, you can either require some kind of login for the page, or you can use a noindex directive on the page. Using a robots.txt rule is not recommended for blocking a page, and will actually prevent noindex from being seen by Google.
  • If you want your page to be removed from Google Search results after it has already been found, you'll need to follow these steps.

Why hasn't my site been reindexed lately?

Google reindexes pages based on a number of criteria, including how often it thinks the page changes. If your site doesn't change often, it might be on a slower refresh rate, which is fine, if your pages haven't changed. If your page has changed substantially since the last recrawl, you can ask Google to recrawl it. Remember, though, that Google automatically recrawls your pages, so don't bother asking for a recrawl unless there is an important change, and Google doesn't seem to have noticed it for a while (a week or more).

Can you please recrawl my page/site?

Ask Google to recrawl it.

Why are so many of my pages not indexed?

Look at the reasons detailed by the Page Indexing report. Here are the most common reasons for not indexing large quantities of URLs on a site:

  • You have a robots.txt rule that is blocking Google from crawling large sections of your site. These pages should be marked in the Page Indexing report as blocked by robots.txt. Track down and remove the blocking rule in your robots.txt file.
  • Your site has a large number of duplicate pages, typically because it uses parameters to filter or sort a common collection (for example: type=dress or color=green or sort=price). These pages will be labeled as "duplicate" or "alternate" in the Page Indexing report. Google doesn't index duplicate copies of a page.
  • The URL redirects to another URL. Redirect URLs are not indexed, only the redirect target.

Google can't access my sitemap

Be sure that your sitemap is not blocked by robots.txt, is valid, and that you're using the proper URL in your robots.txt entry or Sitemaps report submission. Test your sitemap URL using a publicly available sitemap testing tool.

Why does Google keep crawling a page that was removed?

Google continues to crawl all known URLs even after they return 4XX errors for a while, in case it's a temporary error. The only case when a URL won't be crawled is when it returns a noindex directive.

To avoid showing you an eternally growing list of 404 errors, the Page Indexing report shows only URLs that have shown 404 errors in the past month.

I can see my page, why can't Google?

Use the URL Inspection tool to see whether Google can see the live page. If it can't, it should explain why. If it can, the problem is likely that the access error has been fixed since the last crawl. Run a live crawl using the URL Inspection tool and request indexing.

The URL Inspection tool shows no problems, but the Page Indexing report shows an error; why?

You might have fixed the error after the URL was last crawled by Google. Look at the crawl date for your URL (which should be visible in either the URL details page in the Page Indexing report or in the indexed version view in the URL Inspection tool). Determine if you made any fixes since the page was crawled.

Also, the live URL Inspection doesn't test all the issues covered by the Page Indexing report. Most notably, duplicate or canonical conditions are not tested in the live test.

How do I find the index state of a specific URL?

To learn the index status of a specific URL, use the URL Inspection tool. You can't search or filter by URL in the Page Indexing report.

Indexing reasons

The following reasons can be shown for non-indexing, or for problematic indexing, in the Page indexing report:

Not indexed

These pages have not been indexed, but not necessarily because of an error. Read the specific description to see if this is an error that you should address.

Server error (5xx)

Your server returned a 500-level error when the page was requested. See Fixing server errors.

Redirect error

Google experienced one of the following redirect errors:

  • A redirect chain that was too long
  • A redirect loop
  • A redirect URL that eventually exceeded the max URL length
  • A bad or empty URL in the redirect chain

Use a web debugging tool such as Lighthouse to get more details about the redirect.

URL blocked by robots.txt

This page was blocked by your site's robots.txt file. You can verify this using the robots.txt tester. Note that this does not guarantee that the page won't be indexed through some other means. If Google can find other information about this page without loading it, there is a very small chance that the page might still be indexed. To ensure that a page is not indexed by Google, remove the robots.txt block and use a 'noindex' directive.

URL marked ‘noindex’

When Google tried to index the page it encountered a 'noindex' directive and therefore did not index it. If you do not want this page indexed, congratulations! If you do want this page to be indexed, you should remove the 'noindex' directive.

To confirm the problem:

  1. Click the inspection icon next to the URL in the table.
  2. Under Coverage > Indexing > Indexing allowed? the report should show that noindex is preventing indexing. You can search the page source or response headers for the word "noindex".
  3. Confirm that the noindex tag still exists in the live version:
    1. Clicking Test live URL
    2. Under Availability > Indexing > Indexing allowed? see if the noindex directive is still detected. If noindex is no longer present, you can click Request Indexing to ask Google to try again to index the page. If noindex is still present, you must remove it in order for the page to be indexed.
  4. If you want this page to be indexed, you must remove the tag or HTTP header.

Soft 404

The page request returns what we think is a soft 404 response. This means that it returns a user-friendly "not found" message but not a 404 HTTP response code. We recommend returning a 404 response code for truly "not found" pages and adding more information on the page to let us know that it is not a soft 404. To see how Google sees the page, run a live URL inspection test against the page and click View tested page to see a screenshot showing how Google renders the page. Learn how to fix a soft 404.

Blocked due to unauthorized request (401)

The page was blocked to Googlebot by a request for authorization (401 response). If you do want Googlebot to be able to index this page, either remove authorization requirements for this page, or else allow Googlebot to access your pages by verifying its identity. You can verify this error by visiting the page in incognito mode.

Not found (404)

This page returned a 404 error when requested. Google discovered this URL without any explicit request or sitemap. Google might have discovered the URL as a link from another page, or possibly the page existed before and was deleted. Googlebot will probably continue to try this URL for some period of time; there is no way to tell Googlebot to permanently forget a URL, although it will crawl it less and less often. 404 responses are not necessarily a problem, if the page has been removed without any replacement. If your page has moved, use a 301 redirect to the new location. See Fixing 404 errors

Blocked due to access forbidden (403)

HTTP 403 means that the user agent provided credentials, but was not granted access. However, Googlebot never provides credentials, so your server is returning this error incorrectly. The page will not be indexed.

If you do want Googlebot to index this page, you should either admitting non-signed-in users or explicitly allow Googlebot requests without authentication (though you should verify its identity).

URL blocked due to other 4xx issue

The server encountered a 4xx error not covered by any other issue type described here. Try debugging your page using the URL Inspection tool.

Crawled - currently not indexed

The page was crawled by Google but not indexed. It may or may not be indexed in the future; no need to resubmit this URL for crawling.

Discovered - currently not indexed

The page was found by Google, but not crawled yet. Typically, Google wanted to crawl the URL but this was expected to overload the site; therefore Google rescheduled the crawl. This is why the last crawl date is empty on the report.

Alternate page with proper canonical tag

This page is marked as an alternate of another page (that is, an AMP page with a desktop canonical, or a mobile version of a desktop canonical, or the desktop version of a mobile canonical). This page correctly points to the canonical page, which is indexed, so there is nothing you need to do. Alternate language pages are not detected by Search Console.

Duplicate without user-selected canonical

This page is a duplicate of another page, although it doesn't indicate a preferred canonical page. Google has chosen the other page as the canonical for this page, and so will not serve this page in Search. You can Inspect this URL to see which URL Google considers canonical for this page.

This is not an error, but is working as intended, because Google does not serve duplicate pages. However, if you think that Google has chosen the wrong URL as canonical, you can explicitly mark the canonical for this page. Alternately, if you think that this page is not a duplicate of the Google-chosen canonical, you should ensure that the content differs substantially between the two pages.

Duplicate, Google chose different canonical than user

This page is marked as canonical for a set of pages, but Google thinks another URL makes a better canonical. Google has indexed the page that we consider canonical rather than this one.

  1. Inspect this URL to see the Google-selected canonical URL under Page indexing > Google-selected canonical.
  2. Look at the canonical you chose under Page indexing > User-declared canonical.
  3. In your browser, look at the current page, the user-declared canonical, and the Google-selected canonical.
  4. This error means that Google thinks that the tested page isn't a duplicate of the user-declared canonical. Instead, Google thinks that the tested page is a duplicate of the Google-selected canonical.
    • If the Google-selected canonical is the tested page, then Google thinks that the tested page isn't similar to any other pages.
    • If the user-declared canonical is not similar to the current page, then Google won't ever choose that URL as canonical. A duplicate page must be similar to the canonical. (That's what duplicate means.)

Page with redirect

This is a non-canonical URL that redirects to another page. As such, this URL will not be indexed. The target URL of the redirect might or might not be indexed, depending on what Google thinks about that target URL.

A canonical URL with a redirect can be indexed.

If you view this URL in the URL Inspection report, the indexed information applies to the tested URL (ignoring any redirects). To see the index status of the canonical URL associated with this URL (the URL that is in the Google Index), click the INSPECT button in the Page indexing > Indexing section of the report.

The live URL Inspection test follows redirects and then tests the final URL, although the live test doesn't indicate that it is following a redirect.

Warning

Warnings are listed in the Improve page experience table on the summary page of the Page indexing report. These issues don't prevent a page from being indexed, but they do reduce Google's ability to understand and index your pages.

Indexed, though blocked by robots.txt

The page was indexed despite being blocked by your website's robots.txt file. Google always respects robots.txt, but this doesn't necessarily prevent indexing if someone else links to your page. Google won't request and crawl the page, but we can still index it, using the information from the page that links to your blocked page. Because of the robots.txt rule, any snippet shown in Google Search results for the page will probably be very limited.

Next steps:

Page indexed without content

This page appears in the Google index, but for some reason Google could not read the content. Possible reasons are that the page might be cloaked to Google or the page might be in a format that Google can't index. This is not a case of robots.txt blocking. Inspect the page, and look at the Coverage section for details.

Indexed

You can see your indexed URL count in the graph on the summary page. You can see an example list of URLs and more information about them by clicking View data about indexed pages below the graph.

Page is indexed

The page has been indexed successfully. However, it might have other issues that should be addressed, such as structured data issues. Any other issues will be described in the appropriate section in the URL Inspection report.

 

 

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
Main menu
13153198574603117274
true
Search Help Center
true
true
true
true
true
83844
false
false