Search Console URL Inspection API: What You Can Do With It

If you have ever checked pages one by one in Search Console’s URL Inspection tool, you know how slow it gets on a big site. The new Search Console URL Inspection API fixes that. It lets you pull the same index data Google shows in the tool, for many URLs, with code or with a connected SEO tool.

Google announced the URL Inspection API on 31 January 2022. In this guide I explain what it returns, what it can’t do, how to set it up, and the practical ways I plan to use it.

What Is the Search Console URL Inspection API?

An API (a way for one program to ask another program for data) lets software talk to Search Console without you clicking around. The URL Inspection API is the newest part of the Search Console API. It sits next to the older parts for performance data, sitemaps and the list of sites you manage.

You send it two things: the URL you want to check and the Search Console property it belongs to. It sends back what Google knows about the indexed version of that URL. That is the same data you see when you paste a URL into the inspection bar in Search Console.

The key word is “indexed”. The API does not crawl your page again. It tells you what Google stored the last time it crawled.

What Data the URL Inspection API Returns

The response comes as a block of JSON (a simple text format for structured data). It is split into a few sections. Here is what each one tells you.

Index Status

This is the part I care about most. It includes:

• Verdict: a quick pass, fail or neutral result for the URL.
• Coverage state: the same label you see in the Index Coverage report, such as “Submitted and indexed” or “Crawled – currently not indexed”.
• Robots.txt state: whether robots.txt allows Googlebot to crawl the URL.
• Indexing state: whether a noindex tag or header blocks indexing.
• Last crawl time: when Google last crawled the page.
• Page fetch state: whether the fetch worked, or failed with something like a 404, a server error or a soft 404.
• Google-selected canonical and user-declared canonical: the URL Google picked as the main version, and the one you asked for with your canonical tag.
• Sitemaps and referring URLs: which sitemaps list the URL and which pages Google found linking to it.
• Crawled as: whether Google used its mobile or desktop crawler.

Mobile Usability

You get a mobile usability verdict for the page, plus any issues found, like text too small to read or clickable elements too close together. If you are already working through these errors, my guide to the Search Console Mobile Usability report explains how to fix each one.

Rich Results

If Google found structured data (code that describes your content, like a product or an FAQ), the response lists the rich result types it detected. Breadcrumbs and FAQ are common examples. Each item can come with warnings or errors.

AMP

If the page has an AMP version, you get its index status and any AMP issues. If your site doesn’t use AMP, this section simply won’t appear.

One small detail that confuses people: if a section is missing from the response, it means that check wasn’t available for that URL. It is not an error. The response also includes a link that opens the same inspection in Search Console, which is handy when you want to look closer.

What the API Can’t Do

This is where I see the most confusion, so I want to be clear.

• It can’t request indexing. The “Request indexing” button in Search Console is not part of this API. You still have to click it by hand.
• It doesn’t run a live test. The API only shows the indexed version. If you just fixed a page, the API won’t show the fix until Google crawls it again.
• It only works on properties you have access to. You can’t inspect a competitor’s URLs.
• It doesn’t replace a crawler. It tells you what Google saw, not what your page looks like right now.

In my opinion, the missing “request indexing” option is the right call from Google. If it were in the API, people would hammer it with every URL on their site.

URL Inspection API vs Indexing API

These two names sound alike, but they do different jobs. The URL Inspection API reads data about how a URL is indexed. The Indexing API tells Google that a page was added or removed, and Google says it is only for pages with job posting or livestream (BroadcastEvent) structured data.

I’d skip any advice that tells you to push normal blog posts or product pages through the Indexing API. That is not what Google built it for.

Quotas and Limits

Google sets the quota per Search Console property. That means all calls that check URLs on the same site count together.

• 2,000 queries per day per property
• 600 queries per minute per property

For a small or medium site, 2,000 checks a day is plenty. For a site with hundreds of thousands of URLs, it isn’t. You need to choose which URLs to check, and I cover how I’d do that below.

A useful trick for bigger sites: the quota is per property, so separate properties count separately. If you have verified URL-prefix properties for different folders, such as https://example.com/blog/ and https://example.com/shop/, each one gets its own daily quota. Only use this for sections where it makes sense to have their own property anyway.

How to Use the URL Inspection API

You have two paths. Most marketers and business owners will use a tool that already connects to the API. Developers and technical SEOs can call it directly.

Option 1: Use a Tool That Connects for You

Google said it built the API with SEO tools, agencies and CMS or plugin developers in mind. Expect SEO crawlers, reporting tools and website plugins to add support. Usually you just sign in with the Google account that has access to your Search Console property, choose the property, and the tool fetches the data.

Before you connect any tool, check two things. First, that it only asks for the access it needs. Second, that you understand how many of your 2,000 daily checks it will use, so it doesn’t eat your whole quota on one crawl.

