When the URL Inspection tool returns URL is on Google but has issues, the first instinct is to treat it as an indexing failure. It isn't. The page is in the index and can appear in search results; what the verdict flags is a problem with one of the enhancements Google tried to apply on top of the page. This guide explains what the verdict covers, where the warning details sit inside the report, and the order in which to fix, retest and resubmit.
What the verdict means
Google's documentation for the URL Inspection tool defines the verdict in two halves: the URL has been indexed and can appear in Google Search results, but there are problems that may prevent it from showing with all the enhancements you applied. The indexing step succeeded; the enhancement step did not fully pass. The parent verdict, "URL is on Google", is the same result without the warnings, and even that one, as the same page points out, is not a guarantee of appearing in search results.
So the verdict has two layers. The top line answers "is this page in the index?" with yes. The warnings beneath it answer "can every rich feature Google detected on this page be shown?" with "not entirely".
Where the actual warning is
The report is split into cards. The Page indexing card covers discovery, crawling and indexing: sitemaps, referring page, last crawl, crawl allowed, page fetch and indexing allowed. For a "has issues" verdict that card is normally clean; the problem sits further down, under Enhancements & Experience. Google's troubleshooting guide tells you to review each section there and expand any section that reports an issue to read its details.
Typical sources of the warning:
- Structured data. A detected rich result type (product, article, FAQ, breadcrumb and so on) with a missing required property or an invalid value. According to the URL Inspection API reference, items with an error-severity issue cannot appear with rich result features in Search; warning-severity issues are reported but do not block the feature.
- AMP. If the page has an AMP alternate, errors on that version are reported here, and an AMP error means the AMP version cannot appear in results.
- Deprecated checks. The mobile usability result still exists in the API response but is marked deprecated. It is not worth chasing.
How it differs from "URL is not on Google"
These two verdicts are not neighbours on a scale; they describe different stages. "Not on Google" means the page will not appear in results at all, and the reason is in the Page indexing card: blocked by robots.txt, a noindex rule, a fetch error, or Google choosing a different canonical. "Has issues" means all of those checks passed and only an enhancement is degraded. If you are looking at a third pattern, where Google fetched the page and still left it out of the index, that is a separate diagnosis; read up on why Google crawls a page but doesn't index it before changing anything on the page.
Step by step: clearing the warning
- Read the issue text, not just the verdict. Expand the section under Enhancements & Experience. The message names the property or rule that failed.
- Check the indexed version first. The default view is the indexed copy, refreshed each time Google crawls the page. "View crawled page" shows the HTML, HTTP headers and JavaScript console output Google kept for that version. Confirm that the markup Google saw is the markup you expect. On Webflow sites, custom-code embeds and CMS-driven schema fields are the usual places where a template edit produces a broken property on every item at once.
- Fix the markup on the live page. Use the required and recommended properties from Google's documentation for that specific feature rather than a plugin's defaults.
- Run Test live URL. The live test fetches the page in real time and reports its own verdict: "URL is available to Google" or "URL is available to Google, but has issues". A clean live result next to a warning in the indexed view means the fix is live but not yet re-indexed.
- Request indexing. Google's guidance is to run the live test, confirm the fix, then click Request indexing. Submitting a request does not guarantee that the page will be re-indexed, there is a daily limit on requests, and the button is unavailable for a URL whose live test shows it as non-indexable.
- Re-inspect later. The indexed verdict changes only after Google recrawls the page. Until then the warning describes history, not the current state.
Things that look like the same problem but aren't
- The canonical changed. The Indexing section lists the user-declared canonical and the Google-selected canonical. If they differ, the content may be indexed under another address. Google notes that the selected canonical shown in the tool can be a few hours behind the index itself.
- The page was updated after the last crawl. The Last crawl date tells you which version the verdict describes. Changes made after that date are not yet reflected in Search.
- A warning on a template-level element. One broken schema block in a shared layout produces the same "has issues" verdict on every page that uses the layout. Inspecting a single URL hides the scale of the problem.
When one URL at a time isn't enough
URL Inspection works on a single address inside a property you own. For a template-wide warning across hundreds of CMS items, or for pages on domains outside your Search Console account, inspect one representative URL to learn the cause, confirm the index status of the full list with a batch check, and work through the fix from the template outward. The week's full breakdown of every URL Inspection verdict, from "on Google" and "has issues" to "not on Google" and the live-test states, is in the SpeedyIndex guide to URL Inspection verdicts.
FAQ
Does "has issues" lower rankings?
Google's documentation does not describe the verdict as a ranking signal. It describes a page that is indexed but may be shown without some enhancements. Fix it to recover the enhancement, not out of fear of a penalty.
Can the warning refer to the live page instead of the indexed one?
Only if you ran a live test. The default report is the indexed snapshot; the live result is a separate view generated when you click Test live URL, and Google states that it does not use the live test information.
The issue is fixed, but the verdict hasn't changed. Why?
Because the indexed version has not been recrawled yet. Compare the live test with the indexed view: a clean live result and a warning in the indexed one means waiting for the recrawl, or requesting indexing if you have not already.
Sources
- URL Inspection tool (Search Console Help): support.google.com/webmasters/answer/9012289
- Inspect and troubleshoot a single page (Search Console Help): support.google.com/webmasters/answer/12482179
- URL Inspection API, UrlInspectionResult reference: developers.google.com/webmaster-tools/v1/urlInspection.index/UrlInspectionResult