A green "URL is available to Google" next to a red "URL is not on Google" is one of the most common sights in URL Inspection. The live test passed but page not indexed, and nothing on the screen says why. The short version: the two results answer different questions at different moments. The questions below cover what each one means and where the real reason is hiding.

What does a passing live test actually confirm?

Only reachability. Google's help page states that the live test "confirms if Google-InspectionTool can access your page for indexing." It fetches the page in real time, applies robots.txt and noindex rules as they stand right now, and reports whether anything blocked the fetch.

The same page is explicit about the limit: "There is no definitive test that can guarantee whether your page will be included in the Google index." The live test skips several checks that decide indexing: sitemaps and referring pages, duplicates and canonical selection, manual actions, removals, quality issues and temporary blocks. A page can clear every live check and still be left out for a reason the test never examines.

Then why does the indexed-version verdict still say "URL is not on Google"?

Because the default view shows what Google's index knows from the last crawl, not what the page looks like today. The live test is a snapshot of the present; the indexed verdict is a record of the past. There is a second detail that surprises many people: the live test result is for you, not for the indexing system. The troubleshooting guide says plainly, "Google does not use this information." Running the test changes nothing in the index.

Which fields explain the gap?

Switch back to the indexed view and expand Page indexing. One of these fields almost always carries the answer:

• Last crawl is empty. Google has not fetched the page at all. In its own words, "Google simply hasn't found the page." A discovery problem: the URL is missing from the sitemap, has no internal links, or both.
• Page fetch shows Failed. The last attempt hit a server error, a redirect problem, a 404 or a robots.txt block. The live test passes now because the problem was fixed since, but the index still reflects the failed attempt.
• Indexing allowed? shows No. A noindex directive was present at crawl time. Removing it does not update the index until the next crawl.
• Google-selected canonical is a different URL. Google treats the page as a duplicate and indexes the other URL instead. The live test cannot detect this, because canonical choice is determined at indexing time.
• Coverage status reads "Crawled – currently not indexed". Google fetched the page without obstacles and decided not to index it. This is not a technical failure, which is why the live test looks clean. A separate guide covers getting pages out of the crawled-not-indexed limbo, including the content and linking changes that usually precede a successful recrawl.

Does clicking "Request indexing" again help?

Not on its own. The request queues a recrawl; Google says it "does not guarantee that the page will appear in the Google Index," and there is a daily limit per property. If nothing on the page or in its signals has changed, a second request produces the same outcome and uses up quota. The sensible order: find the field that explains the gap, fix the cause, run the live test once to confirm, then request indexing one time.

What should change before resubmitting?

It depends on which field flagged the problem:

1. Empty Last crawl: add the URL to the sitemap and link to it from pages that are already indexed.
2. Failed Page fetch: confirm the page returns 200 on the final URL with no redirect chain, then retest.
3. Indexing allowed = No: remove the noindex tag or X-Robots-Tag header and verify in the live test.