Skip to content
Gryz markGryz
0

Report this document

Describe the issue — this goes directly to our review queue.

0/500

"URL is not available to Google" in the live test: what it means and how to clear it

This note covers the URL is not available to Google live test verdict in Search Console's URL Inspection tool: what Google means by it, where the cause is written, and a checklist ordered from the most common blocker to the rarest. It is the harshest of the three live-test outcomes and the only one that keeps Request indexing unavailable.

What the verdict says

Google's definition is short: the URL can't appear in Google Search results due to a critical issue. The two milder outcomes are "URL is available to Google" (no block or detectable error found, though indexing is still not guaranteed) and "URL is available to Google, but has issues" (indexable, but an enhancement such as structured data has a problem). A further variant, not available due to a site-wide issue, points at DNS or server errors affecting the whole property, and the fix belongs to hosting rather than to the page.

The live test is a real-time fetch by Google-InspectionTool and checks access only. Sitemaps, referring pages, duplicates, manual actions and removals are outside its scope.

Read these three values first

Google's guide to checking availability points at three lines under Coverage in the live result:

  • Crawl allowed? should be Yes. A No means robots.txt is blocking the fetch.
  • Page fetch should be Successful. Anything else means the server did not hand over the page, and the line explains why.
  • Indexing allowed? should be Yes. A No means a noindex tag or directive is present; noindex does not prevent access, but it tells Google not to index the page.

The same three values exist in the indexed view, describing the last crawl rather than now; a failing live test next to a passing indexed view means the blocker appeared after that crawl.

Page fetch failures by name

The URL Inspection API reference enumerates the fetch states Google distinguishes: SOFT_404, BLOCKED_ROBOTS_TXT, NOT_FOUND, ACCESS_DENIED, SERVER_ERROR, REDIRECT_ERROR, ACCESS_FORBIDDEN, BLOCKED_4XX, INTERNAL_CRAWL_ERROR and INVALID_URL. Two of them catch people out:

  • REDIRECT_ERROR: the inspection tools do not follow redirects. Inspect the final destination, not the address that redirects to it.
  • SOFT_404: the server returned 200, but the page reads as empty or missing. Google treats it as not found.

Checklist: from the most common cause to the rarest

  1. Confirm it is not site-wide. Run the live test on the homepage and one page known to be indexed. If all of them fail, look at DNS and server health before touching the page.
  2. Check Crawl allowed? Find the robots.txt rule that matches the path and remove or narrow it. robots.txt does not remove a URL from Google; a blocked page can still show in results without a description.
  3. Check Indexing allowed? Search the HTML for a robots meta tag and the HTTP response for an X-Robots-Tag header; CMS settings and CDNs can add either silently.
  4. Check the response code on the final URL. A 404 or 410 means the address is dead; a 5xx means the server failed.
  5. Resolve redirects before testing. A chain or a loop produces REDIRECT_ERROR no matter how healthy the destination is.
  6. Look for a password or login wall. Google lists a required password among the main reasons a page is not available. Google-InspectionTool does not log in.
  7. Check for bot blocking. A firewall that answers Google-InspectionTool with 403 produces ACCESS_FORBIDDEN while the page opens fine in a browser.
  8. Check for a soft 404. Empty category and "no results" pages returning 200 are the usual sources; return a real 404 or 410, or add content.
  9. Clean the list before resubmitting. When the pages come from a migration or a backlink audit, a share of them will be dead on arrival. A bulk pass that lets you catch dead links before submitting them removes the 404s and 410s from the batch, so the live test and the indexing request are spent on URLs that can be indexed.
  10. Re-run the live test after the fix, then request indexing. The request button appears only when the live result shows the page as indexable. Submit once; the request does not guarantee indexing and is subject to a daily limit.
  11. Re-inspect the indexed view later. The indexed verdict updates only after Google recrawls the page.

Clearing this verdict restores access, nothing more. Whether the page is in the index, or treated as a duplicate, is a question for the indexed view, and Google states that there is no definitive test that can guarantee inclusion in the index. The complete breakdown of every URL Inspection outcome and the action each one calls for is in the SpeedyIndex guide to URL Inspection verdicts.

Sources

  • URL Inspection tool, Search Console Help: support.google.com/webmasters/answer/9012289
  • Check if a URL or image is available to Google, Search Console Help: support.google.com/webmasters/answer/12061956
  • URL Inspection API, UrlInspectionResult reference: developers.google.com/webmaster-tools/v1/urlInspection.index/UrlInspectionResult
  • Redirects and Google Search, Search Central: developers.google.com/search/docs/crawling-indexing/301-redirects
Loading comments…

Comments

Create a free account to join the conversation.

Create accountSign in