Option 2: Call the API Yourself

If you or a developer want full control, the setup takes about an hour the first time. Here are the steps.

1. Create a Google Cloud project. Go to the Google Cloud console and create a new project for your SEO scripts.
2. Enable the Google Search Console API. Find it in the API library and turn it on for your project.
3. Create credentials. Use OAuth if a person will sign in, or a service account (a robot Google account for scripts) if the script runs on its own.
4. Give the credentials access to your property. For a service account, add its email address as a user on the property in Search Console settings. Without this step, every call fails with a permission error.
5. Send a test request. Use the “Try this API” panel in Google’s API reference, or a short script, to inspect one URL.
6. Scale up with a list. Loop through your URL list, save each result to a spreadsheet or database, and stay under the per-minute and per-day limits.

The request goes to this endpoint:

POST https://searchconsole.googleapis.com/v1/urlInspection/index:inspect

And the body is short:

{
  "inspectionUrl": "https://www.example.com/blog/my-post/",
  "siteUrl": "https://www.example.com/",
  "languageCode": "en-US"
}

The siteUrl must match your property exactly as it appears in Search Console. For a Domain property, write it as sc-domain:example.com. The inspectionUrl must sit inside that property. The languageCode is optional and only changes the language of issue messages.

Full details on every field are in Google’s URL Inspection API reference.

Practical Ways to Use the URL Inspection API

Having the data is one thing. Here is how I’d actually put it to work.

Monitor Your Most Important Pages

This is the use I recommend first. Make a list of the pages that bring you money or leads: your homepage, main category pages, top service pages and best-selling products.

Check them on a schedule, daily or weekly. Then flag any change in coverage state, a new noindex, a robots.txt block or a canonical change. You hear about a problem in days, not when traffic has already dropped.

Check Canonicals at Scale

The API gives you both the Google-selected canonical and the user-declared canonical. Put them side by side in a spreadsheet and look for rows where they don’t match.

In my experience, mismatches often point to near-duplicate pages, mixed internal links, or sitemaps listing the wrong version of a URL. I usually see this on ecommerce sites with filter and sort parameters.

Debug Structured Data Across a Template

If one product page has a rich result warning, the rest of the template likely has it too. Pull the rich results data for a sample of pages from each template. Then you can fix the template once instead of chasing single pages.

Check Pages After a Migration or Redesign

After a site move or a big redesign, I want to know fast whether Google has picked up the new URLs. Run your new URL list through the API every few days. Watch the last crawl time and coverage state change as Google works through the site.

Find Pages Google Hasn’t Crawled

Some pages come back as “URL is unknown to Google” or with a very old last crawl time. Those usually need better internal links or a place in your XML sitemap. The referring URLs field also shows which pages Google found linking to a URL, which helps you spot weak internal linking.

How I’d Pick URLs to Check

On a large site, you can’t check everything every day. Here is the order I’d use:

1. Pages that make money or drive leads.
2. New pages published in the last few weeks.
3. Pages you recently changed, redirected or fixed.
4. One or two sample pages from each template, such as product, category, blog post and location pages.
5. A random sample of the rest, rotated each day.

The template sample is the part people skip. One broken template can affect thousands of pages, and a handful of checks will catch it.

Common Mistakes to Avoid

• Wrong property format. Using https://example.com when the property is https://www.example.com/, or forgetting the sc-domain: prefix for Domain properties.
• Forgetting to add the service account. The account must be a user on the property, or you get permission errors.
• Reading old data as current. Always look at the last crawl time before you decide a fix didn’t work.
• Burning the quota on one big run. Spread checks across the day, and leave room for your tools and teammates who use the same property.
• Treating the verdict as the full story. A “pass” means the URL is on Google. It says nothing about how well it ranks.

Is the URL Inspection API Worth Your Time?

If you run a small site with a few dozen pages, the regular URL Inspection tool and the Index Coverage report are probably enough. I wouldn’t build anything custom.

If you manage a large site, an online store, several client sites, or a CMS with many templates, it is worth it. Automated checks on your key pages turn indexing from a guessing game into something you can track.

For me, the biggest win is the canonical data. Seeing Google’s choice next to yours for hundreds of URLs used to take days of clicking. Now it is one export.

Conclusion

The Search Console URL Inspection API gives you the indexed view of your URLs at scale: coverage state, canonicals, crawl dates, mobile usability and rich results. It can’t request indexing or run live tests, and it is limited to 2,000 checks per property each day. Used on the right pages, it catches indexing problems before they cost you traffic.

Your next step: write down the 20 to 50 URLs that matter most to your business and start checking them every week, with a tool or a simple script. If you are still planning your wider priorities for the year, my SEO checklist for 2022 shows where indexing checks fit among everything else.