canonical: https://jentic.com/apis/googleapis.com/indexing

# Google Web Search Indexing API

The Web Search Indexing API lets site owners notify Google Search when pages are added, updated, or removed so the index can be refreshed faster than crawl-based discovery. It is intended for time-sensitive page types such as job postings and live broadcast events. The API exposes two operations on URL notifications: publishing an update or removal event, and reading the metadata for the most recent notification on a URL.

## For AI agents

Notify Google Search to crawl new or updated URLs and read the latest notification metadata. Useful for keeping job postings and live event pages current in search results.

## Scope

Does not handle sitemap submission, search analytics, or arbitrary page types - use only to push URL_UPDATED and URL_DELETED notifications for JobPosting and BroadcastEvent pages.

## Capabilities

- Push URL_UPDATED notifications when a job posting or BroadcastEvent page is created
- Push URL_DELETED notifications when a job posting or BroadcastEvent page is taken down
- Retrieve the timestamp and type of the last notification submitted for a given URL
- Trigger faster recrawls of supported page types without waiting for organic discovery
- Track which URLs have already been submitted to avoid duplicate publish calls

## Use cases

### Time-sensitive job posting indexing

Career sites and job boards can call the Indexing API every time a posting is created, updated, or closed so Google Search reflects the change within hours rather than waiting for the next crawl. Each change is published with a URL_UPDATED or URL_DELETED notification on the urlNotifications:publish endpoint, which keeps Google's job posting structured data current.

Example prompt: Submit a URL_UPDATED notification for https://example.com/jobs/123 and confirm the response includes the new notifyTime.

### Live broadcast event publication

Streaming platforms publishing pages with BroadcastEvent structured data use the Indexing API to inform Google when a live event page goes up and when it ends. Publishing a notification on the v3/urlNotifications:publish endpoint reduces the lag between event start and search visibility, which matters for short-window content.

Example prompt: Publish a URL_UPDATED notification for a livestream page and verify the urlNotificationMetadata returns latestUpdate.type=URL_UPDATED.

### Indexing audit and resubmission

SEO teams use GET /v3/urlNotifications/metadata to verify whether a URL was successfully submitted, when, and with what notification type. This supports audits of indexing pipelines and lets agents detect URLs that need to be republished after a content change.

Example prompt: Call GET /v3/urlNotifications/metadata?url=https://example.com/jobs/123 and report latestUpdate.type and notifyTime.

### Agent-driven indexing automation via Jentic

An agent listening to a job posting database can call the Indexing API through Jentic whenever a row changes. Jentic handles the OAuth 2.0 service account flow and exposes the publish operation as a single MCP tool, so the agent only needs to pass the URL and notification type.

Example prompt: From a webhook indicating a new job, call google_indexing_publish_url with type=URL_UPDATED for the new posting URL.

## Key endpoints

| Method | Path | Description |
| --- | --- | --- |
| POST | /v3/urlNotifications:publish | Publish an update or removal notification for a URL |
| GET | /v3/urlNotifications/metadata | Retrieve metadata for the latest notification on a URL |

## Key resources

- **urlNotifications** — Publish URL_UPDATED and URL_DELETED events and retrieve the latest notification metadata for a URL

## Why Jentic

- **Setup:** Wiring the Web Search Indexing API by hand means configuring service-account OAuth2, narrowing to the indexing scope, refreshing tokens, and building its urlNotifications payloads yourself. Through Jentic you install once, import the Web Search Indexing API from the API Directory, store the credential once, and your agent calls it.
- **Permission scoping:** The indexing API carries the target URL in the request body rather than a resource in the URL path, so scope the agent to the operations it needs, such as publishing a URL_UPDATED notification or reading notification metadata. You choose the allowed set, so if you grant only the metadata read the agent can check status without ever publishing changes.
- **Credential handling:** Your Indexing service-account credential is stored once, encrypted, by your own Jentic One instance and injected at execution time as a short-lived access token scoped to indexing. The private key never enters the agent's prompt, logs, or context.
- **Discovery method:** Agents search Jentic by intent such as 'notify google of a url change' or 'check url notification status', and Jentic returns the matching urlNotifications operation with its input schema so the agent builds the request without browsing Google's docs.

## Related APIs

- **Google Search Console API** — Search Console reports on impressions, clicks, and indexing status; Indexing API pushes change notifications
- **Custom Search API** — Custom Search returns programmable search results; Indexing API controls when pages enter the Google index
- **Cloud Talent Solution API** — Cloud Talent Solution stores and searches job postings; Indexing API tells Google Search the postings exist

## FAQ

### What authentication does the Web Search Indexing API use?

The API uses OAuth 2.0 with the https://www.googleapis.com/auth/indexing scope, typically issued to a Google service account that has been granted Owner permission for the property in Search Console. Through Jentic the OAuth credentials live in the encrypted vault and the agent receives a scoped access token at call time only.

### Which page types are supported by the Web Search Indexing API?

Google currently supports the API for pages with JobPosting structured data and pages with BroadcastEvent embedded in a VideoObject. Submitting other page types is allowed but will not trigger faster crawling, and Google may ignore those notifications.

### What are the rate limits for the Web Search Indexing API?

Google enforces a default daily quota of 200 publish requests and 180 metadata requests per project, with a burst limit of around 600 requests per minute. Quota increases can be requested via the Google Cloud console for high-volume careers sites.

### How do I submit a URL update through Jentic?

Run jentic search 'notify google to recrawl a url' to find the publish operation, jentic load to fetch its input schema, then jentic execute with body {"url": "https://example.com/jobs/123", "type": "URL_UPDATED"} which calls POST /v3/urlNotifications:publish.

### Can I check whether a URL was already submitted?

Yes. Call GET /v3/urlNotifications/metadata with the url query parameter and the response includes latestUpdate and latestRemove timestamps, so an agent can decide whether to resubmit.

### Is the Web Search Indexing API free to use?

The API itself has no per-call charge - costs are governed only by the Google Cloud project quotas. The service account and Search Console verification are also free.

### Can I limit what my agent is allowed to do with the Web Search Indexing API?

Yes. Because you run Jentic One yourself, your own rules decide which Indexing API operations the agent may call and which credentials it may use. This API only exposes two operations: publishing a URL_UPDATED or URL_DELETED notification and reading the latest notification metadata, so you can grant just the metadata read and the agent can check submission status without ever publishing changes. Since the target URL travels in the request body rather than the path, you scope the agent to the operations it needs and it never gets access beyond the set you allow.