## TL;DR

The Search Console API exposes URL inspection, so a publishing pipeline can request indexing right after publish instead of waiting for a human to click through the console. You need a Google Cloud project with the API enabled, OAuth credentials for the property owner, and the inspect endpoint. It is the programmatic version of the manual "request indexing" button, with the same daily quota.

```text
submitting URLs to Google Search Console via API
```

## Use this when

- A content pipeline publishes pages and should request indexing automatically
- You are tired of pasting URLs into the Search Console UI one by one
- You want to check index status of many URLs programmatically
- You need to wire indexing requests into a cron or publish hook

## Not for this skill when

- You need search performance data (queries, clicks, impressions use a different endpoint)
- You only publish occasionally (the manual button is fine)
- You need Bing indexing (Bing has its own Webmaster API and IndexNow)

## Steps

1. Enable the API in Google Cloud. Create or pick a project, enable the Google Search Console API, and create OAuth 2.0 credentials. Expected: the API shows as enabled in the Cloud console.

```
Cloud Console -> APIs and Services -> Enable APIs -> search
"Google Search Console API" -> Enable.
```

2. Authenticate as the property owner. The OAuth flow must use an account with owner or full-user rights on the Search Console property. Expected: tokens that can call the API on behalf of that property.

```
OAuth scopes needed: the Search Console scope.
Store refresh tokens server-side; never in the page or repo.
```

3. Call the URL inspection endpoint. POST the full URL with the site URL of the property. Expected: a response with index status, crawl time, and any issues.

```
POST urlInspection/index/inspect
Body: inspectionUrl set to the page URL, siteUrl set to the property.
Response includes indexStatusResult with verdict and coverageState.
```

4. Request indexing for new pages. After a publish event, call the inspect endpoint with the request-indexing flag for the new URL. Expected: the URL enters Google's crawl queue like a manual request.

```
After publish: call inspect with indexing request for the new URL.
Same daily quota as the manual button, so batch wisely.
```

5. Log the verdicts. Record each URL's coverage state in your publishing log. Expected: you can spot patterns like soft-404s or crawl anomalies across the pipeline.

```
Log columns: url, verdict, coverage state, checked at.
Alert on repeated verdicts like "Crawled - currently not indexed".
```

## Variant phrasings

### GSC API request indexing automatically

Wire step 4 into your publish hook; the pipeline requests indexing the moment a page goes live.

### Check if a URL is indexed via API

Step 3's verdict field answers that directly, at scale.

### Search Console API authentication for agents

OAuth as the property owner is the only supported path; there is no key-only shortcut for inspection calls.

## Why it happens

The manual request-indexing button doesnt scale past a handful of pages a day, and agents publish programmatically, so the pipeline needs the same capability as a function call. Google exposes inspection through the API precisely so CMS platforms and tools can integrate it, with quotas that match the manual flow to prevent abuse.

## Edge cases / pitfalls

- The quota is shared with manual requests; a busy pipeline can exhaust it by noon.
- OAuth tokens expire; build refresh handling or the nightly run starts failing silently.
- The property in siteUrl must match exactly (https vs http, www vs bare); mismatches return permission errors.
- Verdicts lag reality by hours; dont poll the same URL in a tight loop.
- A 200 response with a bad verdict is still a successful API call; check the verdict, not just the status code.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_P5eTVbRSqR5RFPbE6hTC4A
