'URL is not on Google' in URL Inspection: what every detail line means
'URL is not on Google' means the page can't appear in Search. The Page indexing lines below it name the blocker: discovery, crawl, noindex or canonical.
LLaunchScaler·Published ·11 min read
"URL is not on Google" is the URL Inspection verdict for a page that cannot appear in Google Search results, and the reason sits in the Page indexing section directly under it. Read that section's heading first, then its three groups of lines (Discovery, Crawl and Indexing): one of those lines names the blocker, and each points at a different file or setting.
Everything in the default view describes Google's last crawl of the URL, not the page as it is now. The Test live URL button checks the current page. The sections below follow the panel from top to bottom, with the fix for each bad value.
What does "URL is not on Google" mean?
It means Google's indexed record for this URL says the page will not appear in Search results. The verdict comes from the crawl shown under Last crawl, so it can be days out of date. The Page indexing heading gives the reason as "Page is not indexed:" followed by a status from the Page indexing report.
The top of the tool shows one of four verdicts for a URL Google has seen:
Verdict
What Google is telling you
Next step
URL is on Google
Indexed and eligible to appear. Google says this does not guarantee the page shows in results.
Search for the exact URL on Google to confirm.
URL is on Google, but has issues
Indexed, but an enhancement such as structured data or a linked AMP page has problems.
Fix the warnings shown in the tool.
URL is not on Google
Questions, answered
What people ask about this
01
What does 'URL is not on Google' mean in Search Console?
It is the URL Inspection verdict for a page that cannot appear in Google Search results. The heading of the Page indexing section under it gives the reason, such as a noindex rule, a robots.txt block, a redirect or a duplicate.
An AMP page that is an alternate of a canonical non-AMP page.
Check the Google-selected canonical is the page you expect.
The reason after "Page is not indexed:" uses the same wording as the Page indexing report: Excluded by 'noindex' tag, Crawled - currently not indexed, Page with redirect, Duplicate without user-selected canonical and the rest. The page indexing report guide explains every one of them and whether it needs fixing.
Two limits shape what you can see. The URL must belong to the property you have open, so a page on a site you have not verified cannot be inspected. And the stored copy of the page (View crawled page, with the HTTP response and the HTML Google kept) is only available for URLs that are on Google. For a URL that is not, the live test is where you look at the page itself.
What does "URL is unknown to Google" mean?
"Page is not indexed: URL is unknown to Google" means Google has never encountered the URL. No sitemap Google reads, no page it crawled and no external link has led Googlebot to it, so there is no crawl date, no fetch result and no canonical to show. It is a discovery problem, not a verdict on the page.
Most unknown URLs are new pages that nothing links to yet, or pages reachable only through a JavaScript click handler rather than a real <a href> link. Fix it in this order:
Click Test live URL. Confirm the verdict is "URL is available to Google" and that Crawl allowed? and Indexing allowed? both say Yes. The page must be reachable without a login.
Add the URL to your XML sitemap, and make sure the sitemap is either submitted in the Sitemaps report or named on a Sitemap: line in robots.txt.
Link to the page from a page Google already indexes, such as your homepage or a related hub, with a plain <a href="https://example.com/page"> link and descriptive anchor text.
Click Request indexing. For unknown URLs, Google's help says "Indexing typically takes a few days."
If you are not sure whether a page is indexed at all, the guide to checking if a page is indexed compares URL Inspection with a site: search and the Page indexing report.
How did Google find the URL? What do the Discovery lines show?
The Discovery group has two lines. Sitemaps lists the submitted sitemaps that include this URL. Referring page shows a page Google may have used to find it. Together they tell you whether Google found the page the way you intended, or through a link you forgot about.
The Sitemaps line only counts sitemaps submitted in the Sitemaps report or listed in robots.txt; a sitemap Google found some other way is not shown. "No referring sitemap" means Google could not match this URL to any of them. If you expected it in your sitemap, open the sitemap file and check the exact URL: a missing trailing slash, http:// instead of https:// or the www host instead of the bare one makes it a different URL. Google also lists a known issue where a sitemap that does include the page is sometimes not reported.
Referring page is looser than it sounds. The page shown might link to the URL directly, or be a grandparent or great-grandparent of the page that does. A blank value does not mean nothing links to the URL, only that the tool has no referrer to show. The message "URL might be known from other sources that are currently not reported" means Google found it through something other than a sitemap or a referring page.
The Referring page line earns its keep when the value surprises you. A staging host, an old tag archive or a URL with tracking parameters as the referrer tells you exactly which page is leaking links to URLs you did not want crawled.
Crawl allowed?, Page fetch, Indexing allowed?: which one names the blocker?
Read the Crawl group top to bottom and stop at the first bad value. "Crawl allowed? No" means a robots.txt rule. "Page fetch: Failed" means Google could not get the page from your server. "Indexing allowed? No" means a noindex rule in a meta tag or HTTP header. Each one sends you to a different fix.
Line
Bad value
What it means
Where to fix it
Last crawl
A date older than your last change
Everything below describes that older version.
Run Test live URL to see the current page.
Crawled as
Desktop or smartphone
The crawler type used for that crawl.
If it says smartphone, check the mobile layout carries the same content.
Crawl allowed?
No
A Disallow rule in robots.txt matches this path.
The robots.txt at the root of that exact host and protocol. The robots.txt report under Settings shows the file Google last fetched.
Page fetch
Failed, plus a reason such as a 404, a 5xx or a redirect error
Google could not retrieve the page.
Your server, firewall or redirect rules. "N/A" is a generic failure with no further detail.
Indexing allowed?
No, with the source of the rule
A noindex was found in the robots meta tag or the X-Robots-Tag header.
Remove it from the template or the server config that adds it.
The noindex source is spelled out in the line, as "No: 'noindex' detected in 'robots' meta tag" or the same message for the 'X-Robots-Tag' http header. The header version is invisible in the page source, so check the response itself:
Two rules in Google's documentation catch people out. First, "Page fetch: Successful" does not mean indexed; Google says fetching can succeed even when the page is not indexed for another reason. Second, a robots.txt block hides your noindex. Google's help puts it plainly: when robots.txt blocks the page, "Indexing allowed?" will always be "Yes" because Google can't see and respect any noindex directives. A page in that state can still be indexed from links, with no description in the result. To remove such a page from Google, delete the Disallow rule so Google can crawl the page and read the noindex.
User-declared vs Google-selected canonical: what does a mismatch mean?
User-declared canonical is the URL your page asks Google to index, set by a rel="canonical" link, an HTTP header or a sitemap. Google-selected canonical is the URL Google actually chose among similar pages. When they differ, Google indexed the other URL, and the page you inspected is reported as not on Google.
A value of None under User-declared canonical is fine for a page that has no duplicates. When a page has no alternate versions, the Google-selected canonical is simply the inspected URL. Google notes the selected value can be a few hours behind its index, and that canonical choice is only visible in the indexed result: the live test cannot predict it.
When Google picks a different URL, it is weighing your signals against each other. Its documentation ranks them: a redirect is a strong signal, rel="canonical" is a strong signal, and sitemap inclusion is a weak one. The signals stack, so the fix is to make all of them agree:
Put one <link rel="canonical" href="https://example.com/page"> with an absolute URL in the <head>. Google only accepts it in the head.
List that same URL, and not its duplicates, in the sitemap.
Point internal links at the canonical URL, not at a parameter or slash variant.
301 retired duplicates to the canonical when they no longer need to exist.
If the inspected URL redirects, the result describes the URL you entered, and an INSPECT button in the Indexing section opens the canonical target.
How do you see what Googlebot rendered?
Click Test live URL, then View tested page. The HTML tab shows the rendered HTML Google built after running your JavaScript, the Screenshot tab shows the page as Google-InspectionTool drew it, and More info lists the page resources loaded, the JavaScript console output and the HTTP response headers.
This is how you catch content that only exists after JavaScript runs. Google indexes the rendered HTML, and its JavaScript documentation is explicit: "If the content isn't visible in the rendered HTML, Google won't be able to index it." Copy a sentence from the middle of your main content and search for it in the HTML tab. If it is missing, or the screenshot shows a spinner, a blank frame or a cookie wall where your copy should be, Google indexed that instead of your page.
Then open More info. A resource that could not be loaded, such as a script or API call blocked by robots.txt or a firewall rule, explains a half-rendered page, and a console error thrown before your content mounts explains an empty one. Google's JavaScript troubleshooting guide also warns that single-page apps often return a 200 status for their error views, which can get error pages indexed.
The screenshot only exists in a live test with a successful result, and the page must be publicly reachable. The durable fix for missing content is to send it in the server's HTML response, through server-side rendering or prerendering. The client-side rendering SEO guide covers that for JavaScript frameworks.
What is the difference between "URL is not on Google" and "URL is not available to Google"?
"URL is not on Google" is the indexed verdict, from Google's last crawl. "URL is not available to Google" is the live test verdict: the page as it is right now "can't appear in Google Search results due to a critical issue," and the Availability section names it. A clean live result does not overturn the indexed verdict.
The live test checks access: robots.txt, the fetch, noindex, and site-wide failures. Those failures appear in the Page fetch line as values such as DNS error: Host unknown, Server connection error, Invalid server SSL certificate, Robots.txt unreachable and Hostload exceeded.
It cannot test several conditions that keep pages out of the index. Google lists them: Crawled - currently not indexed, Discovered - currently not indexed, every duplicate and canonical status, and Page indexed without content. So a page can show "URL is available to Google" in the live test and "URL is not on Google" in the indexed result at the same time. That combination usually means access is fine and the problem is a decision Google made at indexing time, such as quality, duplication or a canonical elsewhere.
What should you do after fixing the line?
Confirm the fix in a live test, then ask Google to recrawl. Request indexing puts one URL in the crawl queue after a quick check, and it refuses a URL that fails the live test. It does not guarantee indexing, and both inspections and index requests have a daily limit per property.
Run Test live URL and check the line you fixed now reads correctly.
Click Request indexing once. Google's help says indexing "typically takes only a day or so, but can take much longer." The Request indexing guide covers the quota and what the button does.
For many URLs, submit a sitemap with accurate <lastmod> dates instead of requesting each one.
If the same reason affects a whole template, fix the template, then use Validate fix on that row of the Page indexing report so Google rechecks every affected URL.
Check every page's directives in one pass
URL Inspection answers for one URL at a time, and only on a property you have verified. To read the same signals across your live site, run the free scan on LaunchScaler. It needs only the address, no account, and runs 156 checks across 6 of its 7 categories at no cost. Its search checks look for the causes behind these lines: robots.txt rules that block a page you want ranked, noindex in the meta robots tag or the X-Robots-Tag header, a noindex hidden behind a robots.txt block, a canonical that points at a redirected, 404 or noindexed URL, soft 404s, long redirect chains, main content that only appears after JavaScript runs, and invalid HTML in the <head> that drops the canonical and robots tags below it. Fix what it flags, then run Test live URL on the page and request indexing.
Google has never seen the URL, so no sitemap, internal link or external link has led Googlebot to it yet. Run a live test, fix what it reports, link to the page from pages Google already indexes, then click Request indexing.
03
What is the difference between 'URL is not on Google' and 'URL is not available to Google'?
'URL is not on Google' describes Google's indexed record from its last crawl. 'URL is not available to Google' is the live test verdict, and it means the page as it is right now has a critical issue such as a robots.txt block, a noindex rule or a failed fetch.
04
Why does 'Indexing allowed?' say Yes when my page has a noindex tag?
When robots.txt blocks the page, Google cannot read the noindex, so 'Indexing allowed?' always shows Yes. Check 'Crawl allowed?' first, because a No there hides every directive on the page.
05
How long does a page take to appear after Request indexing?
Google's help says indexing typically takes a day or so, can take up to a week or two, and a request does not guarantee the page will be indexed. Asking again for the same URL does not speed it up.
Check WordPress in this order: the Discourage search engines box, SEO plugin noindex settings, one sitemap, coming-soon mode, firewalls, then cached pages.
Neither www nor non-www ranks better. Pick one host, 301 the other in one hop, and align DNS, HSTS and Search Console so only one copy of your site exists.
