Indexing API getMetadata Explained

This guide is for site owners, developers and SEO leads who work with indexing api getmetadata and need a reliable routine without guesswork. Many teams hit the same wall: submissions return mixed status codes, logs are thin, and coverage reports move slowly while stakeholders ask for dates. The facts matter here. The Google Indexing API documents JobPosting and BroadcastEvent pages, and Google does not support IndexNow, so every workflow must respect those limits. You will learn exact checks, safe pacing, logging that proves what happened, and recovery steps that work under quota. Follow the sections in order, test with a handful of URLs first, then scale to hourly batches once responses stay clean.

Key takeaways

What getMetadata does and does not do starts with identity and access checks, not with faster retries.
Publish versus metadata endpoints compared works best with one test URL and full logs before bulk batches.
Daily quota and per minute throttling need different responses, track both in Cloud Console.
Deduplicate, filter noindex and non canonical URLs, then queue at a fixed pace with backoff.

What getMetadata does and does not do
Publish versus metadata endpoints compared
Reading latest update and notify time
Interpreting empty or missing metadata
Using indexing api getmetadata to audit bulk jobs
Metadata for URL_UPDATED versus URL_DELETED
Status codes around metadata calls
Code to fetch and store metadata
Building a dashboard from metadata
Limits and quota cost of metadata calls
A checklist for routine metadata checks
FAQ
Sources
Further reading

What getMetadata does and does not do

This section covers what getmetadata does and does not do in the context of indexing api getmetadata. The metadata endpoint returns the latest URL notification stored for a URL, not live index status. It tells you when your project last sent URL_UPDATED or URL_DELETED and what type was recorded. It does not tell you whether Google indexed the page, ranked it, or crawled it today. Use it to audit your own submission history and to confirm that publishes arrived. Pair it with Search Console coverage and server logs for the full picture of discovery and indexing. We keep the advice practical for owners without a large SEO team. Each step below uses plain checks you can run with Search Console, server logs and a small script. The goal is steady progress you can measure in coverage reports, not a one time spike. Keep notes on what you change and when, so you can link indexing movement to specific fixes.

Google discovers most pages through crawl, not through a single submission. A submission is a hint that asks for a fresh look, but ranking and storage still depend on quality, uniqueness and site trust. That is why steady technical hygiene matters more than any one push. Keep response times low, avoid redirect chains, and return clear status codes. When the crawler can fetch quickly and without loops, each hint carries more weight and uses less of your daily allowance.

Item	What to record	Where to check
Request	URL plus notification type	Worker log row
Auth	Key ID plus scope	IAM and code config
Response	Status plus Retry After	API response body
Follow up	Next retry time	Queue next run field

Search Console verification is the gate for any Google submission. The service account that calls the API must be added as an Owner on the exact property, including the correct scheme and subdomain. Domain properties and URL prefix properties behave differently, so match the property you verify with the URLs you submit. If you see permission denied or 403, check sharing settings first, then OAuth scope, then key expiry. Most auth failures trace to a missed sharing step, not to code.

A 429 means slow down, not try harder. Read the Retry After header when present, then wait with exponential backoff and jitter before retrying. A common pattern waits 2 seconds, then 4, then 8, then 16, with a small random addition to avoid synchronized retries. Cap retries at 4 or 5 and move the URL to a delayed queue after that. Hammering the endpoint during a limit only extends the block and burns log space.

In practice, create a short runbook for what getmetadata does and does not do and review it after each deploy. List who owns keys, who owns Search Console, where logs live, and what alert fires first. Test with five URLs before scaling to hourly batches. Record every response code and timestamp so patterns appear without guesswork. If errors rise, pause automation, fix the root cause, then resume at half pace. Steady, documented pacing restores submissions faster than rushing to catch up in one burst.

Publish versus metadata endpoints compared

This section covers publish versus metadata endpoints compared in the context of indexing api getmetadata. Publish sends a hint that content changed, while metadata reads back the stored hint for that URL. Publish affects quota more heavily and can trigger 429 during bursts, while metadata reads are lighter but still authenticated and counted. A healthy workflow publishes once per real change, then uses metadata sparingly for audits and debugging. Avoid polling metadata in tight loops. Cache results and sample rather than checking every URL every hour. We keep the advice practical for owners without a large SEO team. Each step below uses plain checks you can run with Search Console, server logs and a small script. The goal is steady progress you can measure in coverage reports, not a one time spike. Keep notes on what you change and when, so you can link indexing movement to specific fixes.

