Google Search Console URL Inspection API Used Correctly

The method accepts an inspection URL and the Search Console property URL. The response can include coverage state, robots status, indexing state, fetch state, last crawl time, Google-selected canonical, user-declared canonical, sitemaps, referring URLs, and supported enhancement results. It reflects information available to the URL Inspection system for the indexed version.

It does not execute the live-test workflow exposed in the Search Console interface, request crawling, submit indexing, or report every ranking signal. A stale last-crawl date may explain why a deployment is not reflected. The appropriate label is “inspection result retrieved at,” with the underlying crawl time preserved separately.

The caller needs OAuth authorization and access to the Search Console property being inspected. Domain properties and URL-prefix properties have different identifiers, so persist the exact siteUrl used in the request. Do not print refresh tokens, client secrets, or application-default credentials in logs while diagnosing access.

A 403 may indicate missing property permission, an API or quota-project configuration issue, or a credential that belongs to another account. Prove access with the smallest read-only request and report the status without mutating Cloud projects or Search Console ownership unless separately authorized.

Google documents per-property quotas of 2,000 requests per day and 600 per minute. That is enough for a focused verification system, not an excuse to inspect every URL continuously. Sample the homepage, major hubs, newly published pages, recently changed templates, high-impression pages, and representatives of each page family.

Deduplicate requests by canonical URL and cache results with the retrieval timestamp. A release can inspect ten priority URLs after data has had time to update, while a scheduled monitor rotates through the broader set. Reserve quota for incident diagnosis rather than exhausting it on unchanged low-value routes.

A canonical mismatch means Google selected a different URL; compare redirects, canonical tags, internal links, sitemap entries, content similarity, and protocol or host variants. A robots block requires checking the production robots.txt that applied when Google crawled. A fetch issue should be compared with server logs and current availability without assuming a transient historical failure is still active.

Sitemap and referring URL fields are helpful but not guaranteed to be exhaustive. Enhancement results apply only when the markup and feature are supported. Preserve raw enums beside a normalized internal status so a future API value does not disappear into “unknown error.”

For each priority URL, record the canonical route, family, HTTP validation result, inspection retrieval time, last crawl time, verdict, coverage state, user canonical, Google canonical, robots state, and fetch state. Separate “not yet recrawled” from “recrawled with a defect.” That distinction prevents unnecessary rewrites while Google still holds the prior version.

Do not call the Indexing API for standard articles. Manual indexing requests in Search Console may be used sparingly where appropriate, but neither the interface nor API guarantees inclusion. The durable release gate remains under publisher control: complete public HTML, correct status, indexable directives, canonical consistency, internal links, sitemap presence, and useful content.