URL is not on Google

What this verdict means

The URL Inspection tool returns one of three verdicts for an inspected URL. According to Google's documentation (URL Inspection tool):

A fourth message, "URL is unknown to Google", appears when Google has never seen the address. The same document stresses that the verdict describes the index, not the live page.

The verdict is a summary, not one of the reasons in the Page indexing report, which is why searching the report for it finds nothing. The reason is in the Page indexing section of the inspection result, and the same reason is what the Page indexing report uses to group URLs across the property.

How to read the Page indexing section

Google's documentation describes three parts:

• Discovery: which sitemaps list the URL and which page Google possibly used to discover it.
• Crawl: the last crawl time, the crawler used (desktop or mobile), whether robots.txt allowed the crawl, whether the page fetch succeeded, and whether indexing was allowed.
• Indexing: the canonical you declared and the canonical Google selected.

The row that is not green is the answer, and each maps to a known status:

For Page fetch, Google documents values such as Successful, Failed with a reason, and site-wide errors including DNS errors, Server connection error, Robots.txt unreachable and Hostload exceeded. A site-wide error means the problem is the host, not this page.

Common causes

The page was never discovered

No sitemap lists it and no indexed page links to it, so the inspection says the URL is unknown to Google. New sites, sections without navigation links and pages reachable only through a search box end up here. The XML sitemap entry explains what a sitemap can and cannot do.

A blocking directive

A noindex left on after a staging deploy, a robots.txt Disallow: / from development, or an X-Robots-Tag header added by a CDN rule. These are the quickest to find, because the Crawl rows say so directly.

The server did not deliver the page

A 404 after a URL change without a redirect, a 5xx during a crawl, a 401 or 403 from a security rule, or a redirect that never ends. The Page fetch row says Failed and names the status.

Google crawled the page and did not index it

The page was fetched successfully but Google decided not to keep it: thin content, a near-duplicate or a low-priority page. Nothing is wrong technically, which is why this case takes longest to resolve.

Canonical pointing elsewhere

The page declares a canonical to another URL, or Google selected a different one. The inspected URL is then a duplicate and will not appear, while the canonical may. The indexability entry describes how canonical, noindex and robots.txt interact.

How to confirm it

1. Inspect the exact URL, including protocol, host and trailing slash; a different variant is a different URL to Google.
2. Read the Page indexing section and note which row is not green.
3. Run Test live URL. According to Google the live test shows whether the current page can probably be indexed, with Crawl allowed, Page fetch and Indexing allowed for the live version, but without discovery data or the Google-selected canonical.
4. Check the Sitemaps report to confirm the URL is listed and the file is readable.
5. Run the indexability checker on the URL. It reports the status code, robots directives, canonical and robots.txt rule in one pass, which usually matches the row that failed.
6. For a site-wide picture, open the Page indexing report, which groups every URL by reason.

The site: operator is not a substitute. It shows what Google chooses to display for that query, with approximate counts; a page can be indexed without appearing there.

How to fix it

1. Unknown to Google: add the URL to the sitemap, link to it from an indexed page, then use Request indexing. Google's documentation on asking Google to recrawl describes the sitemap route for many URLs and the inspection tool for a few, and notes that a request does not guarantee indexing.
2. Blocked by noindex or robots.txt: remove the directive or rule, confirm with the live test, then request indexing. Google's guidance on blocking indexing with noindex explains that a page blocked by robots.txt cannot have its noindex seen, so unblock crawling first.
3. Fetch failed: fix the status code, following the article for that status, and retest.
4. Crawled but not indexed: improve the page, consolidate near-duplicates, link to it from stronger pages, and wait. Resubmitting without changes does nothing.
5. Canonical elsewhere: decide which URL should be the canonical and make the tag, the internal links and the sitemap agree on it.

When it is fine and when to act

It is fine when the URL should not be in Google: a filtered listing, a thank-you page, a staging URL, an old variant that redirects to the canonical.

Act when the URL earns or should earn traffic, when the verdict flips to not on Google for a page you did not touch, or when many pages of one template report the same reason. A page dropping out after a release means a technical change broke something, and the Page indexing row tells you what.

How IndexRise helps

IndexRise checks the signals behind this verdict on every monitored page each night: status code, noindex in HTML and headers, canonical and the robots.txt rule, plus the URL count of your sitemaps. A page that gains a noindex or starts returning 404 raises an event confirmed on the next check, usually before Google recrawls and the verdict changes; a sitemap that loses part of its URLs is reported too. A request that could not be completed is reported as "couldn't check" rather than as a change. The full list of checks is on the features page.