Crawl budget is often misunderstood. For small sites it rarely limits indexing, but for catalogs with 50,000 to 500,000 URLs it shapes what gets visited each day. Facets, session parameters, internal search results and duplicate variants can trap crawlers in low value loops. Use robots rules to block filtered views, use canonical tags to consolidate variants, and link best sellers from the home page and category hubs. Fewer dead ends means faster visits to new and updated pages.

Step 1: Confirm Cloud project ID, service account email, and active key ID in IAM.
Step 2: Confirm the Indexing API is enabled in the API library for that project.
Step 3: Confirm Search Console ownership on the exact property including scheme.
Step 4: Send one metadata read, then one publish for a test URL, and inspect both responses.
Step 5: Enable alerts at 60 and 85 percent of quota before resuming bulk work.

The Google Indexing API only documents JobPosting and BroadcastEvent pages, which covers job listings and livestream video. Many site owners still test it for product or article URLs, but that use is off label and results vary. Google may process the hint, ignore it, or throttle it. State this plainly to stakeholders. Use the API for eligible content first, and rely on sitemaps, internal links and IndexNow for broad coverage on other page types.

A 403 usually points to permissions or scope. Confirm the service account email has Owner access in Search Console, confirm the OAuth scope includes the indexing scope, and confirm the JSON key file matches the active key in Cloud Console. Check clock skew on the server, since JWT auth fails when time drifts by more than a few minutes. Rotate keys on a schedule, store them in a secret manager, and never paste private keys into chat tools or shared docs.

In practice, create a short runbook for publish versus metadata endpoints compared and review it after each deploy. List who owns keys, who owns Search Console, where logs live, and what alert fires first. Test with five URLs before scaling to hourly batches. Record every response code and timestamp so patterns appear without guesswork. If errors rise, pause automation, fix the root cause, then resume at half pace. Steady, documented pacing restores submissions faster than rushing to catch up in one burst.

For background on a related setup, see notification types URL_UPDATED vs URL_DELETED which explains how publishers structure notifications and sitemaps for time sensitive pages.

Diagram showing indexing api getmetadata flow with crawl, sitemap and queue steps

Reading latest update and notify time

This section covers reading latest update and notify time in the context of indexing api getmetadata. A typical metadata response includes the URL, the latest notification type, and timestamps for update and notification. Latest update reflects the event time you sent, while notify time reflects when Google recorded it. Small skew between them is normal. Large gaps or stale dates after fresh publishes suggest auth to the wrong project, wrong property, or a queue that never sent. Compare these times against your worker logs to confirm end to end delivery. We keep the advice practical for owners without a large SEO team. Each step below uses plain checks you can run with Search Console, server logs and a small script. The goal is steady progress you can measure in coverage reports, not a one time spike. Keep notes on what you change and when, so you can link indexing movement to specific fixes.

Compare notification history against worker logs and inspect the api metadata response for type and timestamps. Cache metadata json samples for a day and note skew between event time and record time. Small gaps are normal while large gaps point to wrong project or queue bugs.

Google does not support IndexNow, so plan for two ecosystems. IndexNow notifies Bing, Yandex, Naver, Seznam and other partners that share the protocol, while Google relies on sitemaps, Search Console inspection and the Indexing API for eligible types. A practical setup sends product updates to both paths at publish time. One worker prepares the URL list, then one branch pings IndexNow endpoints and another branch queues Google notifications within quota. Coverage improves without double counting.

JWT failures look cryptic but follow a pattern. Invalid signature often means the wrong key file or a corrupted newline in the private key. Invalid grant often means the service account is disabled or the project never enabled the API. Failed to parse often means the token was truncated in logs or copied with extra spaces. Keep token lifetimes short, request a fresh access token per batch, and log the key ID without logging the secret. Small hygiene steps remove most auth noise.

In practice, create a short runbook for reading latest update and notify time and review it after each deploy. List who owns keys, who owns Search Console, where logs live, and what alert fires first. Test with five URLs before scaling to hourly batches. Record every response code and timestamp so patterns appear without guesswork. If errors rise, pause automation, fix the root cause, then resume at half pace. Steady, documented pacing restores submissions faster than rushing to catch up in one burst.

For official details, see developers.google.com docs which documents the expected fields and behavior.

Interpreting empty or missing metadata

