Most Search Console reports are aggregates. The URL Inspection tool is the opposite: one URL, Google's last crawl of it, and a live fetch if you ask for one. When a single article is missing, or when Google has chosen a canonical you did not declare, this is the screen that shows the evidence. The aggregates tell you the pattern. Inspection tells you whether the pattern is true for the URL in front of you.

You can only inspect URLs on a property you have verified. The tool does not grade the writing. It reports discovery, crawl permission, index permission, the canonical pair, and whatever enhancements Google detected on that crawl.

The indexed view

Paste the URL into the inspection bar at the top of Search Console. The first result is the indexed view, built from the most recent crawl, not from a fetch that starts when you click.

Page indexing says the URL is on Google or it is not, with the reason when it is not. Those reasons are the same family of reasons as the Page indexing report. The report is the place to see how many URLs share a reason. Inspection is the place to see the reason for this URL. The Page indexing guide is the map of the reasons. Inspection is how you confirm a sample.

Discovery lists sitemaps that include the URL and referring pages Google knows about. No referring pages, and a sitemap as the only source, means the article is an orphan. Add a real HTML link from a section page before you request anything. That work is the internal linking guide.

Crawl includes the last crawl time, the user agent (smartphone or desktop), whether crawling was allowed, whether indexing was allowed, and whether the fetch succeeded. "Crawl allowed: No" is robots.txt. "Indexing allowed: No" is a noindex meta tag or header. "Page fetch failed" with a soft 404 note means the 200 body looked empty or like an error. Those three are configuration, and they are the cases where a same-day template fix is realistic. The robots.txt guide and the soft 404 guide are the matching repairs.

Indexing shows the user-declared canonical and the Google-selected canonical. If they differ, Google kept another URL as the representative. Do not publish a second canonical and hope. Align redirects, links, and the sitemap with the URL you want, then inspect again after a recrawl. The canonical guide is the order of those signals.

Enhancements appear when Google detected structured data or a similar feature on the crawled HTML. An error there explains a missing rich result. It does not, by itself, explain a missing web result. Fix the markup if you want the enhancement. Fix crawl and canonical fields if you want the URL in the index at all.

The live test is a different document

"Test live URL" fetches the page now. Use it after a deploy, not as a daily ritual. It shows whether Google can retrieve the URL at this moment, the rendered HTML, a screenshot, resources that failed to load, and JavaScript messages.

Read the screenshot first. If you see the headline and the opening paragraph, the response is a page. If you see a blank shell, a cookie wall that hides the text, or a not-found message, the indexed view will not improve until that changes. Then open the rendered HTML and search for a sentence from the article. If the sentence is only in the screenshot and not in the HTML, you are looking at text Google may not be using as the document.

A live test that passes means the URL is eligible to be crawled and rendered. Google's own status-code documentation says a 2xx does not guarantee indexing. Keep that distinction when someone treats a green live test as a promise.

The live test and the indexed view can disagree for a while after a fix. The indexed view stays on the old crawl until Google fetches the URL again. Requesting indexing is one way to ask for that fetch. Waiting for the next ordinary crawl is the other. Comparing the two views too early makes a fixed page look broken.

Request indexing, sparingly

After a live test, the tool offers "Request indexing". That adds the URL to a priority crawl queue. Google does not publish a fixed daily number for the button. The allowance is per property, it is small, and it is there for important URLs, not for a whole archive. Asking twice does not move a URL ahead of itself.

Request indexing when you have just published or substantially updated a URL you care about, and the live test shows a real page with crawling and indexing allowed. Do not request it for a URL the live test still shows as noindex, blocked, or a soft 404. You would be asking Google to recrawl the bug.

The button is not the Indexing API. The API is for job postings and livestream video pages and has its own quota. The manual button works for any URL on a verified property, within its unpublished limit. The comparison is in the Indexing API versus manual inspection article.

The URL Inspection API, when clicking does not scale

The Search Console API exposes URL Inspection for the indexed view. It does not replace the live test. Google's published quota for index inspection is 2,000 queries per day and 600 per minute per site, with a much higher per-project daily ceiling. That is enough to watch a newsroom's daily output, or the head of a large catalog. It is not enough to inspect every URL on a million-page host every night, and it is not a crawl request.

Practical uses: check yesterday's articles for "URL is on Google", record the selected canonical on the URLs that carry your subscriptions and your main sections, and record the last crawl time on templates you just changed. Store the reason when the URL is not indexed so you can group reasons. A hundred URLs with the same reason are a template fix. A hundred manual clicks will not reveal that faster than the Page indexing report will.

The API is authenticated with a Google Cloud project, like the Indexing API, but it is a different API and a different quota. Do not burn inspection quota retrying the same URL every hour. Once a day on a changing URL is already a close watch.

A publisher's sequence for one story

  1. Publish, link the canonical URL from the section, and include it in the sitemap with a real lastmod.
  2. The next day, inspect it. If discovery lists no referring page, fix the links and stop.
  3. If crawl or index is not allowed, fix robots.txt or noindex and run the live test. Request indexing once when the live test is clean.
  4. If the selected canonical is a parameter URL, fix the template. Do not request indexing on every variant.
  5. If the URL was crawled and not indexed, and the live test shows the full article, the remaining work is the article or a duplicate. The indexing diagnostic is that decision.

Use inspection to verify a fix on two or three URLs. Use the Page indexing report to see whether the rest of the template followed. Validating a report row from two green inspections is how you avoid declaring victory on a sample that was never the buggy template.

Readings that get misfiled

Google-selected canonical differs, and the selected URL is a print view or a parameter copy. The article is not "unindexed". A copy of it is indexed at the wrong address. Fix the signals and watch the preferred URL.

Referring page is a redirected URL. The link graph still points at the old path. Update the links to the final URL so the next crawl of the section does not depend on a hop.

The screenshot shows the article and the indexed view says soft 404. The indexed view is stale, or the live test is logged in and the crawler is not. Confirm what an anonymous fetch receives. A 200 that is personalized to a tiny body is a soft 404 for everyone who is not you.

Crawl allowed is yes, indexing allowed is yes, and the URL is unknown. Inspection cannot find a URL Google has never seen. Put it in the sitemap, link to it, and inspect again later. The sitemap guide is the list side of that step.

The URL Inspection tool answers a narrow question: what did Google last conclude about this URL, and what does it get if it fetches the URL now? Use it to confirm a cause you can fix. When the cause is "this page was crawled and not kept", the tool has done its job by ruling out the technical blocks, and another click on request indexing will not add the missing substance.

CrawlFaster polls indexing status for URLs you choose so you are not inspecting each one by hand. When a status looks wrong, this tool is still the place to see the canonical and the live screenshot behind that status.