This section covers interpreting empty or missing metadata in the context of indexing api getmetadata. A 404 or empty result usually means no notification was ever stored for that URL under your project, not that the page is banned. Causes include never publishing, publishing under a different Cloud project, URL normalization mismatch with trailing slash or scheme, or deletion of history after long inactivity. Normalize URLs before lookup, confirm project and property, then publish once and recheck. Treat missing metadata as a workflow signal, not a quality verdict. We keep the advice practical for owners without a large SEO team. Each step below uses plain checks you can run with Search Console, server logs and a small script. The goal is steady progress you can measure in coverage reports, not a one time spike. Keep notes on what you change and when, so you can link indexing movement to specific fixes.

Quotas shape every automation decision. Many projects start with about 200 publish requests per day for URL notifications, plus per minute limits that trigger 429 when bursts arrive. Track usage in Cloud Console under APIs and Services, set alerts at 60 percent and 85 percent, and log each publish with timestamp, URL, response code and notification type. When you know your burn rate by hour, you can pace jobs, defer low priority URLs and avoid midnight surprises.

Item	What to record	Where to check
Request	URL plus notification type	Worker log row
Auth	Key ID plus scope	IAM and code config
Response	Status plus Retry After	API response body
Follow up	Next retry time	Queue next run field

Logging turns guesses into fixes. For each submission store the URL, notification type, HTTP status, response body snippet, latency and a correlation ID. Keep success and error logs separate so you can scan error rates by hour. Export daily counts to a sheet or dashboard that shows submits, 200 responses, 403 responses, 429 responses and remaining quota. When stakeholders ask why a product is not visible, you can point to exact evidence instead of general theories.

In practice, create a short runbook for interpreting empty or missing metadata and review it after each deploy. List who owns keys, who owns Search Console, where logs live, and what alert fires first. Test with five URLs before scaling to hourly batches. Record every response code and timestamp so patterns appear without guesswork. If errors rise, pause automation, fix the root cause, then resume at half pace. Steady, documented pacing restores submissions faster than rushing to catch up in one burst.

To compare paths side by side, read complete setup guide before you commit quota to one route.

Using indexing api getmetadata to audit bulk jobs

This section covers using metadata to audit bulk jobs in the context of indexing api getmetadata. After imports or migrations, sample metadata across priorities to verify what the queue actually sent. Pull ten URLs per batch: new pages, updated pages, and deleted pages. Confirm type matches intent and timestamps fall inside the job window. Mismatches reveal mapping bugs where updates were sent as deletes or staging URLs leaked into production. Audits of this size cost little quota and catch errors before coverage reports turn confusing. We keep the advice practical for owners without a large SEO team. Each step below uses plain checks you can run with Search Console, server logs and a small script. The goal is steady progress you can measure in coverage reports, not a one time spike. Keep notes on what you change and when, so you can link indexing movement to specific fixes.

Sample urlnotifications metadata across priorities and check url notification entries for correct type and window. These indexing api insights catch mapping bugs where staging URLs leaked into production. Keep audits to ten URLs per batch to save quota while staying confident.

Step 1: Export the full URL list from your CMS or commerce platform with last change dates.
Step 2: Join with Search Console coverage to flag Discovered, Crawled, Excluded and Indexed states.
Step 3: Remove duplicates, 404s, noindex pages and non canonical variants from the submit set.
Step 4: Sort by priority such as new, price change, availability change, then evergreen refresh.
Step 5: Queue at a paced rate, log every response, and pause on repeated 429 or 403.

Internal linking does more for indexing than most teams expect. New URLs that sit four clicks from the home page may wait days for a visit, while URLs linked from a popular category or a recent posts block get visited quickly. Add new products to relevant category pages, link related items, and keep pagination crawlable with plain anchors. Avoid loading key links only through scripts that require clicks. Simple, stable links help both Google and IndexNow driven crawlers find changes fast.

In practice, create a short runbook for using metadata to audit bulk jobs and review it after each deploy. List who owns keys, who owns Search Console, where logs live, and what alert fires first. Test with five URLs before scaling to hourly batches. Record every response code and timestamp so patterns appear without guesswork. If errors rise, pause automation, fix the root cause, then resume at half pace. Steady, documented pacing restores submissions faster than rushing to catch up in one burst.

curl -s -H "Authorization: Bearer TOKEN" "https://indexing.googleapis.com/v3/urlNotifications/metadata?url=https://example.com/jobs/123" | python3 -m json.tool

Metadata for URL_UPDATED versus URL_DELETED

This section covers metadata for url_updated versus url_deleted in the context of indexing api getmetadata. The stored type should match the real world state. Send URL_UPDATED when eligible content is created or meaningfully changed, and URL_DELETED only when the URL is gone or permanently removed. Sending deleted for a live page creates confusing history and can mislead later debugging. When a removed page returns, send an updated notification after it serves 200 again. Keep a state table in your worker so type selection is automatic rather than manual. We keep the advice practical for owners without a large SEO team. Each step below uses plain checks you can run with Search Console, server logs and a small script. The goal is steady progress you can measure in coverage reports, not a one time spike. Keep notes on what you change and when, so you can link indexing movement to specific fixes.

Canonical tags decide which URL keeps the indexing credit. If variants with color, size or tracking parameters lack a canonical, Google may pick a different URL or delay indexing while it compares duplicates. Point each variant to the preferred canonical, keep the canonical self referencing on the main URL, and make sure sitemaps list only canonicals. For translated or regional pages, add hreflang and keep each locale self consistent. Clean signals shorten the decision time.

In practice, create a short runbook for metadata for url_updated versus url_deleted and review it after each deploy. List who owns keys, who owns Search Console, where logs live, and what alert fires first. Test with five URLs before scaling to hourly batches. Record every response code and timestamp so patterns appear without guesswork. If errors rise, pause automation, fix the root cause, then resume at half pace. Steady, documented pacing restores submissions faster than rushing to catch up in one burst.

Workflow showing indexing api getmetadata handling with paced queue and logging

Status codes around metadata calls

This section covers status codes around metadata calls in the context of indexing api getmetadata. Metadata reads return 200 with a body when history exists, 403 when the caller lacks property access, 401 or token errors for auth problems, 404 when no history exists, and 429 when paced too fast. Map each code to a distinct action: fix ownership for 403, fix signing for 401, publish once for 404, and slow down for 429. Logging code plus URL plus key ID makes weekly triage fast. Consistent mapping prevents treating an empty history like a permission failure. We keep the advice practical for owners without a large SEO team. Each step below uses plain checks you can run with Search Console, server logs and a small script. The goal is steady progress you can measure in coverage reports, not a one time spike. Keep notes on what you change and when, so you can link indexing movement to specific fixes.

Item	What to record	Where to check
Request	URL plus notification type	Worker log row
Auth	Key ID plus scope	IAM and code config
Response	Status plus Retry After	API response body
Follow up	Next retry time	Queue next run field

Robots directives and meta tags can silently block indexing. A stray noindex in a template, an X-Robots-Tag header from a staging config, or a disallow in robots that covers new paths will keep pages out even after successful submission. Audit headers with a fetch tool, render pages as Googlebot, and check the coverage report for Excluded by noindex or Blocked by robots. Fix the template once rather than patching URLs one by one.

In practice, create a short runbook for status codes around metadata calls and review it after each deploy. List who owns keys, who owns Search Console, where logs live, and what alert fires first. Test with five URLs before scaling to hourly batches. Record every response code and timestamp so patterns appear without guesswork. If errors rise, pause automation, fix the root cause, then resume at half pace. Steady, documented pacing restores submissions faster than rushing to catch up in one burst.

When errors persist, review testing with cURL and Postman to isolate auth, access and pacing causes with logs.

Code to fetch and store metadata

This section covers code to fetch and store metadata in the context of indexing api getmetadata. A small helper keeps metadata checks consistent across languages. It builds an authenticated GET to the metadata endpoint with the URL as a query parameter, parses JSON for type and timestamps, and writes a row to an audit table. Cache responses for a day, retry 500 with backoff, and never retry 404 in a loop. Below is a compact Python pattern that follows this shape without exposing secrets. Adapt the HTTP layer to Node or PHP while keeping the same fields and pacing. We keep the advice practical for owners without a large SEO team. Each step below uses plain checks you can run with Search Console, server logs and a small script. The goal is steady progress you can measure in coverage reports, not a one time spike. Keep notes on what you change and when, so you can link indexing movement to specific fixes.

Thin or duplicated content slows indexing because Google prioritizes pages likely to satisfy searchers. Short product descriptions copied from suppliers, empty category pages and near duplicate articles often sit in Discovered or Crawled without indexing. Add specific details such as dimensions, materials, compatibility, usage steps and original photos. Consolidate near duplicates into one strong page with redirects. Better content earns more frequent revisits and steadier indexing.

Step 1: Confirm Cloud project ID, service account email, and active key ID in IAM.
Step 2: Confirm the Indexing API is enabled in the API library for that project.
Step 3: Confirm Search Console ownership on the exact property including scheme.
Step 4: Send one metadata read, then one publish for a test URL, and inspect both responses.
Step 5: Enable alerts at 60 and 85 percent of quota before resuming bulk work.

In practice, create a short runbook for code to fetch and store metadata and review it after each deploy. List who owns keys, who owns Search Console, where logs live, and what alert fires first. Test with five URLs before scaling to hourly batches. Record every response code and timestamp so patterns appear without guesswork. If errors rise, pause automation, fix the root cause, then resume at half pace. Steady, documented pacing restores submissions faster than rushing to catch up in one burst.

curl -s -H "Authorization: Bearer TOKEN" "https://indexing.googleapis.com/v3/urlNotifications/metadata?url=https://example.com/jobs/123" | python3 -m json.tool

Building a dashboard from metadata

This section covers building a dashboard from metadata in the context of indexing api getmetadata. A useful dashboard joins worker publish logs with periodic metadata samples. Show publishes per hour, metadata match rate, stale entries older than seven days, type breakdown, and error counts by code. Highlight URLs where publish says sent but metadata shows missing, since those point to project or normalization bugs. Refresh metadata samples daily, not every minute. This view helps owners answer whether automation is sending correctly without drowning in raw lines. We keep the advice practical for owners without a large SEO team. Each step below uses plain checks you can run with Search Console, server logs and a small script. The goal is steady progress you can measure in coverage reports, not a one time spike. Keep notes on what you change and when, so you can link indexing movement to specific fixes.

Join an indexing api status check feed with publish logs to show match rate, stale entries and error counts. Track google notification status side by side with a url status api style table for fast triage. These indexing diagnostics views answer whether automation is sending correctly without reading raw lines.

Sitemaps remain the backbone of discovery. A clean product or article sitemap lists only canonical, indexable URLs that return 200 and load quickly. Split large catalogs into chunks of 10,000 to 40,000 URLs, compress with gzip, and reference each chunk from a sitemap index. Update the lastmod field only when content truly changes. Submit the index in Search Console and keep it reachable. A tidy sitemap reduces wasted fetches and leaves room for priority pages.

In practice, create a short runbook for building a dashboard from metadata and review it after each deploy. List who owns keys, who owns Search Console, where logs live, and what alert fires first. Test with five URLs before scaling to hourly batches. Record every response code and timestamp so patterns appear without guesswork. If errors rise, pause automation, fix the root cause, then resume at half pace. Steady, documented pacing restores submissions faster than rushing to catch up in one burst.

For HTTP semantics, see status code reference which defines how clients should handle each response.

Limits and quota cost of metadata calls

This section covers limits and quota cost of metadata calls in the context of indexing api getmetadata. Metadata reads consume quota and count toward API usage, so sample rather than scan full catalogs. Cache results, deduplicate URLs before lookup, and schedule audits outside bulk publish windows. Track spend in Cloud Console by method to see publish versus metadata cost separately. Set a daily cap for audit reads in your worker config. Disciplined sampling gives the same confidence as full scans at a fraction of the cost and with fewer 429 events. We keep the advice practical for owners without a large SEO team. Each step below uses plain checks you can run with Search Console, server logs and a small script. The goal is steady progress you can measure in coverage reports, not a one time spike. Keep notes on what you change and when, so you can link indexing movement to specific fixes.

Item	What to record	Where to check
Request	URL plus notification type	Worker log row
Auth	Key ID plus scope	IAM and code config
Response	Status plus Retry After	API response body
Follow up	Next retry time	Queue next run field

In practice, create a short runbook for limits and quota cost of metadata calls and review it after each deploy. List who owns keys, who owns Search Console, where logs live, and what alert fires first. Test with five URLs before scaling to hourly batches. Record every response code and timestamp so patterns appear without guesswork. If errors rise, pause automation, fix the root cause, then resume at half pace. Steady, documented pacing restores submissions faster than rushing to catch up in one burst.

A checklist for routine metadata checks

This section covers a checklist for routine metadata checks in the context of indexing api getmetadata. Run a short routine weekly: sample ten URLs per priority, confirm type and timestamps, investigate missing entries for normalization or project mismatch, review 403 and 401 counts, and record match rate in a sheet. After migrations, run the same check daily for a week. Assign one owner for audit reads and one for publish pacing so sampling never competes with sending. Regular, small checks keep history trustworthy all year. We keep the advice practical for owners without a large SEO team. Each step below uses plain checks you can run with Search Console, server logs and a small script. The goal is steady progress you can measure in coverage reports, not a one time spike. Keep notes on what you change and when, so you can link indexing movement to specific fixes.

Step 1: Export the full URL list from your CMS or commerce platform with last change dates.
Step 2: Join with Search Console coverage to flag Discovered, Crawled, Excluded and Indexed states.
Step 3: Remove duplicates, 404s, noindex pages and non canonical variants from the submit set.
Step 4: Sort by priority such as new, price change, availability change, then evergreen refresh.
Step 5: Queue at a paced rate, log every response, and pause on repeated 429 or 403.

In practice, create a short runbook for a checklist for routine metadata checks and review it after each deploy. List who owns keys, who owns Search Console, where logs live, and what alert fires first. Test with five URLs before scaling to hourly batches. Record every response code and timestamp so patterns appear without guesswork. If errors rise, pause automation, fix the root cause, then resume at half pace. Steady, documented pacing restores submissions faster than rushing to catch up in one burst.

FAQ

Does urlnotifications metadata show index status?

No. urlnotifications metadata shows the latest notification your project stored for a URL, with type and timestamps, not live index status. Use an indexing api status check in Search Console coverage plus server logs to assess crawl and index state. The api metadata response tells you when your project last sent URL_UPDATED or URL_DELETED and what was recorded. Pair it with coverage reports for discovery truth. Cache samples daily and record match rates so audits start from evidence rather than guesses.

Why is notification history missing for a published URL?

Missing notification history usually means no publish was stored under your project, not that the page is banned. Causes include different Cloud project, URL normalization mismatch with scheme or trailing slash, or long inactivity. To check url notification state, normalize URLs before lookup, confirm project and property, publish once and recheck via metadata json output. Treat gaps as workflow signals. Log project, URL form and key ID so the next audit traces quickly to mapping or queue bugs. Revalidate property ownership after domain moves.

Should I poll metadata often for indexing api insights?

No. Frequent polling wastes quota and risks 429, so sample for indexing api insights instead. Cache the api metadata response for a day and audit ten URLs per priority weekly, daily after migrations. This indexing diagnostics discipline gives the same confidence as full scans at lower cost. Track publish versus metadata spend in Cloud Console, cap audit reads daily and schedule checks outside bulk windows. Record stale entries older than seven days for focused follow up and steady weekly reporting.

What type should I send for removed pages and google notification status?

Send URL_DELETED only when the URL is gone, and send URL_UPDATED after it returns with 200 content. Correct google notification status depends on matching stored type to real world state. Keep worker state so type selection is automatic. To check url notification history after changes, sample metadata and confirm timestamps fall inside the job window. Mismatches reveal mapping bugs where updates were sent as deletes. Document type rules in your queue config to prevent repeat confusion and speed up future debugging.

How do metadata errors map to fixes with url status api?

Use a url status api style map for triage. Return 403 means fix ownership, 401 means fix signing, 404 means publish once for missing history, 429 means slow down and 500 means retry with backoff. Log code plus URL plus key ID for fast weekly review. This indexing diagnostics table prevents treating empty history like permission failure. Confirm scope strings, property access and pacing rules in order. Consistent mapping keeps audits calm and short even during large migrations and busy launch weeks.

Do metadata calls use quota like indexing api status check?

Yes. Every indexing api status check via getMetadata consumes quota and counts toward API usage, so sample rather than scan full catalogs. Deduplicate URLs before lookup, cache metadata json results and schedule audits outside bulk publish windows. Monitor spend by method in Cloud Console to see publish versus metadata cost separately. Set a daily cap for audit reads in worker config. Disciplined sampling delivers reliable indexing diagnostics with fewer 429 events and lower spend across large sites. Review caps every week carefully.

Sources

https://developers.google.com/search/apis/indexing-api/v3/get-notification
https://schema.org/JobPosting
https://developers.google.com/search/apis/indexing-api/v3/quickstart

Indexing API Metadata: What getMetadata() Actually Tells You